RFC 4282 (NAI, revised) [fwd]

["Bernard Aboba" <bernard_aboba@hotmail.com>]

-----Original Message-----
From: Alfred HÃnes [mailto:ah@tr-sys.de]
Sent: Sun 12/18/2005 10:18 AM
To: Bernard Aboba; mbeadles@endforce.com; jari.arkko@ericsson.com; 
pasi.eronen@nokia.com
Cc: rfc-editor@rfc-editor.org
Subject: RFC 4282 (NAI, revised)

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!


Best regards,
 Alfred HÃnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>