doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc6613.txt b/doc/rfc/rfc6613.txt
new file mode 100644
index 0000000..842350c
--- /dev/null
+++ b/doc/rfc/rfc6613.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. DeKok
+Request for Comments: 6613                                    FreeRADIUS
+Category: Experimental                                          May 2012
+ISSN: 2070-1721
+
+
+                            RADIUS over TCP
+
+Abstract
+
+   The Remote Authentication Dial-In User Server (RADIUS) protocol has,
+   until now, required the User Datagram Protocol (UDP) as the
+   underlying transport layer.  This document defines RADIUS over the
+   Transmission Control Protocol (RADIUS/TCP), in order to address
+   handling issues related to RADIUS over Transport Layer Security
+   (RADIUS/TLS).  It permits TCP to be used as a transport protocol for
+   RADIUS only when a transport layer such as TLS or IPsec provides
+   confidentiality and security.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6613.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+DeKok                         Experimental                      [Page 1]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Applicability of Reliable Transport ........................4
+      1.2. Terminology ................................................6
+      1.3. Requirements Language ......................................6
+   2. Changes to RADIUS ...............................................6
+      2.1. Packet Format ..............................................7
+      2.2. Assigned Ports for RADIUS/TCP ..............................7
+      2.3. Management Information Base (MIB) ..........................8
+      2.4. Detecting Live Servers .....................................8
+      2.5. Congestion Control Issues ..................................9
+      2.6. TCP Specific Issues ........................................9
+           2.6.1. Duplicates and Retransmissions .....................10
+           2.6.2. Head of Line Blocking ..............................11
+           2.6.3. Shared Secrets .....................................11
+           2.6.4. Malformed Packets and Unknown Clients ..............12
+           2.6.5. Limitations of the ID Field ........................13
+           2.6.6. EAP Sessions .......................................13
+           2.6.7. TCP Applications Are Not UDP Applications ..........14
+   3. Diameter Considerations ........................................14
+   4. Security Considerations ........................................14
+   5. References .....................................................15
+      5.1. Normative References ......................................15
+      5.2. Informative References ....................................15
+
+
+
+
+
+
+
+
+
+
+
+DeKok                         Experimental                      [Page 2]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+1.  Introduction
+
+   The RADIUS protocol is defined in [RFC2865] as using the User
+   Datagram Protocol (UDP) for the underlying transport layer.  While
+   there are a number of benefits to using UDP as outlined in [RFC2865],
+   Section 2.4, there are also some limitations:
+
+      *  Unreliable transport.  As a result, systems using RADIUS have
+         to implement application-layer timers and retransmissions, as
+         described in [RFC5080], Section 2.2.1.
+
+      *  Packet fragmentation.  [RFC2865], Section 3, permits RADIUS
+         packets up to 4096 octets in length.  These packets are larger
+         than the common Internet MTU (576), resulting in fragmentation
+         of the packets at the IP layer when they are proxied over the
+         Internet.  Transport of fragmented UDP packets appears to be a
+         poorly tested code path on network devices.  Some devices
+         appear to be incapable of transporting fragmented UDP packets,
+         making it difficult to deploy RADIUS in a network where those
+         devices are deployed.
+
+      *  Connectionless transport.  Neither clients nor servers receive
+         positive statements that a "connection" is down.  This
+         information has to be deduced instead from the absence of a
+         reply to a request.
+
+      *  Lack of congestion control.  Clients can send arbitrary amounts
+         of traffic with little or no feedback.  This lack of feedback
+         can result in congestive collapse of the network.
+
+   RADIUS has been widely deployed for well over a decade and continues
+   to be widely deployed.  Experience shows that these issues have been
+   minor in some use cases and problematic in others.  For use cases
+   such as inter-server proxying, an alternative transport and security
+   model -- RADIUS/TLS, is defined in [RFC6614].  That document
+   describes the transport implications of running RADIUS/TLS.
+
+   The choice of TCP as a transport protocol is largely driven by the
+   desire to improve the security of RADIUS by using RADIUS/TLS.  For
+   practical reasons, the transport protocol (TCP) is defined separately
+   from the security mechanism (TLS).
+
+   Since "bare" TCP does not provide for confidentiality or enable
+   negotiation of credible ciphersuites, its use is not appropriate for
+   inter-server communications where strong security is required.  As a
+   result, "bare" TCP transport MUST NOT be used without TLS, IPsec, or
+   another secure upper layer.
+
+
+
+
+DeKok                         Experimental                      [Page 3]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+   However, "bare" TCP transport MAY be used when another method such as
+   IPsec [RFC4301] is used to provide additional confidentiality and
+   security.  Should experience show that such deployments are useful,
+   this specification could be moved to the Standards Track.
+
+1.1.  Applicability of Reliable Transport
+
+   The intent of this document is to address transport issues related to
+   RADIUS/TLS [RFC6614] in inter-server communications scenarios, such
+   as inter-domain communication between proxies.  These situations
+   benefit from the confidentiality and ciphersuite negotiation that can
+   be provided by TLS.  Since TLS is already widely available within the
+   operating systems used by proxies, implementation barriers are low.
+
+   In scenarios where RADIUS proxies exchange a large volume of packets,
+   it is likely that there will be sufficient traffic to enable the
+   congestion window to be widened beyond the minimum value on a long-
+   term basis, enabling ACK piggybacking.  Through use of an
+   application-layer watchdog as described in [RFC3539], it is possible
+   to address the objections to reliable transport described in
+   [RFC2865], Section 2.4, without substantial watchdog traffic, since
+   regular traffic is expected in both directions.
+
+   In addition, use of RADIUS/TLS has been found to improve operational
+   performance when used with multi-round-trip authentication mechanisms
+   such as the Extensible Authentication Protocol (EAP) over RADIUS
+   [RFC3579].  In such exchanges, it is typical for EAP fragmentation to
+   increase the number of round trips required.  For example, where EAP-
+   TLS authentication [RFC5216] is attempted and both the EAP peer and
+   server utilize certificate chains of 8 KB, as many as 15 round trips
+   can be required if RADIUS packets are restricted to the common
+   Ethernet MTU (1500 octets) for EAP over LAN (EAPoL) use cases.
+   Fragmentation of RADIUS/UDP packets is generally inadvisable due to
+   lack of fragmentation support within intermediate devices such as
+   filtering routers, firewalls, and NATs.  However, since RADIUS/UDP
+   implementations typically do not support MTU discovery, fragmentation
+   can occur even when the maximum RADIUS/UDP packet size is restricted
+   to 1500 octets.
+
+   These problems disappear if a 4096-octet application-layer payload
+   can be used alongside RADIUS/TLS.  Since most TCP implementations
+   support MTU discovery, the TCP Maximum Segment Size (MSS) is
+   automatically adjusted to account for the MTU, and the larger
+   congestion window supported by TCP may allow multiple TCP segments to
+   be sent within a single window.  Even those few TCP stacks that do
+   not perform Path MTU discovery can already support arbitrary
+   payloads.
+
+
+
+
+DeKok                         Experimental                      [Page 4]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+   Where the MTU for EAP packets is large, RADIUS/EAP traffic required
+   for an EAP-TLS authentication with 8-KB certificate chains may be
+   reduced to 7 round trips or less, resulting in substantially reduced
+   authentication times.
+
+   In addition, experience indicates that EAP sessions transported over
+   RADIUS/TLS are less likely to abort unsuccessfully.  Historically,
+   RADIUS-over-UDP (see Section 1.2) implementations have exhibited poor
+   retransmission behavior.  Some implementations retransmit packets,
+   others do not, and others send new packets rather than performing
+   retransmission.  Some implementations are incapable of detecting EAP
+   retransmissions, and will instead treat the retransmitted packet as
+   an error.  As a result, within RADIUS/UDP implementations,
+   retransmissions have a high likelihood of causing an EAP
+   authentication session to fail.  For a system with a million logins a
+   day running EAP-TLS mutual authentication with 15 round trips, and
+   having a packet loss probability of P=0.01%, we expect that 0.3% of
+   connections will experience at least one lost packet.  That is, 3,000
+   user sessions each day will experience authentication failure.  This
+   is an unacceptable failure rate for a mass-market network service.
+
+   Using a reliable transport method such as TCP means that RADIUS
+   implementations can remove all application-layer retransmissions, and
+   instead rely on the Operating System (OS) kernel's well-tested TCP
+   transport to ensure Path MTU discovery and reliable delivery.  Modern
+   TCP implementations also implement anti-spoofing provisions, which is
+   more difficult to do in a UDP application.
+
+   In contrast, use of TCP as a transport between a Network Access
+   Server (NAS) and a RADIUS server is usually a poor fit.  As noted in
+   [RFC3539], Section 2.1, for systems originating low numbers of RADIUS
+   request packets, inter-packet spacing is often larger than the packet
+   Round-Trip Time (RTT), meaning that, the congestion window will
+   typically stay below the minimum value on a long-term basis.  The
+   result is an increase in packets due to ACKs as compared to UDP,
+   without a corresponding set of benefits.  In addition, the lack of
+   substantial traffic implies the need for additional watchdog traffic
+   to confirm reachability.
+
+   As a result, the objections to reliable transport indicated in
+   [RFC2865], Section 2.4, continue to apply to NAS-RADIUS server
+   communications, and UDP SHOULD continue to be used as the transport
+   protocol in this scenario.  In addition, it is recommended that
+   implementations of RADIUS Dynamic Authorization Extensions [RFC5176]
+   SHOULD continue to utilize UDP transport, since the volume of dynamic
+   authorization traffic is usually expected to be small.
+
+
+
+
+
+DeKok                         Experimental                      [Page 5]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+1.2.  Terminology
+
+   This document uses the following terms:
+
+   RADIUS client
+      A device that provides an access service for a user to a network.
+      Also referred to as a Network Access Server, or NAS.
+
+   RADIUS server
+      A device that provides one or more of authentication,
+      authorization, and/or accounting (AAA) services to a NAS.
+
+   RADIUS proxy
+      A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS
+      client to the RADIUS server.
+
+   RADIUS request packet
+      A packet originated by a RADIUS client to a RADIUS server.  For
+      example, Access-Request, Accounting-Request, CoA-Request, or
+      Disconnect-Request.
+
+   RADIUS response packet
+      A packet sent by a RADIUS server to a RADIUS client, in response
+      to a RADIUS request packet.  For example, Access-Accept, Access-
+      Reject, Access-Challenge, Accounting-Response, or CoA-ACK.
+
+   RADIUS/UDP
+      RADIUS over UDP, as defined in [RFC2865].
+
+   RADIUS/TCP
+      RADIUS over TCP, as defined in this document.
+
+   RADIUS/TLS
+      RADIUS over TLS, as defined in [RFC6614].
+
+1.3.  Requirements Language
+
+   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 RADIUS
+
+   RADIUS/TCP involves sending RADIUS application messages over a TCP
+   connection.  In the sections that follow, we discuss the implications
+   for the RADIUS packet format (Section 2.1), port usage (Section 2.2),
+   RADIUS MIBs (Section 2.3), and RADIUS proxies (Section 2.5).  TCP-
+   specific issues are discussed in Section 2.6.
+
+
+
+DeKok                         Experimental                      [Page 6]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+2.1.  Packet Format
+
+   The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and
+   [RFC5176].  Specifically, all of the following portions of RADIUS
+   MUST be unchanged when using RADIUS/TCP:
+
+      *  Packet format
+      *  Permitted codes
+      *  Request Authenticator calculation
+      *  Response Authenticator calculation
+      *  Minimum packet length
+      *  Maximum packet length
+      *  Attribute format
+      *  Vendor-Specific Attribute (VSA) format
+      *  Permitted data types
+      *  Calculations of dynamic attributes such as CHAP-Challenge, or
+         Message-Authenticator.
+      *  Calculation of "encrypted" attributes such as Tunnel-Password.
+
+   The use of TLS transport does not change the calculation of security-
+   related fields (such as the Response-Authenticator) in RADIUS
+   [RFC2865] or RADIUS Dynamic Authorization [RFC5176].  Calculation of
+   attributes such as User-Password [RFC2865] or Message-Authenticator
+   [RFC3579] also does not change.
+
+   Clients and servers MUST be able to store and manage shared secrets
+   based on the key described in Section 2.6, of (IP address, port,
+   transport protocol).
+
+   The changes to RADIUS implementations required to implement this
+   specification are largely limited to the portions that send and
+   receive packets on the network.
+
+2.2.  Assigned Ports for RADIUS/TCP
+
+   IANA has already assigned TCP ports for RADIUS transport, as outlined
+   below:
+
+      * radius          1812/tcp
+      * radius-acct     1813/tcp
+      * radius-dynauth  3799/tcp
+
+   Since these ports are unused by existing RADIUS implementations, the
+   assigned values MUST be used as the default ports for RADIUS over
+   TCP.
+
+
+
+
+
+
+DeKok                         Experimental                      [Page 7]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+   The early deployment of RADIUS was done using UDP port number 1645,
+   which conflicts with the "datametrics" service.  Implementations
+   using RADIUS/TCP MUST NOT use TCP ports 1645 or 1646 as the default
+   ports for this specification.
+
+   The "radsec" port (2083/tcp) SHOULD be used as the default port for
+   RADIUS/TLS.  The "radius" port (1812/tcp) SHOULD NOT be used for
+   RADIUS/TLS.
+
+2.3.  Management Information Base (MIB)
+
+   The MIB Module definitions in [RFC4668], [RFC4669], [RFC4670],
+   [RFC4671], [RFC4672], and [RFC4673] are intended to be used for
+   RADIUS over UDP.  As such, they do not support RADIUS/TCP, and will
+   need to be updated in the future.  Implementations of RADIUS/TCP
+   SHOULD NOT reuse these MIB Modules to perform statistics counting for
+   RADIUS/TCP connections.
+
+2.4.  Detecting Live Servers
+
+   As RADIUS is a "hop-by-hop" protocol, a RADIUS proxy shields the
+   client from any information about downstream servers.  While the
+   client may be able to deduce the operational state of the local
+   server (i.e., proxy), it cannot make any determination about the
+   operational state of the downstream servers.
+
+   Within RADIUS, as defined in [RFC2865], proxies typically only
+   forward traffic between the NAS and RADIUS server, and they do not
+   generate their own responses.  As a result, when a NAS does not
+   receive a response to a request, this could be the result of packet
+   loss between the NAS and proxy, a problem on the proxy, loss between
+   the RADIUS proxy and server, or a problem with the server.
+
+   When UDP is used as a transport protocol, the absence of a reply can
+   cause a client to deduce (incorrectly) that the proxy is unavailable.
+   The client could then fail over to another server or conclude that no
+   "live" servers are available (OKAY state in [RFC3539], Appendix A).
+   This situation is made even worse when requests are sent through a
+   proxy to multiple destinations.  Failures in one destination may
+   result in service outages for other destinations, if the client
+   erroneously believes that the proxy is unresponsive.
+
+   For RADIUS/TLS, it is RECOMMENDED that implementations utilize the
+   existence of a TCP connection along with the application-layer
+   watchdog defined in [RFC3539], Section 3.4, to determine that the
+   server is "live".
+
+
+
+
+
+DeKok                         Experimental                      [Page 8]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+   RADIUS clients using RADIUS/TCP MUST mark a connection DOWN if the
+   network stack indicates that the connection is no longer active.  If
+   the network stack indicates that the connection is still active,
+   clients MUST NOT decide that it is down until the application-layer
+   watchdog algorithm has marked it DOWN ([RFC3539], Appendix A).
+   RADIUS clients using RADIUS/TCP MUST NOT decide that a RADIUS server
+   is unresponsive until all TCP connections to it have been marked
+   DOWN.
+
+   The above requirements do not forbid the practice of a client
+   proactively closing connections or marking a server as DOWN due to an
+   administrative decision.
+
+2.5.  Congestion Control Issues
+
+   Additional issues with RADIUS proxies involve transport protocol
+   changes where the proxy receives packets on one transport protocol
+   and forwards them on a different transport protocol.  There are
+   several situations in which the law of "conservation of packets"
+   could be violated on an end-to-end basis (e.g., where more packets
+   could enter the system than could leave it on a short-term basis):
+
+      *  Where TCP is used between proxies, it is possible that the
+         bandwidth consumed by incoming UDP packets destined to a given
+         upstream server could exceed the sending rate of a single TCP
+         connection to that server, based on the window size/RTT
+         estimate.
+
+      *  It is possible for the incoming rate of TCP packets destined to
+         a given realm to exceed the UDP throughput achievable using the
+         transport guidelines established in [RFC5080].  This could
+         happen, for example, where the TCP window between proxies has
+         opened, but packet loss is being experienced on the UDP leg, so
+         that the effective congestion window on the UDP side is 1.
+
+   Intrinsically, proxy systems operate with multiple control loops
+   instead of one end-to-end loop, and so they are less stable.  This is
+   true even for TCP-TCP proxies.  As discussed in [RFC3539], the only
+   way to achieve stability equivalent to a single TCP connection is to
+   mimic the end-to-end behavior of a single TCP connection.  This
+   typically is not achievable with an application-layer RADIUS
+   implementation, regardless of transport.
+
+2.6.  TCP Specific Issues
+
+   The guidelines defined in [RFC3539] for implementing a AAA protocol
+   over reliable transport are applicable to RADIUS/TLS.
+
+
+
+
+DeKok                         Experimental                      [Page 9]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+   The application-layer watchdog defined in [RFC3539], Section 3.4,
+   MUST be used.  The Status-Server packet [RFC5997] MUST be used as the
+   application-layer watchdog message.  Implementations MUST reserve one
+   RADIUS ID per connection for the application-layer watchdog message.
+   This restriction is described further in Section 2.6.4.
+
+   RADIUS/TLS implementations MUST support receiving RADIUS packets over
+   both UDP and TCP transports originating from the same endpoint.
+   RADIUS packets received over UDP MUST be replied to over UDP; RADIUS
+   packets received over TCP MUST be replied to over TCP.  That is,
+   RADIUS clients and servers MUST be treated as unique based on a key
+   of the three-tuple (IP address, port, transport protocol).
+   Implementations MUST permit different shared secrets to be used for
+   UDP and TCP connections to the same destination IP address and
+   numerical port.
+
+   This requirement does not forbid the traditional practice of using
+   primary and secondary servers in a failover relationship.  Instead,
+   it requires that two services sharing an IP address and numerical
+   port, but differing in transport protocol, MUST be treated as
+   independent services for the purpose of failover, load-balancing,
+   etc.
+
+   Whenever the underlying network stack permits the use of TCP
+   keepalive socket options, their use is RECOMMENDED.
+
+2.6.1.  Duplicates and Retransmissions
+
+   As TCP is a reliable transport, implementations MUST NOT retransmit
+   RADIUS request packets over a given TCP connection.  Similarly, if
+   there is no response to a RADIUS packet over one TCP connection,
+   implementations MUST NOT retransmit that packet over a different TCP
+   connection to the same destination IP address and port, while the
+   first connection is in the OKAY state ([RFC3539], Appendix A).
+
+   However, if the TCP connection is broken or closed, retransmissions
+   over new connections are permissible.  RADIUS request packets that
+   have not yet received a response MAY be transmitted by a RADIUS
+   client over a new TCP connection.  As this procedure involves using a
+   new source port, the ID of the packet MAY change.  If the ID changes,
+   any security attributes such as Message-Authenticator MUST be
+   recalculated.
+
+   If a TCP connection is broken or closed, any cached RADIUS response
+   packets ([RFC5080], Section 2.2.2) associated with that connection
+   MUST be discarded.  A RADIUS server SHOULD stop the processing of any
+   requests associated with that TCP connection.  No response to these
+   requests can be sent over the TCP connection, so any further
+
+
+
+DeKok                         Experimental                     [Page 10]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+   processing is pointless.  This requirement applies not only to RADIUS
+   servers, but also to proxies.  When a client's connection to a proxy
+   server is closed, there may be responses from a home server that were
+   supposed to be sent by the proxy back over that connection to the
+   client.  Since the client connection is closed, those responses from
+   the home server to the proxy server SHOULD be silently discarded by
+   the proxy.
+
+   Despite the above discussion, RADIUS servers SHOULD still perform
+   duplicate detection on received packets, as described in [RFC5080],
+   Section 2.2.2.  This detection can prevent duplicate processing of
+   packets from non-conformant clients.
+
+   RADIUS packets SHOULD NOT be retransmitted to the same destination IP
+   and numerical port, but over a different transport protocol.  There
+   is no guarantee in RADIUS that the two ports are in any way related.
+   This requirement does not, however, forbid the practice of putting
+   multiple servers into a failover or load-balancing pool.  In that
+   situation, RADIUS request MAY be retransmitted to another server that
+   is known to be part of the same pool.
+
+2.6.2.  Head of Line Blocking
+
+   When using UDP as a transport for RADIUS, there is no ordering of
+   packets.  If a packet sent by a client is lost, that loss has no
+   effect on subsequent packets sent by that client.
+
+   Unlike UDP, TCP is subject to issues related to Head of Line (HoL)
+   blocking.  This occurs when a TCP segment is lost and a subsequent
+   TCP segment arrives out of order.  While the RADIUS server can
+   process RADIUS packets out of order, the semantics of TCP makes this
+   impossible.  This limitation can lower the maximum packet processing
+   rate of RADIUS/TCP.
+
+2.6.3.  Shared Secrets
+
+   The use of TLS transport does not change the calculation of security-
+   related fields (such as the Response-Authenticator) in RADIUS
+   [RFC2865] or RADIUS Dynamic Authorization [RFC5176].  Calculation of
+   attributes such as User-Password [RFC2865] or Message-Authenticator
+   [RFC3579] also does not change.
+
+   Clients and servers MUST be able to store and manage shared secrets
+   based on the key described above, at the start of this section (i.e.,
+   IP address, port, transport protocol).
+
+
+
+
+
+
+DeKok                         Experimental                     [Page 11]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+2.6.4.  Malformed Packets and Unknown Clients
+
+   The RADIUS specifications ([RFC2865], and many others) say that an
+   implementation should "silently discard" a packet in a number of
+   circumstances.  This action has no further consequences for UDP
+   transport, as the "next" packet is completely independent of the
+   previous one.
+
+   When TCP is used as a transport, decoding the "next" packet on a
+   connection depends on the proper decoding of the previous packet.  As
+   a result, the behavior with respect to discarded packets has to
+   change.
+
+   Implementations of this specification SHOULD treat the "silently
+   discard" texts referenced above as "silently discard and close the
+   connection".  That is, the TCP connection MUST be closed if any of
+   the following circumstances are seen:
+
+      *  Connection from an unknown client
+      *  Packet where the RADIUS "Length" field is less than the minimum
+         RADIUS packet length
+      *  Packet where the RADIUS "Length" field is more than the maximum
+         RADIUS packet length
+      *  Packet that has an Attribute "Length" field has value of zero
+         or one (0 or 1)
+      *  Packet where the attributes do not exactly fill the packet
+      *  Packet where the Request Authenticator fails validation (where
+         validation is required)
+      *  Packet where the Response Authenticator fails validation (where
+         validation is required)
+      *  Packet where the Message-Authenticator attribute fails
+         validation (when it occurs in a packet)
+
+   After applying the above rules, there are still two situations where
+   the previous specifications allow a packet to be "silently discarded"
+   upon receipt:
+
+      *  Packets with an invalid code field
+      *  Response packets that do not match any outstanding request
+
+   In these situations, the TCP connections MAY remain open, or they MAY
+   be closed, as an implementation choice.  However, the invalid packet
+   MUST be silently discarded.
+
+   These requirements reduce the possibility for a misbehaving client or
+   server to wreak havoc on the network.
+
+
+
+
+
+DeKok                         Experimental                     [Page 12]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+2.6.5.  Limitations of the ID Field
+
+   The RADIUS ID field is one octet in size.  As a result, any one TCP
+   connection can have only 256 "in flight" RADIUS packets at a time.
+   If more than 256 simultaneous "in flight" packets are required,
+   additional TCP connections will need to be opened.  This limitation
+   is also noted in [RFC3539], Section 2.4.
+
+   An additional limit is the requirement to send a Status-Server packet
+   over the same TCP connection as is used for normal requests.  As
+   noted in [RFC5997], the response to a Status-Server packet is either
+   an Access-Accept or an Accounting-Response.  If all IDs were
+   allocated to normal requests, then there would be no free ID to use
+   for the Status-Server packet, and it could not be sent over the
+   connection.
+
+   Implementations SHOULD reserve ID zero (0) on each TCP connection for
+   Status-Server packets.  This value was picked arbitrarily, as there
+   is no reason to choose any one value over another for this use.
+
+   Implementors may be tempted to extend RADIUS to permit more than 256
+   outstanding packets on one connection.  However, doing so is a
+   violation of a fundamental part of the protocol and MUST NOT be done.
+   Making that extension here is outside of the scope of this
+   specification.
+
+2.6.6.  EAP Sessions
+
+   When RADIUS clients send EAP requests using RADIUS/TCP, they SHOULD
+   choose the same TCP connection for all packets related to one EAP
+   session.  This practice ensures that EAP packets are transmitted in
+   order, and that problems with any one TCP connection affect the
+   minimum number of EAP sessions.
+
+   A simple method that may work in many situations is to hash the
+   contents of the Calling-Station-Id attribute, which normally contains
+   the Media Access Control (MAC) address.  The output of that hash can
+   be used to select a particular TCP connection.
+
+   However, EAP packets for one EAP session can still be transported
+   from client to server over multiple paths.  Therefore, when a server
+   receives a RADIUS request containing an EAP request, it MUST be
+   processed without considering the transport protocol.  For TCP
+   transport, it MUST be processed without considering the source port.
+   The algorithm suggested in [RFC5080], Section 2.1.1 SHOULD be used to
+   track EAP sessions, as it is independent of the source port and
+   transport protocol.
+
+
+
+
+DeKok                         Experimental                     [Page 13]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+   The retransmission requirements of Section 2.6.1, above, MUST be
+   applied to RADIUS-encapsulated EAP packets.  That is, EAP
+   retransmissions MUST NOT result in retransmissions of RADIUS packets
+   over a particular TCP connection.  EAP retransmissions MAY result in
+   retransmission of RADIUS packets over a different TCP connection, but
+   only when the previous TCP connection is marked DOWN.
+
+2.6.7.  TCP Applications Are Not UDP Applications
+
+   Implementors should be aware that programming a robust TCP
+   application can be very different from programming a robust UDP
+   application.  It is RECOMMENDED that implementors of this
+   specification familiarize themselves with TCP application programming
+   concepts.
+
+   Clients and servers SHOULD implement configurable connection limits.
+   Clients and servers SHOULD implement configurable limits on
+     connection lifetime and idle timeouts.  Clients and servers SHOULD
+   implement configurable rate limiting on new connections.  Allowing an
+   unbounded number or rate of TCP connections may result in resource
+   exhaustion.
+
+   Further discussion of implementation issues is outside of the scope
+   of this document.
+
+3.  Diameter Considerations
+
+   This document defines TCP as a transport layer for RADIUS.  It
+   defines no new RADIUS attributes or codes.  The only interaction with
+   Diameter is in a RADIUS-to-Diameter, or in a Diameter-to-RADIUS
+   gateway.  The RADIUS side of such a gateway MAY implement RADIUS/TCP,
+   but this change has no effect on Diameter.
+
+4.  Security Considerations
+
+   As the RADIUS packet format, signing, and client verification are
+   unchanged from prior specifications, all of the security issues
+   outlined in previous specifications for RADIUS/UDP are also
+   applicable here.
+
+   As noted above, clients and servers SHOULD support configurable
+   connection limits.  Allowing an unlimited number of connections may
+   result in resource exhaustion.
+
+   Implementors should consult [RFC6614] for issues related to the
+   security of RADIUS/TLS, and [RFC5246] for issues related to the
+   security of the TLS protocol.
+
+
+
+
+DeKok                         Experimental                     [Page 14]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+   Since "bare" TCP does not provide for confidentiality or enable
+   negotiation of credible ciphersuites, its use is not appropriate for
+   inter-server communications where strong security is required.  As a
+   result, "bare" TCP transport MUST NOT be used without TLS, IPsec, or
+   another secure upper layer.
+
+   There are no (at this time) other known security issues for RADIUS-
+   over-TCP transport.
+
+5.  References
+
+5.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.
+
+   [RFC3539]    Aboba, B. and J. Wood, "Authentication, Authorization
+                and Accounting (AAA) Transport Profile", RFC 3539, June
+                2003.
+
+   [RFC5997]    DeKok, A., "Use of Status-Server Packets in the Remote
+                Authentication Dial In User Service (RADIUS) Protocol",
+                RFC 5997, August 2010.
+
+   [RFC6614]    Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
+                "Transport Layer Security (TLS) Encryption for RADIUS",
+                RFC 6614, May 2012.
+
+5.2.  Informative References
+
+   [RFC2866]    Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+   [RFC3579]    Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
+                Dial In User Service) Support For Extensible
+                Authentication Protocol (EAP)", RFC 3579, September
+                2003.
+
+   [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
+                Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4668]    Nelson, D., "RADIUS Authentication Client MIB for IPv6",
+                RFC 4668, August 2006.
+
+
+
+
+
+DeKok                         Experimental                     [Page 15]
+
+RFC 6613                     RADIUS over TCP                    May 2012
+
+
+   [RFC4669]    Nelson, D., "RADIUS Authentication Server MIB for IPv6",
+                RFC 4669, August 2006.
+
+   [RFC4670]    Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC
+                4670, August 2006.
+
+   [RFC4671]    Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC
+                4671, August 2006.
+
+   [RFC4672]    De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS
+                Dynamic Authorization Client MIB", RFC 4672, September
+                2006.
+
+   [RFC4673]    De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS
+                Dynamic Authorization Server MIB", RFC 4673, September
+                2006.
+
+   [RFC5080]    Nelson, D. and A. DeKok, "Common Remote Authentication
+                Dial In User Service (RADIUS) Implementation Issues and
+                Suggested Fixes", RFC 5080, December 2007.
+
+   [RFC5176]    Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
+                Aboba, "Dynamic Authorization Extensions to Remote
+                Authentication Dial In User Service (RADIUS)", RFC 5176,
+                January 2008.
+
+   [RFC5216]    Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
+                Authentication Protocol", RFC 5216, March 2008.
+
+   [RFC5246]    Dierks, T. and E. Rescorla, "The Transport Layer
+                Security (TLS) Protocol Version 1.2", RFC 5246, August
+                2008.
+
+Author's Address
+
+   Alan DeKok
+   The FreeRADIUS Server Project
+   http://freeradius.org/
+
+   EMail: aland@freeradius.org
+
+
+
+
+
+
+
+
+
+
+
+DeKok                         Experimental                     [Page 16]
+