draft-ietf-radext-radius-fragmentation-06.txt   draft-ietf-radext-radius-fragmentation-07.txt 
RADIUS EXTensions Working Group A. Perez-Mendez RADIUS EXTensions Working Group A. Perez-Mendez
Internet-Draft R. Marin-Lopez Internet-Draft R. Marin-Lopez
Updates: RFC6929 (if approved) F. Pereniguez-Garcia Updates: RFC6929 (if approved) F. Pereniguez-Garcia
Intended status: Experimental G. Lopez-Millan Intended status: Experimental G. Lopez-Millan
Expires: October 9, 2014 University of Murcia Expires: January 5, 2015 University of Murcia
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
A. DeKok A. DeKok
Network RADIUS Network RADIUS
April 7, 2014 July 4, 2014
Support of fragmentation of RADIUS packets Support of fragmentation of RADIUS packets
draft-ietf-radext-radius-fragmentation-06 draft-ietf-radext-radius-fragmentation-07
Abstract Abstract
The Remote Authentication Dial-In User Service (RADIUS) protocol is The Remote Authentication Dial-In User Service (RADIUS) protocol is
limited to a total packet size of 4096 octets. Provisions exist for limited to a total packet size of 4096 octets. Provisions exist for
fragmenting large amounts of authentication data across multiple fragmenting large amounts of authentication data across multiple
packets, via Access-Challenge. No similar provisions exist for packets, via Access-Challenge. No similar provisions exist for
fragmenting large amounts of authorization data. This document fragmenting large amounts of authorization data. This document
specifies how existing RADIUS mechanisms can be leveraged to provide specifies how existing RADIUS mechanisms can be leveraged to provide
that functionality. These mechanisms are largely compatible with that functionality. These mechanisms are largely compatible with
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 9, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Scope of this document . . . . . . . . . . . . . . . . . . . . 4 2. Scope of this document . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8 4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 9
4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 9 4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 10
4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 13 4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 14
5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Allowed large packet size . . . . . . . . . . . . . . . . . . 17 6. Allowed large packet size . . . . . . . . . . . . . . . . . . 18
7. Handling special attributes . . . . . . . . . . . . . . . . . 18 7. Handling special attributes . . . . . . . . . . . . . . . . . 19
7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 18 7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 19
7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 19 7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 20
7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 20 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 21
7.4. Rebuilding the original large packet . . . . . . . . . . . 20 7.4. Rebuilding the original large packet . . . . . . . . . . . 21
8. New flag T field for the Long Extended Type attribute 8. New flag T field for the Long Extended Type attribute
definition . . . . . . . . . . . . . . . . . . . . . . . . . . 20 definition . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. New attribute definition . . . . . . . . . . . . . . . . . . . 21 9. New attribute definition . . . . . . . . . . . . . . . . . . . 22
9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 21 9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 22
9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 22 9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 23
9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 23 9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 24
10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23 10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 25
10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 25
10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 24 10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 25
11. Operational considerations . . . . . . . . . . . . . . . . . . 25 11. Operational considerations . . . . . . . . . . . . . . . . . . 27
11.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 26 11.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 28
11.3. Proxying based on User-Name . . . . . . . . . . . . . . . 26 11.3. Proxying based on User-Name . . . . . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 28
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
15.2. Informative References . . . . . . . . . . . . . . . . . . 28 15.1. Normative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 15.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The RADIUS [RFC2865] protocol carries authentication, authorization, The RADIUS [RFC2865] protocol carries authentication, authorization,
and accounting information between a Network Access Server (NAS) and and accounting information between a Network Access Server (NAS) and
an Authentication Server (AS). Information is exchanged between the an Authentication Server (AS). Information is exchanged between the
NAS and the AS through RADIUS packets. Each RADIUS packet is NAS and the AS through RADIUS packets. Each RADIUS packet is
composed of a header, and zero or more attributes, up to a maximum composed of a header, and zero or more attributes, up to a maximum
packet size of 4096 octets. The protocol is a request/response packet size of 4096 octets. The protocol is a request/response
protocol, as described in the operational model ( [RFC6158], Section protocol, as described in the operational model ( [RFC6158], Section
skipping to change at page 5, line 4 skipping to change at page 5, line 4
designed to substitute for stream-oriented transport protocols, such designed to substitute for stream-oriented transport protocols, such
as TCP or SCTP. Experience shows that attempts to transport bulk as TCP or SCTP. Experience shows that attempts to transport bulk
data across the Internet with UDP will inevitably fail, unless they data across the Internet with UDP will inevitably fail, unless they
re-implement all of the behavior of TCP. The underlying design of re-implement all of the behavior of TCP. The underlying design of
RADIUS lacks the proper retransmission policies or congestion control RADIUS lacks the proper retransmission policies or congestion control
mechanisms which would make it a competitor to TCP. mechanisms which would make it a competitor to TCP.
Therefore, RADIUS/UDP transport is by design unable to transport bulk Therefore, RADIUS/UDP transport is by design unable to transport bulk
data. It is both undesired and impossible to change the protocol at data. It is both undesired and impossible to change the protocol at
this point in time. This specification is intended to allow the this point in time. This specification is intended to allow the
transport of slightly more than 4096 octets of data through existing transport of more than 4096 octets of data through existing RADIUS/
RADIUS/UDP proxies. Other solutions such as RADIUS/TCP MUST be used UDP proxies. Other solutions such as RADIUS/TCP MUST be used when a
when a "green field" deployment requires the transport of bulk data. "green field" deployment requires the transport of bulk data.
Section 6, below, describes with further details the reasoning for Section 6, below, describes with further details the reasoning for
this limitation, and recommends administrators to adjust it according this limitation, and recommends administrators to adjust it according
to the specific capabilities of their existing systems in terms of to the specific capabilities of their existing systems in terms of
memory and processing power. memory and processing power.
Moreover, its scope is limited to the exchange of authorization data, Moreover, its scope is limited to the exchange of authorization data,
as other exchanges do not require of such a mechanism. In as other exchanges do not require of such a mechanism. In
particular, authentication exchanges have already been defined to particular, authentication exchanges have already been defined to
overcome this limitation (e.g. RADIUS-EAP). Moreover, as they overcome this limitation (e.g. RADIUS-EAP). Moreover, as they
represent the most critical part of a RADIUS conversation, its represent the most critical part of a RADIUS conversation, it is
preferable to not introduce any modification to their operation that preferable to not introduce any modification to their operation that
may affect existing equipment. may affect existing equipment.
There is no need to fragment accounting packets either. While the There is no need to fragment accounting packets either. While the
accounting process can send large amounts of data, that data is accounting process can send large amounts of data, that data is
typically composed of many small updates. That is, there is no typically composed of many small updates. That is, there is no
demonstrated need to send indivisible blocks of more than 4K of data. demonstrated need to send indivisible blocks of more than 4K of data.
The need to send large amounts of data per user session often The need to send large amounts of data per user session often
originates from the need for flow-based accounting. In this use- originates from the need for flow-based accounting. In this use-
case, the client may send accounting data for many thousands of case, the client may send accounting data for many thousands of
skipping to change at page 6, line 9 skipping to change at page 6, line 9
they must be able to communicate in order to operate in unison. The 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 alternative is for the two systems to have differing views of the
users authorization parameters, which is a security disaster. users authorization parameters, which is a security disaster.
This specification does not allow for fragmentation of CoA packets. This specification does not allow for fragmentation of CoA packets.
Allowing for fragmented CoA packets would involve changing multiple Allowing for fragmented CoA packets would involve changing multiple
parts of the RADIUS protocol, with the corresponding possibility for parts of the RADIUS protocol, with the corresponding possibility for
implementation issues, mistakes, etc. implementation issues, mistakes, etc.
Where CoA clients need to send large amounts of authorization data to Where CoA clients (i.e. RADIUS servers) need to send large amounts
a NAS, they need only send a minimal CoA-Request packet, containing of authorization data to a CoA server (i.e. NAS), they need only
Service-Type of Authorize-Only, as per RFC 5176. They SHOULD also send a minimal CoA-Request packet, containing Service-Type of
have a co-located RADIUS server, for the sole purpose of implementing Authorize-Only, as per RFC 5176, along with session identification
this specification. attributes. This CoA packet serves as a signal to the NAS that the
users' session requires re-authorization. When the NAS re-authorizes
The NAS will then perform fragmentation as per this draft to the the user via Access-Request, the RADIUS server can perform
RADIUS server it is configured to use. That RADIUS server SHOULD fragmentation, and send large amounts of authorization data to the
then act as a proxy, and forward the Access-Request to the RADIUS
server on the CoA client. That RADIUS server can then send the large
amounts of authorization to the proxy, which then sends them to the
NAS. NAS.
That is, the NAS sends packets to a server which proxies them to the The assumption in the above scenario is that the CoA client and
system which is co-located with the CoA client.This process is more RADIUS server are co-located, or at least strongly coupled. That is,
complicated than allowing for fragmented CoA packets. However, the the path from CoA client to CoA server SHOULD be the exact reverse of
CoA client and the RADIUS server must communicate even when not using the path from NAS to RADIUS server. The following diagram will
this specification. We believe that standardizing that hopefully clarify the roles:
communication, and using one method for exchange of large data is
preferred to unspecified communication methods and multiple ways of +---------------------+
achieving the same result. | NAS CoA Server |
+---------------------+
| ^
Access-Request | | CoA-Request
v |
+---------------------+
| RADIUS CoA client |
| Server |
+---------------------+
Where there is a proxy involved:
+---------------------+
| NAS CoA Server |
+---------------------+
| ^
Access-Request | | CoA-Request
v |
+---------------------+
| RADIUS CoA |
| Proxy Proxy |
+---------------------+
| ^
Access-Request | | CoA-Request
v |
+---------------------+
| RADIUS CoA client |
| Server |
+---------------------+
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 is 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 The above requirement solves a number of issues. It clearly
separates session identification from authorization. Without this separates session identification from authorization. Without this
separation, it is difficult to both identify a session, and change separation, it is difficult to both identify a session, and change
its authorization using the same attribute. It also ensures that the its authorization using the same attribute. It also ensures that the
authorization process is the same for initial authentication, and for authorization process is the same for initial authentication, and for
CoA. 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.
3. Overview 3. Overview
Authorization exchanges can occur either before or after end user Authorization exchanges can occur either before or after end user
authentication has been completed. An authorization exchange before authentication has been completed. An authorization exchange before
authentication allows a RADIUS client to provide the RADIUS server authentication allows a RADIUS client to provide the RADIUS server
with information that MAY modify how the authentication process will with information that MAY modify how the authentication process will
be performed (e.g. it may affect the selection of the EAP method). be performed (e.g. it may affect the selection of the EAP method).
An authorization exchange after authentication allows the RADIUS An authorization exchange after authentication allows the RADIUS
server to provide the RADIUS client with information about the end server to provide the RADIUS client with information about the end
user, the results of the authentication process and/or obligations to user, the results of the authentication process and/or obligations to
be enforced. In this specification we refer to the "pre- be enforced. In this specification we refer to the "pre-
authorization" as the exchange of authorization information before authorization" as the exchange of authorization information before
the end user authentication has started, while the term "post- the end user authentication has started (from the NAS to the AS),
authorization" is used to refer to an authorization exchange whereas the term "post-authorization" is used to refer to an
happening after this authentication process. authorization exchange happening after this authentication process
(from the AS to the NAS).
In this specification we refer to the "size limit" as the practical In this specification we refer to the "size limit" as the practical
limit on RADIUS packet sizes. This limit is the minimum of 4096 limit on RADIUS packet sizes. This limit is the minimum of 4096
octets, and the current PMTU. We define below a method which uses octets, and the current PMTU. We define below a method which uses
Access-Request and Access-Accept in order to exchange fragmented Access-Request and Access-Accept in order to exchange fragmented
data. The NAS and server exchange a series of Access-Request / data. The NAS and server exchange a series of Access-Request /
Access-Accept packets, until such time as all of the fragmented data Access-Accept packets, until such time as all of the fragmented data
has been transported. Each packet contains a Frag-Status attribute has been transported. Each packet contains a Frag-Status attribute
which lets the other party know if fragmentation is desired, ongoing, which lets the other party know if fragmentation is desired, ongoing,
or finished. Each packet may also contain the fragmented data, or or finished. Each packet may also contain the fragmented data, or
instead be an "ACK" to a previous fragment from the other party. instead be an "ACK" to a previous fragment from the other party.
Each Access-Request contains a User-Name attribute, allowing the Each Access-Request contains a User-Name attribute, allowing the
packet to be proxied if necessary (see Section 10.1). Each Access- packet to be proxied if necessary (see Section 10.1). Each Access-
Request may also contain a State attribute, which serves to tie it to Request may also contain a State attribute, which serves to tie it to
a previous Access-Accept. Each Access-Accept contains a State a previous Access-Accept. Each Access-Accept contains a State
attribute, for use by the NAS in a later Access-Request. Each attribute, for use by the NAS in a later Access-Request. Each
Access-Accept contains a Service-Type indicating that the service Access-Accept contains a Service-Type attribute with the "Additional-
being provided is fragmentation, and that the Access-Accept should 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. not be interpreted as providing network access to the end user.
When a RADIUS client or server need to send data that exceeds the When a RADIUS client or server need to send data that exceeds the
size limit, the mechanism proposed in this document is used. Instead size limit, the mechanism proposed in this document is used. Instead
of encoding one large RADIUS packet, a series of smaller RADIUS of encoding one large RADIUS packet, a series of smaller RADIUS
packets of the same type are encoded. Each smaller packet is called packets of the same type are encoded. Each smaller packet is called
a "chunk" in this specification, in order to distinguish it from a "chunk" in this specification, in order to distinguish it from
traditional RADIUS packets. The encoding process is a simple linear traditional RADIUS packets. The encoding process is a simple linear
walk over the attributes to be encoded. This walk preserves the walk over the attributes to be encoded. This walk preserves the
order of the attributes of the same type, as required by [RFC2865]. order of the attributes of the same type, as required by [RFC2865].
The number of attributes encoded in a particular chunk depends on the The number of attributes encoded in a particular chunk depends on the
size limit, the size of each attribute, the number of proxies between size limit, the size of each attribute, the number of proxies between
client and server, and the overhead for fragmentation signalling client and server, and the overhead for fragmentation signalling
attributes. Specific details are given in Section 5. A a new attributes. Specific details are given in Section 5. A new
attribute called Frag-Status (Section 9.1) signals the fragmentation attribute called Frag-Status (Section 9.1) signals the fragmentation
status. status.
After the first chunk is encoded, it is sent to the other party. The 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 packet is identified as a chunk via the Frag-Status attribute. The
other party then requests additional chunks, again using the Frag- other party then requests additional chunks, again using the Frag-
Status attribute. This process is repeated until all the attributes Status attribute. This process is repeated until all the attributes
have been sent from one party to the other. When all the chunks have have been sent from one party to the other. When all the chunks have
been received, the original list of attributes is reconstructed and been received, the original list of attributes is reconstructed and
processed as if it had been received in one packet. processed as if it had been received in one packet.
skipping to change at page 8, line 44 skipping to change at page 9, line 46
"chunks". "chunks".
4. Fragmentation of packets 4. Fragmentation of packets
When the NAS or the AS desires to send a packet that exceeds the size When the NAS or the AS desires to send a packet that exceeds the size
limit, it is split into chunks and sent via multiple client/server limit, it is split into chunks and sent via multiple client/server
exchanges. The exchange is indicated via the Frag-Status attribute, exchanges. The exchange is indicated via the Frag-Status attribute,
which has value More-Data-Pending for all but the last chunk of the which has value More-Data-Pending for all but the last chunk of the
series. The chunks are tied together via the State attribute. series. The chunks are tied together via the State attribute.
The following sections describe how to perform fragmentation for The delivery of a large fragmented RADIUS packet with authorization
packets from the NAS to the server, followed by packets from the data can happen before or after the end user has been authenticated
server to the NAS. We give the packet type, along with a RADIUS by the AS. We can distinguish two phases:
1. Pre-authorization. In this phase, the NAS can send a large
packet with authorization information to the AS before the end
user is authenticated.
2. Post-authorization. In this phase, the AS can send a large
packet with authorization data to the NAS after the end user has
been authenticated.
The following subsections describe how to perform fragmentation for
packets for these two phases, pre-authorization and post-
authorization. We give the packet type, along with a RADIUS
Identifier, to indicate that requests and responses are connected. Identifier, to indicate that requests and responses are connected.
We then give a list of attributes. We do not give values for most We then give a list of attributes. We do not give values for most
attributes, as we wish to concentrate on the fragmentation behaviour, attributes, as we wish to concentrate on the fragmentation behaviour,
rather than packet contents. Attribute values are given for rather than packet contents. Attribute values are given for
attributes relevant to the fragmentation process. Where "long attributes relevant to the fragmentation process. Where "long
extended" attributes are used, we indicate the M (More) and T extended" attributes are used, we indicate the M (More) and T
(Truncation) flags as optional square brackets after the attribute (Truncation) flags as optional square brackets after the attribute
name. As no "long extended" attributes have yet been defined, we use name. As no "long extended" attributes have yet been defined, we use
example attributes, named as "Example-Long-1", etc. The maximum example attributes, named as "Example-Long-1", etc. The maximum
chunk size is established in term of number of attributes (11), for chunk size is established in term of number of attributes (11), for
skipping to change at page 12, line 34 skipping to change at page 14, line 15
Access-Request (ID = 241) Access-Request (ID = 241)
User-Name User-Name
Example-Long-2 Example-Long-2
State = 0xdef00002 State = 0xdef00002
Message-Authenticator Message-Authenticator
Figure 6: Access-Request (chunk 3) Figure 6: Access-Request (chunk 3)
On reception of this last chunk, the server matches it with an On reception of this last chunk, the server matches it with an
ongoing session via the State attribute, and sees that there is no ongoing session via the State attribute, and sees that there is no
Frag-Status attribute present. It then process the received Frag-Status attribute present. It then processes the received
attributes as if they had been sent in one RADIUS packet. See attributes as if they had been sent in one RADIUS packet. See
Section 7.4 for further details of this process. It generates the Section 7.4 for further details of this process. It generates the
appropriate response, which can be either Access-Accept or Access- appropriate response, which can be either Access-Accept or Access-
Reject. In this example, we show an Access-Accept. The server MUST Reject. In this example, we show an Access-Accept. The server MUST
send a State attribute, which permits link the received data with the send a State attribute, which permits link the received data with the
authentication process. authentication process.
Access-Accept (ID = 241) Access-Accept (ID = 241)
State = 0x98700003 State = 0x98700003
Message-Authenticator Message-Authenticator
Figure 7: Access-Accept (chunk 3) Figure 7: Access-Accept (chunk 3)
The above example shows in practice how the chunking process works. The above example shows in practice how the chunking process works.
We re-iterate the implementation and security requirements here. We re-iterate the implementation and security requirements here.
Each chunk is a valid RADIUS packet, and all RADIUS format and Each chunk is a valid RADIUS packet (see Section 11.2 for some
security requirements MUST be followed before any chunking process is considerations about this), and all RADIUS format and security
applied. requirements MUST be followed before any chunking process is applied.
Every chunk except for the last one from a NAS MUST include a Frag- Every chunk except for the last one from a NAS MUST include a Frag-
Status attribute, with value More-Data-Pending. The last chunk MUST Status attribute, with value More-Data-Pending. The last chunk MUST
NOT contain a Frag-Status attribute. Each chunk except for the last NOT contain a Frag-Status attribute. Each chunk except for the last
from a NAS MUST include a Service-Type attribute, with value from a NAS MUST include a Service-Type attribute, with value
Additional-Authorization. Each chunk MUST include a User-Name Additional-Authorization. Each chunk MUST include a User-Name
attribute, which MUST be identical in all chunks. Each chunk except attribute, which MUST be identical in all chunks. Each chunk except
for the first one from a NAS MUST include a State attribute, which for the first one from a NAS MUST include a State attribute, which
MUST be copied from a previous Access-Accept. MUST be copied from a previous Access-Accept.
skipping to change at page 17, line 38 skipping to change at page 18, line 50
Unauthenticated clients are permitted to trigger the exchange of Unauthenticated clients are permitted to trigger the exchange of
large amounts of fragmented data between the NAS and the AS, having large amounts of fragmented data between the NAS and the AS, having
the potential to allow Denial of Service (DoS) attacks. An attacker the potential to allow Denial of Service (DoS) attacks. An attacker
could initiate a large number of connections, each of which requests could initiate a large number of connections, each of which requests
the server to store a large amount of data. This data could cause the server to store a large amount of data. This data could cause
memory exhaustion on the server, and result in authentic users being memory exhaustion on the server, and result in authentic users being
denied access. It is worth noting that authentication mechanisms are denied access. It is worth noting that authentication mechanisms are
already designed to avoid exceeding the size limit. already designed to avoid exceeding the size limit.
Hence, implementations of this specification MUST limit the total Hence, implementations of this specification MUST limit the total
amount of data they send and/or receive via this specification to amount of data they send and/or receive via this specification. Its
100K. Any more than this may turn RADIUS into a generic transport default value SHOULD be 100K. Any more than this may turn RADIUS into
protocol, which is undesired. It is RECOMMENDED that this limit be a generic transport protocol, which is undesired. This limit SHOULD
exposed to administrators, so that it can be changed if necessary. be configurable, so that it can be changed if necessary.
Implementations of this specification MUST limit the total number of Implementations of this specification MUST limit the total number of
round trips used during the fragmentation process to 25. Any more round trips used during the fragmentation process. Its default value
than this may indicate an implementation error, misconfiguration, or SHOULD be to 25. Any more than this may indicate an implementation
a denial of service (DoS) attack. It is RECOMMENDED that this limit error, misconfiguration, or a denial of service (DoS) attack. This
be exposed to administrators, so that it can be changed if necessary. limit SHOULD be configurable, so that it can be changed if necessary.
For instance, let's imagine the RADIUS server wants to transport an For instance, let's imagine the RADIUS server wants to transport an
SAML assertion which is 15000 octets long, to the RADIUS client. In SAML assertion which is 15000 octets long, to the RADIUS client. In
this hypothetical scenario, we assume there are 3 intermediate this hypothetical scenario, we assume there are 3 intermediate
proxies, each one inserting a Proxy-State attribute of 20 octets. proxies, each one inserting a Proxy-State attribute of 20 octets.
Also we assume the State attributes generated by the RADIUS server Also we assume the State attributes generated by the RADIUS server
have a size of 6 octets. Therefore, the amount of free space in a have a size of 6 octets, and the User-Name attribute take 50 octets.
chunk for the transport of the SAML assertion attributes is: Total Therefore, the amount of free space in a chunk for the transport of
(4096) - RADIUS header (20) - Frag-Status (7 octets) - Service-Type the SAML assertion attributes is: Total (4096) - RADIUS header (20) -
(6 octets) - State (6 octets) - Proxy-State (20 octets) - Proxy-State User-Name (50 octets) - Frag-Status (7 octets) - Service-Type (6
octets) - State (6 octets) - Proxy-State (20 octets) - Proxy-State
(20) - Proxy-State (20) - Message-Authenticator (18 octets), (20) - Proxy-State (20) - Message-Authenticator (18 octets),
resulting in a total of 3979 octets, that is, 15 attributes of 255 resulting in a total of 3929 octets, that is, 15 attributes of 255
bytes. bytes.
According to [RFC6929], a Long-Extended-Type provides a payload of According to [RFC6929], a Long-Extended-Type provides a payload of
251 octets. Therefore, the SAML assertion described above would 251 octets. Therefore, the SAML assertion described above would
result into 60 attributes, requiring of 4 round-trips to be result into 60 attributes, requiring of 4 round-trips to be
completely transmitted. completely transmitted.
7. Handling special attributes 7. Handling special attributes
7.1. Proxy-State attribute 7.1. Proxy-State attribute
RADIUS proxies may introduce Proxy-State attributes into any Access- RADIUS proxies may introduce Proxy-State attributes into any Access-
Request packet they forward. Should they cannot add this information Request packet they forward. Should they are unable to add this
to the packet, they may silently discard forwarding it to its information to the packet, they may silently discard forwarding it to
destination, leading to DoS situations. Moreover, any Proxy-State its destination, leading to DoS situations. Moreover, any Proxy-
attribute received by a RADIUS server in an Access-Request packet State attribute received by a RADIUS server in an Access-Request
MUST be copied into the reply packet to it. For these reasons, packet MUST be copied into the reply packet to it. For these
Proxy-State attributes require a special treatment within the packet reasons, Proxy-State attributes require a special treatment within
fragmentation mechanism. the packet fragmentation mechanism.
When the RADIUS server replies to an Access-Request packet as part of When the RADIUS server replies to an Access-Request packet as part of
a conversation involving a fragmentation (either a chunk or a request a conversation involving a fragmentation (either a chunk or a request
for chunks), it MUST include every Proxy-State attribute received for chunks), it MUST include every Proxy-State attribute received
into the reply packet. This means that the server MUST take into into the reply packet. This means that the server MUST take into
account the size of these Proxy-State attributes in order to account the size of these Proxy-State attributes in order to
calculate the size of the next chunk to be sent. calculate the size of the next chunk to be sent.
However, while a RADIUS server will always know how much space MUST However, while a RADIUS server will always know how much space MUST
be left on each reply packet for Proxy-State attributes (as they are be left on each reply packet for Proxy-State attributes (as they are
skipping to change at page 23, line 37 skipping to change at page 25, line 5
| Kind of packet | | Kind of packet |
+-----+-----+-----+-----+ +-----+-----+-----+-----+
Attribute Name | Req | Acc | Rej | Cha | Attribute Name | Req | Acc | Rej | Cha |
----------------------+-----+-----+-----+-----+ ----------------------+-----+-----+-----+-----+
Frag-Status | 0-1 | 0-1 | 0 | 0-1 | Frag-Status | 0-1 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+ ----------------------+-----+-----+-----+-----+
Proxy-State-Len | 0 | 0-1 | 0 | 0-1 | Proxy-State-Len | 0 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+ ----------------------+-----+-----+-----+-----+
Figure 15
10. Operation with proxies 10. Operation with proxies
The fragmentation mechanism defined above is designed to be The fragmentation mechanism defined above is designed to be
transparent to legacy proxies, as long as they do not want to modify transparent to legacy proxies, as long as they do not want to modify
any fragmented attribute. Nevertheless, updated proxies supporting any fragmented attribute. Nevertheless, updated proxies supporting
this specification can even modify fragmented attributes. this specification can even modify fragmented attributes.
10.1. Legacy proxies 10.1. Legacy proxies
As every chunk is indeed a RADIUS packet, legacy proxies treat them As every chunk is indeed a RADIUS packet, legacy proxies treat them
skipping to change at page 24, line 45 skipping to change at page 26, line 27
|<---------------------------------------------------| |<---------------------------------------------------|
| | | |
| Access-Request(2)(User-Name,State1, | | Access-Request(2)(User-Name,State1, |
| 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-1[M],Example-Long-1} |
|--------------------------------------------------->| |--------------------------------------------------->|
PROXY MODIFIES ATTRIBUTE Data INCREASING ITS PROXY MODIFIES ATTRIBUTE Data INCREASING ITS
SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS
Figure 16: Updated proxy interacts with NAS Figure 15: Updated proxy interacts with NAS
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| Proxy | | AS | | Proxy | | AS |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | |
| Access-Request(3){User-Name,Calling-Station-Id, | | 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[M],Example-Long-1[M], | | Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[MT],Frag-Status(MDP)} | | Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->| |--------------------------------------------------->|
skipping to change at page 25, line 32 skipping to change at page 27, line 32
| Example-Long-1[MT],Frag-Status(MDP)} | | Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->| |--------------------------------------------------->|
| | | |
| Access-Challenge(1){User-Name, | | Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State3} | | Frag-Status(MDR),State3} |
|<---------------------------------------------------| |<---------------------------------------------------|
| | | |
| Access-Request(5){User-Name,State3,Example-Long-1} | | Access-Request(5){User-Name,State3,Example-Long-1} |
|--------------------------------------------------->| |--------------------------------------------------->|
Figure 17: Updated proxy interacts with AS Figure 16: Updated proxy interacts with AS
11. Operational considerations 11. Operational considerations
11.1. Flag T 11.1. Flag T
As described in Section 8, this document modifies the definition of As described in Section 8, this document modifies the definition of
the "Reserved" field of the "Long Extended Type" attribute [RFC6929], the "Reserved" field of the "Long Extended Type" attribute [RFC6929],
by allocating an additional flag "T". The meaning and position of by allocating an additional flag "T". The meaning and position of
this flag is defined in this document, and nowhere else. This might this flag is defined in this document, and nowhere else. This might
generate an issue if subsequent specifications want to allocate a new generate an issue if subsequent specifications want to allocate a new
skipping to change at page 26, line 22 skipping to change at page 28, line 22
11.2. Violation of RFC2865 11.2. Violation of RFC2865
Section 4.1 indicates that all authorization and authentication Section 4.1 indicates that all authorization and authentication
handling will be postponed until all the chunks have been received. handling will be postponed until all the chunks have been received.
This postponement also affects to the verification that the Access- This postponement also affects to the verification that the Access-
Request packet contains some kind of authentication attribute (e.g. Request packet contains some kind of authentication attribute (e.g.
User-Password, CHAP-Password, State or other future attribute), as User-Password, CHAP-Password, State or other future attribute), as
required by [RFC2865]. This checking will therefore be delayed until required by [RFC2865]. This checking will therefore be delayed until
the original large packet has been rebuilt, as some of the chunks may the original large packet has been rebuilt, as some of the chunks may
not contain any of them. The authors acknowledge this is formally not contain any of them.
violating [RFC2865], but there are no known operational issues with
it. Proxies are supposed to not check this, as [RFC2865] specifies The authors acknowledge that this specification violates the "MUST"
that other attributes might be considered as authentication requirement of [RFC2865] Section 4.1. We note that a proxy which
information in future extensions, and doing so would make them too enforces that requirement would be unable to support future RADIUS
restrictive. Once this document goes beyond being considered as authentication extensions. Extensions to the protocol would
experimental, it will state it updates [RFC2865]. therefore be impossible to deploy. All known implementations have
chosen the philosophy of "be liberal in what you accept". That is,
they accept traffic which 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 re-issued as a standards track
document, and update [RFC2865].
11.3. Proxying based on User-Name 11.3. Proxying based on User-Name
This proposal assumes legacy proxies to base their routing decisions This proposal assumes legacy proxies to base their routing decisions
on the value of the User-Name attribute. For this reason, every on the value of the User-Name attribute. For this reason, every
packet sent from the client to the server (either chunks or requests packet sent from the client to the server (either chunks or requests
for more chunks) MUST contain a User-Name attribute. for more chunks) MUST contain a User-Name attribute.
11.4. Transport behaviour
This proposal does not modify the way RADIUS interacts with the
underlying transport (UDP). That is, RADIUS keeps following a lock-
step behaviour, that requires receiving an explicit acknowledge for
each chunk sent. Hence, bursts of traffic which could congest links
between peers are not an issue.
12. Security Considerations 12. Security Considerations
As noted in many earlier specifications ([RFC5080], [RFC6158], etc.) As noted in many earlier specifications ([RFC5080], [RFC6158], etc.)
RADIUS security is problematic. This specification changes nothing RADIUS security is problematic. This specification changes nothing
related to the security of the RADIUS protocol. It requires that all related to the security of the RADIUS protocol. It requires that all
Access-Request packets associated with fragmentation are Access-Request packets associated with fragmentation are
authenticated using the existing Message-Authenticator attribute. authenticated using the existing Message-Authenticator attribute.
This signature prevents forging and replay, to the limits of the This signature prevents forging and replay, to the limits of the
existing security. existing security.
skipping to change at page 27, line 24 skipping to change at page 29, line 40
13. IANA Considerations 13. IANA Considerations
The authors request that Attribute Types and Attribute Values defined The authors request that Attribute Types and Attribute Values defined
in this document be registered by the Internet Assigned Numbers in this document be registered by the Internet Assigned Numbers
Authority (IANA) from the RADIUS namespaces as described in the "IANA Authority (IANA) from the RADIUS namespaces as described in the "IANA
Considerations" section of [RFC3575], in accordance with BCP 26 Considerations" section of [RFC3575], in accordance with BCP 26
[RFC5226]. For RADIUS packets, attributes and registries created by [RFC5226]. For RADIUS packets, attributes and registries created by
this document IANA is requested to place them at this document IANA is requested to place them at
http://www.iana.org/assignments/radius-types. http://www.iana.org/assignments/radius-types.
This document defines the following RADIUS messages: In particular, this document defines two new RADIUS attributes,
entitled "Frag-Status" and "Proxy-State-Len" (see section 9),
assigned values of TBD1 and TBD2 from the Long Extended Space of
[RFC2865]:
o Frag-Status Tag Name Length Meaning
---- ---- ------ -------
TBD1 Frag-Status 7 Signals fragmentation
TBD2 Proxy-State-Len 7 Indicates the length of the
received Proxy-State attributes
o Proxy-State-Len The Frag-Status attribute also defines a 8-bit "Code" field, for
which the IANA is to create and maintain a new sub-registry entitled
"Code values" under the RADIUS "Frag-Status" attribute. Initial
values for the RADIUS Frag-Status "Code" registry are given below;
future assignments are to be made through "RFC required" [IANA-
CONSIDERATIONS]. Assignments consist of a Frag-Status "Code" name
and its associated value.
Value Frag-Status Code Name Definition
---- ------------------------ ----------
0 Reserved See Section 9.1
1 Fragmentation-Supported See Section 9.1
2 More-Data-Pending See Section 9.1
3 More-Data-Request See Section 9.1
4-255 Unassigned
Additionally, allocation of a new Service-Type value for "Additional- Additionally, allocation of a new Service-Type value for "Additional-
Authorization" is requested. Authorization" is requested.
Value Service Type Value Definition
---- ------------------------ ----------
TBA Additional-Authorization See section 4.1
14. Acknowledgements 14. Acknowledgements
The authors would like to thank the members of the RADEXT working The authors would like to thank the members of the RADEXT working
group who have contributed to the development of this specification, group who have contributed to the development of this specification,
either by participating on the discussions on the mailing lists or by either by participating on the discussions on the mailing lists or by
sending comments about our draft. sending comments about our draft.
The authors also thank David Cuenca (University of Murcia) for The authors also thank David Cuenca (University of Murcia) for
implementing a proof of concept implementation of this draft that has implementing a proof of concept implementation of this draft that has
been useful to improve the quality of the specification. been useful to improve the quality of the specification.
 End of changes. 31 change blocks. 
110 lines changed or deleted 196 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/