Skip to main content

Larger Packets for RADIUS over TCP
draft-ietf-radext-bigger-packets-07

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7930.
Author Sam Hartman
Last updated 2016-08-17 (Latest revision 2016-04-12)
Replaces draft-hartman-radext-bigger-packets
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Experimental
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Stefan Winter
Shepherd write-up Show Last changed 2015-12-17
IESG IESG state Became RFC 7930 (Experimental)
Action Holders
(None)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Stephen Farrell
Send notices to jouni.nospam@gmail.com
IANA IANA review state IANA - Not OK
IANA action state RFC-Ed-Ack
draft-ietf-radext-bigger-packets-07
Network Working Group                                         S. Hartman
Internet-Draft                                         Painless Security
Updates: 6613 (if approved)                               April 12, 2016
Intended status: Experimental
Expires: October 14, 2016

                   Larger Packets for RADIUS over TCP
                draft-ietf-radext-bigger-packets-07.txt

Abstract

   The RADIUS over TLS experiment described in RFC 6614 has opened
   RADIUS to new use cases where the 4096-octet maximum size limit of
   RADIUS packet proves problematic.  This specification extends the
   RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS
   packets.  This specification compliments other ongoing work to permit
   fragmentation of RADIUS authorization information.  This document
   registers a new RADIUS code, an action which requires IESG approval.

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 October 14, 2016.

Copyright Notice

   Copyright (c) 2016 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

Hartman                 Expires October 14, 2016                [Page 1]
Internet-Draft            RADIUS Large Packets                April 2016

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements notation . . . . . . . . . . . . . . . . . .   3
   2.  Changes to Packet Processing  . . . . . . . . . . . . . . . .   3
     2.1.  Status-Server Considerations  . . . . . . . . . . . . . .   4
   3.  Forward and backward Compatibility  . . . . . . . . . . . . .   4
     3.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Protocol-Error Code . . . . . . . . . . . . . . . . . . . . .   6
   5.  Too Big Response  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The Remote Authentication Dial In User Service (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 [RFC7499] 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

Hartman                 Expires October 14, 2016                [Page 2]
Internet-Draft            RADIUS Large Packets                April 2016

   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.  This specification provides a mechanism to achieve
   these better transport characteristics when TCP is used.  As part of
   this specification, a new RADIUS code is registered.

   This specification is published as an experimental specification
   because the TCP extensions to RADIUS are currently experimental.  The
   need for this specification arises from operational experience with
   the TCP extensions.  However, this specification introduces no new
   experimental evaluation criteria beyond those in the base TCP
   specification; this specification can be evaluated along with that
   one for advancement on the standards track.

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].

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 RADIUS packet of maximum length.  Servers MAY have a
   maximum size over which they choose to return an error as discussed
   in Section 5 rather than processing a received packet; this size MUST
   be at least 4096 octets.

   Clients implementing this specification MUST be able to receive a
   RADIUS 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 6 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 MUST be able to receive a RADIUS packet of maximum length
   without closing the TCP connection.  Proxies SHOULD be able to
   process and forward packets of maximum length.  When a proxy receives
   a request over a transport with a 4096-octet maximum length and the

Hartman                 Expires October 14, 2016                [Page 3]
Internet-Draft            RADIUS Large Packets                April 2016

   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

   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-Server requests.  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.

3.  Forward and backward Compatibility

   An implementation of [RFC6613] will silently discard any RADIUS
   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 default maximum size of RADIUS packets sent to clients and
   servers.  If an implementation provides more granular configuration
   for some classes of dynamic resources, then the implementation SHOULD
   also provide configuration of default maximum packet sizes at the
   same granularity.  As an example, an implementation that provided
   granular configuration for resources using a particular trust anchor

Hartman                 Expires October 14, 2016                [Page 4]
Internet-Draft            RADIUS Large Packets                April 2016

   or belonging to a particular roaming consortium SHOULD provide
   default packet size configuration at the same granularity.

   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 5) 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 acceptable.  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 [RFC7499] SHOULD use RADIUS fragmentation when the
   following conditions are met:

   1.  A RADIUS packet is being forwarded towards a next hop whose
       configuration does not support a packet that large.

   2.  RADIUS Fragmentation can be used for the packet in question.

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.

Hartman                 Expires October 14, 2016                [Page 5]
Internet-Draft            RADIUS Large Packets                April 2016

   There is a special challenge for proxies or clients with high request
   volume.  When an RFC 6613 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
   that can be processed rather than a response.

4.  Protocol-Error Code

   This document defines a new RADIUS code, TBDCODE (IANA), called
   Protocol-Error.  This packet code may be used in response to any
   request packet, such as Access-Request, Accounting-Request, CoA-
   Request, or Disconnect-Request.  It is a response packet sent by a
   server to a client.  The packet indicates to the client that the
   server is unable to process the request for some reason.

   A Protocol-Error packet MUST contain a Original-Packet-Code
   attribute, along with an Error-Cause attribute.  Other attributes MAY
   be included if desired.  The Original-Packet-Code contains the code
   from the request that generated the protocol error so that clients
   can disambiguate requests with different codes and the same ID.
   Regardless of the original packet code, the RADIUS server calculates
   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
   attributes.

Hartman                 Expires October 14, 2016                [Page 6]
Internet-Draft            RADIUS Large Packets                April 2016

   This RADIUS code is hop-by-hop.  Proxies MUST NOT forward a Protocol-
   Error packet they receive.

5.  Too Big Response

   When a RADIUS server receives a request that is larger than can be
   processed, it generates a Protocol-Error response as follows:

      The code is Protocol-Error.

      The Response-Length attribute MUST be included and its value is
      the maximum size of request that will be processed.

      The Error-Cause attribute is included with a value of TOOBIGTBD.

      The Original-Packet-Code attribute is copied from the request.

   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.

6.  IANA Considerations

   A new RADIUS packet type code is registered in the RADIUS packet type
   codes registry discussed in section 2.1 of RFC 3575 [RFC3575].  The
   name is "Protocol-Error" and the code is TBDCODE.  The IESG is
   requested to approve this registration along with approving
   publication of this document.

   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       | attribute of type "integer"    |
   |                      |           | per Section 5 of RFC 2865      |
   |                      |           | containing  maximum response   |
   |                      |           | length                         |
   |                      |           |                                |
   | Original-Packet-Code | TBD2      | An integer attribute           |
   |                      |           | containing the code from a     |
   |                      |           | packet resulting in a          |
   |                      |           | Protocol-Error response.       |
   +----------------------+-----------+--------------------------------+

Hartman                 Expires October 14, 2016                [Page 7]
Internet-Draft            RADIUS Large Packets                April 2016

   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 indicates the maximum size
   RADIUS request that is permitted.

   A new Error-Cause value is registered in the registry at
   http://www.iana.org/assignments/radius-types/radius-
   types.xhtml#radius-types-18 for "Response Too Big" with value
   TOOBIGTBD.

7.  Security Considerations

   This specification updates [RFC6613] 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.  If these attacks are
   acceptable, then this specification can be used over TCP without TLS.

8.  Acknowledgements

   Sam Hartman's time on this draft was funded by JANET as part of
   Project Moonshot.

   Alan DeKok provided valuable review and text for the Protocol-Error
   packet code.

   Alejandro Perez Mendez provided valuable review comments.

9.  References

9.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.

Hartman                 Expires October 14, 2016                [Page 8]
Internet-Draft            RADIUS Large Packets                April 2016

   [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.

9.2.  Informative 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-09 (work in
              progress), February 2014.

   [RFC7499]  Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia,
              F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of
              Fragmentation of RADIUS Packets", RFC 7499, DOI 10.17487/
              RFC7499, April 2015,
              <http://www.rfc-editor.org/info/rfc7499>.

Author's Address

   Sam Hartman
   Painless Security

   Email: hartmans-ietf@mit.edu

Hartman                 Expires October 14, 2016                [Page 9]