errata logo graphic

Found 6 records.

Status: Verified (5)

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

Status: Verified
Type: Technical

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

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

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)

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