draft-ietf-radext-radius-fragmentation-00.txt   draft-ietf-radext-radius-fragmentation-01.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
Intended status: Experimental F. Pereniguez-Garcia Intended status: Experimental F. Pereniguez-Garcia
Expires: February 28, 2014 G. Lopez-Millan Expires: April 24, 2014 G. Lopez-Millan
University of Murcia University of Murcia
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
A. DeKok A. DeKok
Network RADIUS Network RADIUS
August 27, 2013 October 21, 2013
Support of fragmentation of RADIUS packets Support of fragmentation of RADIUS packets
draft-ietf-radext-radius-fragmentation-00 draft-ietf-radext-radius-fragmentation-01
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 February 28, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 7 4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8
4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 8 4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 8
4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 12 4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 12
5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Allowed large packet size . . . . . . . . . . . . . . . . . . 15 6. Allowed large packet size . . . . . . . . . . . . . . . . . . 16
7. Handling special attributes . . . . . . . . . . . . . . . . . 16 7. Handling special attributes . . . . . . . . . . . . . . . . . 17
7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 16 7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 17
7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 17 7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 18
7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 17 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 19
7.4. Rebuilding the original large packet . . . . . . . . . . . 17 7.4. Rebuilding the original large packet . . . . . . . . . . . 19
8. New attribute definition . . . . . . . . . . . . . . . . . . . 18 8. New attribute definition . . . . . . . . . . . . . . . . . . . 19
8.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 18 8.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 20
8.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 19 8.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 21
8.3. Table of attributes . . . . . . . . . . . . . . . . . . . 20 8.3. Table of attributes . . . . . . . . . . . . . . . . . . . 21
9. Operation with proxies . . . . . . . . . . . . . . . . . . . . 20 9. Operation with proxies . . . . . . . . . . . . . . . . . . . . 22
9.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 22
9.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 21 9.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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 4, line 19 skipping to change at page 4, line 19
o PMTU discovery does not solve the problem, as it does not allow to o PMTU discovery does not solve the problem, as it does not allow to
send data larger than the minimum of (PMTU or 4096) octets. send data larger than the minimum of (PMTU or 4096) octets.
This document provides a mechanism to allow RADIUS peers to exchange This document provides a mechanism to allow RADIUS peers to exchange
large amounts of authorization data exceeding the 4096 octet limit, large amounts of authorization data exceeding the 4096 octet limit,
by fragmenting it across several client/server exchanges. The by fragmenting it across several client/server exchanges. The
proposed solution does not impose any additional requirements to the proposed solution does not impose any additional requirements to the
RADIUS system administrators (e.g. need to modify firewall rules, set RADIUS system administrators (e.g. need to modify firewall rules, set
up web servers, configure routers, or modify any application server). up web servers, configure routers, or modify any application server).
It maintains compatibility with intra-packet fragmentation mechanisms It maintains compatibility with intra-packet fragmentation mechanisms
(like those defined in [RFC3579] or in (like those defined in [RFC3579] or in [RFC6929]). It is also
[I-D.ietf-radext-radius-extensions]). It is also transparent to transparent to existing RADIUS proxies, which do not implement this
existing RADIUS proxies, which do not implement this specification. specification. The only systems needing to implement the draft are
The only systems needing to implement the draft are the ones which the ones which either generate, or consume the fragmented data being
either generate, or consume the fragmented data being transmitted. transmitted. Intermediate proxies just pass the packets without
Intermediate proxies just pass the packets without changes. changes. Nevertheless, if a proxy supports this specification, it
Nevertheless, if a proxy supports this specification, it MAY re- MAY re-assemble the data in order to either examine and/or modify it.
assemble the data in order to either examine and/or modify it.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Scope of this document 2. Scope of this document
This specification describes how a RADIUS client and a RADIUS server This specification describes how a RADIUS client and a RADIUS server
skipping to change at page 5, line 17 skipping to change at page 5, line 16
existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section
5.11 has been proven to work here. 5.11 has been proven to work here.
Similarly, there is no need to fragment CoA packets. Instead, the Similarly, there is no need to fragment CoA packets. Instead, the
CoA client MUST send a CoA-Request packet containing session CoA client MUST send a CoA-Request packet containing session
identification attributes, along with Service-Type = Additional- identification attributes, along with Service-Type = Additional-
Authorization, and a State attribute. Implementations not supporting Authorization, and a State attribute. Implementations not supporting
fragmentation will respond with a CoA-NAK, and an Error-Cause of fragmentation will respond with a CoA-NAK, and an Error-Cause of
Unsupported-Service. Unsupported-Service.
Implementations supporting this specification may not be able to The above requirement does not assume that the CoA client and the
change authorization data for a particular session. In that case, RADIUS server are co-located. They may, in fact be run on separate
they MUST respond with a CoA-NAK, as above. Otherwise, the parts of the infrastructure, or even by separate administrators.
implementation MUST start fragmentation via Access-Request, using the There is, however, a requirement that the two communicate. We can
methods defined here. see that the CoA client needs to send session identification
attributes in order to send CoA packets. These attributes cannot be
known a priori by the CoA client, and can only come from the RADIUS
server. Therefore, even when the two systems are not co-located,
they must be able to communicate in order to operate in unison. The
alternative is for the two systems to have differing views of the
users authorization parameters, which is a security disaster.
The above requirement solves a number of issues. It clearly This specification does not allow for fragmentation of CoA packets.
separates session identification from authorization. Without this Allowing for fragmented CoA packets would involve changing multiple
separation, it is difficult to both identify a session, and change parts of the RADIUS protocol, with the corresponding possibility for
its authorization using the same attribute. It also ensures that the implementation issues, mistakes, etc.
authorization process is the same for initial authentication, and for
CoA.
When a sessions authorization is changed, the CoA server MUST Where CoA clients need to send large amounts of authorization data to
continue the existing service until the new authorization parameters a NAS, they need only send a minimal CoA-Request packet, containing
are applied. The change of service SHOULD be done atomically. If Service-Type of Authorize-Only, as per RFC 5176. They SHOULD also
the CoA server is unable to apply the new authorization, it MUST have a co-located RADIUS server, for the sole purpose of implementing
terminate the user session. this specification.
The NAS will then perform fragmentation as per this draft to the
RADIUS server it is configured to use. That RADIUS server SHOULD
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.
That is, the NAS sends packets to a server which proxies them to the
system which is co-located with the CoA client. This process 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.
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
skipping to change at page 6, line 15 skipping to change at page 6, line 33
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 it to be Each Access-Request contains a User-Name attribute, allowing the
proxied if necessary. Each Access-Request may also contain a State packet to be proxied if necessary (see Section 9.1). Each Access-
attribute, which serves to tie it to a previous Access-Accept. Each Request may also contain a State attribute, which serves to tie it to
Access-Accept contains a State attribute, for use by the NAS in a a previous Access-Accept. Each Access-Accept contains a State
later Access-Request. Each Access-Accept contains a Service-Type attribute, for use by the NAS in a later Access-Request. Each
indicating that the service being provided is fragmentation, and that Access-Accept contains a Service-Type indicating that the service
the Access-Accept should not be interpreted as providing network being provided is fragmentation, and that the Access-Accept should
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, as required by [RFC2865]. The number of order of the attributes, as required by [RFC2865]. The number of
attributes encoded in a particular chunk depends on the size limit, attributes encoded in a particular chunk depends on the size limit,
skipping to change at page 6, line 47 skipping to change at page 7, line 18
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.
When multiple chunks are sent, a special situation may occur for When multiple chunks are sent, a special situation may occur for
Extended Type attributes as defined in Extended Type attributes as defined in [RFC6929]. The fragmentation
[I-D.ietf-radext-radius-extensions]. The fragmentation process may process may split a fragmented attribute across two or more chunks,
split a fragmented attribute across two or more chunks, which is not which is not permitted by that specification. We address this issue
permitted by that specification. We address this issue by defining a by defining a new field in the Reserved field of the "Long Extended
new field in the Reserved field of the "Long Extended Type" attribute Type" attribute format. This field is one bit in size, and is called
format. This field is one bit in size, and is called "T" for "T" for Truncation. It indicates that the attribute is intentionally
Truncation. It indicates that the attribute is intentionally
truncated in this chunk, and is to be continued in the next chunk of truncated in this chunk, and is to be continued in the next chunk of
the sequence. The combination of the flags "M" and "T" indicates the sequence. The combination of the flags "M" and "T" indicates
that the attribute is fragmented (flag M), but that all the fragments that the attribute is fragmented (flag M), but that all the fragments
are not available in this chunk (flag T). are not available in this chunk (flag T). Proxies implementing
[RFC6929] will see these attributes as invalid (they will not be able
to reconstruct them), but they will still forward them as [RFC6929]
section 5.2 indicates they SHOULD forward unknown attributes anyway.
This last situation is expected to be the most common occurrence in This last situation is expected to be the most common occurrence in
chunks. Typically, packet fragmentation will occur as a consequence chunks. Typically, packet fragmentation will occur as a consequence
of a desire to send one or more large (and therefore fragmented) of a desire to send one or more large (and therefore fragmented)
attributes. The large attribute will likely be split into two or attributes. The large attribute will likely be split into two or
more pieces. Where chunking does not split a fragmented attribute, more pieces. Where chunking does not split a fragmented attribute,
no special treatment is necessary. no special treatment is necessary.
The setting of the "T" flag is the only case where the chunking The setting of the "T" flag is the only case where the chunking
process affects the content of an attribute. Even then, the "Value" process affects the content of an attribute. Even then, the "Value"
skipping to change at page 8, line 22 skipping to change at page 9, line 7
multiple Access-Request / Access-Accept exchanges. The example below multiple Access-Request / Access-Accept exchanges. The example below
shows this exchange. shows this exchange.
The following is an Access-Request which the NAS intends to send to a The following is an Access-Request which the NAS intends to send to a
server. However, due to a combination of issues (PMTU, large server. However, due to a combination of issues (PMTU, large
attributes, etc.), the content does not fit into one Access-Request attributes, etc.), the content does not fit into one Access-Request
packet. packet.
Access-Request Access-Request
User-Name User-Name
User-Password NAS-Identifier
Calling-Station-Id 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 [M] Example-Long-1 [M]
Example-Long-1 [M] Example-Long-1 [M]
Example-Long-1 [M] Example-Long-1 [M]
Example-Long-1 [M] Example-Long-1 [M]
Example-Long-1 Example-Long-1
skipping to change at page 9, line 7 skipping to change at page 9, line 39
is sent with a RADIUS Identifier field having value 23. The Frag- is sent with a RADIUS Identifier field having value 23. The Frag-
Status attribute has value More-Data-Pending, to indicate that the Status attribute has value More-Data-Pending, to indicate that the
NAS wishes to send more data in a subsequent Access-Request. The NAS NAS wishes to send more data in a subsequent Access-Request. The NAS
also adds a Service-Type attribute, which indicates that it is part also adds a Service-Type attribute, which indicates that it is part
of the chunking process. The packet is signed with the Message- of the chunking process. The packet is signed with the Message-
Authenticator attribute, completing the maximum number of attributes Authenticator attribute, completing the maximum number of attributes
(11). (11).
Access-Request (ID = 23) Access-Request (ID = 23)
User-Name User-Name
User-Password NAS-Identifier
Calling-Station-Id 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] Example-Long-1 [MT]
Frag-Status = More-Data-Pending Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization Service-Type = Additional-Authorization
Message-Authenticator Message-Authenticator
skipping to change at page 10, line 6 skipping to change at page 10, line 38
will then continue the chunking process. Non-compliant NASes will will then continue the chunking process. Non-compliant NASes will
never see a response such as this, as they will never send a Frag- never see a response such as this, as they will never send a Frag-
Status attribute. The Service-Type attribute is included in the Status attribute. The Service-Type attribute is included in the
Access-Accept in order to signal that the response is part of the Access-Accept in order to signal that the response is part of the
chunking process. This packet therefore does not provision any chunking process. This packet therefore does not provision any
network service for the end user. network service for the end user.
The NAS continues the process by sending the next chunk, which The NAS continues the process by sending the next chunk, which
includes an additional six (6) attributes from the original packet. includes an additional six (6) attributes from the original packet.
It again includes the User-Name attribute, so that non-compliant It again includes the User-Name attribute, so that non-compliant
proxies can process the packet. It sets the Frag-Status attribute to proxies can process the packet (see Section 9.1). It sets the Frag-
More-Data-Pending, as more data is pending. It includes a Service- Status attribute to More-Data-Pending, as more data is pending. It
Type for reasons described above. It includes the State attribute includes a Service-Type for reasons described above. It includes the
from the previous Access-accept. It signs the packet with Message- State attribute from the previous Access-accept. It signs the packet
Authenticator, as there are no authentication attributes in the with Message-Authenticator, as there are no authentication attributes
packet. It uses a new RADIUS Identifier field. in the packet. It uses a new RADIUS Identifier field.
Access-Request (ID = 181) Access-Request (ID = 181)
User-Name User-Name
Example-Long-1 [M] Example-Long-1 [M]
Example-Long-1 [M] Example-Long-1 [M]
Example-Long-1 [M] Example-Long-1 [M]
Example-Long-1 Example-Long-1
Example-Long-2 [M] Example-Long-2 [M]
Example-Long-2 [MT] Example-Long-2 [MT]
Frag-Status = More-Data-Request Frag-Status = More-Data-Request
skipping to change at page 13, line 39 skipping to change at page 14, line 35
Compliant clients receiving this packet will see the Frag-Status Compliant clients receiving this packet will see the Frag-Status
attribute, wand suspend all authorization and authentication handling attribute, wand suspend all authorization and authentication handling
until all of the chunks have been received. Non-compliant clients until all of the chunks have been received. Non-compliant clients
should also see the Service-Type indicating the provisioning for an should also see the Service-Type indicating the provisioning for an
unknown service, and will treat it as an Access-Reject. unknown service, and will treat it as an Access-Reject.
Clients who wish to receive all of the chunks will respond with the Clients who wish to receive all of the chunks will respond with the
following packet, where the value of the State attribute is taken following packet, where the value of the State attribute is taken
from the received Access-Accept. They also include the User-Name from the received Access-Accept. They also include the User-Name
attribute so that non-compliant proxies can process the packet. attribute so that non-compliant proxies can process the packet
(Section 9.1).
Access-Request (ID = 131) Access-Request (ID = 131)
User-Name User-Name
Frag-Status = More-Data-Request Frag-Status = More-Data-Request
Service-Type = Additional-Authorization Service-Type = Additional-Authorization
State = 0xcba00004 State = 0xcba00004
Message-Authenticator Message-Authenticator
Figure 10: Access-Request (chunk 1) Figure 10: Access-Request (chunk 1)
skipping to change at page 16, line 13 skipping to change at page 17, line 9
which is undesired. It is RECOMMENDED that this limit be exposed to which is undesired. It is RECOMMENDED that this limit be exposed to
administrators, so that it can be changed if necessary. administrators, 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. It is RECOMMENDED round trips used during the fragmentation process. It is RECOMMENDED
that the number of round trips be limited to twenty (20). Any more that the number of round trips be limited to twenty (20). Any more
than this may indicate an implementation error, misconfiguration, or than this may indicate an implementation error, misconfiguration, or
a denial of service (DoS) attack. It is RECOMMENDED that this limit a denial of service (DoS) attack. It is RECOMMENDED that this limit
be exposed to administrators, so that it can be changed if necessary. be exposed to administrators, so that it can be changed if necessary.
For instance, let's imagine the RADIUS server wants to transport an
SAML assertion which is 15000 octets long, to the RADIUS client. In
this hypothetical scenario, we assume there are 3 intermediate
proxies, each one inserting a Proxy-State attribute of 20 octets.
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
chunk for the transport of the SAML assertion attributes is: Total
(4096) - RADIUS header (20) - 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),
resulting in a total of 3979 octets, that is, 15 attributes of 255
bytes.
According to [RFC6929], a Long-Extended-Type provides a payload of
251 octets. Therefore, the SAML assertion described above would
result into 60 attributes, requiring of 4 round-trips to be
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 cannot add this information
to the packet, they may silently discard forwarding it to its to the packet, they may silently discard forwarding it to its
destination, leading to DoS situations. Moreover, any Proxy-State destination, leading to DoS situations. Moreover, any Proxy-State
attribute received by a RADIUS server in an Access-Request packet attribute received by a RADIUS server in an Access-Request packet
MUST be copied into the reply packet to it. For these reasons, MUST be copied into the reply packet to it. For these reasons,
skipping to change at page 17, line 5 skipping to change at page 18, line 19
1. When a RADIUS client does not know how many space will be 1. When a RADIUS client does not know how many space will be
required by intermediate proxies for including their Proxy-State required by intermediate proxies for including their Proxy-State
attributes, it SHOULD start using a conservative value (e.g. 1024 attributes, it SHOULD start using a conservative value (e.g. 1024
octets) as the chunk size. octets) as the chunk size.
2. When the RADIUS server receives a chunk from the client, it can 2. When the RADIUS server receives a chunk from the client, it can
calculate the total size of the Proxy-State attributes that have calculate the total size of the Proxy-State attributes that have
been introduced by intermediary proxies along the path. This been introduced by intermediary proxies along the path. This
information MUST be returned to the client in the next reply information MUST be returned to the client in the next reply
packet, encoded into a new attribute called Proxy-State-Len. packet, encoded into a new attribute called Proxy-State-Len. The
server MAY artificially increase this quantity in order to handle
with situations where proxies behave inconsistently (e.g. they
generate Proxy-State attributes with a different size for each
packet), or for situations where intermediary proxies remove
Proxy-State attributes generated by other proxies. Increasing
this value would make the client to leave some free space for
these situations.
3. The RADIUS client reacts upon the reception of this attribute by 3. The RADIUS client SHOULD react upon the reception of this
adjusting the maximum size for the next chunk accordingly. attribute by adjusting the maximum size for the next chunk
accordingly. However, as the Proxy-State-Len offers just an
estimation of the space required by the proxies, the client MAY
select a smaller amount in environments known to be problematic.
7.2. State attribute 7.2. State attribute
This RADIUS fragmentation mechanism makes use of the State attribute This RADIUS fragmentation mechanism makes use of the State attribute
to link all the chunks belonging to the same fragmented packet. to link all the chunks belonging to the same fragmented packet.
However, some considerations are required when the RADIUS server is However, some considerations are required when the RADIUS server is
fragmenting a packet that already contains a State attribute for fragmenting a packet that already contains a State attribute for
other purposes not related with the fragmentation. If the procedure other purposes not related with the fragmentation. If the procedure
described in Section 4 is followed, two different State attributes described in Section 4 is followed, two different State attributes
could be included into a single chunk, incurring into two problems. could be included into a single chunk, incurring into two problems.
skipping to change at page 18, line 29 skipping to change at page 20, line 5
o Proxy-State (except the ones in the last chunk) o Proxy-State (except the ones in the last chunk)
o User-Name (except the one in the first chunk) o User-Name (except the one in the first chunk)
8. New attribute definition 8. New attribute definition
This document proposes the definition of two new extended type This document proposes the definition of two new extended type
attributes, called Frag-Status and Proxy-State-Len. The format of attributes, called Frag-Status and Proxy-State-Len. The format of
these attributes follows the indications for an Extended Type these attributes follows the indications for an Extended Type
attribute defined in [I-D.ietf-radext-radius-extensions]. attribute defined in [RFC6929].
8.1. Frag-Status attribute 8.1. Frag-Status attribute
This attribute is used for fragmentation signalling, and its meaning This attribute is used for fragmentation signalling, and its meaning
depends on the code value transported within it. The following depends on the code value transported within it. The following
figure represents the format of the Frag-Status attribute. figure represents the format of the Frag-Status attribute.
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 4 skipping to change at page 22, line 31
this specification can even modify fragmented attributes. this specification can even modify fragmented attributes.
9.1. Legacy proxies 9.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
as the rest of packets, routing them to their destination. Proxies as the rest of packets, routing them to their destination. Proxies
can introduce Proxy-State attributes to Access-Request packets, even can introduce Proxy-State attributes to Access-Request packets, even
if they are indeed chunks. This will not affect how fragmentation is if they are indeed chunks. This will not affect how fragmentation is
managed. The server will include all the received Proxy-State managed. The server will include all the received Proxy-State
attributes into the generated response, as described in [RFC2865]. attributes into the generated response, as described in [RFC2865].
Hence, proxies do not distinguish between a regular RADIUS packet and Hence, proxies do not distinguish between a regular RADIUS packet and
a chunk. a chunk.
This proposal assumes legacy proxies to base their routing decisions
on the value of the User-Name attribute. For this reason, every
packet sent from the client to the server (either chunks or requests
for more chunks) MUST contain a User-Name attribute.
9.2. Updated proxies 9.2. Updated proxies
Updated proxies can interact with clients and servers in order to Updated proxies can interact with clients and servers in order to
obtain the complete large packet before start forwarding it. In this obtain the complete large packet before start forwarding it. In this
way, proxies can manipulate (modify and/or remove) any attribute of way, proxies can manipulate (modify and/or remove) any attribute of
the packet, or introduce new attributes, without worrying about the packet, or introduce new attributes, without worrying about
crossing the boundaries of the chunk size. Once the manipulated crossing the boundaries of the chunk size. Once the manipulated
packet is ready, it is sent to the original destination using the packet is ready, it is sent to the original destination using the
fragmentation mechanism (if required). The following example shows fragmentation mechanism (if required). The following example shows
how an updated proxy interacts with the NAS to obtain a large Access- how an updated proxy interacts with the NAS to obtain a large Access-
skipping to change at page 23, line 34 skipping to change at page 25, line 34
o Proxy-State-Len o Proxy-State-Len
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.
12. References 12. References
12.1. Normative References 12.1. 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-13 (work in progress),
February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
skipping to change at page 24, line 21 skipping to change at page 26, line 16
Dial In User Service (RADIUS) Implementation Issues and Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007. Suggested Fixes", RFC 5080, December 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, March 2011. BCP 158, RFC 6158, March 2011.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
April 2013.
12.2. Informative References 12.2. Informative References
[RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter
Rule Attribute", RFC 4849, April 2007. Rule Attribute", RFC 4849, April 2007.
Authors' Addresses Authors' Addresses
Alejandro Perez-Mendez (Ed.) Alejandro Perez-Mendez (Ed.)
University of Murcia University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science Campus de Espinardo S/N, Faculty of Computer Science
 End of changes. 25 change blocks. 
86 lines changed or deleted 138 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/