draft-ietf-radext-fixes-01.txt   draft-ietf-radext-fixes-02.txt 
Network Working Group David Nelson Network Working Group David Nelson
INTERNET-DRAFT Individual contributor INTERNET-DRAFT Individual contributor
Updates: 2865, 2866, 2869, 3576, 3579 Alan DeKok Updates: 2865, 2866, 2869, 3579 Alan DeKok
Category: Proposed Standard FreeRADIUS Category: Proposed Standard FreeRADIUS
<draft-ietf-radext-fixes-01.txt> <draft-ietf-radext-fixes-02.txt>
13 February 2007
Common RADIUS Implementation Issues and Suggested Fixes Common RADIUS Implementation Issues and Suggested Fixes
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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-
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes common issues seen in RADIUS implementations This document describes common issues seen in RADIUS implementations
and suggests some fixes. Where applicable, ambiguities and errors in and suggests some fixes. Where applicable, ambiguities and errors in
previous RADIUS specifications are clarified. previous RADIUS specifications are clarified.
Table of Contents Table of Contents
1. Introduction ............................................. 2 1. Introduction ............................................. 3
1.1. Terminology ......................................... 2 1.1. Terminology ......................................... 3
1.2. Requirements Language ............................... 2 1.2. Requirements Language ............................... 3
2. Issues ................................................... 3 2. Issues ................................................... 4
2.1. Session Definition .................................. 3 2.1. Session Definition .................................. 4
2.1.1. State Attribute ................................ 3 2.1.1. State Attribute ................................ 4
2.1.2. Request-ID Supplementation ..................... 4 2.1.2. Request-ID Supplementation ..................... 5
2.2. Overload Conditions ................................. 4 2.2. Overload Conditions ................................. 6
2.2.1. Retransmission Behavior ........................ 4 2.2.1. Retransmission Behavior ........................ 6
2.2.2. Server Response to Overload .................... 5 2.2.2. Duplicate detection and orderly delivery. ...... 6
2.3. Accounting Issues ................................... 6 2.2.3. Server Response to Overload .................... 7
2.3.1. Attributes allowed in an Interim Update ........ 6 2.3. Accounting Issues ................................... 8
2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 6 2.3.1. Attributes allowed in an Interim Update ........ 8
2.3.3. Request Authenticator .......................... 6 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 8
2.3.4. Interim-Accounting-Interval .................... 7 2.3.3. Request Authenticator .......................... 9
2.3.5. Counter values in the RADIUS MIBs .............. 7 2.3.4. Interim-Accounting-Interval .................... 9
2.4. Multiple Filter-ID Attributes ....................... 9 2.3.5. Counter values in the RADIUS MIBs .............. 10
2.5. Mandatory and Optional Attributes ................... 9 2.4. Multiple Filter-ID Attributes ....................... 11
2.6. Interpretation of Access-Reject ..................... 11 2.5. Mandatory and Optional Attributes ................... 12
2.6.1. Improper Use of Access-Reject .................. 11 2.6. Interpretation of Access-Reject ..................... 13
2.6.2. Service Request Denial ......................... 12 2.6.1. Improper Use of Access-Reject .................. 13
2.7. Addressing .......................................... 13 2.6.2. Service Request Denial ......................... 15
2.7.1. Link-Local Addresses ........................... 13 2.7. Addressing .......................................... 15
2.7.2. Multiple Addresses ............................. 13 2.7.1. Link-Local Addresses ........................... 15
2.8. Idle-Timeout ........................................ 14 2.7.2. Multiple Addresses ............................. 16
2.9. Unknown Identity .................................... 14 2.8. Idle-Timeout ........................................ 16
2.10. Responses after retransmissions .................... 15 2.9. Unknown Identity .................................... 17
2.11. Framed-IPv6-Prefix ................................. 16 2.10. Responses after retransmissions .................... 18
3. IANA Considerations ...................................... 17 2.11. Framed-IPv6-Prefix ................................. 18
4. Security Considerations .................................. 17 3. IANA Considerations ...................................... 20
5. References ............................................... 17 4. Security Considerations .................................. 20
5.1. Normative references. ............................... 17 5. References ............................................... 20
5.2. Informative references. ............................. 18 5.1. Normative references. ............................... 20
Intellectual Property Statement .............................. 19 5.2. Informative references. ............................. 20
Disclaimer of Validity ....................................... 21 6. RFC Editor instructions .................................. 21
Full Copyright Statement ..................................... 21 Intellectual Property Statement .............................. 22
Disclaimer of Validity ....................................... 23
Full Copyright Statement ..................................... 23
1. Introduction 1. Introduction
The last few years have seen an increase in the deployment of RADIUS The last few years have seen an increase in the deployment of RADIUS
clients and servers. This document describes common issues seen in clients and servers. This document describes common issues seen in
RADIUS implementations and suggests some fixes. Where applicable, RADIUS implementations and suggests some fixes. Where applicable,
ambiguities and errors in previous RADIUS specifications are ambiguities and errors in previous RADIUS specifications are
clarified. clarified.
1.1. Terminology 1.1. Terminology
skipping to change at page 5, line 45 skipping to change at page 5, line 45
insert session into "active session" table with insert session into "active session" table with
key=(EAP identifier, State, source IP) key=(EAP identifier, State, source IP)
} else { } else {
look up active session in table, with above key look up active session in table, with above key
} }
This algorithm appears to work well in variety of situations, This algorithm appears to work well in variety of situations,
including situations where home servers receive messages via including situations where home servers receive messages via
intermediate RADIUS proxies. intermediate RADIUS proxies.
Implementations that do not use this algorithm are often restricted
to having an EAP Identifier space per NAS, or perhaps one that is
global to the implementation. These restrictions are unnecessary
when the above algorithm is used, which gives each session a unique
EAP Identifier space. The above algorithm SHOULD be used to track
EAP sessions in preference to any other method.
2.2. Overload Conditions 2.2. Overload Conditions
2.2.1. Retransmission Behavior 2.2.1. Retransmission Behavior
[RFC2865] Section 2.4 describes the retransmission requirements for [RFC2865] Section 2.4 describes the retransmission requirements for
RADIUS clients: RADIUS clients:
At one extreme, RADIUS does not require a "responsive" detection At one extreme, RADIUS does not require a "responsive" detection
of lost data. The user is willing to wait several seconds for the of lost data. The user is willing to wait several seconds for the
authentication to complete. The generally aggressive TCP authentication to complete. The generally aggressive TCP
skipping to change at page 6, line 38 skipping to change at page 6, line 47
[b] Congestive backoff. While it is not necessary for RADIUS client [b] Congestive backoff. While it is not necessary for RADIUS client
implementations to implement complex retransmission algorithms, implementations to implement complex retransmission algorithms,
implementations SHOULD support congestive backoff within the limits implementations SHOULD support congestive backoff within the limits
suggested by [RFC2865] Section 2.4. For example, an implementation suggested by [RFC2865] Section 2.4. For example, an implementation
SHOULD double the initial retransmission timer until a maximum SHOULD double the initial retransmission timer until a maximum
retransmission time is reached, after which the client will retransmission time is reached, after which the client will
failover to another RADIUS server. For example, if the initial failover to another RADIUS server. For example, if the initial
retransmission timer is one second, a maximum retransmission timer retransmission timer is one second, a maximum retransmission timer
of 16 seconds might be used. of 16 seconds might be used.
2.2.2. Server Response to Overload 2.2.2. Duplicate detection and orderly delivery.
When packets are retransmitted by a client, the server may receive
duplicate requests. The limitations of the transport protocol used
by RADIUS (UDP) means that the Access-Request packets may be
received, and potentially processed, in an order different from the
order in which the packets were sent. However, the discussion of the
Identifier field in Section 3 of [RFC2865] suys:
The RADIUS server can detect a duplicate request if it has the
same client source IP address and source UDP port and Identifier
within a short span of time.
Also, Section 7 of [RFC4669] defines a
radiusAuthServDupAccessRequests object, as
The number of duplicate Access-Request packets received.
This text has a number of implications. First, without duplicate
detection, a RADIUS server may process an authentication request
twice, leading to an erroneous conclusion that a user has logged in
twice. That behavior is undesirable, so duplicate detection is
desirable. Second, the server may track not only the duplicate
request, but also the replies to those requests. This behavior
permits the server to send duplicate replies in response to duplicate
requests, increasing network stability.
Since Access-Request packets may also be sent by the client in
response to an Access-Challenge from the server, those packets form a
logically ordered stream, and therefore have additional ordering
requirements over Access-Request packets for different sessions.
Implementing duplicate detection results in new packets being
processed only once, ensuring order.
RADIUS servers MUST therefore implement duplicate detection for
Access-Request packets, as described in Section 3 of [RFC2865].
Implementations MUST also cache the Responses (Access-Accept, Access-
Challenge, or Access-Reject) that is sends for those Access-Request
packets. If a server receives a valid duplicate Access-Request for
which is already has sent a Response, it MUST resend its original
Response without reprocessing the request. The server MUST silently
discard any duplicate Access-Requests for which a Response has not
been sent yet.
Each cache entry SHOULD be purged after a period of time. This time
SHOULD be no less than 5 seconds, and no more than 30 seconds.
Cache entries MUST also be purged if the server receives an Access-
Request packet that matches a cached Access-Request packet in source
address, source port, RADIUS Identifier, and receiving socket, but
where the Request Authenticator field is different from the one in
the cached packet.
2.2.3. Server Response to Overload
Some RADIUS server implementations are not robust in response to Some RADIUS server implementations are not robust in response to
overload, dropping packets with even probability across multiple overload, dropping packets with even probability across multiple
sessions. In an overload situation, this results in a high failure sessions. In an overload situation, this results in a high failure
rate for multi-round authentication protocols such as EAP [RFC3579]. rate for multi-round authentication protocols such as EAP [RFC3579].
Typically, users will continually retry in an attempt to gain access, Typically, users will continually retry in an attempt to gain access,
increasing the load even further. increasing the load even further.
A more sensible approach is for a RADIUS server to preferentially A more sensible approach is for a RADIUS server to preferentially
accept RADIUS Access-Request packets containing a valid State accept RADIUS Access-Request packets containing a valid State
skipping to change at page 7, line 33 skipping to change at page 8, line 43
attributes normally found in an Accounting Stop message with the attributes normally found in an Accounting Stop message with the
exception of the Acct-Term-Cause attribute. exception of the Acct-Term-Cause attribute.
Although [RFC2869] does not indicate that it updates [RFC2866], this Although [RFC2869] does not indicate that it updates [RFC2866], this
is an oversight, and the above attributes are allowable in an Interim is an oversight, and the above attributes are allowable in an Interim
Accounting record. Accounting record.
2.3.2. Acct-Session-Id and Acct-Multi-Session-Id 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id
[RFC2866] Section 5.5 describes Acct-Session-Id as Text within the [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the
description, but also states that "The String field SHOULD be a figure summarizing the attribute format, but then goes to state that
string of UTF-8 encoded 10646 characters." "The String field SHOULD be a string of UTF-8 encoded 10646
characters."
Since Acct-Multi-Session-Id is consistently described as a String, it [RFC2865] defines the "Text" type as "containing UTF-8 encoded 10646
appears that this is a typographical error, and that Acct-Session-Id characters", which is compatible with the description of Acct-
is of type String. Session-Id. Since other attributes are consistently described as
"Text" within both the figure summarizing the attribute format, and
the following attribute definition, it appears that this is a
typographical error, and that Acct-Session-Id is of type Text, and
not of type String.
The implication is that a robust implementation SHOULD support the The definition of the Acct-Multi-Session-Id attribute also has
String fields within Acct-Session-Id and Acct-Multi-Session-Id as typographical errors. It says
undistinguished octets.
A summary of the Acct-Session-Id attribute format ...
This text should read
A summary of the Acct-Multi-Session-Id attribute format ...
The Acct-Multi-Session-Id attribute is also defined as being of type
"String". However, the language in the text strongly recommends that
implementors consider the attribute as being of type "Text". It is
unclear why the type "String" was chosen for this attribute when the
type "Text" would be sufficient.
2.3.3. Request Authenticator 2.3.3. Request Authenticator
[RFC2866] Section 4.1 states: [RFC2866] Section 4.1 states:
The Request Authenticator of an Accounting-Request contains a The Request Authenticator of an Accounting-Request contains a
16-octet MD5 hash value calculated according to the method 16-octet MD5 hash value calculated according to the method
described in "Request Authenticator" above. described in "Request Authenticator" above.
However, the text does not indicate any action to take when an However, the text does not indicate any action to take when an
skipping to change at page 14, line 17 skipping to change at page 15, line 42
sessions as being independent. sessions as being independent.
For example, a NAS may offer multi-link services, where a user may For example, a NAS may offer multi-link services, where a user may
have multiple simultaneous network connections. In that case, an have multiple simultaneous network connections. In that case, an
Access-Reject for a later multi-link connection request does not Access-Reject for a later multi-link connection request does not
necessarily mean that earlier multi-link connections are torn down. necessarily mean that earlier multi-link connections are torn down.
Similarly, if a NAS offers both dialup and VOIP services, the Similarly, if a NAS offers both dialup and VOIP services, the
rejection of a VOIP attempt does not mean that the dialup session is rejection of a VOIP attempt does not mean that the dialup session is
torn down. torn down.
Where a NAS offers multiple services, confusion may result with
respect to interpretation of a Disconnect-Request [RFC3576]. In
order to prevent confusion a RADIUS Server SHOULD identify the
session that it desires to terminate as specifically as possible.
For example, an Acct-Session-Id attribute SHOULD be included in
Disconnect-Request and CoA-Request packets, rather than just the
User-Name attribute.
2.7. Addressing 2.7. Addressing
2.7.1. Link-Local Addresses 2.7.1. Link-Local Addresses
Since Link-Local addresses are unique only on the local link, if the Since Link-Local addresses are unique only on the local link, if the
NAS and RADIUS server are not on the same link, then an IPv6 Link- NAS and RADIUS server are not on the same link, then an IPv6 Link-
Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927] Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927]
cannot be used to uniquely identify the NAS. A NAS SHOULD NOT cannot be used to uniquely identify the NAS. A NAS SHOULD NOT
utilize a link-scope address within a NAS-IPv6-Address or NAS-IP- utilize a link-scope address within a NAS-IPv6-Address or NAS-IP-
Address attributes. A RADIUS server receiving a NAS-IPv6-Address or Address attributes. A RADIUS server receiving a NAS-IPv6-Address or
skipping to change at page 17, line 44 skipping to change at page 19, line 13
This Attribute indicates an IPv6 prefix (and corresponding route) This Attribute indicates an IPv6 prefix (and corresponding route)
to be configured for the user. It MAY be used in Access-Accept to be configured for the user. It MAY be used in Access-Accept
packets, and can appear multiple times. It MAY be used in an packets, and can appear multiple times. It MAY be used in an
Access-Request packet as a hint by the NAS to the server that it Access-Request packet as a hint by the NAS to the server that it
would prefer these prefix(es), but the server is not required to would prefer these prefix(es), but the server is not required to
honor the hint. Since it is assumed that the NAS will plumb a honor the hint. Since it is assumed that the NAS will plumb a
route corresponding to the prefix, it is not necessary for the route corresponding to the prefix, it is not necessary for the
server to also send a Framed-IPv6-Route attribute for the same server to also send a Framed-IPv6-Route attribute for the same
prefix. prefix.
An ISP may desire to support Prefix Delegation at the same time that An ISP may desire to support Prefix Delegation [PREFIX] at the same
it would like to assign a prefix for the link between the NAS and the time that it would like to assign a prefix for the link between the
user. The intent of the paragraph was to enable the NAS to advertise NAS and the user. The intent of the paragraph was to enable the NAS
the prefix (such as via a Router Advertisement). If the Framed- to advertise the prefix (such as via a Router Advertisement). If the
Routing attribute is used, it is also possible that the prefix would Framed-Routing attribute is used, it is also possible that the prefix
be advertised in a routing protocol such as RIPNG. RFC 2865 Section would be advertised in a routing protocol such as RIPNG. RFC 2865
5.10 describes the purpose of Framed-Routing: Section 5.10 describes the purpose of Framed-Routing:
This Attribute indicates the routing method for the user, when the This Attribute indicates the routing method for the user, when the
user is a router to a network. It is only used in Access-Accept user is a router to a network. It is only used in Access-Accept
packets. packets.
The description of the Prefix-Length field in RFC 3162 indicates The description of the Prefix-Length field in RFC 3162 indicates
excessively wide latitude: excessively wide latitude:
The length of the prefix, in bits. At least 0 and no larger than The length of the prefix, in bits. At least 0 and no larger than
128. 128.
This length appears too broad, because it is not clear what a NAS This length appears too broad, because it is not clear what a NAS
should do with a prefix of greater granularity than /64. For example, should do with a prefix of greater granularity than /64. For example,
the Framed-IPv6-Prefix may contain a /128. This does not imply that the Framed-IPv6-Prefix may contain a /128. This does not imply that
the NAS should assign an IPv6 address to the end user, because RFC the NAS should assign an IPv6 address to the end user, because RFC
3162 already defines a Framed-IPv6-Identifier attribute to handle the 3162 already defines a Framed-IPv6-Identifier attribute to handle the
Identifier portion. Identifier portion.
It appears that the Framed-IPv6-Prefix is used for the link between It appears that the Framed-IPv6-Prefix is used for the link between
the NAS and CPE only if a /64 prefix is assigned. When a larger the NAS and CPE only if a /64 prefix is assigned. When a /64 or
prefix is sent, the intent is for the NAS to send a routing larger prefix is sent, the intent is for the NAS to send a routing
advertisement containing the information present in the Framed- advertisement containing the information present in the Framed-
IPv6-Prefix attribute. IPv6-Prefix attribute.
The CPE may also require a delegated prefix for its own use, if it is
decrementing the TTL field of IP headers. In that case, it should be
delegated a prefix by the NAS via the Delegated-IPv6-Prefix
attribute. [PREFIX]. If the CPE is not decrementing TTL, it does
not require a delegated prefix.
3. IANA Considerations 3. IANA Considerations
This specification does not create any new registries, nor does it This specification does not create any new registries, nor does it
require assignment of any protocol parameters. require assignment of any protocol parameters.
4. Security Considerations 4. Security Considerations
Since this document describes the use of RADIUS for purposes of Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in WLANs, it is authentication, authorization, and accounting in WLANs, it is
vulnerable to all of the threats that are present in other RADIUS vulnerable to all of the threats that are present in other RADIUS
applications. For a discussion of these threats, see [RFC2865], applications. For a discussion of these threats, see [RFC2865],
[RFC2607], [RFC3162], [RFC3576], [RFC3579], and [RFC3580]. [RFC2607], [RFC3162], [RFC3579], and [RFC3580].
5. References 5. References
5.1. Normative references. 5.1. Normative references.
[RFC2865] [RFC2865]
Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2866] [RFC2866]
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2869] [RFC2869]
Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
2869, June 2000. 2869, June 2000.
[RFC3576]
Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication Dial In
User Service (RADIUS)", RFC 3576, July 2003.
[RFC3579] [RFC3579]
Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[PREFIX]
Salowey, J., Droms., R, "RADIUS Delegated-IPv6-Prefix Attribute",
drafty-ietf-radext-delegated-prefix-05.txt, October, 2006.
5.2. Informative references. 5.2. Informative references.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
skipping to change at page 20, line 5 skipping to change at page 21, line 28
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", RFC 3927, May 2005. of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005. Access Identifier", RFC 4282, December 2005.
[RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC [RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC
4668, August 2006. 4668, August 2006.
[RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", RFC
4669, August 2006.
6. RFC Editor instructions
The references to [PREFIX] should be replaced with a reference to the
RFC when it is issued, and this section deleted, prior to issuing
this document as an RFC.
Acknowledgments Acknowledgments
The authors would like to acknowledge Glen Zorn and Bernard Aboba for The authors would like to acknowledge Glen Zorn and Bernard Aboba for
contributions to this document. contributions to this document.
The alternate algorithm to [RFC3579] Section 2.6.1 that is described The alternate algorithm to [RFC3579] Section 2.6.1 that is described
in section 2.1.2 of this document was designed by Raghu Dendukuri. in section 2.1.2 of this document was designed by Raghu Dendukuri.
David Nelson wishes to acknowledge the support of Enterasys Networks, David Nelson wishes to acknowledge the support of Enterasys Networks,
where he was employed during much of the work on this document. where he was employed during much of the work on this document.
 End of changes. 16 change blocks. 
72 lines changed or deleted 151 lines changed or added

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