RADIUS EXTensions Working Group A. Perez-Mendez
Internet-Draft R. Marin-Lopez
Intended status: Experimental F. Pereniguez-Garcia
Expires: August 5, 2013 G. Lopez-Millan
University of Murcia
D. Lopez
Telefonica I+D
A. DeKok
Network RADIUS
Feb 2013
Support of fragmentation of RADIUS packets
draft-perez-radext-radius-fragmentation-05
Abstract
This document describes a mechanism providing fragmentation support
of RADIUS packets that exceed the 4096 bytes limit.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Perez-Mendez, et al. Expires August 5, 2013 [Page 1]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 5
3.1. Access-Request . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Access-Accept . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Combined use of both fragmented packets . . . . . . . . . 12
3.4. Unsupported packet types . . . . . . . . . . . . . . . . . 15
3.4.1. Accounting . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2. CoA . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Allowed large packet size . . . . . . . . . . . . . . . . . . 16
6. Handling special attributes . . . . . . . . . . . . . . . . . 17
6.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 17
6.2. State attribute . . . . . . . . . . . . . . . . . . . . . 18
6.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 18
6.4. Rebuilding the original large packet . . . . . . . . . . . 19
7. New attribute definition . . . . . . . . . . . . . . . . . . . 19
7.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 19
7.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 20
7.3. Table of attributes . . . . . . . . . . . . . . . . . . . 21
8. Operation with proxies . . . . . . . . . . . . . . . . . . . . 22
8.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Normative References . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Perez-Mendez, et al. Expires August 5, 2013 [Page 2]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
1. Introduction
RADIUS [RFC2865] is a protocol for carrying authentication,
authorization, and configuration information between a Network Access
Server (NAS) which desires to authenticate its links and a shared
Authentication Server (AS). Information is exchanged between the NAS
and the AS through RADIUS packets. Each RADIUS packet can transport
several RADIUS attributes, to convey the necessary information to the
other peer, up to a maximum size of 4096 bytes of total data
(including RADIUS packet headers). RADIUS attributes have a maximum
payload size of 253 bytes.
RADIUS has been extensively used for the years. Along this time, the
need of sending RADIUS attributes larger than 253 bytes has become a
reality. An immediate alternative to overcome this issue consists in
truncating the data into a group of RADIUS attributes of the same
type, and then insert them ordered into the RADIUS packet. At the
destination, the content of these attributes is extracted and joined
to rebuild the original data. This scheme is followed, for example,
by RADIUS-EAP [RFC3579]. A more advanced solution is given in
[I-D.ietf-radext-radius-extensions], where extended attributes can be
marked with a flag to indicate fragmentation. A reference-based
mechanism, where the value of the attributes can be obtained by other
protocol instead of RADIUS, is also proposed in [RFC6158].
However, there are no proposals to fragment a large-sized RADIUS
packet into multiple small-sized RADIUS packets, where the length of
the original (unfragmented) RADIUS packet exceeds the 4096-octet
limit imposed by the RADIUS specification. When RADIUS is considered
in more complex AAA scenarios, including the exchange of bigger
amount of data, like SAML assertions or JSON Web tokens, exceeding
this limit becomes more likely, thus making necessary the
availability of mechanisms for dealing with this situation.
This document defines a mechanism to allow RADIUS peers to exchange
packets exceeding the 4096 bytes limit, by fragmenting them across
several exchanges. This proposal tries to maintain compatibility
with intra-packet fragmentation mechanisms (like those defined in
[RFC3579] or in [I-D.ietf-radext-radius-extensions]) and with the
existing RADIUS deployments.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Perez-Mendez, et al. Expires August 5, 2013 [Page 3]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
2. Overview
When a RADIUS client or server need to send a packet that exceeds the
4096 bytes limit, the mechanism proposed in this document is used.
First, the large packet is truncated into several smaller RADIUS
packets (i.e. chunks) of the same type (i.e. Access-Request or
Access-Accept). Each small RADIUS packet is so-called "chunk" in
this specification. The first chunk contains "n" RADIUS attributes
of the original packet, where the order of the attributes of the same
type is respected, until a limit below 4096 bytes. The actual amount
of data from the original packet included into each chunk will depend
on the specific length of the attributes, the amount of proxies
between both ends, and the number of signalling attributes (more
details in Section 4). Signalling to indicate whether there are
fragmented data to be sent is performed by means of a new attribute
called Frag-Status. Section 7.1 defines this attribute and its
possible values.
The first chunk is sent to the other party, which identifies the
packet as a chunk (based on the information contained in the Frag-
Status attribute), and requests for the next chunk. The RADIUS State
attribute and the RADIUS Identifier field are used to tie the
conversation together.
This process is repeated until all the RADIUS attributes from the
original packet have been sent by means of several chunks. Once all
the chunks have been received by the peer, the original packet is
reconstructed and processed as if received in one piece.
When a packet is truncated into chunks, a special situation may occur
when it is combined with Extended Type attributes as defined in
[I-D.ietf-radext-radius-extensions]. If the truncation splits an
existing fragmented attribute along two or more chunks, the last
fragment of that attribute for the first chunk will have the flag M
enabled (indicating the attribute is not completed). This situation
is specifically forbidden in [I-D.ietf-radext-radius-extensions]. To
indicate that this situation is provoked by a truncation and hence
MUST be allowed, a new flag "T" (indicating truncation) MUST be set
into that Extended-Type-Flag attribute. The combination of the flags
"M" and "T" indicates that the attribute is fragmented (flag M), but
that all the fragments are not available in this chunk (flag T).
Indeed, this last situation will be the most usual. Typically,
packet fragmentation will occur as a consequence of including one or
more large (and fragmented) attributes into a RADIUS packet. Hence,
the truncation will probably split the large attribute into two (or
more) pieces. The rest of possibilities, where the truncation point
does not split a fragmented attribute, do not require any special
Perez-Mendez, et al. Expires August 5, 2013 [Page 4]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
treatment.
The packet fragmentation mechanism described in this draft can only
be used once the authentication process has been completed. The
reason behind this decision is based on security. If unauthenticated
clients were permitted to ask the server to store bulk data, then a
Denial of Service (DoS) attack becomes possible. An attacker could
initiate a large number of connections, each of which requests the
server to store a large amount of data. This data could cause memory
exhaustion on the server, and result in authentic users being denied
access. It is worth noting that authentication mechanisms are
already designed to avoid exceeding the 4096 bytes limit.
3. Fragmentation of packets
When the NAS or the AS desires to send a RADIUS packet that exceeds
the 4096 bytes limit, the packet can be split into smaller packets
(chunks) and sent over different exchanges. This fact is indicated
by including a Frag-Status = More-Data-Pending (except the last one
of the series). All the packets belonging to the same fragmentation
exchange are tied together by making use of the standard RADIUS
mechanisms, that is, by using the Identifier field of the RADIUS
packet by the Client and by using the RADIUS State attribute by the
Server.
The following sections describe how to perform fragmentation for each
RADIUS packet type. In order to make these examples simpler, it is
assumed that each RADIUS packet can include up to 8 RADIUS
attributes, instead of using bytes. The used notation is the
following:
Packet-Type(Identifier){attributes}
where Packet-Type can be Access-Request, Access-Challenge, Access-
Accept or Access-Reject, and Identifier is the value of the
Identifier field of the RADIUS packet header.
Each attribute is denoted by Attr[Flags], where Attr is the name of
the attribute type, and flags represents the active flags as
described in [I-D.ietf-radext-radius-extensions]. Frag-Status(X)
indicates a Frag-Status attribute with value X, where X can be FS for
Fragmentation-Supported, AA for Additional-Authorization, MDP for
More-Data-Pending and MDR for More-Data-Request. Service-Type(X)
indicates a Service-Type attribute with value X, where AA indicates
the value Additional-Authorization.
Perez-Mendez, et al. Expires August 5, 2013 [Page 5]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
3.1. Access-Request
When the client needs to send a large amount of data to the server,
it MUST signal this by including a Frag-Status = Additional-
Authorization in the initial Access-Request. This packet will likely
be small (e.g. contain EAP-Identity), and there will be room for the
attribute. The client MUST NOT send the Frag-Status attribute in
later packets (e.g. responses to any Access-Challenge) until an
Access-Accept packet is received. It has already signalled that
there is data to be sent, and there is no need to do so again.
Servers implementing this specification MUST flag the session as
requiring more data. They MAY respond with Access-Challenge, where
the authentication method requires that. When the authentication is
complete, either an Access-Reject or Access-Accept is returned. If
the client has signalled that there is more data pending for this
session, the server MUST respond with Service-Type = Additional-
Authorization in any Access-Accept. The client is then expected to
initiate the fragmentation procedure as defined here.
If a client sends the Frag-Status = Additional-Authorization
attribute, and receives an Access-Accept without Service-Type =
Additional-Authorization, or with any other value for Service-Type,
it will know the server does not implement this specification and
will not allow the exchange of fragmented packets. Hence, it MAY
behave as if it had received Access-Reject instead and close the
authentication.
If the server supports fragmentation, the data to be sent is then
split into smaller packets (chunks) and sent over different exchanges
to the server. This fact is indicated by including a Frag-Status =
More-Data-Pending attribute on each chunk (except the last one of the
series). All the packets belonging to the same fragmentation
exchange are tied together by making use of the standard RADIUS
mechanisms, that is, by using the Identifier field of the RADIUS
packet by the Client and by using the RADIUS State attribute by the
Server.
o In this example, the client (NAS) is trying to send a large
Access-Request packet to the server (AS). Attributes "Attr1" and
"Attr2" are Extended-Type-Flags attributes, as defined in
[I-D.ietf-radext-radius-extensions]. Attr1 is composed by 9
fragments, while Attr2 is composed by 3 of them.
Access-Request() {User-Name, Calling-Station-Id, Attr1[M],
Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M],
Attr1[M], Attr1, Attr2[M], Attr2[M], Attr2}
Perez-Mendez, et al. Expires August 5, 2013 [Page 6]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
o As the RADIUS packet exceeds the maximum allowed length (8
attributes), the RADIUS client indicates the server its will of
sending additional large data after authentication has been
completed. This fact is indicated by including the Frag-Status =
Additional-Authorization attribute into the first Access-Request
sent from the NAS to the AS.
Access-Request(1) {User-Name, ..., Frag-Status(AA)}
o The RADIUS server flags the session as requiring more data, and
both continue with the authentication process as usual (e.g.
exchange of Access-Request/Access-Challenge). RADIUS Identifier
is not increased in this example for sake of simplicity.
o Within the final Access-Accept packet, the server includes a
Service-Type = Additional-Authorization and a State attribute,
indicating to the client that it is ready to receive the
additional authorization information. If the server wanted to
send a different Service-Type attribute, it would be sent in the
last Access-Accept packet after receiving all the data from the
client.
Access-Accept(1) {User-Name, ..., State1, Service-Type(AA)}
o The RADIUS client truncates the original packet to generate the
first chunk, including the Frag-Status = More-Data-Pending
attribute. As attribute "Attr1" does not completely fit into this
chunk, the flag "T" is activated into the last fragment included
into this chunk, to indicate that it is not the last fragment of
the attribute. If the original Access-Request packet contained a
User-Name attribute, it MUST be included on every chunk sent to
the server. This is required because proxies may need this value
to forward the chunk to its proper destination.
Access-Request(2) {User-Name, Calling-Station-Id, Attr1[M],
Attr1[M], Attr1[M], Attr1[M], State1, Frag-Status(MDP)}
o When the server receives the RADIUS packet containing the Frag-
Status = More-Data-Pending attribute, the processing of the packet
is delayed until all the pending data is received. The pending
data is requested by means of an Access-Challenge packet
containing a Frag-Status = More-Data-Request, using the State
attribute to tie together this response with the subsequent
request from the client.
Access-Challenge(2) {Frag-Status(MDR), State2}
Perez-Mendez, et al. Expires August 5, 2013 [Page 7]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
o The client continues including attributes until another chunk is
completed, including the Frag-Status = More-Data-Pending
attribute, as Attr2 does not fit in this chunk. The State
attribute received in the Access-Challenge (i.e. State2) is also
included.
Access-Request(3) {User-Name, Attr1[M], Attr1[M], Attr1[M],
Attr1[M], Attr1, State2, Frag-Status(MDP)}
o As the received request contains the Frag-Status = More-Data-
Pending attribute, the server stores the attributes into the state
associated to State1 and replies with another Access-Challenge
packet. The challenge contains a Frag-Status = More-Data-Request
and a new State attribute (i.e. State3) that refers to this
conversation.
Access-Challenge(3) {Frag-Status(MDR), State3}
o Finally, the client sends the last chunk of the original packet,
including the received State attribute (i.e. State3).
Access-Request(4) {User-Name, Attr2[M], Attr2[M], Attr2,
State3}
o On reception of this last chunk (no Frag-Status = More-Data-
Pending present), the server can process the received attributes
as if they all had been received into a single RADIUS packet
larger than 4096 bytes. See Section 6.4 for further details. It
generates the Access-Accept packet finalizing the exchange of
data. This packet will contain the original Service-Type
attribute (if any).
Access-Accept(4) {User-Name, Service-Type(X)}
The Figure 1 depicts this scenario.
Perez-Mendez, et al. Expires August 5, 2013 [Page 8]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
+-+-+-+-+ +-+-+-+-+
| NAS | | AS |
+-+-+-+-+ +-+-+-+-+
| |
| Access-Request(1){User-Name,...,Frag-Status(AA)} |
|-------------------------------------------------------->|
| . |
| . |
| Authentication process |
|<------------------------------------------------------->|
| . |
| . |
| Access-Accept(1){User-Name,...,State1, |
| Service-Type(AddAuth)} |
|<--------------------------------------------------------|
| |
| Access-Request(2){User-Name,Calling-Station-Id, |
| Attr1[M],Attr1[M],Attr1[M],Attr1[MT] |
| State1,Frag-Status(MDP)} |
|-------------------------------------------------------->|
| |
| Access-Challenge(2){Frag-Status(MDR),State2} |
|<--------------------------------------------------------|
| |
| Access-Request(3){User-Name,State2,Attr1[M], |
| Attr1[M],Attr1[M],Attr1[M],Attr1, |
| Frag-Status(MDP)} |
|-------------------------------------------------------->|
| |
| Access-Challenge(3){Frag-Status(MDR),State3} |
|<--------------------------------------------------------|
| |
| Access-Request(4){User-Name,State3,Attr2[M], |
| Attr2[M],Attr2} |
|-------------------------------------------------------->|
| |
| Access-Accept(4){User-Name,Service-Type(X)} |
|<--------------------------------------------------------|
Figure 1: Fragmented Access-Request packet
3.2. Access-Accept
If the AS wants to send an Access-Accept packet that exceeds the 4096
bytes limit (e.g. due to the inclusion of authorization-specific
attributes), the operation is slightly different. In addition to the
use of the Frag-Status = More-Data-Pending attribute for each chunk,
the AS makes use of the Service-Type = Additional-Authorization
Perez-Mendez, et al. Expires August 5, 2013 [Page 9]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
attribute. In this way, when a client receives an Access-Accept and
it does not support Additional-Authorization, it MUST treat that
unrecognized Service-Type as though an Access-Reject had been
received instead ([RFC2865] Section 5.6). If the original large
Access-Accept packet contained a Service-Type attribute, it will be
included with its original value in the last transmitted chunk, to
avoid confusion with the one used for fragmentation signalling.
Client supporting this specification and not wanting to send
additional authorization information (see section above) MUST include
a Frag-Status = Fragmentation-Supported attribute in the first
Access-Request sent to the server, in order to indicate they would
accept fragmented data from the sever.
o The RADIUS client includes a Frag-Status = Fragmentation-Supported
attribute into the first Access-Request packet sent to the server,
indicating this specification is supported.
Access-Request(1) {User-Name, ..., Frag-Status(FS)}
o Once the user has been authenticated, the AS wants to send the
following Access-Accept packet. Attr1 has 9 fragments, while
Attr2 has 3 fragments:
Access-Accept(1) {User-Name, Service-Type(X), Framed-IP-
Address, Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M],
Attr1[M], Attr1[M], Attr1[M], Attr1, Attr2[M], Attr2[M],
Attr2[M]}
o As the RADIUS packet exceeds the maximum allowed length (8
attributes), the AS truncates the packet to generate the first
chunk. This chunk includes a Service-Type = Additional-
Authorization, indicating that this Access-Accept MUST not be
considered as a final packet, and a Frag-Status = More-Data-
Pending attribute indicating that there are more chunks yet to be
provided. Note that the Service-Type(X) is not included yet to
avoid confusion. Besides, as attribute "Attr1" does not
completely fit into this chunk, the flag "T" is activated into the
last fragment included into this chunk. Finally, a new RADIUS
State attribute is included to allow the AS to correlate the
following Access-Request with this chunk.
Access-Accept(1) {User-Name, Framed-IP-Address, Attr1[M],
Attr1[M], Attr1[MT],Service-Type(AA), State1, Frag-Status(MDP)}
o When the NAS receives the Access-Accept, it determines, based on
the Frag-Status = More-Data-Pending attribute, that additional
exchanges are required. Thus, it generates a new Access-Request
Perez-Mendez, et al. Expires August 5, 2013 [Page 10]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
packet containing the User-Name attribute, a Frag-Status = More-
Data-Request attribute and the State attribute received from the
server.
Access-Request(2) {User-Name, Frag-Status(MDR), State1}
o The AS then generates a new chunk with part of the remaining
attributes to be sent. As they does not fit into a single chunk,
Frag-Status = More-Data-Pending and Service-Type = Additional-
Authorization are included, along with a new State attribute.
Access-Accept(2) {User-Name, Attr1[M], Attr1[M], Attr1[M],
Attr1[MT], Service-Type(AA), State2, Frag-Status(MDP)}
o The NAS determines there is more data pending, and generates a new
Access-Request packet containing the User-Name attribute, a Frag-
Status = More-Data-Request attribute and the State attribute
received from the server.
Access-Request(3) {User-Name, Frag-Status(MDR), State2}
o Finally, the AS sends the last chunk as all the remaining data
fits into a single packet. This is indicated by not including a
Frag-Status = More-Data-Pending attribute. This last chunk
includes the original Service-Type attribute.
Access-Accept(3) {User-Name, Attr1[M], Attr1, Attr2[M],
Attr2[M], Attr2, Service-Type(X)}
o On reception of this last packet, the NAS can process the totality
of the received attributes as if they were all received into a
single RADIUS packet larger than 4096 bytes. See Section 6.4 for
further details on this.
The following figure depicts the exchange of chunks between the NAS
and the AS.
Perez-Mendez, et al. Expires August 5, 2013 [Page 11]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
+-+-+-+-+ +-+-+-+-+
| NAS | | AS |
+-+-+-+-+ +-+-+-+-+
| |
| Access-Request(1){User-Name,...,Frag-Status(FS)} |
|-------------------------------------------------------->|
| . |
| . |
| Authentication process |
|<------------------------------------------------------->|
| . |
| . |
| Access-Accept(1){User-Name,Framed-IP-Address, |
| Attr1[M],Attr1[M],Attr1[MT],State1, |
| Service-Type(AA),Frag-Status(MDP)} |
|<--------------------------------------------------------|
| |
| Access-Request(2){User-Name,Frag-Status(MDR),State1} |
|-------------------------------------------------------->|
| |
| Access-Accept(2){User-Name,Attr1[M],Attr1[M], |
| Attr1[M],Attr1[M],Service-Type(AA), |
| State2,Frag-Status(MDP)} |
|<--------------------------------------------------------|
| |
| Access-Request(3){User-Name,Frag-Status(MDR),State2} |
|-------------------------------------------------------->|
| |
| Access-Accept(3){User-Name,Attr1[M],Attr1, |
| Attr2[M],Attr2[M],Attr2, |
| Service-Type(X)} |
|<--------------------------------------------------------|
Figure 2: Fragmented Access-Accept packet
3.3. Combined use of both fragmented packets
The use of both fragmented packets may occur simultaneously. In that
case, the AS will be the first sending the fragmented data. In the
last chunk from the AS to the NAS it is included a Service-Type =
Additional-Authorization attribute, indicating the NAS that it can
proceed sending its data. The original Service-Type (if any) will be
included in the last Access-Accept from the AS to the NAS after
having received all the chunks.
Specifically, the NAS wants to send the following Access-Request
packet (Attr1 has 9 fragments):
Perez-Mendez, et al. Expires August 5, 2013 [Page 12]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
Access-Request(1) {User-Name, Calling-Station-Id, Attr1[M],
Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M],
Attr1[M], Attr1}
While the AS wants to send the following Access-Accept packet (Attr2
has 8 fragments):
Access-Accept(1) {User-Name, Service-Type(X), Framed-IP-Address,
Attr2[M], Attr2[M], Attr2[M], Attr2[M], Attr2[M], Attr2[M],
Attr2[M], Attr2}
Perez-Mendez, et al. Expires August 5, 2013 [Page 13]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
+-+-+-+-+ +-+-+-+-+
| NAS | | AS |
+-+-+-+-+ +-+-+-+-+
| |
| Access-Request(1){User-Name,...,Frag-Status(AA)} |
|-------------------------------------------------------->|
| . |
| . |
| Authentication process |
|<------------------------------------------------------->|
| . |
| . |
| Access-Accept(1){User-Name,Framed-IP-Address, |
| Attr2[M],Attr2[M],Attr2[MT],State1, |
| Service-Type(AA),Frag-Status(MDP)} |
|<--------------------------------------------------------|
| |
| Access-Request(2){User-Name,Frag-Status(MDR),State1} |
|-------------------------------------------------------->|
| |
| Access-Accept(2){User-Name,Attr2[M],Attr2[M],|
| Attr2[M],Attr2[M],Attr2, |
| State2,Service-Type(AA)} |
|<--------------------------------------------------------|
| |
| Access-Request(3){User-Name,Calling-Station-Id, |
| Attr1[M],Attr1[M],Attr1[M],Attr1[MT], |
| State1,Frag-Status(MDP)} |
|-------------------------------------------------------->|
| |
| Access-Challenge(3){User-Name, |
| Frag-Status(MDR),State3} |
|<--------------------------------------------------------|
| |
| Access-Request(4){User-Name,State3,Attr1[M], |
| Attr1[M],Attr1[M],Attr1[M],Attr1} |
|-------------------------------------------------------->|
| |
| Access-Accept(4){User-Name,Service-Type(X)} |
|<--------------------------------------------------------|
Figure 3: Combined fragmentation of Access-Request and Access-Accept
packets
Perez-Mendez, et al. Expires August 5, 2013 [Page 14]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
3.4. Unsupported packet types
We define fragmentation for authentication and authorization only.
Fragmentation for other packet types is not supported. This section
explains the rationale behind that decision
3.4.1. Accounting
There is no need to fragment accounting packets. While the
accounting process can send large amounts of data, that data is
typically composed of many small updates. That is, there is no
demonstrated need to send indivisible blocks of more than 4K of data.
The need to send large amounts of data per user session often
originates from the need for flow-based accounting. In this use-
case, the client may send accounting data for many thousands of
flows, where all those flows are tied to one user session. The
existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section
5.11 has been proven to work here.
3.4.2. CoA
There is no need to fragment CoA packets. Instead, the CoA client
MUST send a CoA-Request packet containing session identification
attributes, along with Service-Type = Additional-Authorization, and a
State attribute. Implementations not supporting fragmentation will
respond with a CoA-NAK, and an Error-Cause of Unsupported-Service.
Implementations supporting this specification may not be able to
change authorization data for a particular session. In that case,
they MUST respond with a CoA-NAK, as above. Otherwise, the
implementation MUST start fragmentation via Access-Request, using the
methods defined here.
The above requirement solves a number of issues. It clearly
separates session identification from authorization. Without this
separation, it is difficult to both identify a session, and change
its authorization using the same attribute. It also ensures that the
authorization process is the same for initial authentication, and for
CoA.
When a sessions authorization is changed, the CoA server MUST
continue the existing service until the new authorization parameters
are applied. The change of service SHOULD be done atomically. If
the CoA server is unable to apply the new authorization, it MUST
terminate the user session.
Perez-Mendez, et al. Expires August 5, 2013 [Page 15]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
4. Chunk size
In an ideal scenario, chunks would be exactly 4096 bytes length, and
they would contain exactly 4096-20=4076 bytes of attributes from the
original large packet (where 20 is the size of the RADIUS header).
In this way, the number of round trips required to send a large
packet would be optimal. However, this is not possible for several
reasons.
1. RADIUS attributes have a variable length, and must be included
completely in a chunk. Thus, it is possible that, even if there
is some free space in the chunk, it is not enough to include the
next attribute. This can generate up to 254 bytes of spare space
on every chunk.
2. RADIUS fragmentation requires the introduction of some extra
attributes for signalling. Specifically, a Frag-Status attribute
(7 bytes) is included on every chunk of a packet, except the last
one. A RADIUS State attribute (from 3 to 255 bytes) is also
included in most chunks, to allow the server to bind an Access-
Request with a previous Access-Challenge. User-Name attributes
(from 3 to 255 bytes) are introduced on every chunk the client
sends as they are required by the proxies to route the packet to
its destination. Together, these attributes can generate from up
to 13 to 517 bytes of signalling data, reducing the amount of
payload information that can be sent on each chunk.
3. RADIUS packets SHOULD be adjusted to avoid exceeding the network
MTU. Otherwise, IP fragmentation may occur, having undesirable
consequences. Hence, maximum chunk size would be decreased from
4096 to the actual MTU of the network.
4. The inclusion of Proxy-State attributes by intermediary proxies
can decrease the availability of usable space into the chunk.
This is described with further detail in Section 6.1.
5. Allowed large packet size
There are no provisions for signalling how much data is to be sent
via the fragmentation process as a whole. It is difficult to define
what is meant by the "length" of any fragmented data. That data can
be multiple attributes, which includes RADIUS attribute header
fields. Or it can be one or more "large" attributes (more than 256
octets in length). Proxies can also filter these attributes, to
modify, add, or delete them and their contents. These proxies act on
a "packet by packet" basis, and cannot know what kind of filtering
actions they take on future packets. As a result, it is impossible
Perez-Mendez, et al. Expires August 5, 2013 [Page 16]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
to signal any meaningful value for the total amount of additional
data.
Implementations of this specification MUST limit the total amount of
data they send and/or receive via this specification. It is
RECOMMENDED that the limits be set to a few tens of kilobytes. Any
more than this may turn RADIUS into a generic transport protocol,
which is undesired. It is RECOMMENDED that this limit be exposed to
administrators, so that it can be changed if necessary.
Implementations of this specification MUST limit the total number of
round trips used during the fragmentation process. It is RECOMMENDED
that the number of round trips be limited to twenty (20). Any more
than this may indicate an implementation error, misconfiguration, or
a denial of service (DoS) attack. It is RECOMMENDED that this limit
be exposed to administrators, so that it can be changed if necessary.
6. Handling special attributes
6.1. Proxy-State attribute
RADIUS proxies may introduce Proxy-State attributes into any Access-
Request packet they forward. Should they cannot add this information
to the packet, they may silently discard forwarding it to its
destination, leading to DoS situations. Moreover, any Proxy-State
attribute received by a RADIUS server in an Access-Request packet
MUST be copied into the reply packet to it. For these reasons,
Proxy-State attributes require a special treatment within the packet
fragmentation mechanism.
When the RADIUS server replies to an Access-Request packet as part of
a conversation involving a fragmentation (either a chunk or a request
for chunks), it MUST include every Proxy-State attribute received
into the reply packet. This means that the server MUST take into
account the size of these Proxy-State attributes in order to
calculate the size of the next chunk to be sent.
However, while a RADIUS server will always know how many space MUST
be left on each reply packet for Proxy-State attributes (as they are
directly included by the RADIUS server), a RADIUS client cannot know
this information, as Proxy-State attributes are removed from the
reply packet by their respective proxies before forwarding them back.
Hence, clients need a mechanism to discover the amount of space
required by proxies to introduce their Proxy-State attributes. In
the following we describe a new mechanism to perform such a
discovery:
Perez-Mendez, et al. Expires August 5, 2013 [Page 17]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
1. When a RADIUS client does not know how many space will be
required by intermediate proxies for including their Proxy-State
attributes, it SHOULD start using a conservative value (e.g. 1024
bytes) as the chunk size.
2. When the RADIUS server receives a chunk from the client, it can
calculate the total size of the Proxy-State attributes that have
been introduced by intermediary proxies along the path. This
information MUST be returned to the client in the next reply
packet, encoded into a new attribute called Proxy-State-Len.
3. The RADIUS client reacts upon the reception of this attribute by
adjusting the maximum size for the next chunk accordingly.
6.2. State attribute
This RADIUS fragmentation mechanism makes use of the State attribute
to link all the chunks belonging to the same fragmented packet.
However, some considerations are required when the RADIUS server is
fragmenting a packet that already contains a State attribute for
other purposes not related with the fragmentation. If the procedure
described in Section 3 is followed, two different State attributes
could be included into a single chunk, incurring into two problems.
First, [RFC2865] explicitly forbids that more than one State
attribute appears into a single packet.
A straightforward solution consists on making the RADIUS server to
send the original State attribute into the last chunk of the sequence
(attributes can be re-ordered as specified in [RFC2865]). As the
last chunk (when generated by the RADIUS server) does not contain any
State attribute due to the fragmentation mechanism, both situations
described above are avoided.
Something similar happens when the RADIUS client has to send a
fragmented packet that contains a State attribute on it. The client
MUST assure that this original State is included into the first chunk
sent to the server (as this one never contains any State attribute
due to fragmentation).
6.3. Service-Type attribute
This RADIUS fragmentation mechanism makes use of the Service-Type
attribute to indicate an Access-Accept packet is not granting access
to the service yet, since additional authorization exchange needs to
be performed. Similarly to the State attribute, the RADIUS server
has to send the original Service-Type attribute into the last Access-
Accept of the RADIUS conversation to avoid ambiguity.
Perez-Mendez, et al. Expires August 5, 2013 [Page 18]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
6.4. Rebuilding the original large packet
The RADIUS client stores the RADIUS attributes received on each chunk
in order to be able to rebuild the original large packet after
receiving the last chunk. However, some of these received attributes
MUST NOT be stored in this list, as they have been introduced as part
of the fragmentation signalling and hence, they are not part of the
original packet.
o State (except the one in the last chunk, if present)
o Service-Type = Additional-Authorization
o Frag-Status
o Proxy-State-Len
Similarly, the RADIUS server MUST NOT store the following attributes
as part of the original large packet:
o State (except the one in the first chunk, if present)
o Frag-Status
o Proxy-State (except the ones in the last chunk)
o User-Name (except the one in the first chunk)
7. New attribute definition
This document proposes the definition of two new extended type
attributes, called Frag-Status and Proxy-State-Len. The format of
these attributes follows the indications for an Extended Type
attribute defined in [I-D.ietf-radext-radius-extensions].
7.1. Frag-Status attribute
This attribute is used for fragmentation signalling, and its meaning
depends on the code value transported within it. The following
figure represents the format of the Frag-Status attribute.
Perez-Mendez, et al. Expires August 5, 2013 [Page 19]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Frag-Status format
Type
To be assigned (TBA)
Length
7
Extended-Type
To be assigned (TBA).
Code
4 byte. Integer indicating the code. The values defined in this
specifications are:
0 - Reserved
1 - Fragmentation-Supported
2 - Additional-Authorization
3 - More-Data-Pending
4 - More-Data-Request
This attribute MAY be present in Access-Request, Access-Challenge and
Access-Accept packets. It MUST not be included in Access-Reject
packets.
7.2. Proxy-State-Len attribute
This attribute indicates to the RADIUS client the length of the
Proxy-State attributes received by the RADIUS server. This
information is useful to adjust the length of the chunks sent by the
RADIUS client. The format of this Proxy-State-Len attribute is the
following:
Perez-Mendez, et al. Expires August 5, 2013 [Page 20]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Proxy-State-Len format
Type
To be assigned (TBA)
Length
7
Extended-Type
To be assigned (TBA).
Value
4 bytes. Total length (in bytes) of received Proxy-State
attributes (including headers).
This attribute MAY be present in Access-Challenge and Access-Accept
packets. It MUST not be included in Access-Request or Access-Reject
packets.
7.3. Table of attributes
The following table shows the different attributes defined in this
document related with the kind of RADIUS packets where they can be
present.
| Kind of packet |
+-----+-----+-----+-----+
Attribute Name | Req | Acc | Rej | Cha |
----------------------+-----+-----+-----+-----+
Frag-Status | 0-1 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+
Proxy-State-Len | 0 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+
Figure 6
Perez-Mendez, et al. Expires August 5, 2013 [Page 21]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
8. Operation with proxies
The fragmentation mechanism defined above is designed to be
transparent to legacy proxies, as long as they do not want to modify
any fragmented attribute. Nevertheless, updated proxies supporting
this specification can even modify fragmented attributes.
8.1. Legacy proxies
As every chunk is indeed a RADIUS packet, legacy proxies treat them
as the rest of packets, routing them to their destination. Proxies
can introduce Proxy-State attributes to Access-Request packets, even
if they are indeed chunks. This will not affect how fragmentation is
managed. The server will include all the received Proxy-State
attributes into the generated response, as described in [RFC2865].
Hence, proxies do not distinguish between a regular RADIUS packet and
a chunk.
8.2. Updated proxies
Updated proxies can interact with clients and servers in order to
obtain the complete large packet before start forwarding it. In this
way, proxies can manipulate (modify and/or remove) any attribute of
the packet, or introduce new attributes, without worrying about
crossing the boundaries of the chunk size. Once the manipulated
packet is ready, it is sent to the original destination using the
fragmentation mechanism (if required). The following example shows
how an updated proxy interacts with the NAS to obtain a large Access-
Request packet, modify an attribute resulting into a even more large
packet, and interacts with the AS to complete the transmission of the
modified packet.
Perez-Mendez, et al. Expires August 5, 2013 [Page 22]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
+-+-+-+-+ +-+-+-+-+
| NAS | | Proxy |
+-+-+-+-+ +-+-+-+-+
| |
| Access-Request(1){User-Name,Calling-Station-Id, |
| Attr1[M],Attr1[M],Attr1[M],Attr1[M], |
| Attr1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State1} |
|<---------------------------------------------------|
| |
| Access-Request(2)(User-Name,State1,Attr1[M], |
| Attr1[M],Attr1[M],Attr1} |
|--------------------------------------------------->|
PROXY MODIFIES ATTRIBUTE Data INCREASING ITS
SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS
Figure 7: Updated proxy interacts with NAS
Perez-Mendez, et al. Expires August 5, 2013 [Page 23]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
+-+-+-+-+ +-+-+-+-+
| Proxy | | AS |
+-+-+-+-+ +-+-+-+-+
| |
| Access-Request(3){User-Name,Calling-Station-Id, |
| Attr1[M],Attr1[M],Attr1[M],Attr1[M], |
| Attr1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State2} |
|<---------------------------------------------------|
| |
| Access-Request(4){User-Name,State2,Attr1[M], |
| Attr1[M],Attr1[M],Attr1[M], |
| Attr1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State3} |
|<---------------------------------------------------|
| |
| Access-Request(5){User-Name,State3,Attr1} |
|--------------------------------------------------->|
Figure 8: Updated proxy interacts with AS
9. Security Considerations
As noted in many earlier specifications ([RFC5080], [RFC6158], etc.)
RADIUS security is problematic. This specification changes nothing
related to the security of the RADIUS protocol. It requires that all
Access-Request packets associated with fragmentation are signed using
the existing Message-Authenticator attribute. This signature
prevents forging and replay, to the limits of the existing security.
The ability to send bulk data from one party to another creates new
security considerations. Clients and servers may have to store large
amounts of data per session. The amount of this data can be
significant, leading to the potential for resource exhaustion. We
therefore suggest that implementations limit the amount of bulk data
stored per session. The exact method for this limitation is
implementation-specific. Section 5 gives some indications on what
could be a reasonable limits.
The bulk data can often be pushed off to storage methods other than
the memory of the RADIUS implementation. For example, it can be
Perez-Mendez, et al. Expires August 5, 2013 [Page 24]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
stored in an external database, or in files. This approach mitigates
the resource exhaustion issue, as servers today already store large
amounts of accounting data.
10. IANA Considerations
The authors request that Attribute Types and Attribute Values defined
in this document be registered by the Internet Assigned Numbers
Authority (IANA) from the RADIUS namespaces as described in the "IANA
Considerations" section of [RFC3575], in accordance with BCP 26
[RFC5226]. For RADIUS packets, attributes and registries created by
this document IANA is requested to place them at
http://www.iana.org/assignments/radius-types.
This document defines the following RADIUS messages:
o Frag-Status
o Proxy-State-Len
Additionally, allocation of a new Service-Type value for "Additional-
Authorization" is requested.
11. Normative References
[I-D.ietf-radext-radius-extensions]
DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions",
draft-ietf-radext-radius-extensions-11 (work in progress),
February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Perez-Mendez, et al. Expires August 5, 2013 [Page 25]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, March 2011.
Authors' Addresses
Alejandro Perez-Mendez (Ed.)
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
Murcia, 30100
Spain
Phone: +34 868 88 46 44
Email: alex@um.es
Rafa Marin-Lopez
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
Murcia, 30100
Spain
Phone: +34 868 88 85 01
Email: rafa@um.es
Fernando Pereniguez-Garcia
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
Murcia, 30100
Spain
Phone: +34 868 88 78 82
Email: pereniguez@um.es
Perez-Mendez, et al. Expires August 5, 2013 [Page 26]
Internet-Draft Fragmentation of RADIUS packets Feb 2013
Gabriel Lopez-Millan
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
Murcia, 30100
Spain
Phone: +34 868 88 85 04
Email: gabilm@um.es
Diego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 84
Madrid, 28006
Spain
Phone: +34 913 129 041
Email: diego@tid.es
Alan DeKok
Network RADIUS
15 av du Granier
Meylan, 38240
France
Phone: +34 913 129 041
Email: aland@networkradius.com
URI: http://networkradius.com
Perez-Mendez, et al. Expires August 5, 2013 [Page 27]