draft-ietf-radext-bigger-packets-02.txt   draft-ietf-radext-bigger-packets-03.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft Painless Security Internet-Draft Painless Security
Updates: 6613, 6614 (if approved) February 12, 2015 Updates: 6613, 6614 (if approved) March 6, 2015
Intended status: Experimental Intended status: Experimental
Expires: August 16, 2015 Expires: September 7, 2015
Larger Packets for RADIUS over TCP Larger Packets for RADIUS over TCP
draft-ietf-radext-bigger-packets-02.txt draft-ietf-radext-bigger-packets-03.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 RADIUS packet
proves problematic. This specification extends the RADIUS over TCP proves problematic. This specification extends the RADIUS over TCP
experiment to permit larger RADIUS packets. This specification experiment (RFC 6113) to permit larger RADIUS packets. This
compliments other ongoing work to permit fragmentation of RADIUS specification compliments other ongoing work to permit fragmentation
authorization information. This document registers a new RADIUS of RADIUS authorization information. This document registers a new
code, an action which requires IESG approval. 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 August 16, 2015. This Internet-Draft will expire on September 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Changes to Packet Processing . . . . . . . . . . . . . . . . 3 2. Changes to Packet Processing . . . . . . . . . . . . . . . . 3
2.1. Status-Server Considerations . . . . . . . . . . . . . . 4 2.1. Status-Server Considerations . . . . . . . . . . . . . . 4
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 Type . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol-Error Code . . . . . . . . . . . . . . . . . . . . . 6
5. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 6 5. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 8 9.2. 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 Access Dial-In User Server (RADIUS) over TLS [RFC6614]
experiment provides strong confidentiality and integrity for RADIUS experiment provides strong confidentiality and integrity for RADIUS
[RFC2865]. This enhanced security has opened new opportunities for [RFC2865]. This enhanced security has opened new opportunities for
using RADIUS to convey additional authorization information. As an using RADIUS to convey additional authorization information. As an
example, [I-D.ietf-abfab-aaa-saml] describes a mechanism for using example, [I-D.ietf-abfab-aaa-saml] describes a mechanism for using
RADIUS to carry Security Assertion Markup Language (SAML) messages in RADIUS to carry Security Assertion Markup Language (SAML) messages in
RADIUS. Many attributes carried in these SAML messages will require RADIUS. Many attributes carried in these SAML messages will require
confidentiality or integrity such as that provided by TLS. 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
[I-D.ietf-radext-radius-fragmentation] provides a mechanism to split [I-D.ietf-radext-radius-fragmentation] provides a mechanism to split
authorization information across multiple RADIUS messages. That authorization information across multiple RADIUS messages. That
mechanism is necessary in order to split authorization information mechanism is necessary in order to split 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
these better transport characteristics when TCP is used. As part of these better transport characteristics when TCP is used. As part of
this specification, a new RADIUS code is registered. this specification, a new RADIUS code is registered.
This specification is published as an experimental specification This specification is published as an experimental specification
because the TCP extensions to RADIUS are currently experimental. The because the TCP extensions to RADIUS are currently experimental. The
need for this specification arrises from operational experience with need for this specification arises from operational experience with
the TCP extensions. However, this specification introduces no new the TCP extensions. However, this specification introduces no new
experimental evaluation criteria beyond those in the base TCP experimental evaluation criteria beyond those in the base TCP
specification; this specification can be evaluated along with that specification; this specification can be evaluated along with that
one for advancement on the standards track. one for advancement on the standards track.
1.1. Requirements notation 1.1. Requirements notation
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 3, line 48 skipping to change at page 3, line 48
packet of maximum length; that is clients MUST NOT close a TCP packet of maximum length; that is clients MUST NOT close a TCP
connection simply because a large packet is sent over it. Clients connection simply because a large packet is sent over it. Clients
MAY include the Response-Length attribute defined in Section 6 to MAY include the Response-Length attribute defined in Section 6 to
indicate the maximum size of a packet that they can successfully indicate the maximum size of a packet that they can successfully
process. Clients MAY silently discard a packet greater than some process. Clients MAY silently discard a packet greater than some
configured size; this size MUST be at least 4096 octets. Clients configured size; this size MUST be at least 4096 octets. Clients
MUST NOT retransmit an unmodified request whose response is larger MUST NOT retransmit an unmodified request whose response is larger
than the client can process as subsequent responses will likely than the client can process as subsequent responses will likely
continue to be too large. continue to be too large.
Proxies SHOULD be able to process and forward packets of maximum Proxies MUST be able to receive a packet of maximum length without
length. Proxies MUST include the Response-Length attribute when cloing the TCP connection. Proxies SHOULD be able to process and
forwarding a request received over a transport with a 4096-octet forward packets of maximum length. When a proxy receives a request
maximum length over a transport with a higher maximum length. over a transport with a 4096-octet maximum length and the proxy
forwards that request over a transport with a larger maximum length,
the proxy MUST include the Response-Length attribute with a value of
4096.
2.1. Status-Server Considerations 2.1. Status-Server Considerations
This section extends processing of Status-Server messages as This section extends processing of Status-Server messages as
described in section 4.1 and 4.2 of [RFC5997]. described in section 4.1 and 4.2 of [RFC5997].
Clients implementing this specification SHOULD include the Response- Clients implementing this specification SHOULD include the Response-
Length attribute in Status-Request messages. Servers are already Length attribute in Status-Server requests. Servers are already
required to ignore unknown attributes received in this message. by required to ignore unknown attributes received in this message. by
including the attribute, the client indicates how large of a response including the attribute the client indicates how large of a response
it can process to its Status-Server request. It is very unlikely it can process to its Status-Server request. It is very unlikely
that a response to Status-Server is greater than 4096 octets. that a response to Status-Server is greater than 4096 octets.
However the client also indicates support for this specification However the client also indicates support for this specification
which triggers server behavior below. which triggers server behavior below.
If a server implementing this specification receives a Response- If a server implementing this specification receives a Response-
Length attribute in a Status-Server request, it MUST include a Length attribute in a Status-Server request, it MUST include a
Response-Length attribute indicating the maximum size request it can Response-Length attribute indicating the maximum size request it can
process in its response to the Status-Server request. process in its response to the Status-Server request.
skipping to change at page 5, line 7 skipping to change at page 5, line 11
If a client sends a request larger than 4096 octets and the TCP If a client sends a request larger than 4096 octets and the TCP
connection is closed without a response, the client SHOULD treat the connection is closed without a response, the client SHOULD treat the
request as if a request too big error (Section 5) specifying a request as if a request too big error (Section 5) specifying a
maximum size of 4096 is received. Clients or proxies sending maximum size of 4096 is received. Clients or proxies sending
multiple requests over a single TCP connection without waiting for multiple requests over a single TCP connection without waiting for
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 desirable. Other attributes or to indicate that larger responses are acceptable. Other attributes
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 [I-D.ietf-radext-radius-fragmentation] SHOULD use
RADIUS fragmentation when the following conditions are met: RADIUS fragmentation when the following conditions are met:
1. A packet is being forwarded towards an endpoint whose 1. A packet is being forwarded towards an endpoint 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.
skipping to change at page 5, line 44 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 6113 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 21 skipping to change at page 6, line 26
3.2. Discovery 3.2. Discovery
As discussed in Section 2.1, a client MAY send a Status-Server As discussed in Section 2.1, a client MAY send a Status-Server
message to discover whether an authentication or accounting server message to discover whether an authentication or accounting server
supports this specification. The client includes a Response-Length supports this specification. The client includes a Response-Length
attribute; this signals the server to include a Response-Length attribute; this signals the server to include a Response-Length
attribute indicating the maximum packet size the server can process. attribute indicating the maximum packet size the server can process.
In this one instance, Response-Length indicate the size of a request In this one instance, Response-Length indicate the size of a request
that can be processed rather than a response. that can be processed rather than a response.
4. Protocol Error Type 4. Protocol-Error Code
This document defines a new RADIUS code, TBD (IANA), called Protocol- This document defines a new RADIUS code, TBDCODE (IANA), called
Error. This packet code may be used in response to any request Protocol-Error. This packet code may be used in response to any
packet, such as Access-Request, Accounting-Request, CoA-Request, or request packet, such as Access-Request, Accounting-Request, CoA-
Disconnect-Request. It is a response packet sent by a server to a Request, or Disconnect-Request. It is a response packet sent by a
client. The packet indicates to the client that the server is unable server to a client. The packet indicates to the client that the
to process the request for some reason. server is unable to process the request for some reason.
A Protocol-Error packet MUST contain a Original-Packet-Code A Protocol-Error packet MUST contain a Original-Packet-Code
attribute, along with an Error-Cause attribute. Other attributes MAY attribute, along with an Error-Cause attribute. Other attributes MAY
be included if desired. The Original-Packet-Code contains the code be included if desired. The Original-Packet-Code contains the code
from the request that generated the protocol error. Regardless of from the request that generated the protocol error so that clients
the original packet code, the RADIUS server calculates the Message- can disambiguate requests with different codes and the same ID.
Authenticator attribute as if the original packet were an Access- Regardless of the original packet code, the RADIUS server calculates
Request packet. The identifier is copied from the original request. the Message-Authenticator attribute as if the original packet were an
Access-Request packet. The identifier is copied from the original
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-
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
the maximum size of request that will be processed. the maximum size of request that will be processed.
skipping to change at page 8, line 4 skipping to change at page 8, line 16
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
opportunities for an on-path attacker to impact availability. these opportunities for an on-path attacker to impact availability. These
attacks can be entirely mitigated by using TLS. attacks can be entirely mitigated by using TLS. If these attacks ar
acceptable, then this specification can be used over TCP.
8. Acknowledgements 8. Acknowledgements
Sam Hartman's time on this draft was funded by JANET as part of Sam Hartman's time on this draft was funded by JANET as part of
Project Moonshot. Project Moonshot.
Alan DeKok provided valuable review and text for the Protocol-Error Alan DeKok provided valuable review and text for the Protocol-Error
packet code. packet code.
Alejandro Perez Mendez provided valuable review comments.
9. References 9. References
9.1. Normative References 9.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)", RFC "Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000. 2865, June 2000.
 End of changes. 21 change blocks. 
36 lines changed or deleted 47 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/