Subject: [Dime] error in IANA allocations for RFC 5447 (attributes 124 and 125)

From: Denis Ovsienko <[email-masked]>
Date: Mon, 06 Aug 2018 13:01:01 +0100

Hello.

Recently I was reviewing some code that adds support for two RFC 5447 RADIUS AVPs below:

   The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString
   The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and

It turned out, the current RADIUS Types registry at https://www.iana.org/assignments/radius-types/radius-types.xhtml lists both attributes with wrong types:

125 	MIP6-Home-Link-Prefix 	ipv6prefix 	[RFC5447]
124 	MIP6-Feature-Vector 	string 	[RFC5447]

Those incorrect types had propagated from the IANA registry into FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home-Link-Prefix, see the discussion and the follow-ups at https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested).

Having studied this discrepancy thoroughly, I had concluded the AVP definitions are correct in RFC 5447, so I did not file an erratum. The problem seems to be with those IANA allocations only. Could somebody review this issue and put the IANA allocations right?

Thank you.

-- 
    Denis Ovsienko

---

From: Alan DeKok <[email-masked]>
Date: Mon, 6 Aug 2018 08:59:39 -0400

> 125 	MIP6-Home-Link-Prefix 	ipv6prefix 	[RFC5447]

  That is definitely wrong.  The "ipv6prefix" format is different than the one used by MIP6-Home-Link-Prefix in RFC 5337.

> 124 	MIP6-Feature-Vector 	string 	[RFC5447]

  That issue is a bit different.  64-bit integers were defined in RFC 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC 5447 was published.

  So at the time RFC 5447 was published, "string" was the correct definition.

> Having studied this discrepancy thoroughly, I had concluded the AVP definitions are correct in RFC 5447, so I did not file an erratum. The problem seems to be with those IANA allocations only. Coul…

 In the end, I think that the incorrect IANA allocations were a result of the updates done in RFC 8044.  The early drafts had a table which updated all of the IANA data types, e.g.:

https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2

  The MIP6 attributes are listed there as "ipv6prefix" and "string".  As the author of RFC 8044, I think that's my mistake.  Updating hundreds of attributes required reading many RFCs, and it's understandable that a few mistakes were made.

  Unless there are objections from DIME or RADEXT, I think it would be best for IANA to update the registry as follows:

125 	MIP6-Home-Link-Prefix 	string 	[RFC5447]
124 	MIP6-Feature-Vector 	integer64 	[RFC5447]

  We may need approval from the AD (Ben).  Explicit consensus from the WG would also be helpful.

  Alan DeKok.

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Mon, 06 Aug 2018 20:33:26 +0000

Hi,

On Mon Aug 06 13:00:05 2018, [email-masked] wrote:
> > It turned out, the current RADIUS Types registry at
> > https://www.iana.org/assignments/radius-types/radius-types.xhtml
> > lists both attributes with wrong types:
> >
> That is definitely wrong.  The "ipv6prefix" format is different than
> the one used by MIP6-Home-Link-Prefix in RFC 5337.
> 
> That issue is a bit different.  64-bit integers were defined in RFC
> 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC
> 5447 was published.
> 
> > Those incorrect types had propagated from the IANA registry into
> > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home-
> > Link-Prefix, see the discussion and the follow-ups at
> > https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested).
> >
> > Having studied this discrepancy thoroughly, I had concluded the AVP
> > definitions are correct in RFC 5447, so I did not file an erratum.
> > The problem seems to be with those IANA allocations only. Could
> > somebody review this issue and put the IANA allocations right?
> 
> In the end, I think that the incorrect IANA allocations were a result
> of the updates done in RFC 8044.  The early drafts had a table which
> updated all of the IANA data types, e.g.:
> 

Right, we took the entries from here when the document was approved:

https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section-4.2

> The MIP6 attributes are listed there as "ipv6prefix" and "string".  As
> the author of RFC 8044, I think that's my mistake.  Updating hundreds
> of attributes required reading many RFCs, and it's understandable that
> a few mistakes were made.
> 
> Unless there are objections from DIME or RADEXT, I think it would be
> best for IANA to update the registry as follows:
> 

If there's no errata report required, we can move ahead once the AD lets us know that any appropriate consensus has been reached (if we haven't heard from the chairs first) and gives us the go-ahead.

Best regards,

Amanda Baber
Lead IANA Services Specialist

---

From: <[email-masked]>
Date: Tue, 7 Aug 2018 08:03:26 +0000

I agree with the proposal.
It is important that the types defined in RFC5447 are the ones listed in the IANA registry.
For information, there are existing implementations relying on these AVPs and it is important to be consistent between the RFC and registry.

Regards,

Lionel

> -----Message d'origine-----
> De : radext [mailto:[email-masked]] De la part de Amanda Baber via
> RT
> Envoyé : lundi 6 août 2018 22:33
> Cc : [email-masked]; [email-masked]; [email-masked]
> Objet : [radext] [IANA #1118137] error in IANA allocations for RFC 5447
> (attributes 124 and 125)
> 
> Hi,
> 
> If there's no errata report required, we can move ahead once the AD lets us
> know that any appropriate consensus has been reached (if we haven't heard
> from the chairs first) and gives us the go-ahead.
> 
> Best regards,
> 
> Amanda Baber
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

_________________________________________________________________________________________________________________________

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: "Amanda Baber via RT" <[email-masked]>
Date: Wed, 08 Aug 2018 01:59:31 +0000

Hi Benjamin,

Given Lionel's confirmation, should we go ahead and make these changes at https://www.iana.org/assignments/radius-types?

OLD:

NEW:

thanks,
Amanda

On Tue Aug 07 08:03:49 2018, [email-masked] wrote:
> For information, there are existing implementations relying on these
> AVPs and it is important to be consistent between the RFC and
> registry.
> 
> Regards,
> 
> Lionel
> 
> > > > Recently I was reviewing some code that adds support for two RFC
> > > > 5447
> > > > RADIUS AVPs below:
> > > >
> > > We may need approval from the AD (Ben).  Explicit consensus from
> > > the
> > > WG would also be helpful.
> > >
> > > Alan DeKok.
> >
> 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,
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 11 Aug 2018 11:07:01 -0500

Hi Amanda,

> Given Lionel's confirmation, should we go ahead and make these changes at https://www.iana.org/assignments/radius-types?

Yes, please make those changes.

Thanks,

Benjamin

---

From: Denis Ovsienko <[email-masked]>
Date: Mon, 13 Aug 2018 22:28:46 +0100

---- On Mon, 06 Aug 2018 13:59:39 +0100 Alan DeKok <[email-masked]> wrote ---- 
[...]
 >   The MIP6 attributes are listed there as "ipv6prefix" and "string".  As the author of RFC 8044, I think that's my mistake.  Updating hundreds of attributes required reading many RFCs, and it's un…
[...]

Everybody makes mistakes. Not everybody has the capability to admit and put it right. Well done.

-- 
    Denis Ovsienko

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Mon, 13 Aug 2018 22:35:04 +0000

Hi all,

These RADIUS Attribute Type registrations now read as follows:

Value: 124
Description: MIP6-Feature-Vector
Data Type: integer64
Reference: [RFC5447]

Value: 125
Description: MIP6-Home-Link-Prefix
Data Type: string
Reference: [RFC5447]

Please see
https://www.iana.org/assignments/radius-types

These updates were made after we received confirmation from Lionel Morand and Benjamin Kaduk.

Best regards,

Amanda Baber