Internet DRAFT - draft-hartman-radext-bigger-packets
draft-hartman-radext-bigger-packets
Network Working Group S. Hartman
Internet-Draft Painless Security
Updates: 6613, 6614 (if approved) February 13, 2014
Intended status: Experimental
Expires: August 17, 2014
Larger Packets for RADIUS over TCP
draft-hartman-radext-bigger-packets-01.txt
Abstract
The RADIUS over TLS experiment described in RFC 6614 has opened
RADIUS to new use cases where the 4096-octet maximum RADIUS packet
proves problematic. This specification extends the RADIUS over TCP
experiment to permit larger RADIUS packets. This specification
compliments other ongoing work to permit fragmentation of RADIUS
authorization information.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 17, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Hartman Expires August 17, 2014 [Page 1]
Internet-Draft RADIUS Large Packets February 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Changes to Packet Processing . . . . . . . . . . . . . . . . . 4
2.1. Status-Server Considerations . . . . . . . . . . . . . . . 4
3. Forward and backward Compatibility . . . . . . . . . . . . . . 5
3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Too Big Response . . . . . . . . . . . . . . . . . . . . . . . 8
5. Response Length Attribute . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. References . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Hartman Expires August 17, 2014 [Page 2]
Internet-Draft RADIUS Large Packets February 2014
1. Introduction
The Remote Access Dial-In User Server (RADIUS) over TLS [RFC6614]
experiment provides strong confidentiality and integrity for RADIUS
[RFC2865]. This enhanced security has opened new opportunities for
using RADIUS to convey additional authorization information. As an
example, [I-D.ietf-abfab-aaa-saml] describes a mechanism for using
RADIUS to carry Security Assertion Markup Language (SAML) messages in
RADIUS. Many attributes carried in these SAML messages will require
confidentiality or integrity such as that provided by TLS.
These new use cases involve carrying additional information in RADIUS
packets. The maximum packet length of 4096 octets is proving
insufficient for some SAML messages and for other structures that may
be carried in RADIUS.
One approach is to fragment a RADIUS message across multiple packets
at the RADIUS layer.RADIUS Fragmentation
[I-D.ietf-radext-radius-fragmentation] provides a mechanism to split
authorization information across multiple RADIUS messages. That
mechanism is necessary in order to split authorization information
across existing unmodified proxies.
However, there are some significant disadvantages to RADIUS
fragmentation. First, RADIUS is a lock-step protocol, and only one
fragment can be in transit at a time as part of a given request.
Also, there is no current mechanism to discover the path Maximum
Transmission Unit (MTU) across the entire path that the fragment will
travel. As a result, fragmentation is likely both at the RADIUS
layer and at the transport layer. When TCP is used, much better
transport characteristics can be achieved by fragmentation only at
the TCP layer.
1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Hartman Expires August 17, 2014 [Page 3]
Internet-Draft RADIUS Large Packets February 2014
2. Changes to Packet Processing
The maximum length of a RADIUS message is increased from 4096 to
65535. A RADIUS Server implementing this specification MUST be able
to receive a packet of maximum length. Servers MAY have a maximum
size over which they choose to return an error as discussed in
Section 4 rather than processing a received packet; this size MUST be
at least 4096 octets.
Clients implementing this specification MUST be able to receive a
packet of maximum length; that is clients MUST NOT close a TCP
connection simply because a large packet is sent over it. Clients
MAY include the Response-Length attribute defined in Section 5 to
indicate the maximum size of a packet that they can successfully
process. Clients MAY silently discard a packet greater than some
configured size; this size MUST be at least 4096 octets. Clients
MUST NOT retransmit an unmodified request whose response is larger
than the client can process as subsequent responses will likely
continue to be too large.
Proxies SHOULD be able to process and forward packets of maximum
length. Proxies MUST include the Response-Length attribute when
forwarding a request received over a transport with a 4096-octet
maximum length over a transport with a higher maximum length.
2.1. Status-Server Considerations
This section extends processing of Status-Server messages as
described in section 4.1 and 4.2 of [RFC5997].
Clients implementing this specification SHOULD include the Response-
Length attribute in Status-Request messages. Servers are already
required to ignore unknown attributes received in this message. by
including the attribute, the client indicates how large of a response
it can process to its Status-Server request. It is very unlikely
that a response to Status-Server is greater than 4096 octets.
However the client also indicates support for this specification
which triggers server behavior below.
If a server implementing this specification receives a Response-
Length attribute in a Status-Server request, it MUST include a
Response-Length attribute indicating the maximum size request it can
process in its response to the Status-Server request.
Hartman Expires August 17, 2014 [Page 4]
Internet-Draft RADIUS Large Packets February 2014
3. Forward and backward Compatibility
An implementation of [RFC6613] will silently discard any packet
larger than 4096 octets and will close the TCP connection. This
section provides guidelines for interoperability with these
implementations. These guidelines are stated at the SHOULD level.
In some environments support for large packets will be important
enough that roaming or other agreements will mandate their support.
In these environments, all implementations might be required to
support this specification removing the need for interoperability
with RFC 6613. It is likely that these guidelines will be relaxed to
the MAY level and support for this specification made a requirement
if RADIUS over TLS and TCP are moved to the standards track in the
future.
Clients SHOULD provide configuration for the maximum size of a
request sent to each server. Servers SHOULD provide configuration
for the maximum size of a response sent to each client. If dynamic
discovery mechanisms are supported, configuration SHOULD be provided
for the maximum size of clients and servers in each dynamic discovery
category.
If a client sends a request larger than 4096 octets and the TCP
connection is closed without a response, the client SHOULD treat the
request as if a request too big error (Section 4) specifying a
maximum size of 4096 is received. Clients or proxies sending
multiple requests over a single TCP connection without waiting for
responses SHOULD implement capability discovery as discussed in
Section 3.2.
By default, a server SHOULD not generate a response larger than 4096
octets. The Response-Length attribute MAY be included in a request
to indicate that larger responses are desirable. Other attributes or
configuration MAY be used as an indicator that large responses are
likely to be acceptable.
A proxy that implements both this specification and RADIUS
Fragmentation [I-D.ietf-radext-radius-fragmentation] SHOULD use
RADIUS fragmentation when the following conditions are met:
1. A packet is being forwarded towards an endpoint whose
configuration does not support a packet that large.
2. RADIUS Fragmentation can be used for the packet in question.
Hartman Expires August 17, 2014 [Page 5]
Internet-Draft RADIUS Large Packets February 2014
3.1. Rationale
The interoperability challenge appears at first significant. This
specification proposes to introduce behavior where new
implementations will fail to function with existing implementations.
However, these capabilities are introduced to support new use cases.
If an implementation has 10000 octets of attributes to send, it
cannot in general trim down the response to something that can be
sent. Under this specification a large packet would be generated
that will be silently discarded by an existing implementation.
Without this specification, no packet is generated because the
required attributes cannot be sent.
The biggest risk to interoperability would be if requests and
responses are expanded to include additional information that is not
strictly necessary. So, avoiding creating situations where large
packets are sent to existing implementations is mostly an operational
matter. Interoperability is most impacted when the size of packets
in existing use cases is significantly increased and least impacted
when large packets are used for new use cases where the deployment is
likely to require updated RADIUS implementations.
There is a special challenge for proxies or clients with high request
volume. When an RFc 6113 implementation receives a packet that is
too large, it closes the connection and does not respond to any
requests in process. Such a client would lose requests and might
find distinguishing request-too-big situations from other failures
difficult. In these cases, the discovery mechanism described in
Section 3.2 can be used.
Also, RFC 6613 is an experiment. Part of running that experiment is
to evaluate whether additional changes are required to RADIUS. A
lower bar for interoperability should apply to changes to
experimental protocols than standard protocols.
This specification provides good facilities to enable implementations
to understand packet size when proxying to/from standards-track UDP
RADIUS.
3.2. Discovery
As discussed in Section 2.1, a client MAY send a Status-Server
message to discover whether an authentication or accounting server
supports this specification. The client includes a Response-Length
attribute; this signals the server to include a Response-Length
attribute indicating the maximum packet size the server can process.
In this one instance, Response-Length indicate the size of a request
Hartman Expires August 17, 2014 [Page 6]
Internet-Draft RADIUS Large Packets February 2014
that can be processed rather than a response.
Hartman Expires August 17, 2014 [Page 7]
Internet-Draft RADIUS Large Packets February 2014
4. Too Big Response
Define a new RADIUS code indicating that a server has received a
request that is larger than can be processed. Include mandatory
attribute indicating the maximum size that is permitted.
Clients will not typically be able to adjust and resend requests when
this error is received. In some cases the client can fall back to
RADIUS Fragmentation. In other cases this code will provide for
better client error reporting and will avoid retransmitting requests
guaranteed to fail.
Hartman Expires August 17, 2014 [Page 8]
Internet-Draft RADIUS Large Packets February 2014
5. Response Length Attribute
The following RADIUS attribute type values [RFC3575] are assigned.
The assignment rules in section 10.3 of [RFC6929] are used.
+-----------------+-----------+-------------------------------------+
| Name | Attribute | Description |
+-----------------+-----------+-------------------------------------+
| Response-Length | TBD | 2-octet unsigned integer maximum |
| | | response length |
+-----------------+-----------+-------------------------------------+
The Response-Length attribute MAY be included in any RADIUS request.
In this context it indicates the maximum length of a response the
client is prepared to receive. Values are between 4096 and 65535.
The attribute MAY also be included in a response to a Status-Server
message. In this case the attribute indicate the maximum size RADIUS
request that is permitted.
Hartman Expires August 17, 2014 [Page 9]
Internet-Draft RADIUS Large Packets February 2014
6. IANA Considerations
Once this document is more complete it will define a new RADIUS code
and attribute. Figure out if we have IANA policy lossage defining a
code in an experimental document.
IANA is requested to assign the RADIUS type defined in section
Section 5
Hartman Expires August 17, 2014 [Page 10]
Internet-Draft RADIUS Large Packets February 2014
7. Security Considerations
This specification updates RFC 6613 and will be used with [RFC6614].
When used over plain TCP, this specification creates new
opportunities for an on-path attacker to impact availability. these
attacks can be entirely mitigated by using TLS.
Hartman Expires August 17, 2014 [Page 11]
Internet-Draft RADIUS Large Packets February 2014
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dial In User Service (RADIUS) Protocol",
RFC 5997, August 2010.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, May 2012.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
April 2013.
8.2. References
[I-D.ietf-abfab-aaa-saml]
Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding,
Profiles, Name Identifier Format, and Confirmation Methods
for SAML", draft-ietf-abfab-aaa-saml-08 (work in
progress), November 2013.
[I-D.ietf-radext-radius-fragmentation]
Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez-
Millan, G., Lopez, D., and A. DeKok, "Support of
fragmentation of RADIUS packets",
draft-ietf-radext-radius-fragmentation-02 (work in
progress), November 2013.
Hartman Expires August 17, 2014 [Page 12]
Internet-Draft RADIUS Large Packets February 2014
Author's Address
Sam Hartman
Painless Security
Email: hartmans-ietf@mit.edu
Hartman Expires August 17, 2014 [Page 13]
