draft-ietf-radext-radius-fragmentation-02.txt   draft-ietf-radext-radius-fragmentation-03.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 Updates: RFC6929 (if approved) F. Pereniguez-Garcia
Expires: May 24, 2014 G. Lopez-Millan Intended status: Experimental G. Lopez-Millan
University of Murcia Expires: August 17, 2014 University of Murcia
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
A. DeKok A. DeKok
Network RADIUS Network RADIUS
November 20, 2013 February 13, 2014
Support of fragmentation of RADIUS packets Support of fragmentation of RADIUS packets
draft-ietf-radext-radius-fragmentation-02 draft-ietf-radext-radius-fragmentation-03
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 May 24, 2014. This Internet-Draft will expire on August 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 19 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 20
7.4. Rebuilding the original large packet . . . . . . . . . . . 20 7.4. Rebuilding the original large packet . . . . . . . . . . . 20
8. New attribute definition . . . . . . . . . . . . . . . . . . . 20 8. New RFC6929 Reserved flag definition . . . . . . . . . . . . . 20
8.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 20 9. New attribute definition . . . . . . . . . . . . . . . . . . . 21
8.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 21 9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 21
8.3. Table of attributes . . . . . . . . . . . . . . . . . . . 22 9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 22
9. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23 9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 23
9.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23 10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23
9.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 23 10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 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
skipping to change at page 4, line 25 skipping to change at page 4, line 25
proposed solution does not impose any additional requirements to the proposed solution does not impose any additional requirements to the
RADIUS system administrators (e.g. need to modify firewall rules, set RADIUS system administrators (e.g. need to modify firewall rules, set
up web servers, configure routers, or modify any application server). up web servers, configure routers, or modify any application server).
It maintains compatibility with intra-packet fragmentation mechanisms It maintains compatibility with intra-packet fragmentation mechanisms
(like those defined in [RFC3579] or in [RFC6929]). It is also (like those defined in [RFC3579] or in [RFC6929]). It is also
transparent to existing RADIUS proxies, which do not implement this transparent to existing RADIUS proxies, which do not implement this
specification. The only systems needing to implement the draft are specification. The only systems needing to implement the draft are
the ones which either generate, or consume the fragmented data being the ones which either generate, or consume the fragmented data being
transmitted. Intermediate proxies just pass the packets without transmitted. Intermediate proxies just pass the packets without
changes. Nevertheless, if a proxy supports this specification, it changes. Nevertheless, if a proxy supports this specification, it
MAY re-assemble the data in order to either examine and/or modify it. may re-assemble the data in order to either examine and/or modify it.
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].
When these words appear in lower case, they have their natural
language meaning.
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 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 MUST packet. However, the mechanism described in this specification MUST
NOT be used to exchange more than 100K of data. It has not been NOT be used to exchange more than 100K of data. It has not been
designed to substitute for stream-oriented transport protocols, such designed to substitute for stream-oriented transport protocols, such
as TCP or SCTP. Experience shows that attempts to transport bulk as TCP or SCTP. Experience shows that attempts to transport bulk
data across the Internet with UDP will inevitably fail, unless they data across the Internet with UDP will inevitably fail, unless they
skipping to change at page 6, line 47 skipping to change at page 6, line 50
are applied. The change of service SHOULD be done atomically. If are applied. The change of service SHOULD be done atomically. If
the CoA server is unable to apply the new authorization, it MUST the CoA server is unable to apply the new authorization, it MUST
terminate the user session. 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
be enforced. In this specification we refer to the "pre- be enforced. In this specification we refer to the "pre-
authorization" as the exchange of authorization information before authorization" as the exchange of authorization information before
the end user authentication has started, while the term "post- the end user authentication has started, while the term "post-
authorization" is used to refer to an authorization exchange authorization" is used to refer to an authorization exchange
happening after this authentication process. happening after this authentication process.
In this specification we refer to the "size limit" as the practical In this specification we refer to the "size limit" as the practical
limit on RADIUS packet sizes. This limit is the minimum of 4096 limit on RADIUS packet sizes. This limit is the minimum of 4096
octets, and the current PMTU. We define below a method which uses octets, and the current PMTU. We define below a method which uses
Access-Request and Access-Accept in order to exchange fragmented Access-Request and Access-Accept in order to exchange fragmented
data. The NAS and server exchange a series of Access-Request / data. The NAS and server exchange a series of Access-Request /
Access-Accept packets, until such time as all of the fragmented data Access-Accept packets, until such time as all of the fragmented data
has been transported. Each packet contains a Frag-Status attribute has been transported. Each packet contains a Frag-Status attribute
which lets the other party know if fragmentation is desired, ongoing, which lets the other party know if fragmentation is desired, ongoing,
or finished. Each packet may also contain the fragmented data, or or finished. Each packet may also contain the fragmented data, or
instead be an "ACK" to a previous fragment from the other party. instead be an "ACK" to a previous fragment from the other party.
Each Access-Request contains a User-Name attribute, allowing the Each Access-Request contains a User-Name attribute, allowing the
packet to be proxied if necessary (see Section 9.1). Each Access- packet to be proxied if necessary (see Section 10.1). Each Access-
Request may also contain a State attribute, which serves to tie it to Request may also contain a State attribute, which serves to tie it to
a previous Access-Accept. Each Access-Accept contains a State a previous Access-Accept. Each Access-Accept contains a State
attribute, for use by the NAS in a later Access-Request. Each attribute, for use by the NAS in a later Access-Request. Each
Access-Accept contains a Service-Type indicating that the service Access-Accept contains a Service-Type indicating that the service
being provided is fragmentation, and that the Access-Accept should being provided is fragmentation, and that the Access-Accept should
not be interpreted as providing network access to the end user. not be interpreted as providing network access to the end user.
When a RADIUS client or server need to send data that exceeds the When a RADIUS client or server need to send data that exceeds the
size limit, the mechanism proposed in this document is used. Instead size limit, the mechanism proposed in this document is used. Instead
of encoding one large RADIUS packet, a series of smaller RADIUS of encoding one large RADIUS packet, a series of smaller RADIUS
packets of the same type are encoded. Each smaller packet is called packets of the same type are encoded. Each smaller packet is called
a "chunk" in this specification, in order to distinguish it from a "chunk" in this specification, in order to distinguish it from
traditional RADIUS packets. The encoding process is a simple linear traditional RADIUS packets. The encoding process is a simple linear
walk over the attributes to be encoded. This walk preserves the walk over the attributes to be encoded. This walk preserves the
order of the attributes, as required by [RFC2865]. The number of order of the attributes of the same type, as required by [RFC2865].
attributes encoded in a particular chunk depends on the size limit, The number of attributes encoded in a particular chunk depends on the
the size of each attribute, the number of proxies between client and size limit, the size of each attribute, the number of proxies between
server, and the overhead for fragmentation signalling attributes. client and server, and the overhead for fragmentation signalling
Specific details are given in Section 5. A a new attribute called attributes. Specific details are given in Section 5. A a new
Frag-Status (Section 8.1) signals the fragmentation status. attribute called Frag-Status (Section 9.1) 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.
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 defining a new field in the Reserved field of the "Long Extended by using the newly defined flag "T" in the Reserved field of the
Type" attribute format. This field is one bit in size, and is called "Long Extended Type" attribute format (see Section 8 for further
"T" for Truncation. It indicates that the attribute is intentionally details on this flag).
truncated in this chunk, and is to be continued in the next chunk of
the sequence. The combination of the flags "M" and "T" indicates
that the attribute is fragmented (flag M), but that all the fragments
are not available in this chunk (flag T). Proxies implementing
[RFC6929] will see these attributes as invalid (they will not be able
to reconstruct them), but they will still forward them as [RFC6929]
section 5.2 indicates they SHOULD forward unknown attributes anyway.
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
of a desire to send one or more large (and therefore fragmented) of a desire to send one or more large (and therefore fragmented)
attributes. The large attribute will likely be split into two or attributes. The large attribute will likely be split into two or
more pieces. Where chunking does not split a fragmented attribute, more pieces. Where chunking does not split a fragmented attribute,
no special treatment is necessary. no special treatment is necessary.
The setting of the "T" flag is the only case where the chunking The setting of the "T" flag is the only case where the chunking
process affects the content of an attribute. Even then, the "Value" process affects the content of an attribute. Even then, the "Value"
skipping to change at page 10, line 27 skipping to change at page 10, line 23
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] 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 receiving this packet will see the Frag-Status Compliant servers (i.e. servers implementing fragmentation) receiving
attribute, wand suspend all authorization and authentication handling this packet will see the Frag-Status attribute, and suspend all
until all of the chunks have been received. Non-compliant servers authorization and authentication handling until all of the chunks
should also see the Service-Type requesting provisioning for an have been received. Non-compliant servers (i.e. servers not
unknown service, and return Access-Reject. Other non-compliant implementing fragmentation) should also see the Service-Type
servers may return an Access-Reject, Access-Challenge, or an Access- requesting provisioning for an unknown service, and return Access-
Accept with a particular Service-Type. Compliant NAS implementations 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 MUST treat these responses as if they had received Access-Reject
instead. 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 globally and temporally unique. 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
Message-Authenticator Message-Authenticator
Figure 3: Access-Accept (chunk 1) Figure 3: Access-Accept (chunk 1)
The NAS will see this response, and use the RADIUS Identifier field The NAS will see this response, and use the RADIUS Identifier field
skipping to change at page 11, line 14 skipping to change at page 11, line 12
will then continue the chunking process. Non-compliant NASes will will then continue the chunking process. Non-compliant NASes will
never see a response such as this, as they will never send a Frag- never see a response such as this, as they will never send a Frag-
Status attribute. The Service-Type attribute is included in the Status attribute. The Service-Type attribute is included in the
Access-Accept in order to signal that the response is part of the Access-Accept in order to signal that the response is part of the
chunking process. This packet therefore does not provision any chunking process. This packet therefore does not provision any
network service for the end user. network service for the end user.
The NAS continues the process by sending the next chunk, which The NAS continues the process by sending the next chunk, which
includes an additional six (6) attributes from the original packet. includes an additional six (6) attributes from the original packet.
It again includes the User-Name attribute, so that non-compliant It again includes the User-Name attribute, so that non-compliant
proxies can process the packet (see Section 9.1). It sets the Frag- proxies can process the packet (see Section 10.1). It sets the Frag-
Status attribute to More-Data-Pending, as more data is pending. It Status attribute to More-Data-Pending, as more data is pending. It
includes a Service-Type for reasons described above. It includes the includes a Service-Type for reasons described above. It includes the
State attribute from the previous Access-accept. It signs the packet State attribute from the previous Access-accept. It signs the packet
with Message-Authenticator, as there are no authentication attributes with Message-Authenticator, as there are no authentication attributes
in the packet. It uses a new RADIUS Identifier field. in the packet. It uses a new RADIUS Identifier field.
Access-Request (ID = 181) Access-Request (ID = 181)
User-Name User-Name
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 Example-Long-1
Example-Long-2 [M] Example-Long-2 [M]
Example-Long-2 [MT] Example-Long-2 [MT]
Frag-Status = More-Data-Request Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization Service-Type = Additional-Authorization
State = 0xabc000001 State = 0xabc000001
Message-Authenticator Message-Authenticator
Figure 4: Access-Request (chunk 2) Figure 4: Access-Request (chunk 2)
Compliant servers receiving this packet will see the Frag-Status Compliant servers receiving this packet will see the Frag-Status
attribute, and look for a State attribute. Since one exists and it attribute, and look for a State attribute. Since one exists and it
matches a State sent in an Access-Accept, this packet is part of a matches a State sent in an Access-Accept, this packet is part of a
chunking process. The server will associate the attributes with the chunking process. The server will associate the attributes with the
skipping to change at page 13, line 24 skipping to change at page 13, line 22
When the AS wants to send a large amount of authorization data to the When the AS wants to send a large amount of authorization data to the
NAS after authentication, the operation is very similar to the pre- NAS after authentication, the operation is very similar to the pre-
authorization one. The presence of Service-Type = Additional- authorization one. The presence of Service-Type = Additional-
Authorization attribute ensures that a NAS not supporting this Authorization attribute ensures that a NAS not supporting this
specification will treat that unrecognized Service-Type as though an specification will treat that unrecognized Service-Type as though an
Access-Reject had been received instead ([RFC2865] Section 5.6). If Access-Reject had been received instead ([RFC2865] Section 5.6). If
the original large Access-Accept packet contained a Service-Type the original large Access-Accept packet contained a Service-Type
attribute, it will be included with its original value in the last attribute, it will be included with its original value in the last
transmitted chunk, to avoid confusion with the one used for transmitted chunk, to avoid confusion with the one used for
fragmentation signalling. fragmentation signalling. It is strongly RECOMMENDED that servers
include a State attribute on their original Access-Accept packets,
even if fragmentation is not taking place, to allow the client to
send additional authorization data in subsequent exchanges. This
State attribute would be included in the last transmitted chunk, to
avoid confusion with the ones used for fragmentation signalling.
Client supporting this specification MUST include a Frag-Status = Client supporting this specification MUST include a Frag-Status =
Fragmentation-Supported attribute in the first Access-Request sent to Fragmentation-Supported attribute in the first Access-Request sent to
the server, in order to indicate they would accept fragmented data the server, in order to indicate they would accept fragmented data
from the sever. This is not required if pre-authorization process from the sever. This is not required if pre-authorization process
was carried out, as it is implicit. was carried out, as it is implicit.
The following is an Access-Accept which the AS intends to send to a The following is an Access-Accept which the AS intends to send to a
client. However, due to a combination of issues (PMTU, large client. However, due to a combination of issues (PMTU, large
attributes, etc.), the content does not fit into one Access-Accept attributes, etc.), the content does not fit into one Access-Accept
skipping to change at page 14, line 21 skipping to change at page 14, line 21
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 [M] Example-Long-1 [M]
Example-Long-1 [M] Example-Long-1 [M]
Example-Long-1 Example-Long-1
Example-Long-2 [M] Example-Long-2 [M]
Example-Long-2 [M] Example-Long-2 [M]
Example-Long-2 Example-Long-2
State = 0xcba00003
Figure 8: Desired Access-Accept Figure 8: Desired Access-Accept
The AS therefore must send the attributes listed above in a series of The AS therefore must send the attributes listed above in a series of
chunks. The first chunk contains eight (7) attributes from the chunks. The first chunk contains seven (7) attributes from the
original Access-Accept, and a Frag-Status attribute. Since last original Access-Accept, and a Frag-Status attribute. Since last
attribute is "Example-Long-1" with the "M" flag set, the chunking attribute is "Example-Long-1" with the "M" flag set, the chunking
process also sets the "T" flag in that attribute. The Access-Accept process also sets the "T" flag in that attribute. The Access-Accept
is sent with a RADIUS Identifier field having value 30 corresponding is sent with a RADIUS Identifier field having value 30 corresponding
to a previous Access-Request not depicted. The Frag-Status attribute to a previous Access-Request not depicted. The Frag-Status attribute
has value More-Data-Pending, to indicate that the AS wishes to send has value More-Data-Pending, to indicate that the AS wishes to send
more data in a subsequent Access-Accept. The AS also adds a Service- more data in a subsequent Access-Accept. The AS also adds a Service-
Type attribute with value Additional-Authorization, which indicates Type attribute with value Additional-Authorization, which indicates
that it is part of the chunking process. Note that the original that it is part of the chunking process. Note that the original
Service-Type is not included in this chunk. Finally, a State Service-Type is not included in this chunk. Finally, a State
skipping to change at page 15, line 16 skipping to change at page 15, line 30
Compliant clients receiving this packet will see the Frag-Status Compliant clients receiving this packet will see the Frag-Status
attribute, wand suspend all authorization and authentication handling attribute, wand suspend all authorization and authentication handling
until all of the chunks have been received. Non-compliant clients until all of the chunks have been received. Non-compliant clients
should also see the Service-Type indicating the provisioning for an should also see the Service-Type indicating the provisioning for an
unknown service, and will treat it as an Access-Reject. unknown service, and will treat it as an Access-Reject.
Clients who wish to receive all of the chunks will respond with the Clients who wish to receive all of the chunks will respond with the
following packet, where the value of the State attribute is taken following packet, where the value of the State attribute is taken
from the received Access-Accept. They also include the User-Name from the received Access-Accept. They also include the User-Name
attribute so that non-compliant proxies can process the packet attribute so that non-compliant proxies can process the packet
(Section 9.1). (Section 10.1).
Access-Request (ID = 131) Access-Request (ID = 131)
User-Name User-Name
Frag-Status = More-Data-Request Frag-Status = More-Data-Request
Service-Type = Additional-Authorization Service-Type = Additional-Authorization
State = 0xcba00004 State = 0xcba00004
Message-Authenticator Message-Authenticator
Figure 10: Access-Request (chunk 1) Figure 10: Access-Request (chunk 1)
The AS receives this request, and uses the State attribute to The AS receives this request, and uses the State attribute to
associate it with an ongoing chunking session. Compliant ASes will associate it with an ongoing chunking session. Compliant ASes will
then continue the chunking process. Non-compliant ASes will never then continue the chunking process. Non-compliant ASes will never
see a response such as this, as they will never send a Frag-Status see a response such as this, as they will never send a Frag-Status
attribute. attribute.
The AS continues the chunking process by sending the next chunk, with The AS continues the chunking process by sending the next chunk, with
the final attribute(s) from the original packet. The value of the the final attribute(s) from the original packet. The value of the
Identifier field is taken from the received Access-Request. A Frag- Identifier field is taken from the received Access-Request. A Frag-
Status attribute is not included in the next Access-Accept, as no Status attribute is not included in the next Access-Accept, as no
more chunks are available for sending. The AS includes an State more chunks are available for sending. The AS includes the original
attribute to allow the client to send additional authorization data. State attribute to allow the client to send additional authorization
The original Service-Type attribute is included in this final chunk. data. The original Service-Type attribute is included as well.
Access-Accept (ID = 131) Access-Accept (ID = 131)
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 Example-Long-1
Example-Long-2 [M] Example-Long-2 [M]
Example-Long-2 [M] Example-Long-2 [M]
Example-Long-2 Example-Long-2
Service-Type = Login Service-Type = Login
State = 0xfda000005 State = 0xfda000003
Message-Authenticator Message-Authenticator
Figure 11: Access-Accept (chunk 2) Figure 11: Access-Accept (chunk 2)
On reception of this last chunk, the client matches it with an On reception of this last chunk, the client matches it with an
ongoing session via the Identifier field, and sees that there is no ongoing session via the Identifier field, and sees that there is no
Frag-Status attribute present. It then processes the received Frag-Status attribute present. It then processes the received
attributes as if they had been sent in one RADIUS packet. See attributes as if they had been sent in one RADIUS packet. See
Section 7.4 for further details of this process. Section 7.4 for further details of this process.
skipping to change at page 18, line 37 skipping to change at page 18, line 39
Proxy-State attributes require a special treatment within the packet Proxy-State attributes require a special treatment within the packet
fragmentation mechanism. 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
into the reply packet. This means that the server MUST take into into the reply packet. This means that the server MUST take into
account the size of these Proxy-State attributes in order to account the size of these Proxy-State attributes in order to
calculate the size of the next chunk to be sent. calculate the size of the next chunk to be sent.
However, while a RADIUS server will always know how many space MUST However, while a RADIUS server will always know how much space MUST
be left on each reply packet for Proxy-State attributes (as they are be left on each reply packet for Proxy-State attributes (as they are
directly included by the RADIUS server), a RADIUS client cannot know directly included by the RADIUS server), a RADIUS client cannot know
this information, as Proxy-State attributes are removed from the this information, as Proxy-State attributes are removed from the
reply packet by their respective proxies before forwarding them back. reply packet by their respective proxies before forwarding them back.
Hence, clients need a mechanism to discover the amount of space Hence, clients need a mechanism to discover the amount of space
required by proxies to introduce their Proxy-State attributes. In required by proxies to introduce their Proxy-State attributes. In
the following we describe a new mechanism to perform such a the following we describe a new mechanism to perform such a
discovery: discovery:
1. When a RADIUS client does not know how many 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 client, it can 2. When the RADIUS server receives a chunk from the client, it can
calculate the total size of the Proxy-State attributes that have calculate the total size of the Proxy-State attributes that have
been introduced by intermediary proxies along the path. This been introduced by intermediary proxies along the path. This
information MUST be returned to the client in the next reply information MUST be returned to the client in the next reply
packet, encoded into a new attribute called Proxy-State-Len. The packet, encoded into a new attribute called Proxy-State-Len. The
server MAY artificially increase this quantity in order to handle server MAY artificially increase this quantity in order to handle
skipping to change at page 20, line 31 skipping to change at page 20, line 36
o Frag-Status o Frag-Status
o Proxy-State-Len o Proxy-State-Len
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 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 attribute definition 8. New RFC6929 Reserved flag definition
This document defines a new field in the Reserved field of the "Long
Extended Type" attribute format. This field is one bit in size, and
is called "T" for Truncation. It indicates that the attribute is
intentionally truncated in this chunk, and is to be continued in the
next chunk of the sequence. The combination of the flags "M" and "T"
indicates that the attribute is fragmented (flag M), but that all the
fragments are not available in this chunk (flag T). Proxies
implementing [RFC6929] will see these attributes as invalid (they
will not be able to reconstruct them), but they will still forward
them as [RFC6929] section 5.2 indicates they SHOULD forward unknown
attributes anyway.
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].
8.1. Frag-Status attribute 9.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 41 skipping to change at page 22, line 14
0 - Reserved 0 - Reserved
1 - Fragmentation-Supported 1 - Fragmentation-Supported
2 - More-Data-Pending 2 - More-Data-Pending
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. packets. Clients supporting this specification MUST include a Frag-
Status = Fragmentation-Supported attribute in the first Access-
Request sent to the server, in order to indicate they would accept
fragmented data from the sever.
8.2. Proxy-State-Len attribute 9.2. Proxy-State-Len 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-Len attribute is the
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 28 skipping to change at page 23, line 4
Length Length
7 7
Extended-Type Extended-Type
To be assigned (TBA). To be assigned (TBA).
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.
8.3. Table of attributes 9.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.
| 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 14
9. 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.
9.1. Legacy proxies 10.1. Legacy proxies
As every chunk is indeed a RADIUS packet, legacy proxies treat them As every chunk is indeed a RADIUS packet, legacy proxies treat them
as the rest of packets, routing them to their destination. Proxies as the rest of packets, routing them to their destination. Proxies
can introduce Proxy-State attributes to Access-Request packets, even can introduce Proxy-State attributes to Access-Request packets, even
if they are indeed chunks. This will not affect how fragmentation is if they are indeed chunks. This will not affect how fragmentation is
managed. The server will include all the received Proxy-State managed. The server will include all the received Proxy-State
attributes into the generated response, as described in [RFC2865]. attributes into the generated response, as described in [RFC2865].
Hence, proxies do not distinguish between a regular RADIUS packet and Hence, proxies do not distinguish between a regular RADIUS packet and
a chunk. a chunk.
This proposal assumes legacy proxies to base their routing decisions This proposal assumes legacy proxies to base their routing decisions
on the value of the User-Name attribute. For this reason, every on the value of the User-Name attribute. For this reason, every
packet sent from the client to the server (either chunks or requests packet sent from the client to the server (either chunks or requests
for more chunks) MUST contain a User-Name attribute. for more chunks) MUST contain a User-Name attribute.
9.2. Updated proxies 10.2. Updated proxies
Updated proxies can interact with clients and servers in order to Updated proxies can interact with clients and servers in order to
obtain the complete large packet before start forwarding it. In this obtain the complete large packet before starting forwarding it. In
way, proxies can manipulate (modify and/or remove) any attribute of this way, proxies can manipulate (modify and/or remove) any attribute
the packet, or introduce new attributes, without worrying about of the packet, or introduce new attributes, without worrying about
crossing the boundaries of the chunk size. Once the manipulated crossing the boundaries of the chunk size. Once the manipulated
packet is ready, it is sent to the original destination using the packet is ready, it is sent to the original destination using the
fragmentation mechanism (if required). The following example shows fragmentation mechanism (if required). The following example shows
how an updated proxy interacts with the NAS to obtain a large Access- how an updated proxy interacts with the NAS to obtain a large Access-
Request packet, modify an attribute resulting into a even more large Request packet, modify an attribute resulting into a even more large
packet, and interacts with the AS to complete the transmission of the packet, and interacts with the AS to complete the transmission of the
modified packet. modified packet.
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| NAS | | Proxy | | NAS | | Proxy |
skipping to change at page 25, line 34 skipping to change at page 25, line 34
| | | |
| 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 16: Updated proxy interacts with AS
10. 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 signed using Access-Request packets associated with fragmentation are
the existing Message-Authenticator attribute. This signature authenticated using the existing Message-Authenticator attribute.
prevents forging and replay, to the limits of the existing security. This signature prevents forging and replay, to the limits of the
existing security.
The ability to send bulk data from one party to another creates new The ability to send bulk data from one party to another creates new
security considerations. Clients and servers may have to store large security considerations. Clients and servers may have to store large
amounts of data per session. The amount of this data can be amounts of data per session. The amount of this data can be
significant, leading to the potential for resource exhaustion. We significant, leading to the potential for resource exhaustion. We
therefore suggest that implementations limit the amount of bulk data therefore suggest that implementations limit the amount of bulk data
stored per session. The exact method for this limitation is stored per session. The exact method for this limitation is
implementation-specific. Section 6 gives some indications on what implementation-specific. Section 6 gives some indications on what
could be a reasonable limits. could be reasonable limits.
The bulk data can often be pushed off to storage methods other than The bulk data can often be pushed off to storage methods other than
the memory of the RADIUS implementation. For example, it can be the memory of the RADIUS implementation. For example, it can be
stored in an external database, or in files. This approach mitigates stored in an external database, or in files. This approach mitigates
the resource exhaustion issue, as servers today already store large the resource exhaustion issue, as servers today already store large
amounts of accounting data. amounts of accounting data.
11. IANA Considerations 12. IANA Considerations
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.
This document defines the following RADIUS messages: This document defines the following RADIUS messages:
o Frag-Status o Frag-Status
o Proxy-State-Len o Proxy-State-Len
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.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, Authentication Dial In User Service)", RFC 3575,
July 2003. July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, March 2011. BCP 158, RFC 6158, March 2011.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929, Service (RADIUS) Protocol Extensions", RFC 6929,
April 2013. April 2013.
12.2. Informative References 13.2. Informative References
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter
Rule Attribute", RFC 4849, April 2007. Rule Attribute", RFC 4849, April 2007.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007.
Authors' Addresses Authors' Addresses
Alejandro Perez-Mendez (Ed.) Alejandro Perez-Mendez (Ed.)
University of Murcia University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science Campus de Espinardo S/N, Faculty of Computer Science
Murcia, 30100 Murcia, 30100
Spain Spain
Phone: +34 868 88 46 44 Phone: +34 868 88 46 44
Email: alex@um.es Email: alex@um.es
 End of changes. 47 change blocks. 
91 lines changed or deleted 115 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/