draft-ietf-radext-radius-fragmentation-01.txt   draft-ietf-radext-radius-fragmentation-02.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: April 24, 2014 G. Lopez-Millan Expires: May 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
October 21, 2013 November 20, 2013
Support of fragmentation of RADIUS packets Support of fragmentation of RADIUS packets
draft-ietf-radext-radius-fragmentation-01 draft-ietf-radext-radius-fragmentation-02
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 April 24, 2014. This Internet-Draft will expire on May 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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8 4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8
4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 8 4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 9
4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 12 4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 13
5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Allowed large packet size . . . . . . . . . . . . . . . . . . 16 6. Allowed large packet size . . . . . . . . . . . . . . . . . . 17
7. Handling special attributes . . . . . . . . . . . . . . . . . 17 7. Handling special attributes . . . . . . . . . . . . . . . . . 18
7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 17 7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 18
7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 18 7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 19
7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 19 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 19
7.4. Rebuilding the original large packet . . . . . . . . . . . 19 7.4. Rebuilding the original large packet . . . . . . . . . . . 20
8. New attribute definition . . . . . . . . . . . . . . . . . . . 19 8. New attribute definition . . . . . . . . . . . . . . . . . . . 20
8.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 20 8.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 20
8.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 21 8.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 21
8.3. Table of attributes . . . . . . . . . . . . . . . . . . . 21 8.3. Table of attributes . . . . . . . . . . . . . . . . . . . 22
9. Operation with proxies . . . . . . . . . . . . . . . . . . . . 22 9. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23
9.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 22 9.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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 36 skipping to change at page 4, line 36
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
can exchange large amounts of data exceeding the 4096 octet limit. can exchange data exceeding the 4096 octet limit imposed by one
Specifically, its scope is limited to the exchange of authorization packet. However, the mechanism described in this specification MUST
data, as other exchanges do not require of such a mechanism. In NOT be used to exchange more than 100K of data. It has not been
designed to substitute for stream-oriented transport protocols, such
as TCP or SCTP. Experience shows that attempts to transport bulk
data across the Internet with UDP will inevitably fail, unless they
re-implement all of the behavior of TCP. The underlying design of
RADIUS lacks the proper retransmission policies or congestion control
mechanisms which would make it a competitor to TCP.
Therefore, RADIUS/UDP transport is by design unable to transport bulk
data. It is both undesired and impossible to change the protocol at
this point in time. This specification is intended to allow the
transport of slightly more than 4096 octets of data through existing
RADIUS/UDP proxies. Other solutions such as RADIUS/TCP MUST be used
when a "green field" deployment requires the transport of bulk data.
Section 6, below, describes with further details the reasoning for
this limitation, and recommends administrators to adjust it according
to the specific capabilities of their existing systems in terms of
memory and processing power.
Moreover, its scope is limited to the exchange of authorization data,
as other exchanges do not require of such a mechanism. In
particular, authentication exchanges have already been defined to particular, authentication exchanges have already been defined to
overcome this limitation (e.g. RADIUS-EAP). Moreover, as they overcome this limitation (e.g. RADIUS-EAP). Moreover, as they
represent the most critical part of a RADIUS conversation, its represent the most critical part of a RADIUS conversation, its
preferable to not introduce any modification to their operation that preferable to not introduce any modification to their operation that
may affect existing equipment. may affect existing equipment.
There is no need to fragment accounting packets either. While the There is no need to fragment accounting packets either. While the
accounting process can send large amounts of data, that data is accounting process can send large amounts of data, that data is
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 4K of data. demonstrated need to send indivisible blocks of more than 4K of data.
skipping to change at page 5, line 47 skipping to change at page 6, line 20
this specification. this specification.
The NAS will then perform fragmentation as per this draft to the The NAS will then perform fragmentation as per this draft to the
RADIUS server it is configured to use. That RADIUS server SHOULD RADIUS server it is configured to use. That RADIUS server SHOULD
then act as a proxy, and forward the Access-Request to the RADIUS 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 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 amounts of authorization to the proxy, which then sends them to the
NAS. NAS.
That is, the NAS sends packets to a server which proxies them to the 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 system which is co-located with the CoA client.This process is more
complicated than allowing for fragmented CoA packets. However, the complicated than allowing for fragmented CoA packets. However, the
CoA client and the RADIUS server must communicate even when not using CoA client and the RADIUS server must communicate even when not using
this specification. We believe that standardizing that this specification. We believe that standardizing that
communication, and using one method for exchange of large data is communication, and using one method for exchange of large data is
preferred to unspecified communication methods and multiple ways of preferred to unspecified communication methods and multiple ways of
achieving the same result. achieving the same result.
The above requirement solves a number of issues. It clearly
separates session identification from authorization. Without this
separation, it is difficult to both identify a session, and change
its authorization using the same attribute. It also ensures that the
authorization process is the same for initial authentication, and for
CoA.
When a sessions authorization is changed, the CoA server MUST
continue the existing service until the new authorization parameters
are applied. The change of service SHOULD be done atomically. If
the CoA server is unable to apply the new authorization, it MUST
terminate the user session.
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
user, the results of the authentication process and/or obligations to user, the results of the authentication process and/or obligations to
skipping to change at page 16, line 43 skipping to change at page 17, line 35
Unauthenticated clients are permitted to trigger the exchange of Unauthenticated clients are permitted to trigger the exchange of
large amounts of fragmented data between the NAS and the AS, having large amounts of fragmented data between the NAS and the AS, having
the potential to allow Denial of Service (DoS) attacks. An attacker the potential to allow Denial of Service (DoS) attacks. An attacker
could initiate a large number of connections, each of which requests could initiate a large number of connections, each of which requests
the server to store a large amount of data. This data could cause the server to store a large amount of data. This data could cause
memory exhaustion on the server, and result in authentic users being memory exhaustion on the server, and result in authentic users being
denied access. It is worth noting that authentication mechanisms are denied access. It is worth noting that authentication mechanisms are
already designed to avoid exceeding the size limit. already designed to avoid exceeding the size limit.
Hence, implementations of this specification MUST limit the total Hence, implementations of this specification MUST limit the total
amount of data they send and/or receive via this specification. It amount of data they send and/or receive via this specification to
is RECOMMENDED that the limits be set to a few tens of kilooctets. 100K. Any more than this may turn RADIUS into a generic transport
Any more than this may turn RADIUS into a generic transport protocol, protocol, which is undesired. It is RECOMMENDED that this limit be
which is undesired. It is RECOMMENDED that this limit be exposed to 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 to 25. 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 For instance, let's imagine the RADIUS server wants to transport an
SAML assertion which is 15000 octets long, to the RADIUS client. In SAML assertion which is 15000 octets long, to the RADIUS client. In
this hypothetical scenario, we assume there are 3 intermediate this hypothetical scenario, we assume there are 3 intermediate
proxies, each one inserting a Proxy-State attribute of 20 octets. proxies, each one inserting a Proxy-State attribute of 20 octets.
Also we assume the State attributes generated by the RADIUS server 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 have a size of 6 octets. Therefore, the amount of free space in a
 End of changes. 12 change blocks. 
34 lines changed or deleted 66 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/