Subject: Re: [radext] [Technical Errata Reported] RFC5176 (4311)

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 21 Apr 2015 13:16:23 -0400

Hello,

I haven't seen any discussion on this from the Radext WG.  The report looks
reasonable and make sense to me, but would like to hear from the chairs to
confirm.  Since this is getting addressed in a new draft, I would be
included to mark this as "Hold for Document Update".  This puts the errata
with this draft (it's not rejected) and can be added to a new revision of
this particular draft if it gets updated in the future.

Please let me know if you agree/disagree and I'll mark it appropriately.

Thanks!

On Mon, Mar 23, 2015 at 12:50 PM, RFC Errata System <
[email-masked]> wrote:

> The following errata report has been submitted for RFC5176,
> "Dynamic Authorization Extensions to Remote Authentication Dial In User
> Service (RADIUS)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=4311
>
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok <[email-masked]>
>
> Section: 2.3
>
> Original Text
> -------------
> Section 2.3 says:
>
>       In CoA-Request and Disconnect-Request packets, all attributes MUST
>       be treated as mandatory.
>
>
> Corrected Text
> --------------
> In CoA-Request and Disconnect-Request packets, all attributes MUST
> be treated as mandatory, except Proxy-State.  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.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5176 (draft-ietf-radext-rfc3576bis-13)
> --------------------------------------
> Title               : Dynamic Authorization Extensions to Remote
> Authentication Dial In User Service (RADIUS)
> Publication Date    : January 2008
> Author(s)           : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba
> Category            : INFORMATIONAL
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>

-- 

Best regards,
Kathleen

---

From: <[email-masked]>
Date: Tue, 21 Apr 2015 19:44:07 +0000

I'm OK with this erratum but I would provide further clarifications.
First, I would recommend to clarify what "mandatory" in the context of RADIUS.
I would also highlight the specific case of the Proxy-State.

I would propose the following text:

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

further details on the handling of Proxy-State attributes by NAS.

let me know if it is OK for you.

regards,

Lionel

De : Kathleen Moriarty [mailto:[email-masked]]
Envoyé : mardi 21 avril 2015 19:16
À : RFC Errata System
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Benoit Claise; joel jaeggli; Stefan Winter; MORAND Lionel IMT/OLN; [email-masked]; Alan DeKok
Objet : Re: [radext] [Technical Errata Reported] RFC5176 (4311)

Hello,

I haven't seen any discussion on this from the Radext WG.  The report looks reasonable and make sense to me, but would like to hear from the chairs to confirm.  Since this is getting addressed in a new draft, I would be included to mark this as "Hold for Document Update".  This puts the errata with this draft (it's not rejected) and can be added to a new revision of this particular draft if it gets updated in the future.

Thanks!

On Mon, Mar 23, 2015 at 12:50 PM, RFC Errata System <[email-masked]<mailto:[email-masked]>> wrote:
The following errata report has been submitted for RFC5176,
"Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)".

--------------------------------------
Type: Technical
Reported by: Alan DeKok <[email-masked]<mailto:[email-masked]>>

Section: 2.3

Original Text
-------------
Section 2.3 says:

Corrected Text
--------------

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.

Instructions:
-------------

Title               : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)

_______________________________________________
radext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/radext

--

Best regards,
Kathleen

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 21 Apr 2015 17:40:52 -0400

Thanks, Lionel.  One more question in-line.

> First, I would recommend to clarify what "mandatory" in the context of

I can replace the text with what you provided below, but if clarifying what
"mandatory" means is needed.  Can someone propose text within the paragraph
below so I have the full replacement text?  If I am just doing "Hold For
Document Update", I can add this in a not as well.  I'd just like to get
the agreed upon text.

> let me know if it is OK for you.

Thank you,
Kathleen

>
>
> regards,
>
>
>
> Lionel
>
>
>
> *De :* Kathleen Moriarty [mailto:[email-masked]]
> *Envoyé :* mardi 21 avril 2015 19:16
> *À :* RFC Errata System
> *Cc :* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Benoit Claise; joel jaeggli;
> Stefan Winter; MORAND Lionel IMT/OLN; [email-masked]; Alan DeKok
> *Objet :* Re: [radext] [Technical Errata Reported] RFC5176 (4311)
>
>
>
> Hello,
>
>
>
> I haven't seen any discussion on this from the Radext WG.  The report
> looks reasonable and make sense to me, but would like to hear from the
> chairs to confirm.  Since this is getting addressed in a new draft, I would
> be included to mark this as "Hold for Document Update".  This puts the
> errata with this draft (it's not rejected) and can be added to a new
> revision of this particular draft if it gets updated in the future.
>
>
>

-- 

Best regards,
Kathleen

---

From: <[email-masked]>
Date: Wed, 22 Apr 2015 08:48:21 +0000

Hi Kathleen,

The clarification of "mandatory" was already in the proposed text! ☺
The initial proposed text was "all attributes MUST be treated as mandatory" and my proposed text is "all attributes MUST be treated as mandatory to understand by the NAS".  "Mandatory" refers to the handling of the attributes by the NAS, not to their presence in the requests. It is to avoid misunderstanding.
The complete proposed text is repeated hereafter:

At least, it is my proposal for clarification.

Regards,

Lionel

De : Kathleen Moriarty [mailto:[email-masked]]
Envoyé : mardi 21 avril 2015 23:41
À : MORAND Lionel IMT/OLN
Cc : RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Benoit Claise; joel jaeggli; Stefan Winter; [email-masked]; Alan DeKok
Objet : Re: [radext] [Technical Errata Reported] RFC5176 (4311)

On Tue, Apr 21, 2015 at 3:44 PM, <[email-masked]<mailto:[email-masked]>> wrote:
I'm OK with this erratum but I would provide further clarifications.
First, I would recommend to clarify what "mandatory" in the context of RADIUS.

I can replace the text with what you provided below, but if clarifying what "mandatory" means is needed.  Can someone propose text within the paragraph below so I have the full replacement text?  If I am just doing "Hold For Document Update", I can add this in a not as well.  I'd just like to get the agreed upon text.
I would also highlight the specific case of the Proxy-State.

Thank you,
Kathleen

regards,

Lionel

De : Kathleen Moriarty [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mardi 21 avril 2015 19:16
À : RFC Errata System
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Benoit Claise; joel jaeggli; Stefan Winter; MORAND Lionel IMT/OLN; [email-masked]<mailto:[email-masked]>; Alan DeKok
Objet : Re: [radext] [Technical Errata Reported] RFC5176 (4311)

Hello,

Thanks!

Section: 2.3

Original Text
-------------
Section 2.3 says:

Corrected Text
--------------

Notes
-----

Instructions:
-------------

--

Best regards,
Kathleen

Thank you.

--

Best regards,
Kathleen