[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[radext] #20: Errata for RFC 4282
#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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>