Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: May 7, 2009
Reference: https://datatracker.ietf.org/idtracker/ballot/2883/
Document: Design-Guidelines
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Jari Arkko: Discuss [2009-05-07]: Great doc! I will vote Yes on it, but I wanted to discuss two issues first, one is a Discuss-level problem and the other one a Comment that I'd like you to consider.
The first issue is that Section 2.3 suggests 16-bit vendor space
attribute number fields to replace the existing 8-bit recommendation.
There are a couple of problems with this. First, if you really mean
to change the recommendation, then Updates: RFC 2865 header in the
beginning of the document would have been appropriate.
Secondly, while I agree with the advice of going for 16 bits, the
document is silent on some of the issues involved in such a change,
such as:
- Does RADIUS dictionary software support the VSA format for 16 bits, 8
bits, or both?
- How do you cleanly print or report VSAs when you do not know if the
field size is 8 or 16 bits? I realize that this situation already
exists since the format was never required to be followed, but
your new recommendation makes a potential problem much more likely
to appear. Previously, you could print something like Vendor = ACME,
Code = 17, Contents = ABCDEF0011... Now you couldn't do that.
- Can a vendor who moved from 8 bits to 16 bits deal with this?
Comment [2009-05-07]:
I do agree that for functionality FOO, both the functionality itself
and the MIB, RADIUS, etc. work should take place in the same standards
body. However, Section 3.1 could have said a couple of additional things
as well:
The issues of attribute space and choice of forum are distinct; there
is no reason why IETF couldn't use its own vendor code, for instance.
The section also does not mention one of the potential drawbacks of
SDO-driven development model: it is easy to come up with a number of
different solutions to the same generic problem, as opposed to finding
a common solution.
Ralph Droms:
Comment [2009-04-20]:
Trivial: does the "text" data type include a trailing '\0' byte? I ask because
there has been confusion about this point in DHCP options and it might be good
to make the convention explicit.
Lars Eggert:
Comment [2009-04-20]:
Section 2.1.1, paragraph 2:
> The Length field in the RADIUS packet header is defined in [RFC2865]
> Section 3. It is noted there that the maximum length of a RADIUS
> packet is 4096 octets. As a result, attribute designers SHOULD NOT
> assume that a RADIUS implementation can successfully process RADIUS
> packets larger than 4096 octets.
You may want to point out that even with messages less than 4096 but
larger than the PMTU, persistent IP fragmentation will be incurred,
which makes communication much more brittle, and might even want to
suggest that therefore RADIUS messages should be kept as small as
possible. See RFC5405 Section 3.2.
Adrian Farrel:
Comment [2009-04-18]:
Trivial, but...
Section 2.1.1 says that some address data types are in "network
byte order" while others are "most significant octet first". Is there a reason
for this difference?
I wonder if the text in seciton 4 should be stronger. You have...
This document does not require that the IANA update any existing
registry or create any new registry, but includes information that
affects the IANA, for example:
* includes guidelines that recommend against allocation from the
RADIUS standard attribute space in other SDO RADIUS Attribute
specifications.
But, in fact, IANA are bound by the registry rules already laid down and cannot
make allocations except following IETF process as defined by RFC 3575.
Russ Housley:
Comment [2009-04-20]:
The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
editorial suggestions.
ID nits complains that reference [8] appears in Appendix B.6 but not
in the References.
The Introduction Section should be a non-normative section. However,
Section 1.1 uses normative statements (RECOMMENDED and NOT
RECOMMENDED) before those terms are defined in Section 1.3.
The acronym AAA should be expanded.
When referring to the appendixes, I think the draft should talk about
appendixes, not about sections. For example, it should talk about
Appendix A.5, not about Section A.5.
Alexey Melnikov:
Comment [2009-04-21]:
This is a fine document. Some minor comments:
3.3. RADIUS Operational Model
The RADIUS operational model includes several assumptions:
* The RADIUS protocol is stateless;
* Provisioning of services is not possible within an
Access-Reject;
* Distinction between authorization checks and user
authentication;
* Authentication and integrity protection of RADIUS packets;
* The RADIUS protocol is a Request/Response protocol.
* Packet length restriction.
Half of this list is comprised from full sentences, the other half is not. I
would appreciate if you can make this consistent, otherwise it
is difficult to read/understand.
Tim Polk:
Comment [2009-05-06]:
It might be valuable to supplement the current security considerations section
with a discussion of issues that arise if SDOs do not follow the guidelines
presented here. For example, relying on MTU discovery to support transporting
large amounts of data could fail and result in denial of service, lost
accounting data, etc...
Robert Sparks:
Comment [2009-04-22]:
"the above procedure" in 3.1.1 (page 17) could be hard to follow for some
readers. Recommend providing a more explicit pointer.
Proposed Resolution: DiscussJoin me |