RFC Errata
Found 6 records.
Status: Verified (5)
RFC 5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", January 2008
Note: This RFC has been updated by RFC 8559
Source of RFC: radext (sec)
Errata ID: 1407
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Avi Lior
Date Reported: 2008-04-09
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02
Section 6.1 says:
Typically, the Dynamic Authorization Server will extract the realm from the Network Access Identifier [RFC4282] included within the User-Name or Chargeable-User-Identity Attribute, and determine the corresponding RADIUS servers in the realm routing tables.
It should say:
Typically, the Dynamic Authorization Server will extract the realm from the Network Access Identifier [RFC4282] included within the User-Name and determine the corresponding RADIUS servers in the realm routing tables.
Notes:
Chargeable-User-Identity Attribute defined in RFC4372 does not allow any entity other then the home network to parse the CUI attribute. It is in essence opaque. Here is the text:
"RADIUS entities other than the Home RADIUS
server MUST treat the CUI content as an opaque token, and SHOULD
NOT perform operations on its content other than a binary equality
comparison test, between two instances of CUI."
Errata ID: 2012
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Avi Lior
Date Reported: 2010-01-25
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02
Section 3.5 says:
Values 200-299 represent successful completion, so that these values may only be sent within CoA-ACK or Disconnect-ACK packets and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet.
It should say:
Values 200-299 represent successful completion, so that these values may be sent in other reply messages such as Access-Reject, Access-Challenge, CoA-ACK or Disconnect-ACK packets and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet.
Notes:
RFC 3579 allows for Error-Cause to be sent (specifically) in an access-challenge and also in Reject messages as well.
The specification in 5176 restricts the usage and should be clarified especially since 5176 was published after 3579.
I proposed minimal text but I think a broader approach is needed for this attribute. Here are some thoughts:
1) Error-Cause is needed in Access-Reject (as is allowed by 3579)
2) IANA should have procedures for defining new values (currently no procedure is defined). SDO need to be able to use Error-Cause to report back why an Authentication/Authorization failed. Error-Cause seems to be the only solution other than Reply-Message which is not really designed for reporting error cause to the NAS.
Errata ID: 4311
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2015-03-23
Verifier Name: Kathleen Moriarty
Date Verified: 2015-07-20
Section 2.3 says:
Section 2.3 says:
In CoA-Request and Disconnect-Request packets, all attributes MUST
be treated as mandatory.
It should say:
In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory to understand by the NAS, except Proxy-State attributes that MUST be treated as opaque data. See Section 3.1 for a discussion of how the NAS must handle Proxy-State.
Notes:
This was seen with vendor equipment. CoA proxying was done to the NAS, and the proxy was adding and forwarding Proxy-State as required by Section 3.1. However, the NAS was returning a CoA-NAK with Error-Cause = Unsupported-Attribute.
The issue comes because Proxy-State is called out in Section 3.1 for special handling. However, that special handling isn't called out in Section 2.3. As a result, implementors can get confused.
The RADEXT WG is rechartering with a document to address CoA proxying. We will also be addressing this issue in that document. There are additional attributes which a NAS should ignore, OR which should be filtered out by the proxy closest to the NAS.
The text was slightly updated by the WG from the originally submitted text.
Errata ID: 3294
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mauricio Sanchez
Date Reported: 2012-07-26
Verifier Name: Benoit Claise
Date Verified: 2012-07-26
Section 3.6 says:
Disconnect Messages Request ACK NAK # Attribute 0-1 0 0 1 User-Name (Note 1) 0-1 0 0 4 NAS-IP-Address (Note 1) 0-1 0 0 5 NAS-Port (Note 1) 0 0 0 6 Service-Type 0 0 0 8 Framed-IP-Address (Note 1)
It should say:
Disconnect Messages Request ACK NAK # Attribute 0-1 0 0 1 User-Name (Note 1) 0-1 0 0 4 NAS-IP-Address (Note 1) 0-1 0 0 5 NAS-Port (Note 1) 0 0 0 6 Service-Type 0-1 0 0 8 Framed-IP-Address (Note 1)
Notes:
Section 3.6 ("Table of Attributes") changed the number of Frame-IP-Address attributes allowed in Disconnect-Message compared to previous RFC3576 (changed from "0-1" to "0"). The table should revert back to its original RFC3576 value in order to maintain backward compatibility with RFC3576.
Errata ID: 4280
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2015-02-24
Verifier Name: Kathleen Moriarty
Date Verified: 2015-04-21
Section 3.6 says:
0 0 0+ 101 Error-Cause In both tables, for CoA and Disconnect messages.
It should say:
0 0+ 0+ 101 Error-Cause In both tables, for CoA and Disconnect messages.
Notes:
Section 3.5 says that Error-Cause may be sent in a CoA-ACK or Disconnect-ACK packet:
...
Values 200-299 represent successful completion, so that these
values may only be sent within CoA-ACK or Disconnect-ACK packets
Status: Rejected (1)
RFC 5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", January 2008
Note: This RFC has been updated by RFC 8559
Source of RFC: radext (sec)
Errata ID: 3103
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Davide Magistri
Date Reported: 2012-02-03
Rejected by: Benoit Claise
Date Rejected: 2012-07-26
Section 7 says:
Disconnect Request with User-Name:
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261
Disconnect Request with Acct-Session-ID:
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567
Disconnect Request with Framed-IP-Address:
0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
32: 0a00 0203
It should say:
Disconnect Request with User-Name:
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261
Disconnect Request with Acct-Session-ID:
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567
Notes:
Since cardinality notation value for Framed-IP-Address attribute has now been changed in section 3.6 ("Table of Attributes") compared to previous 3576 RFC (change was from "0-1" to "0"), the "Disconnect Request with Framed-IP-Address" example in section 7 ("Example traces") should be removed.
Furthermore, a new bullet in "Appendix A. Changes from RFC 3576" should be foreseen (just like the one related to Service-Type Attribute), such as:
o Use of the Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix Attributes within a Disconnect-Request is prohibited
Broadly speaking, one thing that seems to me a bit unclear is that Attributes such as Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix are still valid session identifiers that could be present in CoA Requests, while they have been totally prohibited in Disconnect Requests ( even if they are mentioned as valid in section 3, end of page #10 ).
From my point of view, either it's misplaced the example in section 7 or cardinality notation values in Disconnect Message Table of Attributes (related to the ones mentioned above) should be changed back to "0-1" (I personally think this last option would be better).
--VERIFIER NOTES--
Rejected. See the resolution in errata 3294