errata logo graphic

Found 4 records.

Status: Verified (3)

RFC5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", January 2008

Source of RFC: radext (ops)

Errata ID: 1407

Status: Verified
Type: Technical

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

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: 3294

Status: Verified
Type: Technical

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.


Status: Rejected (1)

RFC5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", January 2008

Source of RFC: radext (ops)

Errata ID: 3103

Status: Rejected
Type: Technical

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


Report New Errata