draft-ietf-radext-radius-fragmentation-07.txt   draft-ietf-radext-radius-fragmentation-08.txt 
RADIUS EXTensions Working Group A. Perez-Mendez RADIUS EXTensions Working Group A. Perez-Mendez
Internet-Draft R. Marin-Lopez Internet-Draft R. Marin-Lopez
Updates: RFC6929 (if approved) F. Pereniguez-Garcia Updates: RFC6929 (if approved) F. Pereniguez-Garcia
Intended status: Experimental G. Lopez-Millan Intended status: Experimental G. Lopez-Millan
Expires: January 5, 2015 University of Murcia Expires: April 6, 2015 University of Murcia
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
A. DeKok A. DeKok
Network RADIUS Network RADIUS
July 4, 2014 October 3, 2014
Support of fragmentation of RADIUS packets Support of fragmentation of RADIUS packets
draft-ietf-radext-radius-fragmentation-07 draft-ietf-radext-radius-fragmentation-08
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 January 5, 2015. This Internet-Draft will expire on April 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 44 skipping to change at page 3, line 44
[RFC6158] recommends three approaches for the transmission of large [RFC6158] recommends three approaches for the transmission of large
amount of data within RADIUS. However, they are not applicable to amount of data within RADIUS. However, they are not applicable to
the problem statement of this document for the following reasons: the problem statement of this document for the following reasons:
o The first approach does not talk about large amounts of data sent o The first approach does not talk about large amounts of data sent
from the NAS to a server. Leveraging EAP (request/challenge) to from the NAS to a server. Leveraging EAP (request/challenge) to
send the data is not feasible, as EAP already fills packet to send the data is not feasible, as EAP already fills packet to
PMTU, and not all authentications use EAP. Moreover, as noted for PMTU, and not all authentications use EAP. Moreover, as noted for
NAS-Filter-Rule ([RFC4849]), this approach does entirely solve the NAS-Filter-Rule ([RFC4849]), this approach does entirely solve the
problem of sending large amounts of data from a server to a NAS. problem of sending large amounts of data from a server to a NAS,
as many current RADIUS attributes are not permitted in an Access-
Challenge packets.
o The second approach is not usable either, as using names rather o The second approach is not usable either, as using names rather
than values is difficult when the nature of the data to be sent is than values is difficult when the nature of the data to be sent is
highly dynamic (e.g. SAML sentences or NAS-Filter-Rule highly dynamic (e.g. SAML statement or NAS-Filter-Rule
attributes). URLs could be used as a pointer to the location of attributes). URLs could be used as a pointer to the location of
the actual data, but their use would require them to be (a) the actual data, but their use would require them to be (a)
dynamically created and modified, (b) securely accessed and (c) dynamically created and modified, (b) securely accessed and (c)
accessible from remote systems. Satisfying these constraints accessible from remote systems. Satisfying these constraints
would require the modification of several networking systems (e.g. would require the modification of several networking systems (e.g.
firewalls and web servers). Furthermore, the set up of an firewalls and web servers). Furthermore, the set up of an
additional trust infrastructure (e.g. PKI) would be required to additional trust infrastructure (e.g. PKI) would be required to
allow secure retrieving of the information from the web server. allow secure retrieving of the information from the web server.
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
skipping to change at page 9, line 48 skipping to change at page 9, line 48
4. Fragmentation of packets 4. Fragmentation of packets
When the NAS or the AS desires to send a packet that exceeds the size When the NAS or the AS desires to send a packet that exceeds the size
limit, it is split into chunks and sent via multiple client/server limit, it is split into chunks and sent via multiple client/server
exchanges. The exchange is indicated via the Frag-Status attribute, exchanges. The exchange is indicated via the Frag-Status attribute,
which has value More-Data-Pending for all but the last chunk of the which has value More-Data-Pending for all but the last chunk of the
series. The chunks are tied together via the State attribute. series. The chunks are tied together via the State attribute.
The delivery of a large fragmented RADIUS packet with authorization The delivery of a large fragmented RADIUS packet with authorization
data can happen before or after the end user has been authenticated data can happen before or after the end user has been authenticated
by the AS. We can distinguish two phases: by the AS. We can distinguish two phases, which can be omitted if
there is no authorization data to be sent:
1. Pre-authorization. In this phase, the NAS can send a large 1. Pre-authorization. In this phase, the NAS MAY send a large
packet with authorization information to the AS before the end packet with authorization information to the AS before the end
user is authenticated. user is authenticated. Only the NAS is allowed to send
authorization data during this phase.
2. Post-authorization. In this phase, the AS can send a large 2. Post-authorization. In this phase, the AS MAY send a large
packet with authorization data to the NAS after the end user has packet with authorization data to the NAS after the end user has
been authenticated. been authenticated. Only the AS is allowed to send authorization
data during this phase.
The following subsections describe how to perform fragmentation for The following subsections describe how to perform fragmentation for
packets for these two phases, pre-authorization and post- packets for these two phases, pre-authorization and post-
authorization. We give the packet type, along with a RADIUS authorization. We give the packet type, along with a RADIUS
Identifier, to indicate that requests and responses are connected. Identifier, to indicate that requests and responses are connected.
We then give a list of attributes. We do not give values for most We then give a list of attributes. We do not give values for most
attributes, as we wish to concentrate on the fragmentation behaviour, attributes, as we wish to concentrate on the fragmentation behaviour,
rather than packet contents. Attribute values are given for rather than packet contents. Attribute values are given for
attributes relevant to the fragmentation process. Where "long attributes relevant to the fragmentation process. Where "long
extended" attributes are used, we indicate the M (More) and T extended" attributes are used, we indicate the M (More) and T
skipping to change at page 19, line 37 skipping to change at page 19, line 37
According to [RFC6929], a Long-Extended-Type provides a payload of According to [RFC6929], a Long-Extended-Type provides a payload of
251 octets. Therefore, the SAML assertion described above would 251 octets. Therefore, the SAML assertion described above would
result into 60 attributes, requiring of 4 round-trips to be result into 60 attributes, requiring of 4 round-trips to be
completely transmitted. completely transmitted.
7. Handling special attributes 7. Handling special attributes
7.1. Proxy-State attribute 7.1. Proxy-State attribute
RADIUS proxies may introduce Proxy-State attributes into any Access- RADIUS proxies may introduce Proxy-State attributes into any Access-
Request packet they forward. Should they are unable to add this Request packet they forward. If they are unable to add this
information to the packet, they may silently discard forwarding it to information to the packet, they may silently discard forwarding it to
its destination, leading to DoS situations. Moreover, any Proxy- its destination, leading to DoS situations. Moreover, any Proxy-
State attribute received by a RADIUS server in an Access-Request State attribute received by a RADIUS server in an Access-Request
packet MUST be copied into the reply packet to it. For these packet MUST be copied into the reply packet to it. For these
reasons, Proxy-State attributes require a special treatment within reasons, Proxy-State attributes require a special treatment within
the packet fragmentation mechanism. the packet fragmentation mechanism.
When the RADIUS server replies to an Access-Request packet as part of When the RADIUS server replies to an Access-Request packet as part of
a conversation involving a fragmentation (either a chunk or a request a conversation involving a fragmentation (either a chunk or a request
for chunks), it MUST include every Proxy-State attribute received for chunks), it MUST include every Proxy-State attribute received
skipping to change at page 29, line 43 skipping to change at page 29, line 43
in this document be registered by the Internet Assigned Numbers in this document be registered by the Internet Assigned Numbers
Authority (IANA) from the RADIUS namespaces as described in the "IANA Authority (IANA) from the RADIUS namespaces as described in the "IANA
Considerations" section of [RFC3575], in accordance with BCP 26 Considerations" section of [RFC3575], in accordance with BCP 26
[RFC5226]. For RADIUS packets, attributes and registries created by [RFC5226]. For RADIUS packets, attributes and registries created by
this document IANA is requested to place them at this document IANA is requested to place them at
http://www.iana.org/assignments/radius-types. http://www.iana.org/assignments/radius-types.
In particular, this document defines two new RADIUS attributes, In particular, this document defines two new RADIUS attributes,
entitled "Frag-Status" and "Proxy-State-Len" (see section 9), entitled "Frag-Status" and "Proxy-State-Len" (see section 9),
assigned values of TBD1 and TBD2 from the Long Extended Space of assigned values of TBD1 and TBD2 from the Long Extended Space of
[RFC2865]: [RFC6929]:
Tag Name Length Meaning Tag Name Length Meaning
---- ---- ------ ------- ---- ---- ------ -------
TBD1 Frag-Status 7 Signals fragmentation TBD1 Frag-Status 7 Signals fragmentation
TBD2 Proxy-State-Len 7 Indicates the length of the TBD2 Proxy-State-Len 7 Indicates the length of the
received Proxy-State attributes received Proxy-State attributes
The Frag-Status attribute also defines a 8-bit "Code" field, for The Frag-Status attribute also defines a 8-bit "Code" field, for
which the IANA is to create and maintain a new sub-registry entitled which the IANA is to create and maintain a new sub-registry entitled
"Code values" under the RADIUS "Frag-Status" attribute. Initial "Code values" under the RADIUS "Frag-Status" attribute. Initial
 End of changes. 13 change blocks. 
13 lines changed or deleted 18 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/