Support of fragmentation of RADIUS packets
draft-perez-radext-radius-fragmentation-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Alejandro Pérez-Méndez , Rafael Marin-Lopez , Fernando Pereniguez-Garcia , Gabriel Lopez-Millan , Diego R. Lopez , Alan DeKok | ||
| Last updated | 2012-06-05 | ||
| Replaced by | draft-ietf-radext-radius-fragmentation, RFC 7499 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-perez-radext-radius-fragmentation-02
RADIUS EXTensions Working Group A. Perez-Mendez
Internet-Draft R. Marin-Lopez
Intended status: Experimental F. Pereniguez-Garcia
Expires: December 3, 2012 G. Lopez-Millan
University of Murcia
D. Lopez
Telefonica I+D
A. DeKok
Network RADIUS
Jun 2012
Support of fragmentation of RADIUS packets
draft-perez-radext-radius-fragmentation-02
Abstract
This document describes a mechanism providing fragmentation support
of RADIUS packets that exceed the 4 KB 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 December 3, 2012.
Copyright Notice
Copyright (c) 2012 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 December 3, 2012 [Page 1]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
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. More-Data-Pending attribute . . . . . . . . . . . . . . . . . 5
4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 6
4.1. Access-Request . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Access-Challenge . . . . . . . . . . . . . . . . . . . . . 8
4.3. Access-Accept . . . . . . . . . . . . . . . . . . . . . . 8
5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. State attribute . . . . . . . . . . . . . . . . . . . . . . . 12
7. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Perez-Mendez, et al. Expires December 3, 2012 [Page 2]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
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 packets. Each RADIUS packet can transport several
RADIUS attributes, to convey the necessary information to the other
peer, up to a maximum size of 4 KB of total data (including RADIUS
packet headers). RADIUS attributes have a maximum size of 253 bytes
of payload.
RADIUS has been extensively used along 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 splitting the data into a group of RADIUS attributes of
the same type, and then insert them into the RADIUS packet in order.
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 is also proposed in [RFC6158], where attribute can be
obtained through an out-of-band protocol.
However, there are no proposals to deal with fragmentation at a
packet level, when the total length exceeds the 4 KB limit imposed by
the RADIUS specification. As the usage of RADIUS is being considered
in more complex AAA scenarios, including the exchange of richer data,
like SAML assertions or JWT 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 that exceed the 4 KB limit, by fragmenting them across
several exchanges. This proposal tries to maintain compatibility
with intra-packet fragmentation mechanisms 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 December 3, 2012 [Page 3]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
2. Overview
When a RADIUS peer needs to send a packet that exceeds the 4 KB, the
following mechanism is used. First, the large packet is split into
several smaller RADIUS packets (i.e. chunks) of the same type (e.g.
Access-Request). The first chunk contains the first "n" RADIUS
attributes of the original packet (in the same order), 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 5). If there are
still attributes from the original packet that have not been yet
included into any chunk, a new attribute called More-Data-Pending is
appended into the chunk.
Then the first chunk is sent to the peer, which identifies the packet
as a chunk (the More-Data-Pending attribute is present), and requests
for the next chunk. The State attribute is used to tie the
conversation together.
This process is repeated until all the RADIUS attributes from the
original packet have been included into some chunk. Once all the
chunks have been received by the peer, the original packet is
reconstructed and processed as if it had been 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 occurs in the
middle of a fragmented attribute, the last attribute of the chunk
will be an Extended Type with Flags, with flag M enabled. 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 situation will be the most usual. When packet
fragmentation is required, usually it will be motivated by the
inclusion of one or more large attribute that makes use of attribute
fragmentation. 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 treatment.
Packet fragmentation may occur at any moment during a RADIUS
exchange, as peers may require to send a big amount of data.
Perez-Mendez, et al. Expires December 3, 2012 [Page 4]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
Nevertheless, as authentication mechanisms (e.g. RADIUS-EAP) are
already defined, and they are designed to avoid exceeding the 4 KB
limit, it is envisioned that most of the times large packets will be
generated by authorization data, which is sent along with the Access-
Accept packet (e.g. SAML assertions, JWT tokens, filters...).
3. More-Data-Pending attribute
This document proposes the definition of a new extended type
attribute, called More-Data-Pending. The format of this attribute
follows the indications of an Extended Type attribute defined in
[I-D.ietf-radext-radius-extensions]. The presence of this attribute
indicates that the received RADIUS packet is not complete (i.e. it is
a chunk), and more data MUST be received to regenerate the original
packet. The following figure represents the format of the More-Data-
Pending attribute.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: More-Data-Pending format
Type
To be assigned (TBA)
Length
4
Extended-Type
To be assigned (TBA).
Value
1 byte. Not defined yet.
This attribute MAY be present in Access-Request and Acess-Challenge
packets. It MUST not be included in Acess-Accept packets.
Perez-Mendez, et al. Expires December 3, 2012 [Page 5]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
4. Fragmentation of packets
4.1. Access-Request
When the NAS desires to send a RADIUS packet that exceeds the 4 KB
limit, the packet can be split into smaller packets (chunks) and sent
over different exchanges. This fact is indicated by including a
More-Data-Pending attribute on each chunk (except the last one of the
series). The process is described in detail using the following
example. In this example, the attributes "Data" and "Other" are
Extended Type with Flags, as defined in
[I-D.ietf-radext-radius-extensions].
In order to make the example simpler, it is assumed that each RADIUS
packet can include up to 8 RADIUS attributes, instead of using bytes.
Flag M is indicated as [M]. Flag T is indicated as [T]. Presence of
both is indicated as [MT]. Data1, Data2, Data3... indicate
successive fragments of the attribute "Data".
o The RADIUS client wants to send the following RADIUS packet:
Access-Request = User-Name, Calling-Station-Id, Data1[M],
Data2[M], Data3[M], Data4[M], Data5[M], Data6[M], Data7[M],
Data8[M], Data9[M], Data10, Other1[M], Other2[M], Other3
o As the RADIUS packet exceeds the maximum allowed length (8
attributes), the RADIUS client truncates the packet to generate
the first chunk, including the More-Data-Pending attribute. Flag
"T" is activated into the fragment "Data5", as it is the last of
the packet (chunk), but not the last of the fragmented attribute.
Access-Request-1 = User-Name, Calling-Station-Id, Data1[M],
Data2[M], Data3[M], Data4[M], Data5[MT], More-Data-Pending
o When the server receives the RADIUS packet containing the 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, using the State
attribute to tie together this response with the subsequent
request from the client.
Access-Challenge-1 = State1
o The client continues including attributes until another RADIUS
packet (i.e. chunk) is completed, appending again the More-Data-
Pending attribute. The State attribute received in the Access-
Challenge is also included in this chunk. Again, flag "T" is
enabled in the last fragment of the chunk to indicate that a
Perez-Mendez, et al. Expires December 3, 2012 [Page 6]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
truncation took place.
Acess-Request-2 = State1, Data6[M], Data7[M], Data8[M],
Data9[M], Data10, Other1[MT], More-Data-Pending
o As the received request contains the More-Data-Pending, the server
stores the attributes into the state associated to State1 and
replies with another Access-Challenge. The challenge contains a
new State attribute that refers to this conversation.
Access-Challenge-2 = State2
o Finally, the client sends the last chunk of the original packet,
including the received State attribute.
Access-Request-3 = State2, Other2[M], Other3
o On reception of this last chunk (no More-Data-Pending attribute
present), the server can process the totality of the received
attributes as if they all had been received into a single RADIUS
packet larger than 4 KB.
The following figure depicts the exchange of chucks between the NAS
and the AS.
+-+-+-+-+ +-+-+-+-+
| NAS | | AS |
+-+-+-+-+ +-+-+-+-+
| |
| Access-Request(ID1,User-Name,Calling-Station-Id, |
| Data1[M],Data2[M],Data3[M],Data4[M], |
| Data5[MT],More-Data-Pending) |
|-------------------------------------------------------->|
| |
| Access-Challenge(ID1,State1) |
|<--------------------------------------------------------|
| |
| Access-Request(ID2,State1,Data6[M],Data7[M],Data8[M], |
| Data9[M],Data10,Other1[MT], |
| More-Data-Pending |
|-------------------------------------------------------->|
| |
| Access-Challenge(ID2,State2) |
|<--------------------------------------------------------|
| |
| Access-Request(ID3,State2,Other2[M],Other3) |
|-------------------------------------------------------->|
Perez-Mendez, et al. Expires December 3, 2012 [Page 7]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
Figure 2: Fragmented Access-Request packet
4.2. Access-Challenge
When is the server (AS) the one who wants to send a large RADIUS
packet, the solution is very similar to the previous one. The one
difference is that in this scenario, the AS includes a State
attribute along with the More-Data-Required.
The following figure depicts how the message exchange would be if the
AS wanted to send a large packet to the NAS. Specifically, it wants
to send the following challenge:
Access-Challenge = Data1[M], Data2[M], Data3[M], Data4[M],
Data5[M], Data6[M], Data7[M], Data8[M], Data9[M], Data10,
Other1[M], Other2[M], Other3
+-+-+-+-+ +-+-+-+-+
| NAS | | AS |
+-+-+-+-+ +-+-+-+-+
| |
| Access-Challenge(ID1,Data1[M],Data2[M],Data3[M], |
| Data4[M],Data5[M],Data6[MT], |
| More-Data-Pending,State1) |
|<--------------------------------------------------------|
| |
| Access-Request(ID2,State1) |
|-------------------------------------------------------->|
| |
| Access-Challenge(ID2,Data7[M],Data8[M],Data9[M], |
| Data10,Other1[M],Other2[MT], |
| More-Data-Pending,State2) |
|<--------------------------------------------------------|
| |
| Access-Request(ID3,State2) |
|-------------------------------------------------------->|
| |
| Access-Challenge(ID3,Other3) |
|<--------------------------------------------------------|
Figure 3: Fragmented Access-Challenge packet
4.3. Access-Accept
If the AS wants to send an Access-Accept packet that exceeds the 4 KB
limit (usually due to authorization-specific attributes), the
operation is slightly different. As some attributes are allowed to
Perez-Mendez, et al. Expires December 3, 2012 [Page 8]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
appear in Access-Accept packets, but the cannot be present in Access-
Challenge packets, the solution described in the previous sections is
not directly applicable. Instead, the AS MUST send an Access-Accept
packet to the NAS, containing all the attributes that can not be
included in Access-Challenge packets, and indicating "Authorize-Only"
as the Service-Type. The additional attributes are received via a
series of Access-Request/Access-Challenge exchanges, as described in
the previous section. Finally, the last chunk from the AS to the NAS
would be an Access-Accept containing the last attributes of the
original packet, and containing the actual Service-Type attribute for
the user. For simplicity, in the example Service-Type[X] indicates a
Service-Type attribute of value X.
o The AS wants to send the following Access-Accept packet:
Access-Accept = User-Name, Service-Type[X], Framed-IP-Address,
Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], Data6[M],
Data7[M], Data8[M], Data9[M], Data10
o As the RADIUS packet exceeds the maximum allowed length (8
attributes), the AS truncates the packet to generate the first
chunk. This chunk only includes the attributes that cannot be
included in Access-Challenge packets. In this example they are
the User-Name, the Service-Type and the Framed-IP-Address. The
Service-Type is changed to "Authorize-Only", and a State attribute
is included.
Access-Accept-1 = User-Name, Service-Type[Authorize-Only],
Framed-IP-Addres, State1
o When the NAS receives the Access-Accept, it determines, based on
the Service-Type=Authorize-Only, that an additional exchange is
required. Thus, it generates a new Access-Request packet
containing the received State attribute.
Access-Request-1 = State1
o The AS then generates a new chunk with part of the remaining
attributes to be sent. As they do not fit into a single chunk, a
More-Data-Pending attribute and a new State attribute are also
included.
Access-Challenge-1 = Data1[M], Data2[M], Data3[M], Data4[M],
Data5[M], Data6[MT], More-Data-Pending, State2
o The NAS determines the received packet is part of a larger one
(i.e. it is a chunk) due to the presence of the More-Data-Pending
attribute, hence it requests the rest of the data by sending a new
Perez-Mendez, et al. Expires December 3, 2012 [Page 9]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
Access-Request packet including the received State attribute.
Access-Request-2 = State2
o Finally, the AS includes the rest of the attributes into the final
Access-Accept packet. This packet also includes the original
Service-Type for the user.
Access-Accept-2 = Data7[M], Data8[M], Data9[M], Data10,
Service-Type[X]
o On reception of this last packet, the NAS can process the totality
of the received attributes as if they all had been received into a
single RADIUS packet larger than 4 KB.
The following figure depicts the exchange of chucks between the NAS
and the AS.
+-+-+-+-+ +-+-+-+-+
| NAS | | AS |
+-+-+-+-+ +-+-+-+-+
| |
| Access-Accept(ID1,User-Name,Service-Type[AuthOnly], |
| Framed-IP-Addres,State1) |
|<--------------------------------------------------------|
| |
| Access-Request(ID2,State1) |
|-------------------------------------------------------->|
| |
| Access-Challenge(ID2,Data1[M],Data2[M],Data3[M], |
| Data4[M],Data5[M],Data6[MT], |
| More-Data-Pending,State2) |
|<--------------------------------------------------------|
| |
| Access-Request(ID3,State2) |
|-------------------------------------------------------->|
| |
| Access-Accept(ID3,Data7[M],Data8[M],Data9[M], |
| Data10,Service-Type[X]) |
|<--------------------------------------------------------|
Figure 4: Fragmented Access-Accept packet
5. 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
Perez-Mendez, et al. Expires December 3, 2012 [Page 10]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
original packet. 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, More-Data-Pending (4
bytes length) attribute is included on every chunk of a packet,
except the last one. A State attribute (up to 255 bytes) is also
included in most chunks, to allow the server to bind an Access-
Request with a previous Access-Challenge. Both attributes can
generate up to 259 bytes of signalling data, reducing the amount
of payload information being sent.
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. RADIUS proxies may introduce Proxy-State attributes into every
chunk. Should they cannot add this information to the packet,
they may silently discard forwarding it to its destination,
leading to DoS situations. Hence, every chunk MUST contain
enough free space to allow the proxies to include their Proxy-
State attributes. While a RADIUS server will always know how
many Proxy-State attributes will be included (as they are
received on every Access-Request packet), a RADIUS client cannot
know this information as Proxy-State attributes are removed from
the response by their respective proxies. Hence, a mechanism to
discover the amount of proxies between a client a server is
required. Specifically, a client SHOULD start setting the
maximum chunk size to a conservative value (e.g. 1 KB). Once the
server receives the Access-Request, it can determine the amount
of Proxy-State attributes that have been introduced along the
path by the proxies. This information is returned to the client
into a new attribute (TBD). Hence, the client can adjust the
chunk size to a higher value (MTU - size of proxy state
attributes).
Perez-Mendez, et al. Expires December 3, 2012 [Page 11]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
6. State attribute
This 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 4 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 Access-Challenge packet. Second, even if that
situation were allowed, the RADIUS client would be unable to
determine which State MUST be included in the next Access-Request for
fragmentation purposes, and which one of them MUST be included in the
Access-Request following the reception of the whole fragmented
packet.
A straightforward solution consists on forcing 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).
Keeping these simple rules, dealing with State attributes and
fragmentation does not generate problematic situations.
7. 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.
7.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
Perez-Mendez, et al. Expires December 3, 2012 [Page 12]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
attributes into the generated response, as described in [RFC2865].
Hence, proxies will not be able to distinguish between a regular
RADIUS packet and a chunk.
7.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, remove) any attribute of the
packet, or introduce new attributes, without worrying about crossing
the boundaries of the chunk size. Once the transformed 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.
+-+-+-+-+ +-+-+-+-+
| NAS | | Proxy |
+-+-+-+-+ +-+-+-+-+
| |
| Access-Request(ID1,User-Name,Calling-Station-Id, |
| Data1[M],Data2[M],Data3[M],Data4[M],|
| Data5[MT],More-Data-Pending) |
|--------------------------------------------------->|
| |
| Access-Challenge(ID1,State1) |
|<---------------------------------------------------|
| |
| Access-Request(ID2,State1,Data6[M],Data7[M], |
| Data8[M],Data9[M],Data10) |
|--------------------------------------------------->|
PROXY MODIFIES ATTRIBUTE Data INCREASING ITS
SIZE FROM 10 FRAGMENTS TO 13 FRAGMENTS
Figure 5: Updated proxy interacts with NAS
Perez-Mendez, et al. Expires December 3, 2012 [Page 13]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
+-+-+-+-+ +-+-+-+-+
| Proxy | | AS |
+-+-+-+-+ +-+-+-+-+
| |
| Access-Request(ID3,User-Name,Calling-Station-Id, |
| Data1[M],Data2[M],Data3[M],Data4[M],|
| Data5[MT],More-Data-pending) |
|--------------------------------------------------->|
| |
| Access-Challenge(ID3,State2) |
|<---------------------------------------------------|
| |
| Access-Request(ID4,State2,Data6[M],Data7[M], |
| Data8[M],Data9[M],Data10[M], |
| Data11[M],More-Data-Pending) |
|--------------------------------------------------->|
| |
| Access-Challenge(ID4,State3) |
|<---------------------------------------------------|
| |
| Access-Request(ID5,State3,Data12[M],Data13) |
|--------------------------------------------------->|
Figure 6: Updated proxy interacts with AS
8. Security Considerations
Proxies can modify chunks in such a way that the fragmentation
process fails. Nevertheless, in RADIUS proxies are trusted entities,
and they are always allowed to modify packets completely.
9. IANA Considerations
This document has no actions for IANA.
10. 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-05 (work in progress),
April 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Perez-Mendez, et al. Expires December 3, 2012 [Page 14]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[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 December 3, 2012 [Page 15]
Internet-Draft Fragmentation of RADIUS packets Jun 2012
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 December 3, 2012 [Page 16]