Skip to main content

Support of fragmentation of RADIUS packets
draft-perez-radext-radius-fragmentation-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Alejandro Pérez-Méndez , Rafael Marin-Lopez , Fernando Pereniguez-Garcia , Gabriel Lopez-Millan , Diego R. Lopez , Alan DeKok
Last updated 2013-02-08
Replaced by draft-ietf-radext-radius-fragmentation, RFC 7499
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-perez-radext-radius-fragmentation-05
RADIUS EXTensions Working Group                          A. Perez-Mendez
Internet-Draft                                            R. Marin-Lopez
Intended status: Experimental                       F. Pereniguez-Garcia
Expires: August 5, 2013                                  G. Lopez-Millan
                                                    University of Murcia
                                                                D. Lopez
                                                          Telefonica I+D
                                                                A. DeKok
                                                          Network RADIUS
                                                                Feb 2013

               Support of fragmentation of RADIUS packets
               draft-perez-radext-radius-fragmentation-05

Abstract

   This document describes a mechanism providing fragmentation support
   of RADIUS packets that exceed the 4096 bytes limit.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 5, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Perez-Mendez, et al.     Expires August 5, 2013                 [Page 1]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Fragmentation of packets . . . . . . . . . . . . . . . . . . .  5
     3.1.  Access-Request . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Access-Accept  . . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Combined use of both fragmented packets  . . . . . . . . . 12
     3.4.  Unsupported packet types . . . . . . . . . . . . . . . . . 15
       3.4.1.  Accounting . . . . . . . . . . . . . . . . . . . . . . 15
       3.4.2.  CoA  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.  Allowed large packet size  . . . . . . . . . . . . . . . . . . 16
   6.  Handling special attributes  . . . . . . . . . . . . . . . . . 17
     6.1.  Proxy-State attribute  . . . . . . . . . . . . . . . . . . 17
     6.2.  State attribute  . . . . . . . . . . . . . . . . . . . . . 18
     6.3.  Service-Type attribute . . . . . . . . . . . . . . . . . . 18
     6.4.  Rebuilding the original large packet . . . . . . . . . . . 19
   7.  New attribute definition . . . . . . . . . . . . . . . . . . . 19
     7.1.  Frag-Status attribute  . . . . . . . . . . . . . . . . . . 19
     7.2.  Proxy-State-Len attribute  . . . . . . . . . . . . . . . . 20
     7.3.  Table of attributes  . . . . . . . . . . . . . . . . . . . 21
   8.  Operation with proxies . . . . . . . . . . . . . . . . . . . . 22
     8.1.  Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 22
     8.2.  Updated proxies  . . . . . . . . . . . . . . . . . . . . . 22
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26

Perez-Mendez, et al.     Expires August 5, 2013                 [Page 2]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

1.  Introduction

   RADIUS [RFC2865] is a protocol for carrying authentication,
   authorization, and configuration information between a Network Access
   Server (NAS) which desires to authenticate its links and a shared
   Authentication Server (AS).  Information is exchanged between the NAS
   and the AS through RADIUS packets.  Each RADIUS packet can transport
   several RADIUS attributes, to convey the necessary information to the
   other peer, up to a maximum size of 4096 bytes of total data
   (including RADIUS packet headers).  RADIUS attributes have a maximum
   payload size of 253 bytes.

   RADIUS has been extensively used for the years.  Along this time, the
   need of sending RADIUS attributes larger than 253 bytes has become a
   reality.  An immediate alternative to overcome this issue consists in
   truncating the data into a group of RADIUS attributes of the same
   type, and then insert them ordered into the RADIUS packet.  At the
   destination, the content of these attributes is extracted and joined
   to rebuild the original data.  This scheme is followed, for example,
   by RADIUS-EAP [RFC3579].  A more advanced solution is given in
   [I-D.ietf-radext-radius-extensions], where extended attributes can be
   marked with a flag to indicate fragmentation.  A reference-based
   mechanism, where the value of the attributes can be obtained by other
   protocol instead of RADIUS, is also proposed in [RFC6158].

   However, there are no proposals to fragment a large-sized RADIUS
   packet into multiple small-sized RADIUS packets, where the length of
   the original (unfragmented) RADIUS packet exceeds the 4096-octet
   limit imposed by the RADIUS specification.  When RADIUS is considered
   in more complex AAA scenarios, including the exchange of bigger
   amount of data, like SAML assertions or JSON Web tokens, exceeding
   this limit becomes more likely, thus making necessary the
   availability of mechanisms for dealing with this situation.

   This document defines a mechanism to allow RADIUS peers to exchange
   packets exceeding the 4096 bytes limit, by fragmenting them across
   several exchanges.  This proposal tries to maintain compatibility
   with intra-packet fragmentation mechanisms (like those defined in
   [RFC3579] or in [I-D.ietf-radext-radius-extensions]) and with the
   existing RADIUS deployments.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Perez-Mendez, et al.     Expires August 5, 2013                 [Page 3]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

2.  Overview

   When a RADIUS client or server need to send a packet that exceeds the
   4096 bytes limit, the mechanism proposed in this document is used.
   First, the large packet is truncated into several smaller RADIUS
   packets (i.e. chunks) of the same type (i.e.  Access-Request or
   Access-Accept).  Each small RADIUS packet is so-called "chunk" in
   this specification.  The first chunk contains "n" RADIUS attributes
   of the original packet, where the order of the attributes of the same
   type is respected, until a limit below 4096 bytes.  The actual amount
   of data from the original packet included into each chunk will depend
   on the specific length of the attributes, the amount of proxies
   between both ends, and the number of signalling attributes (more
   details in Section 4).  Signalling to indicate whether there are
   fragmented data to be sent is performed by means of a new attribute
   called Frag-Status.  Section 7.1 defines this attribute and its
   possible values.

   The first chunk is sent to the other party, which identifies the
   packet as a chunk (based on the information contained in the Frag-
   Status attribute), and requests for the next chunk.  The RADIUS State
   attribute and the RADIUS Identifier field are used to tie the
   conversation together.

   This process is repeated until all the RADIUS attributes from the
   original packet have been sent by means of several chunks.  Once all
   the chunks have been received by the peer, the original packet is
   reconstructed and processed as if received in one piece.

   When a packet is truncated into chunks, a special situation may occur
   when it is combined with Extended Type attributes as defined in
   [I-D.ietf-radext-radius-extensions].  If the truncation splits an
   existing fragmented attribute along two or more chunks, the last
   fragment of that attribute for the first chunk will have the flag M
   enabled (indicating the attribute is not completed).  This situation
   is specifically forbidden in [I-D.ietf-radext-radius-extensions].  To
   indicate that this situation is provoked by a truncation and hence
   MUST be allowed, a new flag "T" (indicating truncation) MUST be set
   into that Extended-Type-Flag attribute.  The combination of the flags
   "M" and "T" indicates that the attribute is fragmented (flag M), but
   that all the fragments are not available in this chunk (flag T).

   Indeed, this last situation will be the most usual.  Typically,
   packet fragmentation will occur as a consequence of including one or
   more large (and fragmented) attributes into a RADIUS packet.  Hence,
   the truncation will probably split the large attribute into two (or
   more) pieces.  The rest of possibilities, where the truncation point
   does not split a fragmented attribute, do not require any special

Perez-Mendez, et al.     Expires August 5, 2013                 [Page 4]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

   treatment.

   The packet fragmentation mechanism described in this draft can only
   be used once the authentication process has been completed.  The
   reason behind this decision is based on security.  If unauthenticated
   clients were permitted to ask the server to store bulk data, then a
   Denial of Service (DoS) attack becomes possible.  An attacker could
   initiate a large number of connections, each of which requests the
   server to store a large amount of data.  This data could cause memory
   exhaustion on the server, and result in authentic users being denied
   access.  It is worth noting that authentication mechanisms are
   already designed to avoid exceeding the 4096 bytes limit.

3.  Fragmentation of packets

   When the NAS or the AS desires to send a RADIUS packet that exceeds
   the 4096 bytes limit, the packet can be split into smaller packets
   (chunks) and sent over different exchanges.  This fact is indicated
   by including a Frag-Status = More-Data-Pending (except the last one
   of the series).  All the packets belonging to the same fragmentation
   exchange are tied together by making use of the standard RADIUS
   mechanisms, that is, by using the Identifier field of the RADIUS
   packet by the Client and by using the RADIUS State attribute by the
   Server.

   The following sections describe how to perform fragmentation for each
   RADIUS packet type.  In order to make these examples simpler, it is
   assumed that each RADIUS packet can include up to 8 RADIUS
   attributes, instead of using bytes.  The used notation is the
   following:

      Packet-Type(Identifier){attributes}

   where Packet-Type can be Access-Request, Access-Challenge, Access-
   Accept or Access-Reject, and Identifier is the value of the
   Identifier field of the RADIUS packet header.

   Each attribute is denoted by Attr[Flags], where Attr is the name of
   the attribute type, and flags represents the active flags as
   described in [I-D.ietf-radext-radius-extensions].  Frag-Status(X)
   indicates a Frag-Status attribute with value X, where X can be FS for
   Fragmentation-Supported, AA for Additional-Authorization, MDP for
   More-Data-Pending and MDR for More-Data-Request.  Service-Type(X)
   indicates a Service-Type attribute with value X, where AA indicates
   the value Additional-Authorization.

Perez-Mendez, et al.     Expires August 5, 2013                 [Page 5]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

3.1.  Access-Request

   When the client needs to send a large amount of data to the server,
   it MUST signal this by including a Frag-Status = Additional-
   Authorization in the initial Access-Request.  This packet will likely
   be small (e.g. contain EAP-Identity), and there will be room for the
   attribute.  The client MUST NOT send the Frag-Status attribute in
   later packets (e.g. responses to any Access-Challenge) until an
   Access-Accept packet is received.  It has already signalled that
   there is data to be sent, and there is no need to do so again.

   Servers implementing this specification MUST flag the session as
   requiring more data.  They MAY respond with Access-Challenge, where
   the authentication method requires that.  When the authentication is
   complete, either an Access-Reject or Access-Accept is returned.  If
   the client has signalled that there is more data pending for this
   session, the server MUST respond with Service-Type = Additional-
   Authorization in any Access-Accept.  The client is then expected to
   initiate the fragmentation procedure as defined here.

   If a client sends the Frag-Status = Additional-Authorization
   attribute, and receives an Access-Accept without Service-Type =
   Additional-Authorization, or with any other value for Service-Type,
   it will know the server does not implement this specification and
   will not allow the exchange of fragmented packets.  Hence, it MAY
   behave as if it had received Access-Reject instead and close the
   authentication.

   If the server supports fragmentation, the data to be sent is then
   split into smaller packets (chunks) and sent over different exchanges
   to the server.  This fact is indicated by including a Frag-Status =
   More-Data-Pending attribute on each chunk (except the last one of the
   series).  All the packets belonging to the same fragmentation
   exchange are tied together by making use of the standard RADIUS
   mechanisms, that is, by using the Identifier field of the RADIUS
   packet by the Client and by using the RADIUS State attribute by the
   Server.

   o  In this example, the client (NAS) is trying to send a large
      Access-Request packet to the server (AS).  Attributes "Attr1" and
      "Attr2" are Extended-Type-Flags attributes, as defined in
      [I-D.ietf-radext-radius-extensions].  Attr1 is composed by 9
      fragments, while Attr2 is composed by 3 of them.

         Access-Request() {User-Name, Calling-Station-Id, Attr1[M],
         Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M],
         Attr1[M], Attr1, Attr2[M], Attr2[M], Attr2}

Perez-Mendez, et al.     Expires August 5, 2013                 [Page 6]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

   o  As the RADIUS packet exceeds the maximum allowed length (8
      attributes), the RADIUS client indicates the server its will of
      sending additional large data after authentication has been
      completed.  This fact is indicated by including the Frag-Status =
      Additional-Authorization attribute into the first Access-Request
      sent from the NAS to the AS.

         Access-Request(1) {User-Name, ..., Frag-Status(AA)}

   o  The RADIUS server flags the session as requiring more data, and
      both continue with the authentication process as usual (e.g.
      exchange of Access-Request/Access-Challenge).  RADIUS Identifier
      is not increased in this example for sake of simplicity.

   o  Within the final Access-Accept packet, the server includes a
      Service-Type = Additional-Authorization and a State attribute,
      indicating to the client that it is ready to receive the
      additional authorization information.  If the server wanted to
      send a different Service-Type attribute, it would be sent in the
      last Access-Accept packet after receiving all the data from the
      client.

         Access-Accept(1) {User-Name, ..., State1, Service-Type(AA)}

   o  The RADIUS client truncates the original packet to generate the
      first chunk, including the Frag-Status = More-Data-Pending
      attribute.  As attribute "Attr1" does not completely fit into this
      chunk, the flag "T" is activated into the last fragment included
      into this chunk, to indicate that it is not the last fragment of
      the attribute.  If the original Access-Request packet contained a
      User-Name attribute, it MUST be included on every chunk sent to
      the server.  This is required because proxies may need this value
      to forward the chunk to its proper destination.

         Access-Request(2) {User-Name, Calling-Station-Id, Attr1[M],
         Attr1[M], Attr1[M], Attr1[M], State1, Frag-Status(MDP)}

   o  When the server receives the RADIUS packet containing the Frag-
      Status = More-Data-Pending attribute, the processing of the packet
      is delayed until all the pending data is received.  The pending
      data is requested by means of an Access-Challenge packet
      containing a Frag-Status = More-Data-Request, using the State
      attribute to tie together this response with the subsequent
      request from the client.

         Access-Challenge(2) {Frag-Status(MDR), State2}

Perez-Mendez, et al.     Expires August 5, 2013                 [Page 7]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

   o  The client continues including attributes until another chunk is
      completed, including the Frag-Status = More-Data-Pending
      attribute, as Attr2 does not fit in this chunk.  The State
      attribute received in the Access-Challenge (i.e.  State2) is also
      included.

         Access-Request(3) {User-Name, Attr1[M], Attr1[M], Attr1[M],
         Attr1[M], Attr1, State2, Frag-Status(MDP)}

   o  As the received request contains the Frag-Status = More-Data-
      Pending attribute, the server stores the attributes into the state
      associated to State1 and replies with another Access-Challenge
      packet.  The challenge contains a Frag-Status = More-Data-Request
      and a new State attribute (i.e.  State3) that refers to this
      conversation.

         Access-Challenge(3) {Frag-Status(MDR), State3}

   o  Finally, the client sends the last chunk of the original packet,
      including the received State attribute (i.e.  State3).

         Access-Request(4) {User-Name, Attr2[M], Attr2[M], Attr2,
         State3}

   o  On reception of this last chunk (no Frag-Status = More-Data-
      Pending present), the server can process the received attributes
      as if they all had been received into a single RADIUS packet
      larger than 4096 bytes.  See Section 6.4 for further details.  It
      generates the Access-Accept packet finalizing the exchange of
      data.  This packet will contain the original Service-Type
      attribute (if any).

         Access-Accept(4) {User-Name, Service-Type(X)}

   The Figure 1 depicts this scenario.

Perez-Mendez, et al.     Expires August 5, 2013                 [Page 8]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

     +-+-+-+-+                                                 +-+-+-+-+
     |  NAS  |                                                 |  AS   |
     +-+-+-+-+                                                 +-+-+-+-+
         |                                                         |
         | Access-Request(1){User-Name,...,Frag-Status(AA)}        |
         |-------------------------------------------------------->|
         |                           .                             |
         |                           .                             |
         |                 Authentication process                  |
         |<------------------------------------------------------->|
         |                           .                             |
         |                           .                             |
         |                Access-Accept(1){User-Name,...,State1,   |
         |                                 Service-Type(AddAuth)}  |
         |<--------------------------------------------------------|
         |                                                         |
         | Access-Request(2){User-Name,Calling-Station-Id,         |
         |            Attr1[M],Attr1[M],Attr1[M],Attr1[MT]         |
         |            State1,Frag-Status(MDP)}                     |
         |-------------------------------------------------------->|
         |                                                         |
         |            Access-Challenge(2){Frag-Status(MDR),State2} |
         |<--------------------------------------------------------|
         |                                                         |
         | Access-Request(3){User-Name,State2,Attr1[M],            |
         |            Attr1[M],Attr1[M],Attr1[M],Attr1,            |
         |            Frag-Status(MDP)}                            |
         |-------------------------------------------------------->|
         |                                                         |
         |            Access-Challenge(3){Frag-Status(MDR),State3} |
         |<--------------------------------------------------------|
         |                                                         |
         | Access-Request(4){User-Name,State3,Attr2[M],            |
         |                   Attr2[M],Attr2}                       |
         |-------------------------------------------------------->|
         |                                                         |
         |             Access-Accept(4){User-Name,Service-Type(X)} |
         |<--------------------------------------------------------|

                Figure 1: Fragmented Access-Request packet

3.2.  Access-Accept

   If the AS wants to send an Access-Accept packet that exceeds the 4096
   bytes limit (e.g. due to the inclusion of authorization-specific
   attributes), the operation is slightly different.  In addition to the
   use of the Frag-Status = More-Data-Pending attribute for each chunk,
   the AS makes use of the Service-Type = Additional-Authorization

Perez-Mendez, et al.     Expires August 5, 2013                 [Page 9]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

   attribute.  In this way, when a client receives an Access-Accept and
   it does not support Additional-Authorization, it MUST treat that
   unrecognized Service-Type as though an Access-Reject had been
   received instead ([RFC2865] Section 5.6).  If the original large
   Access-Accept packet contained a Service-Type attribute, it will be
   included with its original value in the last transmitted chunk, to
   avoid confusion with the one used for fragmentation signalling.

   Client supporting this specification and not wanting to send
   additional authorization information (see section above) MUST include
   a Frag-Status = Fragmentation-Supported attribute in the first
   Access-Request sent to the server, in order to indicate they would
   accept fragmented data from the sever.

   o  The RADIUS client includes a Frag-Status = Fragmentation-Supported
      attribute into the first Access-Request packet sent to the server,
      indicating this specification is supported.

         Access-Request(1) {User-Name, ..., Frag-Status(FS)}

   o  Once the user has been authenticated, the AS wants to send the
      following Access-Accept packet.  Attr1 has 9 fragments, while
      Attr2 has 3 fragments:

         Access-Accept(1) {User-Name, Service-Type(X), Framed-IP-
         Address, Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M],
         Attr1[M], Attr1[M], Attr1[M], Attr1, Attr2[M], Attr2[M],
         Attr2[M]}

   o  As the RADIUS packet exceeds the maximum allowed length (8
      attributes), the AS truncates the packet to generate the first
      chunk.  This chunk includes a Service-Type = Additional-
      Authorization, indicating that this Access-Accept MUST not be
      considered as a final packet, and a Frag-Status = More-Data-
      Pending attribute indicating that there are more chunks yet to be
      provided.  Note that the Service-Type(X) is not included yet to
      avoid confusion.  Besides, as attribute "Attr1" does not
      completely fit into this chunk, the flag "T" is activated into the
      last fragment included into this chunk.  Finally, a new RADIUS
      State attribute is included to allow the AS to correlate the
      following Access-Request with this chunk.

         Access-Accept(1) {User-Name, Framed-IP-Address, Attr1[M],
         Attr1[M], Attr1[MT],Service-Type(AA), State1, Frag-Status(MDP)}

   o  When the NAS receives the Access-Accept, it determines, based on
      the Frag-Status = More-Data-Pending attribute, that additional
      exchanges are required.  Thus, it generates a new Access-Request

Perez-Mendez, et al.     Expires August 5, 2013                [Page 10]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

      packet containing the User-Name attribute, a Frag-Status = More-
      Data-Request attribute and the State attribute received from the
      server.

         Access-Request(2) {User-Name, Frag-Status(MDR), State1}

   o  The AS then generates a new chunk with part of the remaining
      attributes to be sent.  As they does not fit into a single chunk,
      Frag-Status = More-Data-Pending and Service-Type = Additional-
      Authorization are included, along with a new State attribute.

         Access-Accept(2) {User-Name, Attr1[M], Attr1[M], Attr1[M],
         Attr1[MT], Service-Type(AA), State2, Frag-Status(MDP)}

   o  The NAS determines there is more data pending, and generates a new
      Access-Request packet containing the User-Name attribute, a Frag-
      Status = More-Data-Request attribute and the State attribute
      received from the server.

         Access-Request(3) {User-Name, Frag-Status(MDR), State2}

   o  Finally, the AS sends the last chunk as all the remaining data
      fits into a single packet.  This is indicated by not including a
      Frag-Status = More-Data-Pending attribute.  This last chunk
      includes the original Service-Type attribute.

         Access-Accept(3) {User-Name, Attr1[M], Attr1, Attr2[M],
         Attr2[M], Attr2, Service-Type(X)}

   o  On reception of this last packet, the NAS can process the totality
      of the received attributes as if they were all received into a
      single RADIUS packet larger than 4096 bytes.  See Section 6.4 for
      further details on this.

   The following figure depicts the exchange of chunks between the NAS
   and the AS.

Perez-Mendez, et al.     Expires August 5, 2013                [Page 11]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

     +-+-+-+-+                                                 +-+-+-+-+
     |  NAS  |                                                 |  AS   |
     +-+-+-+-+                                                 +-+-+-+-+
         |                                                         |
         | Access-Request(1){User-Name,...,Frag-Status(FS)}        |
         |-------------------------------------------------------->|
         |                           .                             |
         |                           .                             |
         |                 Authentication process                  |
         |<------------------------------------------------------->|
         |                           .                             |
         |                           .                             |
         |           Access-Accept(1){User-Name,Framed-IP-Address, |
         |                     Attr1[M],Attr1[M],Attr1[MT],State1, |
         |                     Service-Type(AA),Frag-Status(MDP)}  |
         |<--------------------------------------------------------|
         |                                                         |
         | Access-Request(2){User-Name,Frag-Status(MDR),State1}    |
         |-------------------------------------------------------->|
         |                                                         |
         |           Access-Accept(2){User-Name,Attr1[M],Attr1[M], |
         |                     Attr1[M],Attr1[M],Service-Type(AA), |
         |                     State2,Frag-Status(MDP)}            |
         |<--------------------------------------------------------|
         |                                                         |
         | Access-Request(3){User-Name,Frag-Status(MDR),State2}    |
         |-------------------------------------------------------->|
         |                                                         |
         |              Access-Accept(3){User-Name,Attr1[M],Attr1, |
         |                               Attr2[M],Attr2[M],Attr2,  |
         |                               Service-Type(X)}          |
         |<--------------------------------------------------------|

                 Figure 2: Fragmented Access-Accept packet

3.3.  Combined use of both fragmented packets

   The use of both fragmented packets may occur simultaneously.  In that
   case, the AS will be the first sending the fragmented data.  In the
   last chunk from the AS to the NAS it is included a Service-Type =
   Additional-Authorization attribute, indicating the NAS that it can
   proceed sending its data.  The original Service-Type (if any) will be
   included in the last Access-Accept from the AS to the NAS after
   having received all the chunks.

   Specifically, the NAS wants to send the following Access-Request
   packet (Attr1 has 9 fragments):

Perez-Mendez, et al.     Expires August 5, 2013                [Page 12]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

      Access-Request(1) {User-Name, Calling-Station-Id, Attr1[M],
      Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M],
      Attr1[M], Attr1}

   While the AS wants to send the following Access-Accept packet (Attr2
   has 8 fragments):

      Access-Accept(1) {User-Name, Service-Type(X), Framed-IP-Address,
      Attr2[M], Attr2[M], Attr2[M], Attr2[M], Attr2[M], Attr2[M],
      Attr2[M], Attr2}

Perez-Mendez, et al.     Expires August 5, 2013                [Page 13]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

     +-+-+-+-+                                                 +-+-+-+-+
     |  NAS  |                                                 |  AS   |
     +-+-+-+-+                                                 +-+-+-+-+
         |                                                         |
         | Access-Request(1){User-Name,...,Frag-Status(AA)}        |
         |-------------------------------------------------------->|
         |                           .                             |
         |                           .                             |
         |                 Authentication process                  |
         |<------------------------------------------------------->|
         |                           .                             |
         |                           .                             |
         |           Access-Accept(1){User-Name,Framed-IP-Address, |
         |                  Attr2[M],Attr2[M],Attr2[MT],State1,    |
         |                  Service-Type(AA),Frag-Status(MDP)}     |
         |<--------------------------------------------------------|
         |                                                         |
         | Access-Request(2){User-Name,Frag-Status(MDR),State1}    |
         |-------------------------------------------------------->|
         |                                                         |
         |            Access-Accept(2){User-Name,Attr2[M],Attr2[M],|
         |                             Attr2[M],Attr2[M],Attr2,    |
         |                             State2,Service-Type(AA)}    |
         |<--------------------------------------------------------|
         |                                                         |
         | Access-Request(3){User-Name,Calling-Station-Id,         |
         |            Attr1[M],Attr1[M],Attr1[M],Attr1[MT],        |
         |            State1,Frag-Status(MDP)}                     |
         |-------------------------------------------------------->|
         |                                                         |
         |                          Access-Challenge(3){User-Name, |
         |                                Frag-Status(MDR),State3} |
         |<--------------------------------------------------------|
         |                                                         |
         | Access-Request(4){User-Name,State3,Attr1[M],            |
         |            Attr1[M],Attr1[M],Attr1[M],Attr1}            |
         |-------------------------------------------------------->|
         |                                                         |
         |             Access-Accept(4){User-Name,Service-Type(X)} |
         |<--------------------------------------------------------|

   Figure 3: Combined fragmentation of Access-Request and Access-Accept
                                  packets

Perez-Mendez, et al.     Expires August 5, 2013                [Page 14]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

3.4.  Unsupported packet types

   We define fragmentation for authentication and authorization only.
   Fragmentation for other packet types is not supported.  This section
   explains the rationale behind that decision

3.4.1.  Accounting

   There is no need to fragment accounting packets.  While the
   accounting process can send large amounts of data, that data is
   typically composed of many small updates.  That is, there is no
   demonstrated need to send indivisible blocks of more than 4K of data.

   The need to send large amounts of data per user session often
   originates from the need for flow-based accounting.  In this use-
   case, the client may send accounting data for many thousands of
   flows, where all those flows are tied to one user session.  The
   existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section
   5.11 has been proven to work here.

3.4.2.  CoA

   There is no need to fragment CoA packets.  Instead, the CoA client
   MUST send a CoA-Request packet containing session identification
   attributes, along with Service-Type = Additional-Authorization, and a
   State attribute.  Implementations not supporting fragmentation will
   respond with a CoA-NAK, and an Error-Cause of Unsupported-Service.

   Implementations supporting this specification may not be able to
   change authorization data for a particular session.  In that case,
   they MUST respond with a CoA-NAK, as above.  Otherwise, the
   implementation MUST start fragmentation via Access-Request, using the
   methods defined here.

   The above requirement solves a number of issues.  It clearly
   separates session identification from authorization.  Without this
   separation, it is difficult to both identify a session, and change
   its authorization using the same attribute.  It also ensures that the
   authorization process is the same for initial authentication, and for
   CoA.

   When a sessions authorization is changed, the CoA server MUST
   continue the existing service until the new authorization parameters
   are applied.  The change of service SHOULD be done atomically.  If
   the CoA server is unable to apply the new authorization, it MUST
   terminate the user session.

Perez-Mendez, et al.     Expires August 5, 2013                [Page 15]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

4.  Chunk size

   In an ideal scenario, chunks would be exactly 4096 bytes length, and
   they would contain exactly 4096-20=4076 bytes of attributes from the
   original large packet (where 20 is the size of the RADIUS header).
   In this way, the number of round trips required to send a large
   packet would be optimal.  However, this is not possible for several
   reasons.

   1.  RADIUS attributes have a variable length, and must be included
       completely in a chunk.  Thus, it is possible that, even if there
       is some free space in the chunk, it is not enough to include the
       next attribute.  This can generate up to 254 bytes of spare space
       on every chunk.

   2.  RADIUS fragmentation requires the introduction of some extra
       attributes for signalling.  Specifically, a Frag-Status attribute
       (7 bytes) is included on every chunk of a packet, except the last
       one.  A RADIUS State attribute (from 3 to 255 bytes) is also
       included in most chunks, to allow the server to bind an Access-
       Request with a previous Access-Challenge.  User-Name attributes
       (from 3 to 255 bytes) are introduced on every chunk the client
       sends as they are required by the proxies to route the packet to
       its destination.  Together, these attributes can generate from up
       to 13 to 517 bytes of signalling data, reducing the amount of
       payload information that can be sent on each chunk.

   3.  RADIUS packets SHOULD be adjusted to avoid exceeding the network
       MTU.  Otherwise, IP fragmentation may occur, having undesirable
       consequences.  Hence, maximum chunk size would be decreased from
       4096 to the actual MTU of the network.

   4.  The inclusion of Proxy-State attributes by intermediary proxies
       can decrease the availability of usable space into the chunk.
       This is described with further detail in Section 6.1.

5.  Allowed large packet size

   There are no provisions for signalling how much data is to be sent
   via the fragmentation process as a whole.  It is difficult to define
   what is meant by the "length" of any fragmented data.  That data can
   be multiple attributes, which includes RADIUS attribute header
   fields.  Or it can be one or more "large" attributes (more than 256
   octets in length).  Proxies can also filter these attributes, to
   modify, add, or delete them and their contents.  These proxies act on
   a "packet by packet" basis, and cannot know what kind of filtering
   actions they take on future packets.  As a result, it is impossible

Perez-Mendez, et al.     Expires August 5, 2013                [Page 16]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

   to signal any meaningful value for the total amount of additional
   data.

   Implementations of this specification MUST limit the total amount of
   data they send and/or receive via this specification.  It is
   RECOMMENDED that the limits be set to a few tens of kilobytes.  Any
   more than this may turn RADIUS into a generic transport protocol,
   which is undesired.  It is RECOMMENDED that this limit be exposed to
   administrators, so that it can be changed if necessary.

   Implementations of this specification MUST limit the total number of
   round trips used during the fragmentation process.  It is RECOMMENDED
   that the number of round trips be limited to twenty (20).  Any more
   than this may indicate an implementation error, misconfiguration, or
   a denial of service (DoS) attack.  It is RECOMMENDED that this limit
   be exposed to administrators, so that it can be changed if necessary.

6.  Handling special attributes

6.1.  Proxy-State attribute

   RADIUS proxies may introduce Proxy-State attributes into any Access-
   Request packet they forward.  Should they cannot add this information
   to the packet, they may silently discard forwarding it to its
   destination, leading to DoS situations.  Moreover, any Proxy-State
   attribute received by a RADIUS server in an Access-Request packet
   MUST be copied into the reply packet to it.  For these reasons,
   Proxy-State attributes require a special treatment within the packet
   fragmentation mechanism.

   When the RADIUS server replies to an Access-Request packet as part of
   a conversation involving a fragmentation (either a chunk or a request
   for chunks), it MUST include every Proxy-State attribute received
   into the reply packet.  This means that the server MUST take into
   account the size of these Proxy-State attributes in order to
   calculate the size of the next chunk to be sent.

   However, while a RADIUS server will always know how many space MUST
   be left on each reply packet for Proxy-State attributes (as they are
   directly included by the RADIUS server), a RADIUS client cannot know
   this information, as Proxy-State attributes are removed from the
   reply packet by their respective proxies before forwarding them back.
   Hence, clients need a mechanism to discover the amount of space
   required by proxies to introduce their Proxy-State attributes.  In
   the following we describe a new mechanism to perform such a
   discovery:

Perez-Mendez, et al.     Expires August 5, 2013                [Page 17]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

   1.  When a RADIUS client does not know how many space will be
       required by intermediate proxies for including their Proxy-State
       attributes, it SHOULD start using a conservative value (e.g. 1024
       bytes) as the chunk size.

   2.  When the RADIUS server receives a chunk from the client, it can
       calculate the total size of the Proxy-State attributes that have
       been introduced by intermediary proxies along the path.  This
       information MUST be returned to the client in the next reply
       packet, encoded into a new attribute called Proxy-State-Len.

   3.  The RADIUS client reacts upon the reception of this attribute by
       adjusting the maximum size for the next chunk accordingly.

6.2.  State attribute

   This RADIUS fragmentation mechanism makes use of the State attribute
   to link all the chunks belonging to the same fragmented packet.
   However, some considerations are required when the RADIUS server is
   fragmenting a packet that already contains a State attribute for
   other purposes not related with the fragmentation.  If the procedure
   described in Section 3 is followed, two different State attributes
   could be included into a single chunk, incurring into two problems.
   First, [RFC2865] explicitly forbids that more than one State
   attribute appears into a single packet.

   A straightforward solution consists on making the RADIUS server to
   send the original State attribute into the last chunk of the sequence
   (attributes can be re-ordered as specified in [RFC2865]).  As the
   last chunk (when generated by the RADIUS server) does not contain any
   State attribute due to the fragmentation mechanism, both situations
   described above are avoided.

   Something similar happens when the RADIUS client has to send a
   fragmented packet that contains a State attribute on it.  The client
   MUST assure that this original State is included into the first chunk
   sent to the server (as this one never contains any State attribute
   due to fragmentation).

6.3.  Service-Type attribute

   This RADIUS fragmentation mechanism makes use of the Service-Type
   attribute to indicate an Access-Accept packet is not granting access
   to the service yet, since additional authorization exchange needs to
   be performed.  Similarly to the State attribute, the RADIUS server
   has to send the original Service-Type attribute into the last Access-
   Accept of the RADIUS conversation to avoid ambiguity.

Perez-Mendez, et al.     Expires August 5, 2013                [Page 18]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

6.4.  Rebuilding the original large packet

   The RADIUS client stores the RADIUS attributes received on each chunk
   in order to be able to rebuild the original large packet after
   receiving the last chunk.  However, some of these received attributes
   MUST NOT be stored in this list, as they have been introduced as part
   of the fragmentation signalling and hence, they are not part of the
   original packet.

   o  State (except the one in the last chunk, if present)

   o  Service-Type = Additional-Authorization

   o  Frag-Status

   o  Proxy-State-Len

   Similarly, the RADIUS server MUST NOT store the following attributes
   as part of the original large packet:

   o  State (except the one in the first chunk, if present)

   o  Frag-Status

   o  Proxy-State (except the ones in the last chunk)

   o  User-Name (except the one in the first chunk)

7.  New attribute definition

   This document proposes the definition of two new extended type
   attributes, called Frag-Status and Proxy-State-Len.  The format of
   these attributes follows the indications for an Extended Type
   attribute defined in [I-D.ietf-radext-radius-extensions].

7.1.  Frag-Status attribute

   This attribute is used for fragmentation signalling, and its meaning
   depends on the code value transported within it.  The following
   figure represents the format of the Frag-Status attribute.

Perez-Mendez, et al.     Expires August 5, 2013                [Page 19]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type        |    Length     | Extended-Type |     Code
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         Code (cont)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 4: Frag-Status format

   Type

      To be assigned (TBA)

   Length

      7

   Extended-Type

      To be assigned (TBA).

   Code

      4 byte.  Integer indicating the code.  The values defined in this
      specifications are:

         0 - Reserved

         1 - Fragmentation-Supported

         2 - Additional-Authorization

         3 - More-Data-Pending

         4 - More-Data-Request

   This attribute MAY be present in Access-Request, Access-Challenge and
   Access-Accept packets.  It MUST not be included in Access-Reject
   packets.

7.2.  Proxy-State-Len attribute

   This attribute indicates to the RADIUS client the length of the
   Proxy-State attributes received by the RADIUS server.  This
   information is useful to adjust the length of the chunks sent by the
   RADIUS client.  The format of this Proxy-State-Len attribute is the
   following:

Perez-Mendez, et al.     Expires August 5, 2013                [Page 20]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type        |    Length     | Extended-Type |     Value
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Value (cont)                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 5: Proxy-State-Len format

   Type

      To be assigned (TBA)

   Length

      7

   Extended-Type

      To be assigned (TBA).

   Value

      4 bytes.  Total length (in bytes) of received Proxy-State
      attributes (including headers).

   This attribute MAY be present in Access-Challenge and Access-Accept
   packets.  It MUST not be included in Access-Request or Access-Reject
   packets.

7.3.  Table of attributes

   The following table shows the different attributes defined in this
   document related with the kind of RADIUS packets where they can be
   present.

                            |     Kind of packet    |
                            +-----+-----+-----+-----+
      Attribute Name        | Req | Acc | Rej | Cha |
      ----------------------+-----+-----+-----+-----+
      Frag-Status           | 0-1 | 0-1 |  0  | 0-1 |
      ----------------------+-----+-----+-----+-----+
      Proxy-State-Len       | 0   | 0-1 |  0  | 0-1 |
      ----------------------+-----+-----+-----+-----+

                                 Figure 6

Perez-Mendez, et al.     Expires August 5, 2013                [Page 21]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

8.  Operation with proxies

   The fragmentation mechanism defined above is designed to be
   transparent to legacy proxies, as long as they do not want to modify
   any fragmented attribute.  Nevertheless, updated proxies supporting
   this specification can even modify fragmented attributes.

8.1.  Legacy proxies

   As every chunk is indeed a RADIUS packet, legacy proxies treat them
   as the rest of packets, routing them to their destination.  Proxies
   can introduce Proxy-State attributes to Access-Request packets, even
   if they are indeed chunks.  This will not affect how fragmentation is
   managed.  The server will include all the received Proxy-State
   attributes into the generated response, as described in [RFC2865].
   Hence, proxies do not distinguish between a regular RADIUS packet and
   a chunk.

8.2.  Updated proxies

   Updated proxies can interact with clients and servers in order to
   obtain the complete large packet before start forwarding it.  In this
   way, proxies can manipulate (modify and/or remove) any attribute of
   the packet, or introduce new attributes, without worrying about
   crossing the boundaries of the chunk size.  Once the manipulated
   packet is ready, it is sent to the original destination using the
   fragmentation mechanism (if required).  The following example shows
   how an updated proxy interacts with the NAS to obtain a large Access-
   Request packet, modify an attribute resulting into a even more large
   packet, and interacts with the AS to complete the transmission of the
   modified packet.

Perez-Mendez, et al.     Expires August 5, 2013                [Page 22]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

       +-+-+-+-+                                            +-+-+-+-+
       |  NAS  |                                            | Proxy |
       +-+-+-+-+                                            +-+-+-+-+
           |                                                    |
           | Access-Request(1){User-Name,Calling-Station-Id,    |
           |        Attr1[M],Attr1[M],Attr1[M],Attr1[M],        |
           |        Attr1[MT],Frag-Status(MDP)}                 |
           |--------------------------------------------------->|
           |                                                    |
           |                     Access-Challenge(1){User-Name, |
           |                           Frag-Status(MDR),State1} |
           |<---------------------------------------------------|
           |                                                    |
           | Access-Request(2)(User-Name,State1,Attr1[M],       |
           |                   Attr1[M],Attr1[M],Attr1}         |
           |--------------------------------------------------->|

                PROXY MODIFIES ATTRIBUTE Data INCREASING ITS
                   SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS

                Figure 7: Updated proxy interacts with NAS

Perez-Mendez, et al.     Expires August 5, 2013                [Page 23]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

       +-+-+-+-+                                            +-+-+-+-+
       | Proxy |                                            |   AS  |
       +-+-+-+-+                                            +-+-+-+-+
           |                                                    |
           | Access-Request(3){User-Name,Calling-Station-Id,    |
           |        Attr1[M],Attr1[M],Attr1[M],Attr1[M],        |
           |        Attr1[MT],Frag-Status(MDP)}                 |
           |--------------------------------------------------->|
           |                                                    |
           |                     Access-Challenge(1){User-Name, |
           |                           Frag-Status(MDR),State2} |
           |<---------------------------------------------------|
           |                                                    |
           | Access-Request(4){User-Name,State2,Attr1[M],       |
           |                Attr1[M],Attr1[M],Attr1[M],         |
           |                Attr1[MT],Frag-Status(MDP)}         |
           |--------------------------------------------------->|
           |                                                    |
           |                     Access-Challenge(1){User-Name, |
           |                           Frag-Status(MDR),State3} |
           |<---------------------------------------------------|
           |                                                    |
           | Access-Request(5){User-Name,State3,Attr1}          |
           |--------------------------------------------------->|

                 Figure 8: Updated proxy interacts with AS

9.  Security Considerations

   As noted in many earlier specifications ([RFC5080], [RFC6158], etc.)
   RADIUS security is problematic.  This specification changes nothing
   related to the security of the RADIUS protocol.  It requires that all
   Access-Request packets associated with fragmentation are signed using
   the existing Message-Authenticator attribute.  This signature
   prevents forging and replay, to the limits of the existing security.

   The ability to send bulk data from one party to another creates new
   security considerations.  Clients and servers may have to store large
   amounts of data per session.  The amount of this data can be
   significant, leading to the potential for resource exhaustion.  We
   therefore suggest that implementations limit the amount of bulk data
   stored per session.  The exact method for this limitation is
   implementation-specific.  Section 5 gives some indications on what
   could be a reasonable limits.

   The bulk data can often be pushed off to storage methods other than
   the memory of the RADIUS implementation.  For example, it can be

Perez-Mendez, et al.     Expires August 5, 2013                [Page 24]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

   stored in an external database, or in files.  This approach mitigates
   the resource exhaustion issue, as servers today already store large
   amounts of accounting data.

10.  IANA Considerations

   The authors request that Attribute Types and Attribute Values defined
   in this document be registered by the Internet Assigned Numbers
   Authority (IANA) from the RADIUS namespaces as described in the "IANA
   Considerations" section of [RFC3575], in accordance with BCP 26
   [RFC5226].  For RADIUS packets, attributes and registries created by
   this document IANA is requested to place them at
   http://www.iana.org/assignments/radius-types.

   This document defines the following RADIUS messages:

   o  Frag-Status

   o  Proxy-State-Len

   Additionally, allocation of a new Service-Type value for "Additional-
   Authorization" is requested.

11.  Normative References

   [I-D.ietf-radext-radius-extensions]
              DeKok, A. and A. Lior, "Remote Authentication Dial In User
              Service (RADIUS) Protocol Extensions",
              draft-ietf-radext-radius-extensions-11 (work in progress),
              February 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC3575]  Aboba, B., "IANA Considerations for RADIUS (Remote
              Authentication Dial In User Service)", RFC 3575,
              July 2003.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible

Perez-Mendez, et al.     Expires August 5, 2013                [Page 25]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC5080]  Nelson, D. and A. DeKok, "Common Remote Authentication
              Dial In User Service (RADIUS) Implementation Issues and
              Suggested Fixes", RFC 5080, December 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6158]  DeKok, A. and G. Weber, "RADIUS Design Guidelines",
              BCP 158, RFC 6158, March 2011.

Authors' Addresses

   Alejandro Perez-Mendez (Ed.)
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia,   30100
   Spain

   Phone: +34 868 88 46 44
   Email: alex@um.es

   Rafa Marin-Lopez
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia,   30100
   Spain

   Phone: +34 868 88 85 01
   Email: rafa@um.es

   Fernando Pereniguez-Garcia
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia,   30100
   Spain

   Phone: +34 868 88 78 82
   Email: pereniguez@um.es

Perez-Mendez, et al.     Expires August 5, 2013                [Page 26]
Internet-Draft       Fragmentation of RADIUS packets            Feb 2013

   Gabriel Lopez-Millan
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia,   30100
   Spain

   Phone: +34 868 88 85 04
   Email: gabilm@um.es

   Diego R. Lopez
   Telefonica I+D
   Don Ramon de la Cruz, 84
   Madrid,   28006
   Spain

   Phone: +34 913 129 041
   Email: diego@tid.es

   Alan DeKok
   Network RADIUS
   15 av du Granier
   Meylan,   38240
   France

   Phone: +34 913 129 041
   Email: aland@networkradius.com
   URI:   http://networkradius.com

Perez-Mendez, et al.     Expires August 5, 2013                [Page 27]