draft-ietf-radext-tcp-transport-01.txt   draft-ietf-radext-tcp-transport-02.txt 
Network Working Group A. DeKok Network Working Group A. DeKok
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Proposed Standard Category: Proposed Standard
<draft-ietf-radext-tcp-transport-01.txt> <draft-ietf-radext-tcp-transport-02.txt>
Expires: June 11, 2009 Expires: June 16, 2009
11 December 2008 16 December 2008
RADIUS Over TCP RADIUS Over TCP
draft-ietf-radext-tcp-transport-01 draft-ietf-radext-tcp-transport-02
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."
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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).
Table of Contents Table of Contents
1. Introduction ............................................. 3 1. Introduction ............................................. 3
1.1. Benefits of Reliable Transport ...................... 3 1.1. Applicability of Reliable Transport ................. 3
1.2. Drawbacks of Reliable Transport ..................... 4 1.2. Terminology ......................................... 5
1.3. Terminology ......................................... 4 1.3. Requirements Language ............................... 5
1.4. Requirements Language ............................... 5
2. Changes to RADIUS ........................................ 5 2. Changes to RADIUS ........................................ 5
2.1. Packet Format ....................................... 5 2.1. Packet Format ....................................... 6
2.2. Assigned Ports for RADIUS Over TCP .................. 6 2.2. Assigned Ports for RADIUS Over TCP .................. 6
2.3. Management Information Base (MIB) ................... 6 2.3. Management Information Base (MIB) ................... 6
2.4. Interaction with RadSec ............................. 7 2.4. Interaction with RadSec ............................. 7
2.4.1. Applicability .................................. 7
2.5. RADIUS Proxies ...................................... 7 2.5. RADIUS Proxies ...................................... 7
2.6. TCP Specific Issues ................................. 8 2.6. TCP Specific Issues ................................. 9
2.6.1. Duplicates and Retransmissions ................. 9 2.6.1. Duplicates and Retransmissions ................. 9
2.6.2. Shared Secrets ................................. 10 2.6.2. Shared Secrets ................................. 10
2.6.3. Malformed Packets and Unknown Clients .......... 10 2.6.3. Malformed Packets and Unknown Clients .......... 11
2.6.4. Limitations of the ID Field .................... 11 2.6.4. Limitations of the ID Field .................... 11
2.6.5. EAP Sessions ................................... 11 2.6.5. EAP Sessions ................................... 12
2.6.6. TCP Applications are not UDP Applications ...... 12 2.6.6. TCP Applications are not UDP Applications ...... 12
3. Diameter Considerations .................................. 12 3. Diameter Considerations .................................. 13
4. IANA Considerations ...................................... 12 4. IANA Considerations ...................................... 13
5. Security Considerations .................................. 12 5. Security Considerations .................................. 13
6. References ............................................... 13 6. References ............................................... 13
6.1. Normative References ................................ 13 6.1. Normative References ................................ 13
6.2. Informative References .............................. 13 6.2. Informative References .............................. 14
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
described in [RFC5080] Section 2.2.1. described in [RFC5080] Section 2.2.1.
* Packet fragmentation. [RFC2865] Section 3 permits RADIUS * Packet fragmentation. [RFC2865] Section 3 permits RADIUS
packets to 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 can
reliably detect when the other is down. This information has to reliably detect when the other is down. This information has to
be deduced instead from the absence of a reply to a request. 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 are relatively minor. However, new
systems may be interested in choosing a different set of trade-offs systems may be interested in choosing a different set of trade-offs
than those outlined in [RFC2865] Section 2.4. For those systems, we than those outlined in [RFC2865] Section 2.4. For those systems, we
define RADIUS over TCP. define RADIUS over TCP.
1.1. Benefits of Reliable Transport 1.1. Applicability of Reliable Transport
The intent of this document is to address transport issues related to
RadSec [RADSEC]. The use of "bare" TCP transport is NOT RECOMMENDED,
as there has been little implementational or operational experience
with it. Additionally, [RFC2865] Section 2.4 contains a list of
reasons why UDP was originally chosen as the transport protocol for
RADIUS. UDP SHOULD 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 There are a number of benefits to using a reliable transport. For
example, when RADIUS is used to carry EAP conversions [RFC3579], the example, when RADIUS is used to carry EAP conversions [RFC3579], the
EAP exchanges may involve 10 round trips at the RADIUS application EAP exchanges may involve 5 round trips at the RADIUS application
layer. If we assume a 0.1% probability of packet loss in each layer. We may assume a probability P of packet loss in each
direction, then approximately 2% (1 - 0.999^20) of the authentication direction (with P having a value of 1% or less). Any one
attempts will have a lost packet. If we assume a 0.01% packet loss, authentication attempt will then have at least one lost packet, with
then 0.2% of authentication attempts will result in a lost packet. 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.
Some implementations are incapable of detecting EAP retransmissions, Some implementations are incapable of detecting EAP retransmissions,
and will instead treat the retransmitted packet as an error. and will instead treat the retransmitted packet as an error.
These retransmissions have a high likelihood of causing the entire These retransmissions have a high likelihood of causing the entire
authentication session to fail. For systems with millions to tens of authentication session to fail. For a system with a million logins a
millions of users, such a high authentication failure rate (0.2% to day, and having a packet loss probability of P=0.01%, we expect that
2%) may be unacceptable. 0.1% of connections will experience a lost packet. That is, 1,000
user sessions each day will experience authentication failure.
In addition, transport of fragmented UDP packets appears to be a In addition, transport of fragmented UDP packets is a poorly tested
poorly tested code path on network devices. Some devices appear to code path on network devices. Some devices appear to be incapable of
be incapable of transporting fragmented UDP packets, meaning that the transporting fragmented UDP packets, meaning that the packet loss
packet loss rate for fragmented packets approaches 100 percent. The rate for fragmented packets approaches 100 percent. The net effect
net effect can be to prevent the deployment of authentication methods can be to prevent the deployment of authentication methods such as
such as EAP-TLS that require large RADIUS packets. EAP-TLS that require large RADIUS packets.
Using a reliable transport method such as TCP means that RADIUS Using a reliable transport method such as TCP means that RADIUS
implementations can remove all application-layer retransmissions, and implementations can remove all application-layer retransmissions, and
instead rely on the Operating System (OS) kernel's well-tested TCP instead rely on the Operating System (OS) kernel's well-tested TCP
transport to ensure reliable delivery. In addition, most TCP transport to ensure reliable delivery. In addition, most TCP
implementations discover Path MTU better than RADIUS application implementations discover Path MTU better than RADIUS application
implementations, resulting in significantly fewer fragmented packets. implementations, resulting in significantly fewer fragmented packets.
Modern TCP implementations also implement anti-spoofing provisions, Modern TCP implementations also implement anti-spoofing provisions,
which is more difficult to do in UDP applications. which is more difficult to do in UDP applications.
Transporting RADIUS over TCP means that the RADIUS applications can Transporting RADIUS over TCP means that the RADIUS applications can
leverage these additional protections offered by TCP. leverage these additional protections offered by TCP.
1.2. Drawbacks of Reliable Transport However, there are also some drawbacks to using TCP. RADIUS over TCP
has some drawbacks, as noted in [RFC2865] Section 2.4. [RFC3539]
No protocol is perfect for all uses. RADIUS over TCP has some Section 2 discusses further issues with using TCP as a transport for
drawbacks, as noted in [RFC2865] Section 2.4. [RFC3539] Section 2
discusses further issues with using TCP as a transport for
Authentication, Authorization, and/or Accounting (AAA) protocols such Authentication, Authorization, and/or Accounting (AAA) protocols such
as RADIUS. as RADIUS.
The impact of these issues is dicussed in more detail below. Specifically, 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 RTT. In those situations,
RADIUS over TCP SHOULD NOT be used.
1.3. Terminology In general, RADIUS clients generating small amounts of RADIUS traffic
SHOULD NOT use TCP. This suggestion will usually apply to most
NASes, and to most clients that originate CoA-Request and Disconnect-
Request packets.
RADIUS over TCP is most applicable to RADIUS proxies that exchange a
large volume of packets with RADIUS clients and servers (10's to
1000's of packets per second). In those situations, RADIUS over TCP
may be a good fit, and may result in increased network stability and
performance.
1.2. Terminology
This document uses the following terms: This document uses the following terms:
RADIUS client RADIUS client
A device that provides an access service for a user to a network. A device that provides an access service for a user to a network.
Also referred to as a Network Access Server, or NAS. Also referred to as a Network Access Server, or NAS.
RADIUS server RADIUS server
A RADIUS authentication, authorization, and/or accounting (AAA) A RADIUS authentication, authorization, and/or accounting (AAA)
server is an entity that provides one or more AAA services to a server is an entity that provides one or more AAA services to a
skipping to change at page 5, line 19 skipping to change at page 5, line 38
RADIUS request packet RADIUS request packet
A packet originated by a RADIUS client to a RADIUS server. e.g. A packet originated by a RADIUS client to a RADIUS server. e.g.
Access-Request, Accounting-Request, CoA-Request, or Disconnect- Access-Request, Accounting-Request, CoA-Request, or Disconnect-
Request. Request.
RADIUS response packet RADIUS response packet
A packet sent by a RADIUS server to a RADIUS client, in response to A packet sent by a RADIUS server to a RADIUS client, in response to
a RADIUS request packet. e.g. Access-Accept, Access-Reject, a RADIUS request packet. e.g. Access-Accept, Access-Reject,
Access-Challenge, Accounting-Response, CoA-ACK, etc. Access-Challenge, Accounting-Response, CoA-ACK, etc.
1.4. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Changes to RADIUS 2. Changes to RADIUS
Adding TCP as a RADIUS transport has a number of impacts on the Adding TCP as a RADIUS transport has a number of impacts on the
protocol, on applications using the protocol, and on networks that protocol, on applications using the protocol, and on networks that
deploy the protocol. In short, RADIUS over TCP is little more than deploy the protocol. In short, RADIUS over TCP is little more than
skipping to change at page 6, line 31 skipping to change at page 6, line 49
Implementations SHOULD use the assigned values as the default ports Implementations SHOULD use the assigned values as the default ports
for RADIUS over TCP. for RADIUS over TCP.
The early deployment of RADIUS was done using UDP port number 1645, The early deployment of RADIUS was done using UDP port number 1645,
which conflicts with the "datametrics" service. Implementations which conflicts with the "datametrics" service. Implementations
using RADIUS over TCP MUST NOT use TCP ports 1645 or 1646 as the using RADIUS over TCP MUST NOT use TCP ports 1645 or 1646 as the
default ports for this specification. default ports for this specification.
2.3. Management Information Base (MIB) 2.3. Management Information Base (MIB)
The MIB definitions in [RFC4668], [RFC4669], [RFC4670], [RFC4671], The MIB Module definitions in [RFC4668], [RFC4669], [RFC4670],
[RFC4672], and [RFC4673] each contain only one reference to UDP. [RFC4671], [RFC4672], and [RFC4673] each contain only one reference
These references are in the DESCRIPTION field of the MIB definition, to UDP. These references are in the DESCRIPTION field of the MIB
and are in the form of "The UDP port" or "the UDP destination port". Module definition, and are in the form of "The UDP port" or "the UDP
destination port".
Implementations of RADIUS over TCP SHOULD re-use these MIBs to Implementations of RADIUS over TCP SHOULD re-use these MIB Modules to
perform statistics counting for RADIUS over TCP connections. perform statistics counting for RADIUS over TCP connections.
However, implementors are warned that there is no way for these MIBs However, implementors are warned that there is no way for these MIB
to distinguish between packets sent over UDP or over TCP transport. Modules to distinguish between packets sent over UDP or over TCP
Similarly, there is no requirement in RADIUS that the RADIUS services transport. Similarly, there is no requirement in RADIUS that the
offered over UDP on a particular IP address and port are identical to RADIUS services offered over UDP on a particular IP address and port
the RADIUS services offered over TCP on a particular IP address and are identical to the RADIUS services offered over TCP on a particular
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. This information can radiusAccClientIdentifier fields of the MIB Module. This information
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 RadSec
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 (i.e. RadSec). The "radius" port (1812/tcp) SHOULD NOT be used for
RadSec. RadSec.
2.4.1. Applicability
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 RTT. In those situations, RADIUS over TCP
SHOULD NOT be used.
In general, RADIUS clients generating small amounts of RADIUS traffic
SHOULD NOT use TCP. This suggestion will usually apply to most
NASes, and to most clients that originate CoA-Request and Disconnect-
Request packets.
RADIUS over TCP is most applicable to RADIUS proxies that exchange a
large volume of packets with RADIUS clients and servers (10's to
1000's of packets per second). In those situations, RADIUS over TCP
is a good fit, and may result in increased network stability and
performance.
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
possible to detect which of the later hops is responsible for the possible to detect which of the later hops is responsible for the
skipping to change at page 8, line 23 skipping to change at page 8, line 25
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 other, non-watchdog requests.
RADIUS clients using RADIUS over TCP MUST NOT decide that a RADIUS clients using RADIUS over TCP MUST NOT decide that a
connection is down until the application layer watchdog algorithm has connection is down until the application layer watchdog algorithm has
marked it DOWN ([RFC3539] Appendix A). RADIUS clients using RADIUS marked it DOWN ([RFC3539] Appendix A). RADIUS clients using RADIUS
over TCP MUST NOT decide that a RADIUS server is unresponsive until over TCP MUST NOT decide that a RADIUS server is unresponsive until
all TCP connections to it have been marked DOWN. all TCP connections to it have been marked DOWN.
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 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 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.
skipping to change at page 10, line 5 skipping to change at page 10, line 34
are in any way related. This requirement does not forbid the are in any way related. This requirement does not forbid the
practice of putting multiple servers into a fail-over or load-balance practice of putting multiple servers into a fail-over or load-balance
pool. 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. (e.g. considered to be a new request, and be treated accordingly. This
header calculations, packet signatures, associated timers and involves updating header calculations, packet signatures, associated
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. 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.3. Malformed Packets and Unknown Clients
The RADIUS specifications ([RFC2865], etc.) say that an implemention The RADIUS specifications ([RFC2865], etc.) say that an
should "silently discard" a packet in a number of circumstances. implementation should "silently discard" a packet in a number of
This action has no further consequences for UDP transport, as the circumstances. This action has no further consequences for UDP
"next" packet is completely independent of the previous one. 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 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 * Packet from an unknown client
* Packet where the RADIUS "length" field is less than the minimim * 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 applicable).
* Packet where the Response Authenticator fails validation * Packet where the Response Authenticator fails validation
(where applicable). (where applicable).
skipping to change at page 11, line 21 skipping to change at page 11, line 51
BE silently discarded. 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.4. Limitations of the ID Field
The RADIUS ID field is one octet in size. As a result, a single TCP The RADIUS ID field is one octet in size. As a result, any one TCP
connection can only send 256 RADIUS request packets at a time. If connection can have only 256 "in flight" RADIUS packets at a time.
those packets are not responded to, no more packets can be sent over
that connection. If more packets need to be sent by a client to a If more than 256 simultaneous "in flight" packets are required,
server, more TCP connections are needed.. This limitation is also additional TCP connections will need to be opened. This limitation
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
noted in [STATUS], the response to a Status-Server packet is either noted in [STATUS], the response to a Status-Server packet is either
an Access-Accept, an Accounting-Response, or a CoA-ACK. If all IDs an Access-Accept or an Accounting-Response. If all IDs were
were allocated to normal requests, then there would be no free Id to allocated to normal requests, then there would be no free Id to use
use for the Status-Server packet, and it could not be sent over the for the Status-Server packet, and it could not be sent over the
connection. connection.
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.
skipping to change at page 12, line 9 skipping to change at page 12, line 38
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 conversation. A simple method that may work in many situations
is to hash the contents of the Calling-Station-Id attribute, which is to hash the contents of the Calling-Station-Id attribute, which
normally contains the MAC address. The output of that hash can be normally contains the MAC address. The output of that hash can be
used to select a particular TCP connection. used to select a particular TCP connection.
If this practice is used, then the client SHOULD also reserve one If this practice is used, then the client SHOULD also reserve one
RADIUS Id per TCP connection for a particular EAP session. RADIUS Id per TCP connection for a particular EAP session.
The retransmission requires of Section 2.6.1, above, MUST be applied The retransmission requirements of Section 2.6.1, above, MUST be
to RADIUS encapsulated EAP packets. That is, EAP retransmissions applied to RADIUS encapsulated EAP packets. That is, EAP
MUST NOT result in retransmissions of RADIUS packets over a retransmissions MUST NOT result in retransmissions of RADIUS packets
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 as per the
algorithm in [RFC3539] Appendix A. algorithm in [RFC3539] Appendix A.
2.6.6. TCP Applications are not UDP Applications 2.6.6. 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
skipping to change at page 14, line 15 skipping to change at page 14, line 44
[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-02.txt, November 2008. ietf-radext-status-server-02.txt, November 2008 (work in
progress).
Acknowledgments [RADSEC] Winter, S. et. al., "TLS encryption for RADIUS over TCP
(RadSec)", draft-ietf-radext-radsec-02.txt, October 2008 (work
in progress).
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. 34 change blocks. 
95 lines changed or deleted 129 lines changed or added

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