draft-ietf-radext-bigger-packets-03.txt   draft-ietf-radext-bigger-packets-04.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft Painless Security Internet-Draft Painless Security
Updates: 6613, 6614 (if approved) March 6, 2015 Updates: 6613, 6614 (if approved) October 19, 2015
Intended status: Experimental Intended status: Experimental
Expires: September 7, 2015 Expires: April 21, 2016
Larger Packets for RADIUS over TCP Larger Packets for RADIUS over TCP
draft-ietf-radext-bigger-packets-03.txt draft-ietf-radext-bigger-packets-04.txt
Abstract Abstract
The RADIUS over TLS experiment described in RFC 6614 has opened The RADIUS over TLS experiment described in RFC 6614 has opened
RADIUS to new use cases where the 4096-octet maximum RADIUS packet RADIUS to new use cases where the 4096-octet maximum size limit of
proves problematic. This specification extends the RADIUS over TCP RADIUS packet proves problematic. This specification extends the
experiment (RFC 6113) to permit larger RADIUS packets. This RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS
specification compliments other ongoing work to permit fragmentation packets. This specification compliments other ongoing work to permit
of RADIUS authorization information. This document registers a new fragmentation of RADIUS authorization information. This document
RADIUS code, an action which requires IESG approval. registers a new RADIUS code, an action which requires IESG approval.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 7, 2015. This Internet-Draft will expire on April 21, 2016.
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 24 skipping to change at page 2, line 24
3. Forward and backward Compatibility . . . . . . . . . . . . . 4 3. Forward and backward Compatibility . . . . . . . . . . . . . 4
3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol-Error Code . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol-Error Code . . . . . . . . . . . . . . . . . . . . . 6
5. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 7 5. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. References . . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Remote Access Dial-In User Server (RADIUS) over TLS [RFC6614] The Remote Authentication DialIn User Service (RADIUS) over TLS
experiment provides strong confidentiality and integrity for RADIUS [RFC6614] experiment provides strong confidentiality and integrity
[RFC2865]. This enhanced security has opened new opportunities for for RADIUS [RFC2865]. This enhanced security has opened new
using RADIUS to convey additional authorization information. As an opportunities for using RADIUS to convey additional authorization
example, [I-D.ietf-abfab-aaa-saml] describes a mechanism for using information. As an example, [I-D.ietf-abfab-aaa-saml] describes a
RADIUS to carry Security Assertion Markup Language (SAML) messages in mechanism for using RADIUS to carry Security Assertion Markup
RADIUS. Many attributes carried in these SAML messages will require Language (SAML) messages in RADIUS. Many attributes carried in these
confidentiality or integrity such as that provided by TLS. SAML messages will require confidentiality or integrity such as that
provided by TLS.
These new use cases involve carrying additional information in RADIUS These new use cases involve carrying additional information in RADIUS
packets. The maximum packet length of 4096 octets is proving packets. The maximum packet length of 4096 octets is proving
insufficient for some SAML messages and for other structures that may insufficient for some SAML messages and for other structures that may
be carried in RADIUS. be carried in RADIUS.
One approach is to fragment a RADIUS message across multiple packets One approach is to fragment a RADIUS message across multiple packets
at the RADIUS layer. RADIUS Fragmentation at the RADIUS layer. RADIUS Fragmentation [RFC7499] provides a
[I-D.ietf-radext-radius-fragmentation] provides a mechanism to split mechanism to split authorization information across multiple RADIUS
authorization information across multiple RADIUS messages. That messages. That mechanism is necessary in order to split
mechanism is necessary in order to split authorization information authorization information across existing unmodified proxies.
across existing unmodified proxies.
However, there are some significant disadvantages to RADIUS However, there are some significant disadvantages to RADIUS
fragmentation. First, RADIUS is a lock-step protocol, and only one 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. 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 Also, there is no current mechanism to discover the path Maximum
Transmission Unit (MTU) across the entire path that the fragment will Transmission Unit (MTU) across the entire path that the fragment will
travel. As a result, fragmentation is likely both at the RADIUS travel. As a result, fragmentation is likely both at the RADIUS
layer and at the transport layer. When TCP is used, much better layer and at the transport layer. When TCP is used, much better
transport characteristics can be achieved by fragmentation only at transport characteristics can be achieved by fragmentation only at
the TCP layer. This specification provides a mechanism to achieve the TCP layer. This specification provides a mechanism to achieve
skipping to change at page 5, line 16 skipping to change at page 5, line 16
responses SHOULD implement capability discovery as discussed in responses SHOULD implement capability discovery as discussed in
Section 3.2. Section 3.2.
By default, a server SHOULD not generate a response larger than 4096 By default, a server SHOULD not generate a response larger than 4096
octets. The Response-Length attribute MAY be included in a request octets. The Response-Length attribute MAY be included in a request
to indicate that larger responses are acceptable. Other attributes to indicate that larger responses are acceptable. Other attributes
or configuration MAY be used as an indicator that large responses are or configuration MAY be used as an indicator that large responses are
likely to be acceptable. likely to be acceptable.
A proxy that implements both this specification and RADIUS A proxy that implements both this specification and RADIUS
Fragmentation [I-D.ietf-radext-radius-fragmentation] SHOULD use Fragmentation [RFC7499] SHOULD use RADIUS fragmentation when the
RADIUS fragmentation when the following conditions are met: following conditions are met:
1. A packet is being forwarded towards an endpoint whose 1. A packet is being forwarded towards an next hop whose
configuration does not support a packet that large. configuration does not support a packet that large.
2. RADIUS Fragmentation can be used for the packet in question. 2. RADIUS Fragmentation can be used for the packet in question.
3.1. Rationale 3.1. Rationale
The interoperability challenge appears at first significant. This The interoperability challenge appears at first significant. This
specification proposes to introduce behavior where new specification proposes to introduce behavior where new
implementations will fail to function with existing implementations. implementations will fail to function with existing implementations.
skipping to change at page 5, line 48 skipping to change at page 5, line 48
The biggest risk to interoperability would be if requests and The biggest risk to interoperability would be if requests and
responses are expanded to include additional information that is not responses are expanded to include additional information that is not
strictly necessary. So, avoiding creating situations where large strictly necessary. So, avoiding creating situations where large
packets are sent to existing implementations is mostly an operational packets are sent to existing implementations is mostly an operational
matter. Interoperability is most impacted when the size of packets matter. Interoperability is most impacted when the size of packets
in existing use cases is significantly increased and least impacted in existing use cases is significantly increased and least impacted
when large packets are used for new use cases where the deployment is when large packets are used for new use cases where the deployment is
likely to require updated RADIUS implementations. likely to require updated RADIUS implementations.
There is a special challenge for proxies or clients with high request There is a special challenge for proxies or clients with high request
volume. When an RFC 6113 implementation receives a packet that is volume. When an RFC 6613 implementation receives a packet that is
too large, it closes the connection and does not respond to any too large, it closes the connection and does not respond to any
requests in process. Such a client would lose requests and might requests in process. Such a client would lose requests and might
find distinguishing request-too-big situations from other failures find distinguishing request-too-big situations from other failures
difficult. In these cases, the discovery mechanism described in difficult. In these cases, the discovery mechanism described in
Section 3.2 can be used. Section 3.2 can be used.
Also, RFC 6613 is an experiment. Part of running that experiment is Also, RFC 6613 is an experiment. Part of running that experiment is
to evaluate whether additional changes are required to RADIUS. A to evaluate whether additional changes are required to RADIUS. A
lower bar for interoperability should apply to changes to lower bar for interoperability should apply to changes to
experimental protocols than standard protocols. experimental protocols than standard protocols.
skipping to change at page 6, line 48 skipping to change at page 6, line 48
from the request that generated the protocol error so that clients from the request that generated the protocol error so that clients
can disambiguate requests with different codes and the same ID. can disambiguate requests with different codes and the same ID.
Regardless of the original packet code, the RADIUS server calculates Regardless of the original packet code, the RADIUS server calculates
the Message-Authenticator attribute as if the original packet were an the Message-Authenticator attribute as if the original packet were an
Access-Request packet. The identifier is copied from the original Access-Request packet. The identifier is copied from the original
request. request.
Clients processing Protocol-Error MUST ignore unknown or unexpected Clients processing Protocol-Error MUST ignore unknown or unexpected
attributes. attributes.
This RADIUS code is hop-by-hop. Proxies MUST not forward a Protocol- This RADIUS code is hop-by-hop. Proxies MUST NOT forward a Protocol-
Error packet they receive. Error packet they receive.
5. Too Big Response 5. Too Big Response
When a RADIUS server receives a request that is larger than can be When a RADIUS server receives a request that is larger than can be
processed, it generates a Protocol-Error response as follows: processed, it generates a Protocol-Error response as follows:
The code is Protocol-Error. The code is Protocol-Error.
The Response-Length attribute MUST be included and its value is The Response-Length attribute MUST be included and its value is
skipping to change at page 8, line 4 skipping to change at page 8, line 4
| Original-Packet-Code | TBD2 | An integer attribute | | Original-Packet-Code | TBD2 | An integer attribute |
| | | containing the code from a | | | | containing the code from a |
| | | packet resulting in a | | | | packet resulting in a |
| | | Protocol-Error response. | | | | Protocol-Error response. |
+----------------------+-----------+--------------------------------+ +----------------------+-----------+--------------------------------+
The Response-Length attribute MAY be included in any RADIUS request. The Response-Length attribute MAY be included in any RADIUS request.
In this context it indicates the maximum length of a response the In this context it indicates the maximum length of a response the
client is prepared to receive. Values are between 4096 and 65535. client is prepared to receive. Values are between 4096 and 65535.
The attribute MAY also be included in a response to a Status-Server The attribute MAY also be included in a response to a Status-Server
message. In this case the attribute indicate the maximum size RADIUS message. In this case the attribute indicates the maximum size
request that is permitted. RADIUS request that is permitted.
A new Error-Cause value is registered in the registry at A new Error-Cause value is registered in the registry at
http://www.iana.org/assignments/radius-types/radius- http://www.iana.org/assignments/radius-types/radius-
types.xhtml#radius-types-18 for "Response Too Big" with value types.xhtml#radius-types-18 for "Response Too Big" with value
TOOBIGTBD. TOOBIGTBD.
7. Security Considerations 7. Security Considerations
This specification updates RFC 6613 and will be used with [RFC6614]. This specification updates RFC 6613 and will be used with [RFC6614].
When used over plain TCP, this specification creates new When used over plain TCP, this specification creates new
skipping to change at page 9, line 13 skipping to change at page 9, line 13
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS", "Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, May 2012. RFC 6614, May 2012.
[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, April Service (RADIUS) Protocol Extensions", RFC 6929, April
2013. 2013.
9.2. References 9.2. Informative References
[I-D.ietf-abfab-aaa-saml] [I-D.ietf-abfab-aaa-saml]
Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding,
Profiles, Name Identifier Format, and Confirmation Methods Profiles, Name Identifier Format, and Confirmation Methods
for SAML", draft-ietf-abfab-aaa-saml-09 (work in for SAML", draft-ietf-abfab-aaa-saml-09 (work in
progress), February 2014. progress), February 2014.
[I-D.ietf-radext-radius-fragmentation] [RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia,
Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez- F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of
Millan, G., Lopez, D., and A. DeKok, "Support of Fragmentation of RADIUS Packets", RFC 7499, DOI 10.17487/
fragmentation of RADIUS packets", draft-ietf-radext- RFC7499, April 2015,
radius-fragmentation-06 (work in progress), April 2014. <http://www.rfc-editor.org/info/rfc7499>.
Author's Address Author's Address
Sam Hartman Sam Hartman
Painless Security Painless Security
Email: hartmans-ietf@mit.edu Email: hartmans-ietf@mit.edu
 End of changes. 15 change blocks. 
37 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/