Larger Packets for Remote RADIUS over TCP
draft-hartman-radext-bigger-packets-00

Network Working Group                                         S. Hartman
Internet-Draft                                         Painless Security
Updates: 6613, 6614 (if approved)                       October 21, 2013
Intended status: Experimental
Expires: April 24, 2014

               Larger Packets for Remote RADIUS  over TCP
               draft-hartman-radext-bigger-packets-00.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 April 24, 2014.

Copyright Notice

   Copyright (c) 2013 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 April 24, 2014                 [Page 1]
Internet-Draft            RADIUS Large Packets              October 2013

   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
   3.  Forward and backward Compatibility . . . . . . . . . . . . . .  5
     3.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Capability Negotiation . . . . . . . . . . . . . . . . . .  6
   4.  Diameter Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  Too Big Response . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Response Length Attribute  . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  References . . . . . . . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13

Hartman                  Expires April 24, 2014                 [Page 2]
Internet-Draft            RADIUS Large Packets              October 2013

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 April 24, 2014                 [Page 3]
Internet-Draft            RADIUS Large Packets              October 2013

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

Hartman                  Expires April 24, 2014                 [Page 4]
Internet-Draft            RADIUS Large Packets              October 2013

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 5) specifying a
   maximum size of 4096 is received.

   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.

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.

Hartman                  Expires April 24, 2014                 [Page 5]
Internet-Draft            RADIUS Large Packets              October 2013

   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.

   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.  Capability Negotiation

   A capability negotiation mechanism would allow a client to determine
   whether a server supported large packets before sending a request.
   If such a mechanism is standardized for RADIUS, then a capability
   should be defined for carrying the maximum size packet the server
   accepts.

   However, in practice, a capability negotiation mechanism does not
   provide sufficient value to large-packet support to block large-
   packet support on its development.  Generally, if a client has a
   large packet to send, it can either send the large packet or signal
   an error.  RFC 6613 already has well-defined error behavior if a
   large packet is received: the TCP connection is closed.

Hartman                  Expires April 24, 2014                 [Page 6]
Internet-Draft            RADIUS Large Packets              October 2013

4.  Diameter Considerations

   The mechanism described in this specification is a transport matter
   between a RADIUS server and client.  Diameter already supports
   sending more than 4096 octets of information.  A Diameter to RADIUS
   proxy implementing this specification MAY forward packets that would
   otherwise be too big.

   XXX discuss handling of the new code and Response-Length attribute.

Hartman                  Expires April 24, 2014                 [Page 7]
Internet-Draft            RADIUS Large Packets              October 2013

5.  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 April 24, 2014                 [Page 8]
Internet-Draft            RADIUS Large Packets              October 2013

6.  Response Length Attribute

   Define an attribute to carry the maximum length of a response that a
   client will accept.  Values between 4096 and 65535.

Hartman                  Expires April 24, 2014                 [Page 9]
Internet-Draft            RADIUS Large Packets              October 2013

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

Hartman                  Expires April 24, 2014                [Page 10]
Internet-Draft            RADIUS Large Packets              October 2013

8.  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 April 24, 2014                [Page 11]
Internet-Draft            RADIUS Large Packets              October 2013

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.

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

9.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-06 (work in
              progress), July 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-00 (work in
              progress), August 2013.

Hartman                  Expires April 24, 2014                [Page 12]
Internet-Draft            RADIUS Large Packets              October 2013

Author's Address

   Sam Hartman
   Painless Security

   Email: hartmans-ietf@mit.edu

Hartman                  Expires April 24, 2014                [Page 13]