draft-ietf-radext-tcp-transport-03.txt   draft-ietf-radext-tcp-transport-04.txt 
Network Working Group A. DeKok Network Working Group A. DeKok
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Proposed Standard Category: Experimental
<draft-ietf-radext-tcp-transport-03.txt> <draft-ietf-radext-tcp-transport-04.txt>
Expires: September 1, 2009 Expires: April 12,2009
1 March 2009 12 October 2009
RADIUS Over TCP RADIUS Over TCP
draft-ietf-radext-tcp-transport-03 draft-ietf-radext-tcp-transport-04
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2009. This Internet-Draft will expire on April 12, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
The Remote Authentication Dial In User Server (RADIUS) Protocol has The Remote Authentication Dial In User Server (RADIUS) Protocol has
traditionally used the User Datagram Protocol (UDP) as it's traditionally used the User Datagram Protocol (UDP) as it's
underlying transport layer. This document defines RADIUS over the underlying transport layer. This document defines RADIUS over the
Transmission Control Protocol (TCP). Transmission Control Protocol (TCP), in order to address transport
issues related to RADIUS over TLS [RTLS]. It is not intended to
define TCP as a transport protocol for RADIUS in the absence of TLS.
Table of Contents Table of Contents
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Applicability of Reliable Transport ................. 4 1.1. Applicability of Reliable Transport ................. 4
1.2. Terminology ......................................... 6 1.2. Terminology ......................................... 6
1.3. Requirements Language ............................... 6 1.3. Requirements Language ............................... 7
2. Changes to RADIUS ........................................ 6 2. Changes to RADIUS ........................................ 7
2.1. Packet Format ....................................... 7 2.1. Packet Format ....................................... 7
2.2. Assigned Ports for RADIUS Over TCP .................. 7 2.2. Assigned Ports for RADIUS Over TCP .................. 8
2.3. Management Information Base (MIB) ................... 7 2.3. Management Information Base (MIB) ................... 8
2.4. Interaction with RadSec ............................. 8 2.4. Interaction with RADIUS over TLS .................... 9
2.5. RADIUS Proxies ...................................... 8 2.5. RADIUS Proxies ...................................... 9
2.6. TCP Specific Issues ................................. 10 2.6. TCP Specific Issues ................................. 10
2.6.1. Duplicates and Retransmissions ................. 10 2.6.1. Duplicates and Retransmissions ................. 11
2.6.2. Shared Secrets ................................. 11 2.6.2. Head of Line Blocking .......................... 12
2.6.3. Malformed Packets and Unknown Clients .......... 12 2.6.3. Shared Secrets ................................. 12
2.6.4. Limitations of the ID Field .................... 12 2.6.4. Malformed Packets and Unknown Clients .......... 13
2.6.5. EAP Sessions ................................... 13 2.6.5. Limitations of the ID Field .................... 13
2.6.6. TCP Applications are not UDP Applications ...... 13 2.6.6. EAP Sessions ................................... 14
3. Diameter Considerations .................................. 14 2.6.7. TCP Applications are not UDP Applications ...... 15
4. IANA Considerations ...................................... 14 3. Diameter Considerations .................................. 15
5. Security Considerations .................................. 14 4. IANA Considerations ...................................... 15
6. References ............................................... 14 5. Security Considerations .................................. 15
6.1. Normative References ................................ 14 6. References ............................................... 16
6.2. Informative References .............................. 15 6.1. Normative References ................................ 16
6.2. Informative References .............................. 16
1. Introduction 1. Introduction
The RADIUS Protocol has been defined in [RFC2865] as using the User The RADIUS Protocol has been defined in [RFC2865] as using the User
Datagram Protocol (UDP) for the underlying transport layer. While Datagram Protocol (UDP) for the underlying transport layer. While
there are a number of benefits to using UDP as outlined in [RFC2865] there are a number of benefits to using UDP as outlined in [RFC2865]
Section 2.4, there are also some limitations: Section 2.4, there are also some limitations:
* Unreliable transport. As a result, systems using RADIUS have to * Unreliable transport. As a result, systems using RADIUS have to
implement application-layer timers and re-transmissions, as implement application-layer timers and re-transmissions, as
skipping to change at page 4, line 25 skipping to change at page 4, line 25
* Packet fragmentation. [RFC2865] Section 3 permits RADIUS * Packet fragmentation. [RFC2865] Section 3 permits RADIUS
packets up to 4096 octets in length. These packets are larger packets up to 4096 octets in length. These packets are larger
than the default Internet MTU (576), resulting in fragmentation of than the default Internet MTU (576), resulting in fragmentation of
the packets at the IP layer. Transport of fragmented UDP packets the packets at the IP layer. Transport of fragmented UDP packets
appears to be a poorly tested code path on network devices. Some appears to be a poorly tested code path on network devices. Some
devices appear to be incapable of transporting fragmented UDP devices appear to be incapable of transporting fragmented UDP
packets, making it difficult to deploy RADIUS in a network where packets, making it difficult to deploy RADIUS in a network where
those devices are deployed. those devices are deployed.
* Connectionless transport. Neither clients nor servers can * Connectionless transport. Neither clients nor servers receive
reliably detect when the other is down. This information has to positive statements that a "connection" is down. This information
be deduced instead from the absence of a reply to a request. has to be deduced instead from the absence of a reply to a
request.
As RADIUS is widely deployed, and has been widely deployed for well As RADIUS is widely deployed, and has been widely deployed for well
over a decade, these issues are relatively minor. However, new over a decade, these issues have been minor in some use-cases, and
systems may be interested in choosing a different set of trade-offs problematic in others.. New systems may be interested in choosing a
than those outlined in [RFC2865] Section 2.4. For those systems, we different set of trade-offs than those outlined in [RFC2865] Section
define RADIUS over TCP. 2.4. New systems may also be interested in choosing a more reliable
transport for use-cases such as inter-server proxying. For those
systems, we define RADIUS over TCP
1.1. Applicability of Reliable Transport 1.1. Applicability of Reliable Transport
The intent of this document is to address transport issues related to The intent of this document is to address transport issues related to
RadSec [RADSEC]. The use of "bare" TCP transport is NOT RECOMMENDED, RADIUS over TLS [RTLS]. The use of "bare" TCP transport (i.e.
as there has been little implementational or operational experience without TLS) is NOT RECOMMENDED, as there has been little
with it. Additionally, [RFC2865] Section 2.4 contains a list of implementational or operational experience with it. Additionally,
reasons why UDP was originally chosen as the transport protocol for [RFC2865] Section 2.4 contains a list of reasons why UDP was
RADIUS. UDP SHOULD be used as transport protocol in all cases where originally chosen as the transport protocol for RADIUS. UDP SHOULD
the rationale given in [RFC2865] Section 2.4 applies. be used as transport protocol in all cases where the rationale given
in [RFC2865] Section 2.4 applies.
There are a number of benefits to using a reliable transport. For Deployment experience with RADIUS over TLS indicates that it is most
example, when RADIUS is used to carry EAP conversions [RFC3579], the useful for inter-server communication, such as inter-domain
EAP exchanges may involve 5 round trips at the RADIUS application 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.
RADIUS over TCP has a similar set of use cases. Use of TCP as a
transport between a NAS and RADIUS server is a poor fit, since as
noted in [RFC3539], there is likely to be insufficient traffic for
the congestion window to remain above 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 server-server communications the traffic levels in both directions
are typically high enough to support a larger congestion window as
well as ACK piggy-backing. 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.
However, in these scenarios "bare" TCP does not provide for
confidentiality or enable negotiation of stronger ciphersuites than
are available in RADIUS.
As a result of these considerations, use of RADIUS over TCP SHOULD be
restricted to situations where RADIUS over TLS is employed. RADIUS
over "bare" TCP is NOT RECOMMENDED.
There are still a number of benefits to using a reliable transport.
For example, when RADIUS is used to carry EAP conversions [RFC3579],
the EAP exchanges may involve 5 round trips at the RADIUS application
layer. We may assume a probability P of packet loss in each layer. We may assume a probability P of packet loss in each
direction (with P having a value of 1% or less). Any one direction (with P having a value of 1% or less). Any one
authentication attempt will then have at least one lost packet, with authentication attempt will then have at least one lost packet, with
a probability of approximately (10 * P). a probability of approximately (10 * P).
These lost packets require the supplicant and/or the NAS to re- These lost packets require the supplicant and/or the NAS to re-
transmit packets at the application layer. The difficulty with this transmit packets at the application layer. The difficulty with this
approach is that retransmission implementations have historically approach is that retransmission implementations have historically
been poor. Some implementations retransmit packets, others do not, been poor. Some implementations retransmit packets, others do not,
and others send new packets rather then performing retransmission. and others send new packets rather then performing retransmission.
skipping to change at page 8, line 23 skipping to change at page 9, line 7
are identical to the RADIUS services offered over TCP on a particular are identical to the RADIUS services offered over TCP on a particular
IP address and the same (numerical) port. IP address and the same (numerical) port.
Implementations of RADIUS over TCP SHOULD include the protocol (UDP) Implementations of RADIUS over TCP SHOULD include the protocol (UDP)
or (TCP) in the radiusAuthServIdent, radiusAuthClientID, or (TCP) in the radiusAuthServIdent, radiusAuthClientID,
radiusAuthClientIdentifier, radiusAccServIdent, radiusAccClientID, or radiusAuthClientIdentifier, radiusAccServIdent, radiusAccClientID, or
radiusAccClientIdentifier fields of the MIB Module. This information radiusAccClientIdentifier fields of the MIB Module. This information
can help the administrator distinguish capabilities of systems in the can help the administrator distinguish capabilities of systems in the
network. network.
2.4. Interaction with RadSec 2.4. Interaction with RADIUS over TLS
IANA has already assigned TCP ports for RadSec (i.e. RADIUS over TLS IANA has already assigned TCP ports for RadSec (i.e. RADIUS over TLS
over TCP), as outlined below: over TCP), as outlined below:
* radsec 2083/tcp * radsec 2083/tcp
This value SHOULD be used as the default port for RADIUS over TLS This value SHOULD be used as the default port for RADIUS over TLS.
(i.e. RadSec). The "radius" port (1812/tcp) SHOULD NOT be used for The "radius" port (1812/tcp) SHOULD NOT be used for RADIUS over TLS.
RadSec.
2.5. RADIUS Proxies 2.5. RADIUS Proxies
As RADIUS is a "hop by hop" protocol, a RADIUS proxy effectively As RADIUS is a "hop by hop" protocol, a RADIUS proxy effectively
shields the client from any information about downstream servers. shields the client from any information about downstream servers.
While the client may be able to deduce the operational state of the 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 local server (i.e. proxy), it cannot make any determination about the
operational state of the downstream servers. operational state of the downstream servers.
If a request is proxied through intermediate proxies, it is not If a request is proxied through intermediate proxies, it is not
skipping to change at page 9, line 17 skipping to change at page 9, line 47
This situation is made even worse when requests are sent through a This situation is made even worse when requests are sent through a
proxy to multiple destinations. Failures in one destination may proxy to multiple destinations. Failures in one destination may
result in service outages for other destinations, if the client result in service outages for other destinations, if the client
erroneously believes that the proxy is unresponsive. erroneously believes that the proxy is unresponsive.
For RADIUS over TCP, the continued existence of the TCP connection For RADIUS over TCP, the continued existence of the TCP connection
SHOULD be used to deduce that the service on the other end of the SHOULD be used to deduce that the service on the other end of the
connection is still responsive. Further, the application layer connection is still responsive. Further, the application layer
watchdog defined in [RFC3539] Section 3.4 enables clients to watchdog defined in [RFC3539] Section 3.4 enables clients to
determine that the server is "live", even though it may not have determine that the server is "live", even though it may not have
responded recently to other, non-watchdog requests. responded recently to non-watchdog requests.
RADIUS clients using RADIUS over TCP MUST NOT decide that a RADIUS clients using RADIUS over TCP MUST mark a connection DOWN if
connection is down until the application layer watchdog algorithm has the network stack indicates that the connection is no longer active.
marked it DOWN ([RFC3539] Appendix A). RADIUS clients using RADIUS If the network stack indicates that connection is still active,
over TCP MUST NOT decide that a RADIUS server is unresponsive until Clients MUST NOT decide that it is down until the application layer
all TCP connections to it have been marked DOWN. watchdog algorithm has marked it DOWN ([RFC3539] Appendix A). RADIUS
clients using RADIUS over 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 pro-
actively closing connections, or marking a server as DOWN due to an
administrative decision.
Additional issues with RADIUS proxies involve transport protocol Additional issues with RADIUS proxies involve transport protocol
changes where the proxy receives packets on one transport protocol, changes where the proxy receives packets on one transport protocol,
and forwards them on a different transport protocol. There are and forwards them on a different transport protocol. There are
several situations in which the law of "conservation of packets" 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 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): could enter the system than could leave it on a short-term basis):
* Where TCP is used between proxies, it is possible that the * Where TCP is used between proxies, it is possible that the
bandwidth consumed by incoming UDP packets destined to a given bandwidth consumed by incoming UDP packets destined to a given
skipping to change at page 10, line 15 skipping to change at page 10, line 50
2.6. TCP Specific Issues 2.6. TCP Specific Issues
The guidelines defined in [RFC3539] for implementing an AAA protocol The guidelines defined in [RFC3539] for implementing an AAA protocol
operating over a reliable transport MUST be followed by implementors operating over a reliable transport MUST be followed by implementors
of this specification. of this specification.
The Application Layer Watchdog defined in [RFC3539] Section 3.4 MUST The Application Layer Watchdog defined in [RFC3539] Section 3.4 MUST
be used. The Status-Server packet [STATUS] MUST be used as the be used. The Status-Server packet [STATUS] MUST be used as the
application layer watchdog message. Implementations MUST reserve one application layer watchdog message. Implementations MUST reserve one
RADIUS ID per connection for the application layer watchdog message. RADIUS ID per connection for the application layer watchdog message.
This restriction is described further below. This restriction is described further below in Section 2.6.4.
Implementations MUST NOT confuse UDP and TCP transport. That is, Implementations MUST NOT confuse UDP and TCP transport. That is,
RADIUS clients and servers MUST be treated as unique based on a key RADIUS clients and servers MUST be treated as unique based on a key
of the three-tuple (IP address, port, transport protocol). of the three-tuple (IP address, port, transport protocol).
Implementations MUST be configurable to have different shared secrets Implementations MUST permit different shared secrets to be used for
for UDP and TCP to the same destination IP address and numerical UDP and TCP connections to the same destination IP address and
port. numerical port.
This requirement does not forbid the traditional practice of using This requirement does not forbid the traditional practice of using
primary and secondary servers in a fail-over relationship. Instead, primary and secondary servers in a fail-over relationship. Instead,
it requires that two services sharing an IP address and numerical it requires that two services sharing an IP address and numerical
port, but differing in transport protocol, MUST be treated as port, but differing in transport protocol, MUST be treated as
independent services for the purpose of fail-over, load-balancing, independent services for the purpose of fail-over, load-balancing,
etc. etc.
Whenever the underlying operating system permits the use of TCP Whenever the underlying network stack permits the use of TCP
keepalive socket options, their use is RECOMMENDED. keepalive socket options, their use is RECOMMENDED.
2.6.1. Duplicates and Retransmissions 2.6.1. Duplicates and Retransmissions
As TCP is a reliable transport, implementors of this specification As TCP is a reliable transport, implementations MUST NOT retransmit
MUST NOT retransmit RADIUS request packets over the same TCP RADIUS request packets over a given TCP connection. Similarly, if
connection. Similarly, if there is no response to a RADIUS packet there is no response to a RADIUS packet over one TCP connection,
over one TCP connection, implementations MUST NOT retransmit that implementations MUST NOT retransmit that packet over a different TCP
packet over a different TCP connection to the same destination IP connection to the same destination IP address and port, while the
address and port, while the first connection is in the OKAY state first connection is in the OKAY state ([RFC3539] Appendix A).
([RFC3539] Appendix A).
However, if the TCP connection is broken or closed, retransmissions However, if the TCP connection is broken or closed, retransmissions
over new connections are permissible. RADIUS request packets that over new connections are permissible. RADIUS request packets that
have not yet received a response MAY be transmitted by a RADIUS have not yet received a response MAY be transmitted by a RADIUS
client over a new TCP connection. As this procedure involves using a 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, new source port, the ID of the packet MAY change. If the ID changes,
any security attributes such as Message-Authenticator MUST be any security attributes such as Message-Authenticator MUST be
recalculated. recalculated.
If a TCP connection is broken or closed, any cached RADIUS response If a TCP connection is broken or closed, any cached RADIUS response
skipping to change at page 11, line 24 skipping to change at page 12, line 11
the proxy. the proxy.
Despite the above discussion, RADIUS servers SHOULD still perform Despite the above discussion, RADIUS servers SHOULD still perform
duplicate detection on received packets, as described in [RFC5080] duplicate detection on received packets, as described in [RFC5080]
Section 2.2.2. This detection can prevent duplicate processing of Section 2.2.2. This detection can prevent duplicate processing of
packets from non-conformant clients. packets from non-conformant clients.
As noted previously, RADIUS packets SHOULD NOT be re-transmitted to As noted previously, RADIUS packets SHOULD NOT be re-transmitted to
the same destination IP and numerical port, but over a different the same destination IP and numerical port, but over a different
transport layer. There is no guarantee in RADIUS that the two ports transport layer. There is no guarantee in RADIUS that the two ports
are in any way related. This requirement does not forbid the are in any way related. This requirement does not, however, forbid
practice of putting multiple servers into a fail-over or load-balance the practice of putting multiple servers into a fail-over or load-
pool. balance pool.
Much of the discussion in this section can be summarized by the Much of the discussion in this section can be summarized by the
following requirement. RADIUS requests MAY be re-transmitted following requirement. RADIUS requests MAY be re-transmitted
verbatim only if the following 5-tuple (Client IP address, Client verbatim only if the following 5-tuple (Client IP address, Client
port, Transport Protocol, Server IP address, Server port) remains the port, Transport Protocol, Server IP address, Server port) remains the
same. If any field of that 5-tuple changes, the packet MUST NOT be same. If any field of that 5-tuple changes, the packet MUST NOT be
considered to be a re-transmission. Instead, the packet MUST be considered to be a re-transmission. Instead, the packet MUST be
considered to be a new request, and be treated accordingly. This considered to be a new request, and be treated accordingly. This
involves updating header calculations, packet signatures, associated involves updating header calculations, packet signatures, associated
timers and counters, etc. timers and counters, etc.
The above requirement is necessary, but not sufficient in all cases. The above requirement is necessary, but not sufficient in all cases.
Other specifications give additional situations where the packet is Other specifications give additional situations where the packet is
to be considered as a new request. Those recommendations MUST also to be considered as a new request. Those recommendations MUST also
be followed. be followed.
2.6.2. Shared Secrets 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 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 over TCP.
2.6.3. Shared Secrets
The use of shared secrets in calculating the Response Authenticator, The use of shared secrets in calculating the Response Authenticator,
and other attributes such as User-Password or Message-Authenticator and other attributes such as User-Password or Message-Authenticator
[RFC3579] MUST be unchanged from previous specifications. [RFC3579] MUST be unchanged from previous specifications.
Clients and servers MUST be able to store and manage shared secrets Clients and servers MUST be able to store and manage shared secrets
based on the key described above, of (IP address, port, transport based on the key described above, of (IP address, port, transport
protocol). protocol).
2.6.3. Malformed Packets and Unknown Clients 2.6.4. Malformed Packets and Unknown Clients
The RADIUS specifications ([RFC2865], etc.) say that an The RADIUS specifications ([RFC2865], etc.) say that an
implementation should "silently discard" a packet in a number of implementation should "silently discard" a packet in a number of
circumstances. This action has no further consequences for UDP circumstances. This action has no further consequences for UDP
transport, as the "next" packet is completely independent of the transport, as the "next" packet is completely independent of the
previous one. previous one.
When TCP is used as a transport, decoding the "next" packet on a When TCP is used as a transport, decoding the "next" packet on a
connection depends on the proper decoding of the previous packet. As connection depends on the proper decoding of the previous packet. As
a result, the behavior with respect to discarded packets has to a result, the behavior with respect to discarded packets has to
change. change.
Implementations of this specification SHOULD treat the "silently Implementations of this specification SHOULD treat the "silently
discard" texts referenced above as "silently discard and close the discard" texts referenced above as "silently discard and close the
connection." That is, the TCP connection MUST be closed if any of connection." That is, the TCP connection MUST be closed if any of
the following circumstances are seen: the following circumstances are seen:
* Packet from an unknown client * Connection from an unknown client
* Packet where the RADIUS "length" field is less than the minimum * Packet where the RADIUS "length" field is less than the minimum
RADIUS packet length RADIUS packet length
* Packet where the RADIUS "length" field is more than the maximum * Packet where the RADIUS "length" field is more than the maximum
RADIUS packet length RADIUS packet length
* Packet that has an Attribute "length" field has value of zero * Packet that has an Attribute "length" field has value of zero
or one (0 or 1). or one (0 or 1).
* Packet where the attributes do not exactly fill the packet * Packet where the attributes do not exactly fill the packet
* Packet where the Request Authenticator fails validation * Packet where the Request Authenticator fails validation
(where applicable). (where validation is required).
* Packet where the Response Authenticator fails validation * Packet where the Response Authenticator fails validation
(where applicable). (where validation is required).
* Packet where the Message-Authenticator attribute fails * Packet where the Message-Authenticator attribute fails
validation (where applicable). validation (when it occurs in a packet).
TCP connections MAY be closed if any of the following circumstances TCP connections MAY be closed if any of the circumstances outlined
are seen. Alternatively, the TCP connection MAY remain open if any below are seen. Alternatively, the TCP connection MAY remain open if
of the following circumstances are seen, but the invalid packet MUST any of the following circumstances are seen, but the invalid packet
BE silently discarded. MUST BE silently discarded.
* Packet with an invalid code field * Packet with an invalid code field
* Response packets that do not match any outstanding request * Response packets that do not match any outstanding request
These requirements minimize the possibility for a misbehaving client These requirements minimize the possibility for a misbehaving client
or server to wreak havoc on the network. or server to wreak havoc on the network.
2.6.4. Limitations of the ID Field 2.6.5. Limitations of the ID Field
The RADIUS ID field is one octet in size. As a result, any one TCP 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. connection can have only 256 "in flight" RADIUS packets at a time.
If more than 256 simultaneous "in flight" packets are required, If more than 256 simultaneous "in flight" packets are required,
additional TCP connections will need to be opened. This limitation additional TCP connections will need to be opened. This limitation
is also noted in [RFC3539] Section 2.4. is also noted in [RFC3539] Section 2.4.
An additional limit is the requirement to send a Status-Server packet An additional limit is the requirement to send a Status-Server packet
over the same TCP connection as is used for normal requests. As over the same TCP connection as is used for normal requests. As
skipping to change at page 13, line 26 skipping to change at page 14, line 26
Implementations SHOULD reserve ID zero on each TCP connection for Implementations SHOULD reserve ID zero on each TCP connection for
Status-Server packets. This value was picked arbitrarily, as there Status-Server packets. This value was picked arbitrarily, as there
is no reason to choose any one value over another for this use. 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 Implementors may be tempted to extend RADIUS to permit more than 256
outstanding packets on one connection. However, doing so will likely outstanding packets on one connection. However, doing so will likely
require fundamental changes to the RADIUS protocol, and as such, is require fundamental changes to the RADIUS protocol, and as such, is
outside of the scope of this specification. outside of the scope of this specification.
2.6.5. EAP Sessions 2.6.6. EAP Sessions
When RADIUS clients send EAP requests using RADIUS over TCP, they When RADIUS clients send EAP requests using RADIUS over TCP, they
SHOULD choose the same TCP connection for all packets related to one SHOULD choose the same TCP connection for all packets related to one
EAP conversation. A simple method that may work in many situations EAP session. This practice ensures that EAP packets are transmitted
is to hash the contents of the Calling-Station-Id attribute, which in order, and that problems with any one TCP connection do affect the
normally contains the MAC address. The output of that hash can be minimum number of EAP sessions.
used to select a particular TCP connection.
If this practice is used, then the client SHOULD also reserve one A simple method that may work in many situations is to hash the
RADIUS Id per TCP connection for a particular EAP session. contents of the Calling-Station-Id attribute, which normally contains
the 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 source port and transport
protocol.
The retransmission requirements of Section 2.6.1, above, MUST be The retransmission requirements of Section 2.6.1, above, MUST be
applied to RADIUS encapsulated EAP packets. That is, EAP applied to RADIUS encapsulated EAP packets. That is, EAP
retransmissions MUST NOT result in retransmissions of RADIUS packets retransmissions MUST NOT result in retransmissions of RADIUS packets
over a particular TCP connection. EAP retransmissions MAY result in over a particular TCP connection. EAP retransmissions MAY result in
retransmission of RADIUS packets over a different TCP connection, but retransmission of RADIUS packets over a different TCP connection, but
only when the previous TCP connection is marked DOWN as per the only when the previous TCP connection is marked DOWN.
algorithm in [RFC3539] Appendix A.
2.6.6. TCP Applications are not UDP Applications 2.6.7. TCP Applications are not UDP Applications
Implementors should be aware that programming a robust TCP Implementors should be aware that programming a robust TCP
application can be very different from programming a robust UDP application can be very different from programming a robust UDP
application. We RECOMMEND that implementors of this specification application. We RECOMMEND that implementors of this specification
familiarize themselves with TCP application programming concepts. We familiarize themselves with TCP application programming concepts. We
RECOMMEND also that existing TCP applications be examined with an eye RECOMMEND also that existing TCP applications be examined with an eye
to robustness, performance, scalability, etc. to robustness, performance, scalability, etc.
Clients and servers SHOULD implement configurable connection limits. Clients and servers SHOULD implement configurable connection limits.
Clients and servers SHOULD implement configurable rate limiting on Clients and servers SHOULD implement configurable rate limiting on
skipping to change at page 15, line 44 skipping to change at page 17, line 7
[RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In
User Service (RADIUS) Implementation Issues and Suggested User Service (RADIUS) Implementation Issues and Suggested
Fixes", RFC 5080, December 2007. Fixes", RFC 5080, December 2007.
[RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176, Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008. January 2008.
[STATUS] DeKok, A., "Use of Status-Server Packets in the Remote [STATUS] DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dial In User Service (RADIUS) Protocol", draft- Authentication Dial In User Service (RADIUS) Protocol", draft-
ietf-radext-status-server-03.txt, March 2009 (work in ietf-radext-status-server-04.txt, October 2009 (work in
progress). progress).
[RADSEC] Winter, S. et. al., "TLS encryption for RADIUS over TCP [RTLS] Winter, S. et. al., "TLS encryption for RADIUS over TCP
(RadSec)", draft-ietf-radext-radsec-03.txt, Februrary 2009 (RadSec)", draft-ietf-radext-radsec-05.txt, July 2009 (work in
(work in progress). progress).
Acknowledgments Acknowledgments
None at this time. None at this time.
Authors' Addresses Authors' Addresses
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
http://freeradius.org/ http://freeradius.org/
Email: aland@freeradius.org Email: aland@freeradius.org
 End of changes. 38 change blocks. 
103 lines changed or deleted 154 lines changed or added

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