draft-ietf-radext-radius-fragmentation-10.txt   draft-ietf-radext-radius-fragmentation-11.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 Updates: 2865, 6158, 6929 F. Pereniguez-Garcia
(if approved) G. Lopez-Millan (if approved) G. Lopez-Millan
Intended status: Experimental University of Murcia Intended status: Experimental University of Murcia
Expires: July 13, 2015 D. Lopez Expires: July 24, 2015 D. Lopez
Telefonica I+D Telefonica I+D
A. DeKok A. DeKok
Network RADIUS Network RADIUS
January 9, 2015 January 20, 2015
Support of fragmentation of RADIUS packets Support of fragmentation of RADIUS packets
draft-ietf-radext-radius-fragmentation-10 draft-ietf-radext-radius-fragmentation-11
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 13, 2015. This Internet-Draft will expire on July 24, 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 36 skipping to change at page 2, line 36
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-Len 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 . . . . . . . . . . . . . . . . . . . . . . 27
11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28 11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28
12. General considerations . . . . . . . . . . . . . . . . . . . . 29 12. General considerations . . . . . . . . . . . . . . . . . . . . 29
12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 30 12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 30
12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 30 12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 30
12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 30 12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 8, line 12 skipping to change at page 8, line 12
typically composed of many small updates. That is, there is no typically composed of many small updates. That is, there is no
demonstrated need to send indivisible blocks of more than 4 kilo- demonstrated need to send indivisible blocks of more than 4 kilo-
octets of data. The need to send large amounts of data per user octets of data. The need to send large amounts of data per user
session often originates from the need for flow-based accounting. In session often originates from the need for flow-based accounting. In
this use-case, the RADIUS Client may send accounting data for many this use-case, the RADIUS Client may send accounting data for many
thousands of flows, where all those flows are tied to one user thousands of flows, where all those flows are tied to one user
session. The existing Acct-Multi-Session-Id attribute defined in session. The existing Acct-Multi-Session-Id attribute defined in
[RFC2866] Section 5.11 has been proven to work here. [RFC2866] Section 5.11 has been proven to work here.
Similarly, there is no need to fragment Change of Authorization (CoA) Similarly, there is no need to fragment Change of Authorization (CoA)
[RFC5176] packets. Instead, the CoA client MUST send a CoA-Request [RFC5176] packets. Instead, according to [RFC5176] the CoA client
packet containing session identification attributes, along with will send a CoA-Request packet containing session identification
Service-Type = Additional-Authorization, and a State attribute. attributes, along with Service-Type = Additional-Authorization, and a
Implementations not supporting fragmentation will respond with a CoA- State attribute. Implementations not supporting fragmentation will
NAK, and an Error-Cause of Unsupported-Service. respond with a CoA-NAK, and an Error-Cause of Unsupported-Service.
The above requirement does not assume that the CoA client and the The above requirement does not assume that the CoA client and the
RADIUS Server are co-located. They may, in fact be run on separate RADIUS Server are co-located. They may, in fact be run on separate
parts of the infrastructure, or even by separate administrators. parts of the infrastructure, or even by separate administrators.
There is, however, a requirement that the two communicate. We can There is, however, a requirement that the two communicate. We can
see that the CoA client needs to send session identification see that the CoA client needs to send session identification
attributes in order to send CoA packets. These attributes cannot be 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 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, Server. Therefore, even when the two systems are not co-located,
they must be able to communicate in order to operate in unison. The they must be able to communicate in order to operate in unison. The
skipping to change at page 8, line 38 skipping to change at page 8, line 38
users authorization parameters, which is a security disaster. users authorization parameters, which is a security disaster.
This specification does not allow for fragmentation of CoA packets. This specification does not allow for fragmentation of CoA packets.
Allowing for fragmented CoA packets would involve changing multiple Allowing for fragmented CoA packets would involve changing multiple
parts of the RADIUS protocol, with the corresponding possibility for parts of the RADIUS protocol, with the corresponding possibility for
implementation issues, mistakes, etc. implementation issues, mistakes, etc.
Where CoA clients (i.e. RADIUS Servers) need to send large amounts Where CoA clients (i.e. RADIUS Servers) need to send large amounts
of authorization data to a CoA server (i.e. RADIUS Client), they of authorization data to a CoA server (i.e. RADIUS Client), they
need only send a minimal CoA-Request packet, containing Service-Type need only send a minimal CoA-Request packet, containing Service-Type
of Authorize-Only, as per RFC 5176, along with session identification of Authorize-Only, as per [RFC5176], along with session
attributes. This CoA packet serves as a signal to the RADIUS Client identification attributes. This CoA packet serves as a signal to the
that the users' session requires re-authorization. When the RADIUS RADIUS Client that the users' session requires re-authorization.
Client re-authorizes the user via Access-Request, the RADIUS Server When the RADIUS Client re-authorizes the user via Access-Request, the
can perform fragmentation, and send large amounts of authorization RADIUS Server can perform fragmentation, and send large amounts of
data to the RADIUS Client. authorization data to the RADIUS Client.
The assumption in the above scenario is that the CoA client and The assumption in the above scenario is that the CoA client and
RADIUS Server are co-located, or at least strongly coupled. That is, RADIUS Server are co-located, or at least strongly coupled. That is,
the path from CoA client to CoA server SHOULD be the exact reverse of the path from CoA client to CoA server SHOULD be the exact reverse of
the path from RADIUS Client to RADIUS Server. The following diagram the path from RADIUS Client to RADIUS Server. The following diagram
will hopefully clarify the roles: will hopefully clarify the roles:
+---------------------+ +----------------+
| RADIUS | | RADIUS CoA |
| Client CoA Server | | Client Server |
+---------------------+ +----------------+
| ^ | ^
Access-Request | | CoA-Request Access-Request | | CoA-Request
v | v |
+---------------------+ +----------------+
| RADIUS CoA client | | RADIUS CoA |
| Server | | Server Client |
+---------------------+ +----------------+
Where there is a proxy involved: Where there is a proxy involved:
+---------------------+ +----------------+
| RADIUS | | RADIUS CoA |
| Client CoA Server | | Client Server |
+---------------------+ +----------------+
| ^ | ^
Access-Request | | CoA-Request Access-Request | | CoA-Request
v | v |
+---------------------+ +----------------+
| RADIUS CoA | | RADIUS CoA |
| Proxy Proxy | | Proxy Proxy |
+---------------------+ +----------------+
| ^ | ^
Access-Request | | CoA-Request Access-Request | | CoA-Request
v | v |
+---------------------+ +----------------+
| RADIUS CoA client | | RADIUS CoA |
| Server | | Server Client |
+---------------------+ +----------------+
That is, the RADIUS and CoA subsystems at each hop are strongly That is, the RADIUS and CoA subsystems at each hop are strongly
connected. Where they are not strongly connected, it will be connected. Where they are not strongly connected, it will be
impossible to use CoA-Request packets to transport large amounts of impossible to use CoA-Request packets to transport large amounts of
authorization data. authorization data.
This design is more complicated than allowing for fragmented CoA This design is more complicated than allowing for fragmented CoA
packets. However, the CoA client and the RADIUS Server must packets. However, the CoA client and the RADIUS Server must
communicate even when not using this specification. We believe that communicate even when not using this specification. We believe that
standardizing that communication, and using one method for exchange standardizing that communication, and using one method for exchange
skipping to change at page 23, line 16 skipping to change at page 23, line 16
1. When a RADIUS Client does not know how much space will be 1. When a RADIUS Client does not know how much 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 RADIUS Client, 2. When the RADIUS Server receives a chunk from the RADIUS Client,
it can calculate the total size of the Proxy-State attributes it can calculate the total size of the Proxy-State attributes
that have been introduced by intermediary proxies along the path. that have been introduced by intermediary proxies along the path.
This information MUST be returned to the RADIUS Client in the This information MUST be returned to the RADIUS Client in the
next reply packet, encoded into a new attribute called Proxy- next reply packet, encoded into a new attribute called Proxy-
State-Len. The RADIUS Server MAY artificially increase this State-Length. The RADIUS Server MAY artificially increase this
quantity in order to handle with situations where proxies behave quantity in order to handle with situations where proxies behave
inconsistently (e.g. they generate Proxy-State attributes with a inconsistently (e.g. they generate Proxy-State attributes with a
different size for each packet), or for situations where different size for each packet), or for situations where
intermediary proxies remove Proxy-State attributes generated by intermediary proxies remove Proxy-State attributes generated by
other proxies. Increasing this value would make the RADIUS other proxies. Increasing this value would make the RADIUS
Client to leave some free space for these situations. Client to leave some free space for these situations.
3. The RADIUS Client SHOULD react upon the reception of this 3. The RADIUS Client SHOULD react upon the reception of this
attribute by adjusting the maximum size for the next chunk attribute by adjusting the maximum size for the next chunk
accordingly. However, as the Proxy-State-Len offers just an accordingly. However, as the Proxy-State-Length offers just an
estimation of the space required by the proxies, the RADIUS estimation of the space required by the proxies, the RADIUS
Client MAY select a smaller amount in environments known to be Client MAY select a smaller amount in environments known to be
problematic. problematic.
8.2. State attribute 8.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
skipping to change at page 24, line 32 skipping to change at page 24, line 32
MUST NOT be stored in this list, as they have been introduced as part MUST NOT be stored in this list, as they have been introduced as part
of the fragmentation signalling and hence, they are not part of the of the fragmentation signalling and hence, they are not part of the
original packet. original packet.
o State (except the one in the last chunk, if present) o State (except the one in the last chunk, if present)
o Service-Type = Additional-Authorization o Service-Type = Additional-Authorization
o Frag-Status o Frag-Status
o Proxy-State-Len o Proxy-State-Length
Similarly, the RADIUS Server MUST NOT store the following attributes Similarly, the RADIUS Server MUST NOT store the following attributes
as part of the original large packet: as part of the original large packet:
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
skipping to change at page 25, line 30 skipping to change at page 25, line 30
| Type | Length | Extended-Type |M|T| Reserved | | Type | Length | Extended-Type |M|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Updated Long Extended Type attribute format Figure 12: Updated Long Extended Type attribute format
10. New attribute definition 10. 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-Length. 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].
10.1. Frag-Status attribute 10.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Code | Type | Length | Extended-Type | Code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code (cont) | Code (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Frag-Status format Figure 13: Frag-Status format
Type Type
To be assigned (TBA) 241 (To be confirmed by IANA)
Length Length
7 7
Extended-Type Extended-Type
To be assigned (TBA). TBD1
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:
0 - Reserved 0 - Reserved
1 - Fragmentation-Supported 1 - Fragmentation-Supported
skipping to change at page 26, line 34 skipping to change at page 26, line 34
3 - More-Data-Request 3 - More-Data-Request
This attribute MAY be present in Access-Request, Access-Challenge and This attribute MAY be present in Access-Request, Access-Challenge and
Access-Accept packets. It MUST NOT be included in Access-Reject Access-Accept packets. It MUST NOT be included in Access-Reject
packets. RADIUS Clients supporting this specification MUST include a packets. RADIUS Clients supporting this specification MUST include a
Frag-Status = Fragmentation-Supported attribute in the first Access- Frag-Status = Fragmentation-Supported attribute in the first Access-
Request sent to the RADIUS Server, in order to indicate they would Request sent to the RADIUS Server, in order to indicate they would
accept fragmented data from the sever. accept fragmented data from the sever.
10.2. Proxy-State-Len attribute 10.2. Proxy-State-Length attribute
This attribute indicates to the RADIUS Client the length of the This attribute indicates to the RADIUS Client the length of the
Proxy-State attributes received by the RADIUS Server. This Proxy-State attributes received by the RADIUS Server. This
information is useful to adjust the length of the chunks sent by the information is useful to adjust the length of the chunks sent by the
RADIUS Client. The format of this Proxy-State-Len attribute is the RADIUS Client. The format of this Proxy-State-Length attribute is
following: the 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 14: Proxy-State-Len format Figure 14: Proxy-State-Length format
Type Type
To be assigned (TBA) 241 (To be confirmed by IANA)
Length Length
7 7
Extended-Type Extended-Type
To be assigned (TBA). 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).
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.
skipping to change at page 27, line 38 skipping to change at page 27, line 38
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.
| 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-Length | 0 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+ ----------------------+-----+-----+-----+-----+
11. Operation with proxies 11. 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.
11.1. Legacy proxies 11.1. Legacy proxies
skipping to change at page 31, line 41 skipping to change at page 31, line 41
The authors request that Attribute Types and Attribute Values defined The authors request that Attribute Types and Attribute Values defined
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-Length" (see Section 10),
assigned values of TBD1 and TBD2 from the Long Extended Space of with assigned values of 241.TBD1 and 241.TBD2 from the Short Extended
[RFC6929]: Space of [RFC6929]:
Tag Name Length Meaning Type Name Length Meaning
---- ---- ------ ------- ---- ---- ------ -------
TBD1 Frag-Status 7 Signals fragmentation 241.TBD1 Frag-Status 7 Signals fragmentation
TBD2 Proxy-State-Len 7 Indicates the length of the 241.TBD2 Proxy-State-Length 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
values for the RADIUS Frag-Status "Code" registry are given below; values for the RADIUS Frag-Status "Code" registry are given below;
future assignments are to be made through "RFC required" [RFC5226]. future assignments are to be made through "RFC required" [RFC5226].
Assignments consist of a Frag-Status "Code" name and its associated Assignments consist of a Frag-Status "Code" name and its associated
value. value.
Value Frag-Status Code Name Definition Value Frag-Status Code Name Definition
---- ------------------------ ---------- ---- ------------------------ ----------
0 Reserved See Section 9.1 0 Reserved See Section 10.1
1 Fragmentation-Supported See Section 9.1 1 Fragmentation-Supported See Section 10.1
2 More-Data-Pending See Section 9.1 2 More-Data-Pending See Section 10.1
3 More-Data-Request See Section 9.1 3 More-Data-Request See Section 10.1
4-255 Unassigned 4-255 Unassigned
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.
Value Service Type Value Definition Value Service Type Value Definition
---- ------------------------ ---------- ---- ------------------------ ----------
TBA Additional-Authorization See section 4.1 TBA Additional-Authorization See Section 5.1
15. Acknowledgements 15. Acknowledgements
The authors would like to thank the members of the RADEXT working The authors would like to thank the members of the RADEXT working
group who have contributed to the development of this specification, group who have contributed to the development of this specification,
either by participating on the discussions on the mailing lists or by either by participating on the discussions on the mailing lists or by
sending comments about our RFC. sending comments about our RFC.
The authors also thank David Cuenca (University of Murcia) for The authors also thank David Cuenca (University of Murcia) for
implementing a proof of concept implementation of this RFC that has implementing a proof of concept implementation of this RFC that has
 End of changes. 28 change blocks. 
65 lines changed or deleted 65 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/