draft-ietf-radext-radius-fragmentation-03.txt   draft-ietf-radext-radius-fragmentation-04.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: August 17, 2014 University of Murcia Expires: September 2, 2014 University of Murcia
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
A. DeKok A. DeKok
Network RADIUS Network RADIUS
February 13, 2014 March 2014
Support of fragmentation of RADIUS packets Support of fragmentation of RADIUS packets
draft-ietf-radext-radius-fragmentation-03 draft-ietf-radext-radius-fragmentation-04
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 August 17, 2014. This Internet-Draft will expire on September 2, 2014.
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 2, line 31 skipping to change at page 2, line 31
4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8 4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8
4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 9 4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 9
4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 13 4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 13
5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Allowed large packet size . . . . . . . . . . . . . . . . . . 17 6. Allowed large packet size . . . . . . . . . . . . . . . . . . 17
7. Handling special attributes . . . . . . . . . . . . . . . . . 18 7. Handling special attributes . . . . . . . . . . . . . . . . . 18
7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 18 7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 18
7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 19 7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 19
7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 20 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 20
7.4. Rebuilding the original large packet . . . . . . . . . . . 20 7.4. Rebuilding the original large packet . . . . . . . . . . . 20
8. New RFC6929 Reserved flag definition . . . . . . . . . . . . . 20 8. New flag T field for the Long Extended Type attribute
definition . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. New attribute definition . . . . . . . . . . . . . . . . . . . 21 9. New attribute definition . . . . . . . . . . . . . . . . . . . 21
9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 21 9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 21
9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 22 9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 22
9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 23 9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 23
10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23 10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23
10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23
10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 24 10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
skipping to change at page 10, line 24 skipping to change at page 10, line 24
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
Figure 2: Access-Request (chunk 1) Figure 2: Access-Request (chunk 1)
Compliant servers (i.e. servers implementing fragmentation) receiving Compliant servers (i.e. servers implementing fragmentation) receiving
this packet will see the Frag-Status attribute, and suspend all this packet will see the Frag-Status attribute, and postpone all
authorization and authentication handling until all of the chunks authorization and authentication handling until all of the chunks
have been received. Non-compliant servers (i.e. servers not have been received. This postponement also affects to the
implementing fragmentation) should also see the Service-Type verification that the Access-Request packet contains some kind of
requesting provisioning for an unknown service, and return Access- authentication attribute (e.g. User-Password, CHAP-Password, State
Reject. Other non-compliant servers may return an Access-Reject, or other future attribute), as required by [RFC2865]. This checking
Access-Challenge, or an Access-Accept with a particular Service-Type will therefore be delayed until the original large packet has been
other then Additional-Authorization. Compliant NAS implementations rebuilt, as some of the chunks may not contain any of them.
MUST treat these responses as if they had received Access-Reject
instead. Non-compliant servers (i.e. servers not implementing fragmentation)
should also see the Service-Type requesting provisioning for an
unknown service, and return Access-Reject. Other non-compliant
servers may return an Access-Reject, Access-Challenge, or an Access-
Accept with a particular Service-Type other then Additional-
Authorization. Compliant NAS implementations MUST treat these
responses as if they had received Access-Reject instead.
Compliant servers who wish to receive all of the chunks will respond Compliant servers who wish to receive all of the chunks will respond
with the following packet. The value of the State here is arbitrary, with the following packet. The value of the State here is arbitrary,
and serves only as a unique token for example purposes. We only note and serves only as a unique token for example purposes. We only note
that it MUST be temporally unique to the server. that it MUST be temporally unique to the server.
Access-Accept (ID = 23) Access-Accept (ID = 23)
Frag-Status = More-Data-Request Frag-Status = More-Data-Request
Service-Type = Additional-Authorization Service-Type = Additional-Authorization
State = 0xabc00001 State = 0xabc00001
skipping to change at page 20, line 44 skipping to change at page 20, line 44
o State (except the one in the first chunk, if present) o State (except the one in the first chunk, if present)
o Service-Type = Additional-Authorization o Service-Type = Additional-Authorization
o Frag-Status o Frag-Status
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 RFC6929 Reserved flag definition 8. New flag T field for the Long Extended Type attribute definition
This document defines a new field in the Reserved field of the "Long This document defines a new field in the "Long Extended Type"
Extended Type" attribute format. This field is one bit in size, and attribute format. This field is one bit in size, and is called "T"
is called "T" for Truncation. It indicates that the attribute is for Truncation. It indicates that the attribute is intentionally
intentionally truncated in this chunk, and is to be continued in the truncated in this chunk, and is to be continued in the next chunk of
next chunk of the sequence. The combination of the flags "M" and "T" the sequence. The combination of the flags "M" and "T" indicates
indicates that the attribute is fragmented (flag M), but that all the that the attribute is fragmented (flag M), but that all the fragments
fragments are not available in this chunk (flag T). Proxies are not available in this chunk (flag T). Proxies implementing
implementing [RFC6929] will see these attributes as invalid (they [RFC6929] will see these attributes as invalid (they will not be able
will not be able to reconstruct them), but they will still forward to reconstruct them), but they will still forward them as [RFC6929]
them as [RFC6929] section 5.2 indicates they SHOULD forward unknown section 5.2 indicates they SHOULD forward unknown attributes anyway.
attributes anyway.
As a consequence of this addition, the Reserved field is now 6 bits
long. The following figure represents the new attribute format.
0 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 |M|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Updated Long Extended Type attribute format
9. New attribute definition 9. 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 [RFC6929]. attribute defined in [RFC6929].
9.1. Frag-Status attribute 9.1. Frag-Status attribute
skipping to change at page 21, line 31 skipping to change at page 21, line 43
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Code | Type | Length | Extended-Type | Code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code (cont) | Code (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Frag-Status format Figure 13: Frag-Status format
Type Type
To be assigned (TBA) To be assigned (TBA)
Length Length
7 7
Extended-Type Extended-Type
To be assigned (TBA). To be assigned (TBA).
Code Code
4 byte. Integer indicating the code. The values defined in this 4 byte. Integer indicating the code. The values defined in this
specifications are: specifications are:
skipping to change at page 22, line 36 skipping to change at page 22, line 46
following: following:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value | Type | Length | Extended-Type | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) | Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Proxy-State-Len format Figure 14: Proxy-State-Len format
Type Type
To be assigned (TBA) To be assigned (TBA)
Length Length
7 7
Extended-Type Extended-Type
skipping to change at page 23, line 26 skipping to change at page 23, line 37
| Kind of packet | | Kind of packet |
+-----+-----+-----+-----+ +-----+-----+-----+-----+
Attribute Name | Req | Acc | Rej | Cha | Attribute Name | Req | Acc | Rej | Cha |
----------------------+-----+-----+-----+-----+ ----------------------+-----+-----+-----+-----+
Frag-Status | 0-1 | 0-1 | 0 | 0-1 | Frag-Status | 0-1 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+ ----------------------+-----+-----+-----+-----+
Proxy-State-Len | 0 | 0-1 | 0 | 0-1 | Proxy-State-Len | 0 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+ ----------------------+-----+-----+-----+-----+
Figure 14 Figure 15
10. Operation with proxies 10. Operation with proxies
The fragmentation mechanism defined above is designed to be The fragmentation mechanism defined above is designed to be
transparent to legacy proxies, as long as they do not want to modify transparent to legacy proxies, as long as they do not want to modify
any fragmented attribute. Nevertheless, updated proxies supporting any fragmented attribute. Nevertheless, updated proxies supporting
this specification can even modify fragmented attributes. this specification can even modify fragmented attributes.
10.1. Legacy proxies 10.1. Legacy proxies
skipping to change at page 24, line 41 skipping to change at page 24, line 50
|<---------------------------------------------------| |<---------------------------------------------------|
| | | |
| Access-Request(2)(User-Name,State1, | | Access-Request(2)(User-Name,State1, |
| 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[M],Example-Long-1} |
|--------------------------------------------------->| |--------------------------------------------------->|
PROXY MODIFIES ATTRIBUTE Data INCREASING ITS PROXY MODIFIES ATTRIBUTE Data INCREASING ITS
SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS
Figure 15: Updated proxy interacts with NAS Figure 16: Updated proxy interacts with NAS
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| Proxy | | AS | | Proxy | | AS |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | |
| Access-Request(3){User-Name,Calling-Station-Id, | | Access-Request(3){User-Name,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],Frag-Status(MDP)} | | Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->| |--------------------------------------------------->|
skipping to change at page 25, line 32 skipping to change at page 25, line 32
| Example-Long-1[MT],Frag-Status(MDP)} | | Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->| |--------------------------------------------------->|
| | | |
| Access-Challenge(1){User-Name, | | Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State3} | | Frag-Status(MDR),State3} |
|<---------------------------------------------------| |<---------------------------------------------------|
| | | |
| Access-Request(5){User-Name,State3,Example-Long-1} | | Access-Request(5){User-Name,State3,Example-Long-1} |
|--------------------------------------------------->| |--------------------------------------------------->|
Figure 16: Updated proxy interacts with AS Figure 17: Updated proxy interacts with AS
11. Security Considerations 11. 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. 15 change blocks. 
32 lines changed or deleted 50 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/