GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7499

Internet Engineering Task Force (IETF) A. Perez-Mendez, Ed. Request for Comments: 7499 R. Marin-Lopez Category: Experimental F. Pereniguez-Garcia ISSN: 2070-1721 G. Lopez-Millan

                                                  University of Murcia
                                                              D. Lopez
                                                        Telefonica I+D
                                                              A. DeKok
                                                        Network RADIUS
                                                            April 2015
             Support of Fragmentation of RADIUS Packets

Abstract

 The Remote Authentication Dial-In User Service (RADIUS) protocol is
 limited to a total packet size of 4096 bytes.  Provisions exist for
 fragmenting large amounts of authentication data across multiple
 packets, via Access-Challenge packets.  No similar provisions exist
 for fragmenting large amounts of authorization data.  This document
 specifies how existing RADIUS mechanisms can be leveraged to provide
 that functionality.  These mechanisms are largely compatible with
 existing implementations, and they are designed to be invisible to
 proxies and "fail-safe" to legacy RADIUS Clients and Servers.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.
 This document defines an Experimental Protocol for the Internet
 community.  This document is a product of the Internet Engineering
 Task Force (IETF).  It represents the consensus of the IETF
 community.  It has received public review and has been approved for
 publication by the Internet Engineering Steering Group (IESG).  Not
 all documents approved by the IESG are a candidate for any level of
 Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7499.

Perez-Mendez, et al. Experimental [Page 1] RFC 7499 Fragmentation of RADIUS Packets April 2015

Copyright Notice

 Copyright (c) 2015 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
 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.

Perez-Mendez, et al. Experimental [Page 2] RFC 7499 Fragmentation of RADIUS Packets April 2015

Table of Contents

 1. Introduction ....................................................4
    1.1. Requirements Language ......................................6
 2. Status of This Document .........................................6
 3. Scope of This Document ..........................................7
 4. Overview .......................................................10
 5. Fragmentation of Packets .......................................13
    5.1. Pre-Authorization .........................................14
    5.2. Post-Authorization ........................................18
 6. Chunk Size .....................................................21
 7. Allowed Large Packet Size ......................................22
 8. Handling Special Attributes ....................................23
    8.1. Proxy-State Attribute .....................................23
    8.2. State Attribute ...........................................24
    8.3. Service-Type Attribute ....................................25
    8.4. Rebuilding the Original Large Packet ......................25
 9. New T Flag for the Long Extended Type Attribute Definition .....26
 10. New Attribute Definition ......................................26
    10.1. Frag-Status Attribute ....................................27
    10.2. Proxy-State-Length Attribute .............................28
    10.3. Table of Attributes ......................................29
 11. Operation with Proxies ........................................29
    11.1. Legacy Proxies ...........................................29
    11.2. Updated Proxies ..........................................29
 12. General Considerations ........................................31
    12.1. T Flag ...................................................31
    12.2. Violation of RFC 2865 ....................................32
    12.3. Proxying Based on User-Name ..............................32
    12.4. Transport Behavior .......................................33
 13. Security Considerations .......................................33
 14. IANA Considerations ...........................................34
 15. References ....................................................35
    15.1. Normative References .....................................35
    15.2. Informative References ...................................35
 Acknowledgements ..................................................37
 Authors' Addresses ................................................37

Perez-Mendez, et al. Experimental [Page 3] RFC 7499 Fragmentation of RADIUS Packets April 2015

1. Introduction

 The RADIUS [RFC2865] protocol carries authentication, authorization,
 and accounting information between a RADIUS Client and a RADIUS
 Server.  Information is exchanged between them through RADIUS
 packets.  Each RADIUS packet is composed of a header, and zero or
 more attributes, up to a maximum packet size of 4096 bytes.  The
 protocol is a request/response protocol, as described in the
 operational model ([RFC6158], Section 3.1).
 The intention of the above packet size limitation was to avoid UDP
 fragmentation as much as possible.  Back then, a size of 4096 bytes
 seemed large enough for any purpose.  Now, new scenarios are emerging
 that require the exchange of authorization information exceeding this
 4096-byte limit.  For instance, the Application Bridging for
 Federated Access Beyond web (ABFAB) IETF working group defines the
 transport of Security Assertion Markup Language (SAML) statements
 from the RADIUS Server to the RADIUS Client [SAML-RADIUS].  This
 assertion is likely to be larger than 4096 bytes.
 This means that peers desiring to send large amounts of data must
 fragment it across multiple packets.  For example, RADIUS-EAP
 [RFC3579] defines how an Extensible Authentication Protocol (EAP)
 exchange occurs across multiple Access-Request / Access-Challenge
 sequences.  No such exchange is possible for accounting or
 authorization data.  [RFC6158], Section 3.1 suggests that exchanging
 large amounts of authorization data is unnecessary in RADIUS.
 Instead, the data should be referenced by name.  This requirement
 allows large policies to be pre-provisioned and then referenced in an
 Access-Accept.  In some cases, however, the authorization data sent
 by the RADIUS Server is large and highly dynamic.  In other cases,
 the RADIUS Client needs to send large amounts of authorization data
 to the RADIUS Server.  Neither of these cases is met by the
 requirements in [RFC6158].  As noted in that document, the practical
 limit on RADIUS packet sizes is governed by the Path MTU (PMTU),
 which may be significantly smaller than 4096 bytes.  The combination
 of the two limitations means that there is a pressing need for a
 method to send large amounts of authorization data between RADIUS
 Client and Server, with no accompanying solution.

Perez-Mendez, et al. Experimental [Page 4] RFC 7499 Fragmentation of RADIUS Packets April 2015

 [RFC6158], Section 3.1 recommends three approaches for the
 transmission of large amounts of data within RADIUS.  However, they
 are not applicable to the problem statement of this document for the
 following reasons:
 o  The first approach (utilization of a sequence of packets) does not
    talk about large amounts of data sent from the RADIUS Client to a
    RADIUS Server.  Leveraging EAP (request/challenge) to send the
    data is not feasible, as EAP already fills packets to PMTU, and
    not all authentications use EAP.  Moreover, as noted for the
    NAS-Filter-Rule attribute ([RFC4849]), this approach does not
    entirely solve the problem of sending large amounts of data from a
    RADIUS Server to a RADIUS Client, as many current RADIUS
    attributes are not permitted in Access-Challenge packets.
 o  The second approach (utilization of names rather than values) is
    not usable either, as using names rather than values is difficult
    when the nature of the data to be sent is highly dynamic (e.g., a
    SAML statement or NAS-Filter-Rule attributes).  URLs could be used
    as a pointer to the location of the actual data, but their use
    would require them to be (a) dynamically created and modified,
    (b) securely accessed, and (c) accessible from remote systems.
    Satisfying these constraints would require the modification of
    several networking systems (e.g., firewalls and web servers).
    Furthermore, the setup of an additional trust infrastructure
    (e.g., Public Key Infrastructure (PKI)) would be required to allow
    secure retrieval of the information from the web server.
 o  PMTU discovery does not solve the problem, as it does not allow
    the sending of data larger than the minimum of (PMTU or 4096)
    bytes.
 This document provides a mechanism to allow RADIUS peers to exchange
 large amounts of authorization data exceeding the 4096-byte limit by
 fragmenting it across several exchanges.  The proposed solution does
 not impose any additional requirements to the RADIUS system
 administrators (e.g., need to modify firewall rules, set up web
 servers, configure routers, or modify any application server).  It
 maintains compatibility with intra-packet fragmentation mechanisms
 (like those defined in [RFC3579] or [RFC6929]).  It is also
 transparent to existing RADIUS proxies, which do not implement this
 specification.  The only systems needing to implement this RFC are
 the ones that either generate or consume the fragmented data being
 transmitted.  Intermediate proxies just pass the packets without
 changes.  Nevertheless, if a proxy supports this specification, it
 may reassemble the data in order to examine and/or modify it.

Perez-Mendez, et al. Experimental [Page 5] RFC 7499 Fragmentation of RADIUS Packets April 2015

 A different approach to deal with RADIUS packets above the 4096-byte
 limit is described in [RADIUS-Larger-Pkts], which proposes to extend
 RADIUS over TCP by allowing the Length field in the RADIUS header to
 take values up to 65535 bytes.  This provides a simpler operation,
 but it has the drawback of requiring every RADIUS proxy in the path
 between the RADIUS Client and the RADIUS Server to implement the
 extension as well.

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].
 When these words appear in lower case, they have their natural
 language meaning.

2. Status of This Document

 This document is an Experimental RFC.  It defines a proposal to allow
 the sending and receiving of data exceeding the 4096-byte limit in
 RADIUS packets imposed by [RFC2865], without requiring the
 modification of intermediary proxies.
 The experiment consists of verifying whether the approach is usable
 in a large-scale environment, by observing the uptake, usability, and
 operational behavior it shows in large-scale, real-life deployments.
 In that sense, so far the main use case for this specification is the
 transportation of large SAML statements defined within the ABFAB
 architecture [ABFAB-Arch].  Hence, it can be tested wherever an ABFAB
 deployment is being piloted.
 Besides, this proposal defines some experimental features that will
 need to be tested and verified before the document can be considered
 for the Standards Track.  The first one of them is the requirement of
 updating [RFC2865] in order to relax the sentence defined in
 Section 4.1 of that document that states that "An Access-Request MUST
 contain either a User-Password or a CHAP-Password or a State."  This
 specification might generate Access-Request packets without any of
 these attributes.  Although all known implementations have chosen the
 philosophy of "be liberal in what you accept," we need to gain more
 operational experience to verify that unmodified proxies do not drop
 these types of packets.  More details on this aspect can be found in
 Section 12.2.

Perez-Mendez, et al. Experimental [Page 6] RFC 7499 Fragmentation of RADIUS Packets April 2015

 Another experimental feature of this specification is that it
 requires proxies to base their routing decisions on the value of the
 RADIUS User-Name attribute.  Our experience is that this is the
 common behavior; thus, no issues are expected.  However, it needs to
 be confirmed after using different implementations of intermediate
 proxies.  More details on this aspect can be found in Section 12.3.
 Moreover, this document requires two minor updates to Standards Track
 documents.  First, it modifies the definition of the Reserved field
 of the Long Extended Type attribute [RFC6929] by allocating an
 additional flag called the T (Truncation) flag.  No issues are
 expected with this update, although some proxies might drop packets
 that do not have the Reserved field set to 0.  More details on this
 aspect can be found in Section 12.1.
 The other Standards Track document that requires a minor update is
 [RFC6158].  It states that "attribute designers SHOULD NOT assume
 that a RADIUS implementation can successfully process RADIUS packets
 larger than 4096 bytes," something no longer true if this document
 advances.
 A proper "Updates" clause will be included for these modifications
 when/if the experiment is successful and this document is reissued as
 a Standards Track document.

3. Scope of This Document

 This specification describes how a RADIUS Client and a RADIUS Server
 can exchange data exceeding the 4096-byte limit imposed by one
 packet.  However, the mechanism described in this specification
 SHOULD NOT be used to exchange more than 100 kilobytes of data.  Any
 more than this may turn RADIUS into a generic transport protocol,
 such as TCP or the Stream Control Transmission Protocol (SCTP), which
 is undesirable.  Experience shows that attempts to transport bulk
 data across the Internet with UDP will inevitably fail, unless these
 transport attempts reimplement all of the behavior of TCP.  The
 underlying design of RADIUS lacks the proper retransmission policies
 or congestion control mechanisms that would make it a competitor
 of TCP.
 Therefore, RADIUS/UDP transport is by design unable to transport bulk
 data.  It is both undesirable and impossible to change the protocol
 at this point in time.  This specification is intended to allow the
 transport of more than 4096 bytes of data through existing RADIUS/UDP
 proxies.  Other solutions such as RADIUS/TCP MUST be used when a
 "green field" deployment requires the transport of bulk data.

Perez-Mendez, et al. Experimental [Page 7] RFC 7499 Fragmentation of RADIUS Packets April 2015

 Section 7, below, describes in further detail what is considered to
 be a reasonable amount of data and recommends that administrators
 adjust limitations on data transfer according to the specific
 capabilities of their existing systems in terms of memory and
 processing power.
 Moreover, its scope is limited to the exchange of authorization data,
 as other exchanges do not require such a mechanism.  In particular,
 authentication exchanges have already been defined to overcome this
 limitation (e.g., RADIUS-EAP).  Moreover, as they represent the most
 critical part of a RADIUS conversation, it is preferable to not
 introduce into their operation any modification that may affect
 existing equipment.
 There is no need to fragment accounting packets either.  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 4 kilobytes
 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 RADIUS 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.
 Similarly, there is no need to fragment Change-of-Authorization (CoA)
 [RFC5176] packets.  Instead, according to [RFC5176], the CoA client
 will 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.
 The above requirement does not assume that the CoA client and the
 RADIUS Server are co-located.  They may, in fact, be run on separate
 parts of the infrastructure, or even by separate administrators.
 There is, however, a requirement that the two communicate.  We can
 see that the CoA client needs to send session identification
 attributes in order to send CoA packets.  These attributes cannot be
 known a priori by the CoA client and can only come from the RADIUS
 Server.  Therefore, even when the two systems are not co-located,
 they must be able to communicate in order to operate in unison.  The
 alternative is for the two systems to have differing views of the
 users' authorization parameters; such a scenario would be a security
 disaster.

Perez-Mendez, et al. Experimental [Page 8] RFC 7499 Fragmentation of RADIUS Packets April 2015

 This specification does not allow for fragmentation of CoA packets.
 Allowing for fragmented CoA packets would involve changing multiple
 parts of the RADIUS protocol; such changes introduce the risk of
 implementation issues, mistakes, etc.
 Where CoA clients (i.e., RADIUS Servers) need to send large amounts
 of authorization data to a CoA server (i.e., RADIUS Client), they
 need only send a minimal CoA-Request packet containing a Service-Type
 of Authorize Only, as per [RFC5176], along with session
 identification attributes.  This CoA packet serves as a signal to the
 RADIUS Client that the users' session requires re-authorization.
 When the RADIUS Client re-authorizes the user via Access-Request, the
 RADIUS Server can perform fragmentation and send large amounts of
 authorization data to the RADIUS Client.
 The assumption in the above scenario is that the CoA client and
 RADIUS Server are co-located, or at least strongly coupled.  That is,
 the path from CoA client to CoA server SHOULD be the exact reverse of
 the path from RADIUS Client to RADIUS Server.  The following diagram
 will hopefully clarify the roles:
                            +----------------+
                            | RADIUS   CoA   |
                            | Client  Server |
                            +----------------+
                               |        ^
               Access-Request  |        |   CoA-Request
                               v        |
                            +----------------+
                            | RADIUS   CoA   |
                            | Server  Client |
                            +----------------+

Perez-Mendez, et al. Experimental [Page 9] RFC 7499 Fragmentation of RADIUS Packets April 2015

 Where there is a proxy involved:
                            +----------------+
                            | RADIUS   CoA   |
                            | Client  Server |
                            +----------------+
                               |        ^
               Access-Request  |        |   CoA-Request
                               v        |
                            +----------------+
                            | RADIUS   CoA   |
                            | Proxy   Proxy  |
                            +----------------+
                               |        ^
               Access-Request  |        |   CoA-Request
                               v        |
                            +----------------+
                            | RADIUS   CoA   |
                            | Server  Client |
                            +----------------+
 That is, the RADIUS and CoA subsystems at each hop are strongly
 connected.  Where they are not strongly connected, it will be
 impossible to use CoA-Request packets to transport large amounts of
 authorization data.
 This design is more complicated than allowing for fragmented CoA
 packets.  However, the CoA client and the RADIUS Server must
 communicate even when not using this specification.  We believe that
 standardizing that communication and using one method for exchange of
 large data are preferred to unspecified communication methods and
 multiple ways of achieving the same result.  If we were to allow
 fragmentation of data over CoA packets, the size and complexity of
 this specification would increase significantly.
 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.

4. Overview

 Authorization exchanges can occur either before or after end-user
 authentication has been completed.  An authorization exchange before
 authentication allows a RADIUS Client to provide the RADIUS Server
 with information that MAY modify how the authentication process will

Perez-Mendez, et al. Experimental [Page 10] RFC 7499 Fragmentation of RADIUS Packets April 2015

 be performed (e.g., it may affect the selection of the EAP method).
 An authorization exchange after authentication allows the RADIUS
 Server to provide the RADIUS Client with information about the end
 user, the results of the authentication process, and/or obligations
 to be enforced.  In this specification, we refer to
 "pre-authorization" as the exchange of authorization information
 before the end-user authentication has started (from the RADIUS
 Client to the RADIUS Server), whereas the term "post-authorization"
 is used to refer to an authorization exchange happening after this
 authentication process (from the RADIUS Server to the RADIUS Client).
 In this specification, we refer to the "size limit" as the practical
 limit on RADIUS packet sizes.  This limit is the minimum between
 4096 bytes and the current PMTU.  We define below a method that uses
 Access-Request and Access-Accept in order to exchange fragmented
 data.  The RADIUS Client and Server exchange a series of
 Access-Request / Access-Accept packets, until such time as all of the
 fragmented data has been transported.  Each packet contains a
 Frag-Status attribute, which lets the other party know if
 fragmentation is desired, ongoing, or finished.  Each packet may also
 contain the fragmented data or may instead be an "ACK" to a previous
 fragment from the other party.  Each Access-Request contains a
 User-Name attribute, allowing the packet to be proxied if necessary
 (see Section 11.1).  Each Access-Request may also contain a State
 attribute, which serves to tie it to a previous Access-Accept.  Each
 Access-Accept contains a State attribute, for use by the RADIUS
 Client in a later Access-Request.  Each Access-Accept contains a
 Service-Type attribute with the "Additional-Authorization" value.
 This indicates that the service being provided is part of a
 fragmented exchange and that the Access-Accept should not be
 interpreted as providing network access to the end user.
 When a RADIUS Client or RADIUS Server needs to send data that exceeds
 the size limit, the mechanism proposed in this document is used.
 Instead of encoding one large RADIUS packet, a series of smaller
 RADIUS packets of the same type are encoded.  Each smaller packet is
 called a "chunk" in this specification, in order to distinguish it
 from traditional RADIUS packets.  The encoding process is a simple
 linear walk over the attributes to be encoded.  This walk preserves
 the order of the attributes of the same type, as required by
 [RFC2865].  The number of attributes encoded in a particular chunk
 depends on the size limit, the size of each attribute, the number of
 proxies between the RADIUS Client and RADIUS Server, and the overhead
 for fragmentation-signaling attributes.  Specific details are given
 in Section 6.  A new attribute called Frag-Status (Section 10.1)
 signals the fragmentation status.

Perez-Mendez, et al. Experimental [Page 11] RFC 7499 Fragmentation of RADIUS Packets April 2015

 After the first chunk is encoded, it is sent to the other party.  The
 packet is identified as a chunk via the Frag-Status attribute.  The
 other party then requests additional chunks, again using the
 Frag-Status attribute.  This process is repeated until all the
 attributes have been sent from one party to the other.  When all the
 chunks have been received, the original list of attributes is
 reconstructed and processed as if it had been received in one packet.
 The reconstruction process is performed by simply appending all of
 the chunks together.  Unlike IPv4 fragmentation, there is no Fragment
 Offset field.  The chunks in this specification are explicitly
 ordered, as RADIUS is a lock-step protocol, as noted in Section 12.4.
 That is, chunk N+1 cannot be sent until all of the chunks up to and
 including N have been received and acknowledged.
 When multiple chunks are sent, a special situation may occur for Long
 Extended Type attributes as defined in [RFC6929].  The fragmentation
 process may split a fragmented attribute across two or more chunks,
 which is not permitted by that specification.  We address this issue
 by using the newly defined T flag in the Reserved field of the Long
 Extended Type attribute format (see Section 9 for further details on
 this flag).
 This last situation is expected to be the most common occurrence in
 chunks.  Typically, packet fragmentation will occur as a consequence
 of a desire to send one or more large (and therefore fragmented)
 attributes.  The large attribute will likely be split into two or
 more pieces.  Where chunking does not split a fragmented attribute,
 no special treatment is necessary.
 The setting of the T flag is the only case where the chunking process
 affects the content of an attribute.  Even then, the Value fields of
 all attributes remain unchanged.  Any per-packet security attributes,
 such as Message-Authenticator, are calculated for each chunk
 independently.  Neither integrity checks nor security checks are
 performed on the "original" packet.
 Each RADIUS packet sent or received as part of the chunking process
 MUST be a valid packet, subject to all format and security
 requirements.  This requirement ensures that a "transparent" proxy
 not implementing this specification can receive and send compliant
 packets.  That is, a proxy that simply forwards packets without
 detailed examination or any modification will be able to proxy
 "chunks".

Perez-Mendez, et al. Experimental [Page 12] RFC 7499 Fragmentation of RADIUS Packets April 2015

5. Fragmentation of Packets

 When the RADIUS Client or the RADIUS Server desires to send a packet
 that exceeds the size limit, it is split into chunks and sent via
 multiple client/server exchanges.  The exchange is indicated via the
 Frag-Status attribute, which has value More-Data-Pending for all but
 the last chunk of the series.  The chunks are tied together via the
 State attribute.
 The delivery of a large fragmented RADIUS packet with authorization
 data can happen before or after the end user has been authenticated
 by the RADIUS Server.  We can distinguish two phases, which can be
 omitted if there is no authorization data to be sent:
 1.  Pre-authorization.  In this phase, the RADIUS Client MAY send a
     large packet with authorization information to the RADIUS Server
     before the end user is authenticated.  Only the RADIUS Client is
     allowed to send authorization data during this phase.
 2.  Post-authorization.  In this phase, the RADIUS Server MAY send a
     large packet with authorization data to the RADIUS Client after
     the end user has been authenticated.  Only the RADIUS Server is
     allowed to send authorization data during this phase.
 The following subsections describe how to perform fragmentation for
 packets for these two phases.  We give the packet type, along with a
 RADIUS Identifier, to indicate that requests and responses are
 connected.  We then give a list of attributes.  We do not give values
 for most attributes, as we wish to concentrate on the fragmentation
 behavior rather than packet contents.  Attribute values are given for
 attributes relevant to the fragmentation process.  Where "long
 extended" attributes are used, we indicate the M (More) and T
 (Truncation) flags as optional square brackets after the attribute
 name.  As no "long extended" attributes have yet been defined, we use
 example attributes, named as "Example-Long-1", etc.  For the sake of
 simplicity, the maximum chunk size is established in terms of the
 number of attributes (11).

Perez-Mendez, et al. Experimental [Page 13] RFC 7499 Fragmentation of RADIUS Packets April 2015

5.1. Pre-Authorization

 When the RADIUS Client needs to send a large amount of data to the
 RADIUS Server, the data to be sent is split into chunks and sent to
 the RADIUS Server via multiple Access-Request / Access-Accept
 exchanges.  The example below shows this exchange.
 The following is an Access-Request that the RADIUS Client intends to
 send to a RADIUS Server.  However, due to a combination of issues
 (PMTU, large attributes, etc.), the content does not fit into one
 Access-Request packet.
 Access-Request
     User-Name
     NAS-Identifier
     Calling-Station-Id
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1
     Example-Long-2 [M]
     Example-Long-2 [M]
     Example-Long-2
                   Figure 1: Desired Access-Request
 The RADIUS Client therefore must send the attributes listed above in
 a series of chunks.  The first chunk contains eight (8) attributes
 from the original Access-Request, and a Frag-Status attribute.  Since
 the last attribute is "Example-Long-1" with the M flag set, the
 chunking process also sets the T flag in that attribute.  The
 Access-Request is sent with a RADIUS Identifier field having
 value 23.  The Frag-Status attribute has value More-Data-Pending, to
 indicate that the RADIUS Client wishes to send more data in a
 subsequent Access-Request.  The RADIUS Client also adds a
 Service-Type attribute, which indicates that it is part of the
 chunking process.  The packet is signed with the
 Message-Authenticator attribute, completing the maximum number of
 attributes (11).

Perez-Mendez, et al. Experimental [Page 14] RFC 7499 Fragmentation of RADIUS Packets April 2015

 Access-Request (ID = 23)
     User-Name
     NAS-Identifier
     Calling-Station-Id
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [MT]
     Frag-Status = More-Data-Pending
     Service-Type = Additional-Authorization
     Message-Authenticator
                  Figure 2: Access-Request (Chunk 1)
 Compliant RADIUS Servers (i.e., servers implementing fragmentation)
 receiving this packet will see the Frag-Status attribute and will
 postpone all authorization and authentication handling until all of
 the chunks have been received.  This postponement also applies to the
 verification that the Access-Request packet contains some kind of
 authentication attribute (e.g., User-Password, CHAP-Password, State,
 or other future attribute), as required by [RFC2865] (see
 Section 12.2 for more information on this).
 Non-compliant RADIUS Servers (i.e., servers not implementing
 fragmentation) should also see the Service-Type requesting
 provisioning for an unknown service and return Access-Reject.  Other
 non-compliant RADIUS Servers may return an Access-Reject or
 Access-Challenge, or they may return an Access-Accept with a
 particular Service-Type other than Additional-Authorization.
 Compliant RADIUS Client implementations MUST treat these responses as
 if they had received Access-Reject instead.
 Compliant RADIUS Servers who wish to receive all of the chunks will
 respond with the following packet.  The value of the State here is
 arbitrary and serves only as a unique token for example purposes.  We
 only note that it MUST be temporally unique to the RADIUS Server.
 Access-Accept (ID = 23)
     Frag-Status = More-Data-Request
     Service-Type = Additional-Authorization
     State = 0xabc00001
     Message-Authenticator
                   Figure 3: Access-Accept (Chunk 1)

Perez-Mendez, et al. Experimental [Page 15] RFC 7499 Fragmentation of RADIUS Packets April 2015

 The RADIUS Client will see this response and use the RADIUS
 Identifier field to associate it with an ongoing chunking session.
 Compliant RADIUS Clients will then continue the chunking process.
 Non-compliant RADIUS Clients will never see a response such as this,
 as they will never send a Frag-Status attribute.  The Service-Type
 attribute is included in the Access-Accept in order to signal that
 the response is part of the chunking process.  This packet therefore
 does not provision any network service for the end user.
 The RADIUS Client continues the process by sending the next chunk,
 which includes an additional six (6) attributes from the original
 packet.  It again includes the User-Name attribute, so that
 non-compliant proxies can process the packet (see Section 11.1).  It
 sets the Frag-Status attribute to More-Data-Pending, as more data is
 pending.  It includes a Service-Type, for the reasons described
 above.  It includes the State attribute from the previous
 Access-Accept.  It signs the packet with Message-Authenticator, as
 there are no authentication attributes in the packet.  It uses a new
 RADIUS Identifier field.
 Access-Request (ID = 181)
     User-Name
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1
     Example-Long-2 [M]
     Example-Long-2 [MT]
     Frag-Status = More-Data-Pending
     Service-Type = Additional-Authorization
     State = 0xabc000001
     Message-Authenticator
                  Figure 4: Access-Request (Chunk 2)
 Compliant RADIUS Servers receiving this packet will see the
 Frag-Status attribute and look for a State attribute.  Since one
 exists and it matches a State sent in an Access-Accept, this packet
 is part of a chunking process.  The RADIUS Server will associate the
 attributes with the previous chunk.  Since the Frag-Status attribute
 has value More-Data-Request, the RADIUS Server will respond with an
 Access-Accept as before.  It MUST include a State attribute, with a
 value different from the previous Access-Accept.  This State MUST
 again be globally and temporally unique.

Perez-Mendez, et al. Experimental [Page 16] RFC 7499 Fragmentation of RADIUS Packets April 2015

 Access-Accept (ID = 181)
     Frag-Status = More-Data-Request
     Service-Type = Additional-Authorization
     State = 0xdef00002
     Message-Authenticator
                   Figure 5: Access-Accept (Chunk 2)
 The RADIUS Client will see this response and use the RADIUS
 Identifier field to associate it with an ongoing chunking session.
 The RADIUS Client continues the chunking process by sending the next
 chunk, with the final attribute(s) from the original packet, and
 again includes the original User-Name attribute.  The Frag-Status
 attribute is not included in the next Access-Request, as no more
 chunks are available for sending.  The RADIUS Client includes the
 State attribute from the previous Access-Accept.  It signs the packet
 with Message-Authenticator, as there are no authentication attributes
 in the packet.  It again uses a new RADIUS Identifier field.
 Access-Request (ID = 241)
     User-Name
     Example-Long-2
     State = 0xdef00002
     Message-Authenticator
                  Figure 6: Access-Request (Chunk 3)
 On reception of this last chunk, the RADIUS Server matches it with an
 ongoing session via the State attribute and sees that there is no
 Frag-Status attribute present.  It then processes the received
 attributes as if they had been sent in one RADIUS packet.  See
 Section 8.4 for further details on this process.  It generates the
 appropriate response, which can be either Access-Accept or
 Access-Reject.  In this example, we show an Access-Accept.  The
 RADIUS Server MUST send a State attribute, which allows linking the
 received data with the authentication process.
 Access-Accept (ID = 241)
     State = 0x98700003
     Message-Authenticator
                   Figure 7: Access-Accept (Chunk 3)
 The above example shows in practice how the chunking process works.
 We reiterate the implementation and security requirements here.

Perez-Mendez, et al. Experimental [Page 17] RFC 7499 Fragmentation of RADIUS Packets April 2015

 Each chunk is a valid RADIUS packet (see Section 12.2 for some
 considerations about this), and all RADIUS format and security
 requirements MUST be followed before any chunking process is applied.
 Every chunk except for the last one from a RADIUS Client MUST include
 a Frag-Status attribute, with value More-Data-Pending.  The last
 chunk MUST NOT contain a Frag-Status attribute.  Each chunk except
 for the last one from a RADIUS Client MUST include a Service-Type
 attribute, with value Additional-Authorization.  Each chunk MUST
 include a User-Name attribute, which MUST be identical in all chunks.
 Each chunk except for the first one from a RADIUS Client MUST include
 a State attribute, which MUST be copied from a previous
 Access-Accept.
 Each Access-Accept MUST include a State attribute.  The value for
 this attribute MUST change in every new Access-Accept and MUST be
 globally and temporally unique.

5.2. Post-Authorization

 When the RADIUS Server wants to send a large amount of authorization
 data to the RADIUS Client after authentication, the operation is very
 similar to the pre-authorization process.  The presence of a
 Service-Type = Additional-Authorization attribute ensures that a
 RADIUS Client not supporting this specification will 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 signaling.  It is
 RECOMMENDED that RADIUS Servers include a State attribute in their
 original Access-Accept packets, even if fragmentation is not taking
 place, to allow the RADIUS Client to send additional authorization
 data in subsequent exchanges.  This State attribute would be included
 in the last transmitted chunk, to avoid confusion with the ones used
 for fragmentation signaling.
 Clients supporting this specification MUST include a Frag-Status =
 Fragmentation-Supported attribute in the first Access-Request sent to
 the RADIUS Server, in order to indicate that they would accept
 fragmented data from the server.  This is not required if the
 pre-authorization process was carried out, as it is implicit.

Perez-Mendez, et al. Experimental [Page 18] RFC 7499 Fragmentation of RADIUS Packets April 2015

 The following is an Access-Accept that the RADIUS Server intends to
 send to a RADIUS Client.  However, due to a combination of issues
 (PMTU, large attributes, etc.), the content does not fit into one
 Access-Accept packet.
 Access-Accept
     User-Name
     EAP-Message
     Service-Type = Login
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1
     Example-Long-2 [M]
     Example-Long-2 [M]
     Example-Long-2
     State = 0xcba00003
                    Figure 8: Desired Access-Accept
 The RADIUS Server therefore must send the attributes listed above in
 a series of chunks.  The first chunk contains seven (7) attributes
 from the original Access-Accept, and a Frag-Status attribute.  Since
 the last attribute is "Example-Long-1" with the M flag set, the
 chunking process also sets the T flag in that attribute.  The
 Access-Accept is sent with a RADIUS Identifier field having value 30,
 corresponding to a previous Access-Request not depicted.  The
 Frag-Status attribute has value More-Data-Pending, to indicate that
 the RADIUS Server wishes to send more data in a subsequent
 Access-Accept.  The RADIUS Server also adds a Service-Type attribute
 with value Additional-Authorization, which indicates that it is part
 of the chunking process.  Note that the original Service-Type is not
 included in this chunk.  Finally, a State attribute is included to
 allow matching subsequent requests with this conversation, and the
 packet is signed with the Message-Authenticator attribute, completing
 the maximum number of attributes (11).

Perez-Mendez, et al. Experimental [Page 19] RFC 7499 Fragmentation of RADIUS Packets April 2015

 Access-Accept (ID = 30)
     User-Name
     EAP-Message
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [MT]
     Frag-Status = More-Data-Pending
     Service-Type = Additional-Authorization
     State = 0xcba00004
     Message-Authenticator
                   Figure 9: Access-Accept (Chunk 1)
 Compliant RADIUS Clients receiving this packet will see the
 Frag-Status attribute and suspend all authorization handling until
 all of the chunks have been received.  Non-compliant RADIUS Clients
 should also see the Service-Type indicating the provisioning for an
 unknown service and will treat it as an Access-Reject.
 RADIUS Clients who wish to receive all of the chunks will respond
 with the following packet, where the value of the State attribute is
 taken from the received Access-Accept.  They will also include the
 User-Name attribute so that non-compliant proxies can process the
 packet (Section 11.1).
 Access-Request (ID = 131)
     User-Name
     Frag-Status = More-Data-Request
     Service-Type = Additional-Authorization
     State = 0xcba00004
     Message-Authenticator
                  Figure 10: Access-Request (Chunk 1)
 The RADIUS Server receives this request and uses the State attribute
 to associate it with an ongoing chunking session.  Compliant RADIUS
 Servers will then continue the chunking process.  Non-compliant
 RADIUS Servers will never see a response such as this, as they will
 never send a Frag-Status attribute.
 The RADIUS Server continues the chunking process by sending the next
 chunk, with the final attribute(s) from the original packet.  The
 value of the Identifier field is taken from the received
 Access-Request.  A Frag-Status attribute is not included in the next
 Access-Accept, as no more chunks are available for sending.  The

Perez-Mendez, et al. Experimental [Page 20] RFC 7499 Fragmentation of RADIUS Packets April 2015

 RADIUS Server includes the original State attribute to allow the
 RADIUS Client to send additional authorization data.  The original
 Service-Type attribute is included as well.
 Access-Accept (ID = 131)
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1 [M]
     Example-Long-1
     Example-Long-2 [M]
     Example-Long-2 [M]
     Example-Long-2
     Service-Type = Login
     State = 0xfda000003
     Message-Authenticator
                  Figure 11: Access-Accept (Chunk 2)
 On reception of this last chunk, the RADIUS Client matches it with an
 ongoing session via the Identifier field and sees that there is no
 Frag-Status attribute present.  It then processes the received
 attributes as if they had been sent in one RADIUS packet.  See
 Section 8.4 for further details on this process.

6. Chunk Size

 In an ideal scenario, each intermediate chunk would be exactly the
 size limit in length.  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
     in every chunk.
 2.  RADIUS fragmentation requires the introduction of some extra
     attributes for signaling.  Specifically, a Frag-Status attribute
     (7 bytes) is included in 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 RADIUS Server to bind an
     Access-Request with a previous Access-Challenge.  User-Name
     attributes (from 3 to 255 bytes) are included in every chunk the
     RADIUS 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 signaling data, reducing
     the amount of payload information that can be sent in each chunk.

Perez-Mendez, et al. Experimental [Page 21] RFC 7499 Fragmentation of RADIUS Packets April 2015

 3.  RADIUS packets SHOULD be adjusted to avoid exceeding the network
     MTU.  Otherwise, IP fragmentation may occur, with 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 in the chunk.  This
     is described in further detail in Section 8.1.

7. Allowed Large Packet Size

 There are no provisions for signaling 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 and can include RADIUS attribute header fields,
 or it can be one or more "large" attributes (more than 256 bytes 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
 will take on future packets.  As a result, it is impossible to signal
 any meaningful value for the total amount of additional data.
 Unauthenticated end users are permitted to trigger the exchange of
 large amounts of fragmented data between the RADIUS Client and the
 RADIUS Server, having the potential to allow denial-of-service (DoS)
 attacks.  An attacker could initiate a large number of connections,
 each of which requests the RADIUS Server to store a large amount of
 data.  This data could cause memory exhaustion on the RADIUS Server
 and result in authentic users being denied access.  It is worth
 noting that authentication mechanisms are already designed to avoid
 exceeding the size limit.
 Hence, implementations of this specification MUST limit the total
 amount of data they send and/or receive via this specification.  Its
 default value SHOULD be 100 kilobytes.  Any more than this may turn
 RADIUS into a generic transport protocol, which is undesirable.  This
 limit SHOULD be configurable, 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.  Its default value
 SHOULD be 25.  Any more than this may indicate an implementation
 error, misconfiguration, or DoS attack.  This limit SHOULD be
 configurable, so that it can be changed if necessary.

Perez-Mendez, et al. Experimental [Page 22] RFC 7499 Fragmentation of RADIUS Packets April 2015

 For instance, let's imagine that the RADIUS Server wants to transport
 a SAML assertion that is 15000 bytes long to the RADIUS Client.  In
 this hypothetical scenario, we assume that there are three
 intermediate proxies, each one inserting a Proxy-State attribute of
 20 bytes.  Also, we assume that the State attributes generated by the
 RADIUS Server have a size of 6 bytes and the User-Name attribute
 takes 50 bytes.  Therefore, the amount of free space in a chunk for
 the transport of the SAML assertion attributes is as follows:
 Total (4096 bytes) - RADIUS header (20 bytes) - User-Name (50 bytes)
 - Frag-Status (7 bytes) - Service-Type (6 bytes) - State (6 bytes) -
 Proxy-State (20 bytes) - Proxy-State (20 bytes) - Proxy-State
 (20 bytes) - Message-Authenticator (18 bytes), resulting in a total
 of 3929 bytes.  This amount of free space allows the transmission of
 up to 15 attributes of 255 bytes each.
 According to [RFC6929], a Long-Extended-Type provides a payload of
 251 bytes.  Therefore, the SAML assertion described above would
 result in 60 attributes, requiring four round trips to be completely
 transmitted.

8. Handling Special Attributes

8.1. Proxy-State Attribute

 RADIUS proxies may introduce Proxy-State attributes into any
 Access-Request packet they forward.  If they are unable to add this
 information to the packet, they may silently discard it rather than
 forward it to its destination; this would lead to DoS situations.
 Moreover, any Proxy-State attribute received by a RADIUS Server in an
 Access-Request packet MUST be copied into the corresponding reply
 packet.  For these reasons, Proxy-State attributes require 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 in
 the reply packet.  This means that the RADIUS 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 much space MUST
 be left in 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, RADIUS Clients need a mechanism to discover the amount of

Perez-Mendez, et al. Experimental [Page 23] RFC 7499 Fragmentation of RADIUS Packets April 2015

 space required by proxies to introduce their Proxy-State attributes.
 In the following paragraphs, we describe a new mechanism to perform
 such a discovery:
 1.  When a RADIUS Client does not know how much 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 RADIUS 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 RADIUS Client in the
     next reply packet, encoded into a new attribute called
     Proxy-State-Length.  The RADIUS Server MAY artificially increase
     this quantity in order to handle situations where proxies behave
     inconsistently (e.g., they generate Proxy-State attributes with a
     different size for each packet) or where intermediary proxies
     remove Proxy-State attributes generated by other proxies.
     Increasing this value would make the RADIUS Client leave some
     free space for these situations.
 3.  The RADIUS Client SHOULD respond to the reception of this
     attribute by adjusting the maximum size for the next chunk
     accordingly.  However, as the Proxy-State-Length offers just an
     estimation of the space required by the proxies, the RADIUS
     Client MAY select a smaller amount in environments known to be
     problematic.

8.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 to the fragmentation.  If the procedure
 described in Section 5 is followed, two different State attributes
 could be included in a single chunk.  This is something explicitly
 forbidden in [RFC2865].
 A straightforward solution consists of making the RADIUS Server send
 the original State attribute in the last chunk of the sequence
 (attributes can be reordered 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.

Perez-Mendez, et al. Experimental [Page 24] RFC 7499 Fragmentation of RADIUS Packets April 2015

 Something similar happens when the RADIUS Client has to send a
 fragmented packet that contains a State attribute in it.  The RADIUS
 Client MUST ensure that this original State is included in the first
 chunk sent to the RADIUS Server (as this one never contains any State
 attribute due to fragmentation).

8.3. Service-Type Attribute

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

8.4. Rebuilding the Original Large Packet

 The RADIUS Client stores the RADIUS attributes received in each chunk
 in a list, 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 that list, as they have been
 introduced as part of the fragmentation signaling and hence 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-Length
 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  Service-Type = Additional-Authorization
 o  Frag-Status
 o  Proxy-State (except the ones in the last chunk)
 o  User-Name (except the one in the first chunk)

Perez-Mendez, et al. Experimental [Page 25] RFC 7499 Fragmentation of RADIUS Packets April 2015

9. New T Flag for the Long Extended Type Attribute Definition

 This document defines a new field in the Long Extended Type attribute
 format.  This field is one bit in size and is called "T" for
 Truncation.  It indicates that the attribute is intentionally
 truncated in this chunk and is to be continued in the next chunk of
 the sequence.  The combination of the M flag and the T flag indicates
 that the attribute is fragmented (M flag) but that all the fragments
 are not available in this chunk (T flag).  Proxies implementing
 [RFC6929] will see these attributes as invalid (they will not be able
 to reconstruct them), but they will still forward them, as
 Section 5.2 of [RFC6929] indicates that they SHOULD forward unknown
 attributes anyway.
 As a consequence of this addition, the Reserved field is now 6 bits
 long (see Section 12.1 for some considerations).  The following
 figure represents the new attribute format:
     0                   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 |M|T| Reserved  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Value ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Figure 12: Updated Long Extended Type Attribute Format

10. New Attribute Definition

 This document proposes the definition of two new extended type
 attributes, called Frag-Status and Proxy-State-Length.  The format of
 these attributes follows the indications for an Extended Type
 attribute defined in [RFC6929].

Perez-Mendez, et al. Experimental [Page 26] RFC 7499 Fragmentation of RADIUS Packets April 2015

10.1. Frag-Status Attribute

 This attribute is used for fragmentation signaling, and its meaning
 depends on the code value transported within it.  The following
 figure represents the format of the Frag-Status attribute:
     0                   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 13: Frag-Status Format
 Type
    241
 Length
    7
 Extended-Type
    1
 Code
    4 bytes.  Integer indicating the code.  The values defined in this
    specification are:
       0 - Reserved
       1 - Fragmentation-Supported
       2 - More-Data-Pending
       3 - 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.  RADIUS Clients supporting this specification MUST include a
 Frag-Status = Fragmentation-Supported attribute in the first
 Access-Request sent to the RADIUS Server, in order to indicate that
 they would accept fragmented data from the server.

Perez-Mendez, et al. Experimental [Page 27] RFC 7499 Fragmentation of RADIUS Packets April 2015

10.2. Proxy-State-Length Attribute

 This attribute indicates to the RADIUS Client the length of the
 Proxy-State attributes received by the RADIUS Server.  This
 information is useful for adjusting the length of the chunks sent by
 the RADIUS Client.  The format of this Proxy-State-Length attribute
 is as follows:
     0                   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 14: Proxy-State-Length Format
 Type
    241
 Length
    7
 Extended-Type
    2
 Value
    4 bytes.  Total length (in bytes) of received Proxy-State
    attributes (including headers).  As the RADIUS Length field cannot
    take values over 4096 bytes, values of Proxy-State-Length MUST be
    less than that maximum length.
 This attribute MAY be present in Access-Challenge and Access-Accept
 packets.  It MUST NOT be included in Access-Request or Access-Reject
 packets.

Perez-Mendez, et al. Experimental [Page 28] RFC 7499 Fragmentation of RADIUS Packets April 2015

10.3. Table of Attributes

 The following table shows the different attributes defined in this
 document, along with the types of RADIUS packets in which they can be
 present.
                          |     Type of Packet    |
                          +-----+-----+-----+-----+
    Attribute Name        | Req | Acc | Rej | Cha |
    ----------------------+-----+-----+-----+-----+
    Frag-Status           | 0-1 | 0-1 |  0  | 0-1 |
    ----------------------+-----+-----+-----+-----+
    Proxy-State-Length    | 0   | 0-1 |  0  | 0-1 |
    ----------------------+-----+-----+-----+-----+

11. 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.

11.1. Legacy Proxies

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

11.2. Updated Proxies

 Updated proxies can interact with RADIUS Clients and Servers in order
 to obtain the complete large packet before starting to forward 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 example in
 Figure 15 shows how an updated proxy interacts with the RADIUS Client
 to (1) obtain a large Access-Request packet and (2) modify an
 attribute, resulting in an even larger packet.  The proxy then
 interacts with the RADIUS Server to complete the transmission of the
 modified packet, as shown in Figure 16.

Perez-Mendez, et al. Experimental [Page 29] RFC 7499 Fragmentation of RADIUS Packets April 2015

   +-+-+-+-+-+                                          +-+-+-+-+-+
   | RADIUS  |                                          | RADIUS  |
   | Client  |                                          | Proxy   |
   +-+-+-+-+-+                                          +-+-+-+-+-+
       |                                                    |
       | Access-Request(1){User-Name,Calling-Station-Id,    |
       |        Example-Long-1[M],Example-Long-1[M],        |
       |        Example-Long-1[M],Example-Long-1[M],        |
       |        Example-Long-1[MT],Frag-Status(MDP)}        |
       |--------------------------------------------------->|
       |                                                    |
       |                     Access-Challenge(1){User-Name, |
       |                           Frag-Status(MDR),State1} |
       |<---------------------------------------------------|
       |                                                    |
       | Access-Request(2){User-Name,State1,                |
       |        Example-Long-1[M],Example-Long-1[M],        |
       |        Example-Long-1[M],Example-Long-1}           |
       |--------------------------------------------------->|
            Proxy Modifies Attribute Data, Increasing Its
               Size from 9 Fragments to 11 Fragments
         Figure 15: Updated Proxy Interacts with RADIUS Client

Perez-Mendez, et al. Experimental [Page 30] RFC 7499 Fragmentation of RADIUS Packets April 2015

   +-+-+-+-+-+                                          +-+-+-+-+-+
   | RADIUS  |                                          | RADIUS  |
   | Proxy   |                                          | Server  |
   +-+-+-+-+-+                                          +-+-+-+-+-+
       |                                                    |
       | Access-Request(3){User-Name,Calling-Station-Id,    |
       |        Example-Long-1[M],Example-Long-1[M],        |
       |        Example-Long-1[M],Example-Long-1[M],        |
       |        Example-Long-1[MT],Frag-Status(MDP)}        |
       |--------------------------------------------------->|
       |                                                    |
       |                     Access-Challenge(1){User-Name, |
       |                           Frag-Status(MDR),State2} |
       |<---------------------------------------------------|
       |                                                    |
       | Access-Request(4){User-Name,State2,                |
       |        Example-Long-1[M],Example-Long-1[M],        |
       |        Example-Long-1[M],Example-Long-1[M],        |
       |        Example-Long-1[MT],Frag-Status(MDP)}        |
       |--------------------------------------------------->|
       |                                                    |
       |                     Access-Challenge(1){User-Name, |
       |                           Frag-Status(MDR),State3} |
       |<---------------------------------------------------|
       |                                                    |
       | Access-Request(5){User-Name,State3,Example-Long-1} |
       |--------------------------------------------------->|
         Figure 16: Updated Proxy Interacts with RADIUS Server

12. General Considerations

12.1. T Flag

 As described in Section 9, this document modifies the definition of
 the Reserved field of the Long Extended Type attribute [RFC6929] by
 allocating an additional flag called the T flag.  The meaning and
 position of this flag are defined in this document, and nowhere else.
 This might cause an issue if subsequent specifications want to
 allocate a new flag as well, as there would be no direct way for them
 to know which parts of the Reserved field have already been defined.
 An immediate and reasonable solution for this issue would be
 declaring that this RFC updates [RFC6929].  In this way, [RFC6929]
 would include an "Updated by" clause that will point readers to this
 document.  Another alternative would be creating an IANA registry for

Perez-Mendez, et al. Experimental [Page 31] RFC 7499 Fragmentation of RADIUS Packets April 2015

 the Reserved field.  However, the RADIUS Extensions (RADEXT) working
 group thinks that would be overkill, as a large number of
 specifications extending that field are not expected.
 In the end, the proposed solution is that this experimental RFC
 should not update RFC 6929.  Instead, we rely on the collective mind
 of the working group to remember that this T flag is being used as
 specified by this Experimental document.  If the experiment is
 successful, the T flag will be properly assigned.

12.2. Violation of RFC 2865

 Section 5.1 indicates that all authorization and authentication
 handling will be postponed until all the chunks have been received.
 This postponement also applies to the verification that the
 Access-Request packet contains some kind of authentication attribute
 (e.g., User-Password, CHAP-Password, State, or other future
 attribute), as required by [RFC2865].  This checking will therefore
 be delayed until the original large packet has been rebuilt, as some
 of the chunks may not contain any of them.
 The authors acknowledge that this specification violates the "MUST"
 requirement of [RFC2865], Section 4.1 that states that "An
 Access-Request MUST contain either a User-Password or a CHAP-Password
 or a State."  We note that a proxy that enforces that requirement
 would be unable to support future RADIUS authentication extensions.
 Extensions to the protocol would therefore be impossible to deploy.
 All known implementations have chosen the philosophy of "be liberal
 in what you accept."  That is, they accept traffic that violates the
 requirement of [RFC2865], Section 4.1.  We therefore expect to see no
 operational issues with this specification.  After we gain more
 operational experience with this specification, it can be reissued as
 a Standards Track document and can update [RFC2865].

12.3. Proxying Based on User-Name

 This proposal assumes that legacy proxies base their routing
 decisions on the value of the User-Name attribute.  For this reason,
 every packet sent from the RADIUS Client to the RADIUS Server (either
 chunks or requests for more chunks) MUST contain a User-Name
 attribute.

Perez-Mendez, et al. Experimental [Page 32] RFC 7499 Fragmentation of RADIUS Packets April 2015

12.4. Transport Behavior

 This proposal does not modify the way RADIUS interacts with the
 underlying transport (UDP).  That is, RADIUS keeps following a
 lock-step behavior that requires receiving an explicit
 acknowledgement for each chunk sent.  Hence, bursts of traffic
 that could congest links between peers are not an issue.
 Another benefit of the lock-step nature of RADIUS is that there are
 no security issues with overlapping fragments.  Each chunk simply has
 a length, with no Fragment Offset field as with IPv4.  The order of
 the fragments is determined by the order in which they are received.
 There is no ambiguity about the size or placement of each chunk, and
 therefore no security issues associated with overlapping chunks.

13. 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
 authenticated 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.  RADIUS 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 7 gives some indications of what
 could be 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
 stored in an external database or in files.  This approach mitigates
 the resource exhaustion issue, as RADIUS Servers today already store
 large amounts of accounting data.

Perez-Mendez, et al. Experimental [Page 33] RFC 7499 Fragmentation of RADIUS Packets April 2015

14. IANA Considerations

 The Internet Assigned Numbers Authority (IANA) has registered the
 Attribute Types and Attribute Values defined in this document in 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
 has updated <http://www.iana.org/assignments/radius-types>
 accordingly.
 In particular, this document defines two new RADIUS attributes,
 entitled "Frag-Status" (value 241.1) and "Proxy-State-Length"
 (value 241.2), which have been allocated from the short extended
 space as described in [RFC6929]:
 Type     Name                 Length  Meaning
 ----     ----                 ------  -------
 241.1    Frag-Status          7       Signals fragmentation
 241.2    Proxy-State-Length   7       Indicates the length of the
                                       received Proxy-State attributes
 The Frag-Status attribute also defines an 8-bit "Code" field, for
 which IANA has created and now maintains a new sub-registry entitled
 "Code Values for RADIUS Attribute 241.1, Frag-Status".  Initial
 values for the RADIUS Frag-Status "Code" registry are given below;
 future assignments are to be made through "RFC Required" [RFC5226].
 Assignments consist of a Frag-Status "Code" name and its associated
 value.
       Value    Frag-Status Code Name           Definition
       ----     ------------------------        ----------
       0        Reserved                        See Section 10.1
       1        Fragmentation-Supported         See Section 10.1
       2        More-Data-Pending               See Section 10.1
       3        More-Data-Request               See Section 10.1
       4-255    Unassigned
 Additionally, IANA has allocated a new Service-Type value for
 "Additional-Authorization".
       Value    Service Type Value              Definition
       ----     ------------------------        ----------
       19       Additional-Authorization        See Section 5.1

Perez-Mendez, et al. Experimental [Page 34] RFC 7499 Fragmentation of RADIUS Packets April 2015

15. References

15.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
            "Remote Authentication Dial In User Service (RADIUS)",
            RFC 2865, June 2000, <http://www.rfc-editor.org/
            info/rfc2865>.
 [RFC3575]  Aboba, B., "IANA Considerations for RADIUS (Remote
            Authentication Dial In User Service)", RFC 3575,
            July 2003, <http://www.rfc-editor.org/info/rfc3575>.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008, <http://www.rfc-editor.org/info/rfc5226>.
 [RFC6158]  DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines",
            BCP 158, RFC 6158, March 2011,
            <http://www.rfc-editor.org/info/rfc6158>.
 [RFC6929]  DeKok, A. and A. Lior, "Remote Authentication Dial In User
            Service (RADIUS) Protocol Extensions", RFC 6929,
            April 2013, <http://www.rfc-editor.org/info/rfc6929>.

15.2. Informative References

 [ABFAB-Arch]
            Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
            Schaad, "Application Bridging for Federated Access Beyond
            Web (ABFAB) Architecture", Work in Progress,
            draft-ietf-abfab-arch-13, July 2014.
 [RADIUS-Larger-Pkts]
            Hartman, S., "Larger Packets for RADIUS over TCP", Work in
            Progress, draft-ietf-radext-bigger-packets-03, March 2015.
 [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000,
            <http://www.rfc-editor.org/info/rfc2866>.
 [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
            Dial In User Service) Support For Extensible
            Authentication Protocol (EAP)", RFC 3579, September 2003,
            <http://www.rfc-editor.org/info/rfc3579>.

Perez-Mendez, et al. Experimental [Page 35] RFC 7499 Fragmentation of RADIUS Packets April 2015

 [RFC4849]  Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter
            Rule Attribute", RFC 4849, April 2007,
            <http://www.rfc-editor.org/info/rfc4849>.
 [RFC5080]  Nelson, D. and A. DeKok, "Common Remote Authentication
            Dial In User Service (RADIUS) Implementation Issues and
            Suggested Fixes", RFC 5080, December 2007,
            <http://www.rfc-editor.org/info/rfc5080>.
 [RFC5176]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
            Aboba, "Dynamic Authorization Extensions to Remote
            Authentication Dial In User Service (RADIUS)", RFC 5176,
            January 2008, <http://www.rfc-editor.org/info/rfc5176>.
 [SAML-RADIUS]
            Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
            RADIUS Attribute, Binding, Profiles, Name Identifier
            Format, and Confirmation Methods for SAML", Work in
            Progress, draft-ietf-abfab-aaa-saml-10, February 2015.

Perez-Mendez, et al. Experimental [Page 36] RFC 7499 Fragmentation of RADIUS Packets April 2015

Acknowledgements

 The authors would like to thank the members of the RADEXT working
 group who have contributed to the development of this specification
 by either participating in the discussions on the mailing lists or
 sending comments about our RFC.
 The authors also thank David Cuenca (University of Murcia) for
 implementing a proof-of-concept implementation of this RFC that has
 been useful to improve the quality of the specification.
 This work has been partly funded by the GEANT GN3+ SA5 and CLASSe
 (<http://www.um.es/classe/>) projects.

Authors' Addresses

 Alejandro Perez-Mendez (editor)
 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. Experimental [Page 37] RFC 7499 Fragmentation of RADIUS Packets April 2015

 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 SARL
 57bis Boulevard des Alpes
 Meylan  38240
 France
 EMail: aland@networkradius.com
 URI:   http://networkradius.com

Perez-Mendez, et al. Experimental [Page 38]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7499.txt · Last modified: 2015/04/06 20:30 (external edit)