Subject: [radext] #20: Errata for RFC 4282

From: "radext issue tracker" <[email-masked]>
Date: Fri, 14 May 2010 02:09:04 -0000

#20: Errata for RFC 4282
-----------------------------------+----------------------------------------
 Reporter:  ah@…                   |       Owner:  aland@…                  
     Type:  defect                 |      Status:  new                      
 Priority:  minor                  |   Milestone:  milestone1               
Component:  RFC4282bis             |     Version:  1.0                      
 Severity:  Candidate WG Document  |    Keywords:                           
-----------------------------------+----------------------------------------
 Date first submitted: December 18, 2005
 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01160.html

 I just read the recently published RFC 4282 (revised NAI spec)
 authored by you and would like to submit a few comments.

 Unfortunately, the text of that RFC does not fully reflect the
 established state of the IETF standards, by referring to obsolete
 documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,
 e.g., STD 3, RFC 1123, and RFC 2821.

 In particular, the text of RFC 4282 repeatedly (e.g. in Section
 2.6.) emphasizes making a deviation from established standards
 for host / domain names.

 This is not true!
 The pretended deviation in fact reflects the current standards.

 The modification to RFC 952, RFC 821, et al. has already been
 introduced into the IETF Standards by STD 3, RFC 1123 (Host
 Requirements, Part II), published 16 years ago, in October 1989.
 Section 2.1 of that RFC, on page 13, says:

    "One aspect of host name syntax is hereby changed: the
     restriction on the first character is relaxed to allow
     either a letter or a digit. Host software MUST support
     this more liberal syntax."

 and continues saying:

    "Host software MUST handle host names of up to 63 characters
     and SHOULD handle host names of up to 255 characters."

 Therefore, it would have been strongly advisable to point out
 on page 6 of RFC 4282, in Section 2.2, first bullet, that the
 named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

 Note: IMHO, it is a fundamental design flaw of RADIUS and certain
 other protocols using TLVs, AVPs, -- or however similar protocol
 objects are named -- to specify that the 'length' information
 (being stored in a single octet) is to comprise the cumulative
 size of the Type, Length and Value fields, instead of just giving
 the size of the Value (payload) field; the latter solution would
 always allow to fully exhaust the total range of an 8-bit unsigned
 Length and thereby allow payload octet strings of size 0..255 !

 Similarly, RFC 4282 ignores the standardization state of the
 proprietary historic tunnelling protocols that have served as
 'precursors with major deficiencies to learn from' for the
 development of L2TP, the only comparable protocol named in
 RFC 4282 that is on the IETF Standards Track.

  o   L2F [RFC2341] has been published for information only
      as a Historic RFC 'ab initio'.

  o   PPTP [RFC2637] has purposely been rejected by the IETF --
      because of its well known significant security flaws, among
      other issues, and the Informational RFC 2637 has been
      published with a very clear IESG Note to this end.

 I am surprised that a new Standards Track RFC is getting published
 that repeatedly refers to obsolete protocols equally as to official
 protocols, in a manner that does not make clear the distinction.
 The continued unreflected use of PPTP, in particular, is seen by
 major security consultants as 'one of the most widespread trojan
 horses' in the current Internet.  We should do everything to
 communicate and emphasize the 1998/1999 decisions of the IETF and
 IESG and the reasons behind it, and push the evolved standards!

 [Jari Arkko]

 Unfortunately, the text of that RFC does not fully reflect the
 established state of the IETF standards, by referring to obsolete
 documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,
 e.g., STD 3, RFC 1123, and RFC 2821.

 This is indeed an oversight. Too bad you did not tell us about it
 a few days earlier... and I'm kind of surprised this does not
 happen at the RFC editor side automatically.

 We could make an errate entry for this.

 In particular, the text of RFC 4282 repeatedly (e.g. in Section
 2.6.) emphasizes making a deviation from established standards
 for host / domain names.

 This is not true!
 The pretended deviation in fact reflects the current standards.

 Right. Material for an errata.

 The modification to RFC 952, RFC 821, et al. has already been
 introduced into the IETF Standards by STD 3, RFC 1123 (Host
 Requirements, Part II), published 16 years ago, in October 1989.
 Section 2.1 of that RFC, on page 13, says:

    "One aspect of host name syntax is hereby changed: the
     restriction on the first character is relaxed to allow
     either a letter or a digit. Host software MUST support
     this more liberal syntax."

 and continues saying:

    "Host software MUST handle host names of up to 63 characters
     and SHOULD handle host names of up to 255 characters."

 Therefore, it would have been strongly advisable to point out
 on page 6 of RFC 4282, in Section 2.2, first bullet, that the
 named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

 This is true, but IMHO not the task of this RFC to complain.
 There is ongoing work in the RADEXT WG on documenting
 issues with the RADIUS protocol, and it might be good to
 take care of this issue in there.

 Note: IMHO, it is a fundamental design flaw of RADIUS and certain
 other protocols using TLVs, AVPs, -- or however similar protocol
 objects are named -- to specify that the 'length' information
 (being stored in a single octet) is to comprise the cumulative
 size of the Type, Length and Value fields, instead of just giving
 the size of the Value (payload) field; the latter solution would
 always allow to fully exhaust the total range of an 8-bit unsigned
 Length and thereby allow payload octet strings of size 0..255 !

 Yeah. But we have to live with it.

 Similarly, RFC 4282 ignores the standardization state of the
 proprietary historic tunnelling protocols that have served as
 'precursors with major deficiencies to learn from' for the
 development of L2TP, the only comparable protocol named in
 RFC 4282 that is on the IETF Standards Track.

  o   L2F [RFC2341] has been published for information only
      as a Historic RFC 'ab initio'.

  o   PPTP [RFC2637] has purposely been rejected by the IETF --
      because of its well known significant security flaws, among
      other issues, and the Informational RFC 2637 has been
      published with a very clear IESG Note to this end.

 I am surprised that a new Standards Track RFC is getting published
 that repeatedly refers to obsolete protocols equally as to official
 protocols, in a manner that does not make clear the distinction.
 The continued unreflected use of PPTP, in particular, is seen by
 major security consultants as 'one of the most widespread trojan
 horses' in the current Internet.  We should do everything to
 communicate and emphasize the 1998/1999 decisions of the IETF and
 IESG and the reasons behind it, and push the evolved standards!

 This text was inherited from RFC 2486. But again, while I agree
 with some of the issues in these non-IETF protocols, I'm not sure
 the NAI RFC is the right place to discuss such issues. I agree that
 if the text had been written from scratch, it probably would have
 been better to keep the tunneling protocol text to a minimum.
 Still, I happen to believe in pointing to usage as opposed to
 not mentioning this. It would be good to be able to separate standards
 from non-standards in references, but I'm not sure how to do
 that easily. Its easy most of the time to separate the normative
 and informational references, as we do here too, but your
 issue is with the separation between standards-track and
 individual submission RFCs. Unfortunately, the current
 designations in the references section do not make a clear
 distinction here. For instance, since 2661 is only a Proposed
 Standard, the reference entry looks the same as 2637, which
 is an individual submission RFC. Thoughts?

 Anyway, as a conclusion I'm suggesting we send an errata
 entry to the RFC Editor that shows the 821 update and 2.6
 new situation.

 [Bernard Aboba]

 This is indeed an oversight. Too bad you did not tell us about it
 a few days earlier... and I'm kind of surprised this does not
 happen at the RFC editor side automatically.

 Part of the problem is that RFC 1123 does not state that it updates RFC
 821, although RFC 2821 does state that it obsoletes 821, 974, 1869 and
 updates 1123.

 Anyway, as a conclusion I'm suggesting we send an errata
 entry to the RFC Editor that shows the 821 update and 2.6
 new situation.

 I think we also need to check that the ABNF in RFC 4282 is compatible with
 RFC 2821 ABNF (Section 4.1.2).

 [Pasi]
 It's not -- as we found out when discussing what IKEv2 ID
 payload type should be used for NAIs.

 But this is not really a problem. It's not necessary that
 all valid SMTP email addresses are usable as NAIs or vice
 versa.

 (Couple of examples: "joe@[1.2.3.4]", "foo"@example.com,
 "joe", "@example.com", and everything containing UTF-8.)

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/20>
radext <http://tools.ietf.org/radext/>

--
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/>