draft-ietf-radext-radius-fragmentation-11.txt   draft-ietf-radext-radius-fragmentation-12.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: 2865, 6158, 6929 F. Pereniguez-Garcia Intended status: Experimental F. Pereniguez-Garcia
(if approved) G. Lopez-Millan Expires: July 30, 2015 G. Lopez-Millan
Intended status: Experimental University of Murcia University of Murcia
Expires: July 24, 2015 D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
A. DeKok A. DeKok
Network RADIUS Network RADIUS
January 20, 2015 January 26, 2015
Support of fragmentation of RADIUS packets Support of fragmentation of RADIUS packets
draft-ietf-radext-radius-fragmentation-11 draft-ietf-radext-radius-fragmentation-12
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 July 24, 2015. This Internet-Draft will expire on July 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. Status of this document . . . . . . . . . . . . . . . . . . . 6 2. Status of this document . . . . . . . . . . . . . . . . . . . 6
3. Scope of this document . . . . . . . . . . . . . . . . . . . . 7 3. Scope of this document . . . . . . . . . . . . . . . . . . . . 7
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 12 5. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 12
5.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 12 5.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 13
5.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 17 5.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 17
6. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Allowed large packet size . . . . . . . . . . . . . . . . . . 21 7. Allowed large packet size . . . . . . . . . . . . . . . . . . 21
8. Handling special attributes . . . . . . . . . . . . . . . . . 22 8. Handling special attributes . . . . . . . . . . . . . . . . . 22
8.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 22 8.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 22
8.2. State attribute . . . . . . . . . . . . . . . . . . . . . 23 8.2. State attribute . . . . . . . . . . . . . . . . . . . . . 23
8.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 24 8.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 24
8.4. Rebuilding the original large packet . . . . . . . . . . . 24 8.4. Rebuilding the original large packet . . . . . . . . . . . 24
9. New flag T field for the Long Extended Type attribute 9. New flag T field for the Long Extended Type attribute
definition . . . . . . . . . . . . . . . . . . . . . . . . . . 24 definition . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. New attribute definition . . . . . . . . . . . . . . . . . . . 25 10. New attribute definition . . . . . . . . . . . . . . . . . . . 25
10.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 25 10.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 25
10.2. Proxy-State-Length attribute . . . . . . . . . . . . . . . 26 10.2. Proxy-State-Length attribute . . . . . . . . . . . . . . . 26
10.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27 10.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27
11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27 11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27
11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 28
11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28 11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28
12. General considerations . . . . . . . . . . . . . . . . . . . . 29 12. General considerations . . . . . . . . . . . . . . . . . . . . 30
12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 30 12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 31
12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 30 12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 31
12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 30 12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 31
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 32
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
16.2. Informative References . . . . . . . . . . . . . . . . . . 33 16.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The RADIUS [RFC2865] protocol carries authentication, authorization, The RADIUS [RFC2865] protocol carries authentication, authorization,
and accounting information between a RADIUS Client and an RADIUS and accounting information between a RADIUS Client and an RADIUS
Server. Information is exchanged between them through RADIUS Server. Information is exchanged between them through RADIUS
packets. Each RADIUS packet is composed of a header, and zero or packets. Each RADIUS packet is composed of a header, and zero or
more attributes, up to a maximum packet size of 4096 octets. The more attributes, up to a maximum packet size of 4096 octets. The
protocol is a request/response protocol, as described in the protocol is a request/response protocol, as described in the
operational model ([RFC6158], Section 3.1). operational model ([RFC6158], Section 3.1).
skipping to change at page 7, line 13 skipping to change at page 7, line 13
although some proxies might drop packets that does not have the although some proxies might drop packets that does not have the
"Reserved" field set to 0. More details on this aspect can be found "Reserved" field set to 0. More details on this aspect can be found
in Section 12.1. in Section 12.1.
The other Standards Track document that requires a minor update is The other Standards Track document that requires a minor update is
[RFC6158]. It states that "attribute designers SHOULD NOT assume [RFC6158]. It states that "attribute designers SHOULD NOT assume
that a RADIUS implementation can successfully process RADIUS packets that a RADIUS implementation can successfully process RADIUS packets
larger than 4096 octets", something no longer true if this document larger than 4096 octets", something no longer true if this document
advances. advances.
A proper "Updates" clause will be included for these modifications
when/if the experiment is successful and this document is re-issued
as a Standards Track document.
3. Scope of this document 3. 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
can exchange data exceeding the 4096 octet limit imposed by one can exchange data exceeding the 4096 octet limit imposed by one
packet. However, the mechanism described in this specification packet. However, the mechanism described in this specification
SHOULD NOT be used to exchange more than 100 kilo-octets of data. SHOULD NOT be used to exchange more than 100 kilo-octets of data.
Any more than this may turn RADIUS into a generic transport protocol, Any more than this may turn RADIUS into a generic transport protocol,
such as TCP or SCTP, which is undesired. Experience shows that such as TCP or SCTP, which is undesired. Experience shows that
attempts to transport bulk data across the Internet with UDP will attempts to transport bulk data across the Internet with UDP will
inevitably fail, unless they re-implement all of the behavior of TCP. inevitably fail, unless they re-implement all of the behavior of TCP.
skipping to change at page 11, line 24 skipping to change at page 11, line 28
signals the fragmentation status. signals the fragmentation status.
After the first chunk is encoded, it is sent to the other party. The After the first chunk is encoded, it is sent to the other party. The
packet is identified as a chunk via the Frag-Status attribute. The packet is identified as a chunk via the Frag-Status attribute. The
other party then requests additional chunks, again using the Frag- other party then requests additional chunks, again using the Frag-
Status attribute. This process is repeated until all the attributes Status attribute. This process is repeated until all the attributes
have been sent from one party to the other. When all the chunks have have been sent from one party to the other. When all the chunks have
been received, the original list of attributes is reconstructed and been received, the original list of attributes is reconstructed and
processed as if it had been received in one packet. processed as if it had been received in one packet.
The reconstruction process is performed by simply appending all of
the chunks together. Unlike IPv4 fragmentation, there is no
"fragment offset" field. The chunks in this specification are
explicitly ordered, as RADIUS is a lock-step protocol, as noted in
Section Section 12.4. That is, chunk N+1 cannot be sent until all of
the chunks up to and including N have been received and acknowledged.
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 [RFC6929]. The fragmentation Extended Type attributes as defined in [RFC6929]. The fragmentation
process may split a fragmented attribute across two or more chunks, process may split a fragmented attribute across two or more chunks,
which is not permitted by that specification. We address this issue which is not permitted by that specification. We address this issue
by using the newly defined flag "T" in the Reserved field of the by using the newly defined flag "T" in the Reserved field of the
"Long Extended Type" attribute format (see Section 9 for further "Long Extended Type" attribute format (see Section 9 for further
details on this flag). details on this flag).
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
skipping to change at page 27, line 20 skipping to change at page 27, line 20
7 7
Extended-Type Extended-Type
TBD2 TBD2
Value Value
4 octets. Total length (in octets) of received Proxy-State 4 octets. Total length (in octets) of received Proxy-State
attributes (including headers). attributes (including headers). As the RADIUS "length" field
cannot take values over 4096 octets, values of Proxy-State-Length
MUST be less than that maximum length.
This attribute MAY be present in Access-Challenge and Access-Accept This attribute MAY be present in Access-Challenge and Access-Accept
packets. It MUST NOT be included in Access-Request or Access-Reject packets. It MUST NOT be included in Access-Request or Access-Reject
packets. packets.
10.3. Table of attributes 10.3. Table of attributes
The following table shows the different attributes defined in this The following table shows the different attributes defined in this
document related with the kind of RADIUS packets where they can be document related with the kind of RADIUS packets where they can be
present. present.
skipping to change at page 30, line 7 skipping to change at page 31, line 7
parts of the "Reserved" field have already been defined. parts of the "Reserved" field have already been defined.
An immediate and reasonable solution for this issue would be An immediate and reasonable solution for this issue would be
declaring that this RFC updates [RFC6929]. In this way, [RFC6929] declaring that this RFC updates [RFC6929]. In this way, [RFC6929]
would include an "Updated by" clause that will point readers to this would include an "Updated by" clause that will point readers to this
document. Another alternative would be creating an IANA registry for document. Another alternative would be creating an IANA registry for
the "Reserved" field. However, the working group thinks that would the "Reserved" field. However, the working group thinks that would
be overkill, as not such a great number of specifications extending be overkill, as not such a great number of specifications extending
that field are expected. that field are expected.
Hence, we have decided to include the "Updates" clause in the In the end, the proposed solution is that this experimental RFC
document so far. Note that if this experiment does not succeed, the should not update RFC 6929. Instead, we rely on the collective mind
"T" flag allocation would not persist, as it is tightly associated to of the WG to recall that this T flag is used. When/if the experiment
this document. will be successful, the T flag will be properly assigned.
12.2. Violation of RFC2865 12.2. Violation of RFC2865
Section 5.1 indicates that all authorization and authentication Section 5.1 indicates that all authorization and authentication
handling will be postponed until all the chunks have been received. handling will be postponed until all the chunks have been received.
This postponement also affects to the verification that the Access- This postponement also affects to the verification that the Access-
Request packet contains some kind of authentication attribute (e.g. Request packet contains some kind of authentication attribute (e.g.
User-Password, CHAP-Password, State or other future attribute), as User-Password, CHAP-Password, State or other future attribute), as
required by [RFC2865]. This checking will therefore be delayed until required by [RFC2865]. This checking will therefore be delayed until
the original large packet has been rebuilt, as some of the chunks may the original large packet has been rebuilt, as some of the chunks may
skipping to change at page 31, line 5 skipping to change at page 32, line 5
attribute. attribute.
12.4. Transport behaviour 12.4. Transport behaviour
This proposal does not modify the way RADIUS interacts with the This proposal does not modify the way RADIUS interacts with the
underlying transport (UDP). That is, RADIUS keeps following a lock- underlying transport (UDP). That is, RADIUS keeps following a lock-
step behaviour, that requires receiving an explicit acknowledge for step behaviour, that requires receiving an explicit acknowledge for
each chunk sent. Hence, bursts of traffic which could congest links each chunk sent. Hence, bursts of traffic which could congest links
between peers are not an issue. between peers are not an issue.
Another benefit of the lock-step nature of RADIUS, is that there are
no security issues with overlapping fragments. Each chunk simply has
a length, with no "fragment offset" field as with IPv4. The order of
the fragments is determined by the order in which they are received.
There is no ambiguity about the size or placement of each chunk, and
therefore no security issues associated with overlapping chunks.
13. Security Considerations 13. Security Considerations
As noted in many earlier specifications ([RFC5080], [RFC6158], etc.) As noted in many earlier specifications ([RFC5080], [RFC6158], etc.)
RADIUS security is problematic. This specification changes nothing RADIUS security is problematic. This specification changes nothing
related to the security of the RADIUS protocol. It requires that all related to the security of the RADIUS protocol. It requires that all
Access-Request packets associated with fragmentation are Access-Request packets associated with fragmentation are
authenticated using the existing Message-Authenticator attribute. authenticated using the existing Message-Authenticator attribute.
This signature prevents forging and replay, to the limits of the This signature prevents forging and replay, to the limits of the
existing security. existing security.
 End of changes. 13 change blocks. 
26 lines changed or deleted 46 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/