Subject: FW: ISSUE: Inappropriate use of RFC 2119 key word and misleading references

From: "Glen Zorn" <[email-masked]>
Date: Thu, 22 Oct 2009 17:48:55 +0700

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]] 
Sent: Thursday, October 22, 2009 5:32 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'; 'Alan DeKok';
[email-masked]
Subject: ISSUE: Inappropriate use of RFC 2119 key word and misleading
references

Description of issue:  Misleading references and invention of integer64 data
type

Submitter name: Glen Zorn

Submitter email address: [email-masked]

Date first submitted: 22 October 2009

Document: draft-ietf-radext-design-09

Comment type: T

Priority: S

Section: 2.1.1

Rationale/Explanation of issue:

The relevant section of the draft in question says:

   The integer64 type is used for the ARAP-
   Challenge-Response Attribute defined in [RFC2869] Section 5.15, and
   the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
   [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
   length, but denotes it as type String.

   Given that attributes of type IPv6 address, IPv6 prefix, and
   integer64 are already in use, it is RECOMMENDED that RADIUS server
   implementations include support for these additional basic types, in
   addition to the types defined in [RFC2865].

This is what RFC 2869 says about the Value field of the
APAP-Challenge-Response Attribute:

   Value

      The Value field contains an 8 octet response to the dial-in
      client's challenge. The RADIUS server calculates this value by
      taking the dial-in client's challenge from the high order 8 octets
      of the ARAP-Password attribute and  performing DES encryption on
      this value with the authenticating user's password as the key. If
      the user's password is less than 8 octets in length, the password
      is padded at the end with NULL octets to a length of 8 before
      using it as a key.

If one takes the word "integer" as having its normal meaning it is obvious
that far from defining a 64-bit integer data type the only thing that the
ARAP-Challenge-Response attribute has in common with a 64-bit integer is its
length.  The same is true, in spades, for the Framed-Interface-Id Attribute:
the attribute was designed to carry the Interface-Identifier IPCOv6 option
(RFC 2472).  Glancing at section 4.1 of that document (it's too long to
quote here) makes it abundantly clear that the Interface-Id field of the
Framed-Interface-Id attribute was designed not as an integer but as a
specially formatted octet string.  Neither RFC 2869 nor RFC 3162 uses the
term "integer64", for good reason; interestingly, RFC 2869 _does_ define
data types, but "integer64" is not among the types defined (again, for good
reason).  Therefore, it is technically incorrect to claim that either of the
referenced RFCs defines an "integer64" data type.

Requested change:
Given that the "integer64" data type has never in fact been defined by any
RFC, either all mention of it must be removed from this draft or the text
changed to make clear that it is an invention of the author.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 22 Oct 2009 07:36:30 -0700

Glen Zorn said:  

"Glancing at section 4.1 of that document (it's too long to
quote here) makes it abundantly clear that the Interface-Id field of the
Framed-Interface-Id attribute was designed not as an integer but as a
specially formatted octet string.  Neither RFC 2869 nor RFC 3162 uses the
term "integer64", for good reason; interestingly, RFC 2869 _does_ define
data types, but "integer64" is not among the types defined (again, for good
reason).  Therefore, it is technically incorrect to claim that either of the
referenced RFCs defines an "integer64" data type."

Requested change:

[BA] How about this?  In Section 2.1.1 change:

"  IPv6 address   128 bit value, in network byte order.
   IPv6 prefix    8 bits of reserved, 8 bits of prefix length, up to
                  128 bits of value, in network byte order.
   integer64      64 bit unsigned value, in network byte order
                  This type has also been used to represent an IPv6
                  interface identifier.

   Examples of the IPv6 address type include NAS-IPv6-Address defined in
   [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162]
   Section 2.4.  The IPv6 prefix type is used in [RFC3162] Section 2.3,
   and in [RFC4818] Section 3.  The integer64 type is used for the ARAP-
   Challenge-Response Attribute defined in [RFC2869] Section 5.15, and
   the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
   [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
   length, but denotes it as type String.

"  

To:

"  IPv6 address      128 bit value, in network byte order.
   IPv6 prefix       8 bits of reserved, 8 bits of prefix length, up to
                     128 bits of value, in network byte order.
   Interface ID      64 bit octet string, in network byte order,
                     used to represent an IPv6 Interface identifier. 

   Examples of the IPv6 address type include NAS-IPv6-Address defined in
   [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162]
   Section 2.4.  The IPv6 prefix type is used in [RFC3162] Section 2.3,
   and in [RFC4818] Section 3.  The Interface ID type is used for the 
   the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
   [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
   length, but denotes it as type String.

   Given that attributes of type IPv6 address, IPv6 prefix, and
   Interface ID are already in use, it is recommended that RADIUS server
   implementations include support for these additional basic types, in
   addition to the types defined in [RFC2865].
"