RADIUS Design Guidelines
draft-ietf-radext-design-19

[Ballot comment]
2.  Guidelines

        Attributes within the standard space are appropriate for this
        purpose, and are allocated via IANA as described in [RFC3575].
        Since the standard space represents a finite resource, and is
        the only attribute space available for use by IETF working
        groups, vendors and SDOs are encouraged to utilize the VSA
        space, rather than requesting allocation of attributes from the
        standard space.  Usage of attribute type codes reserved for
        standard attributes is considered anti-social behavior and is
        strongly discouraged.

In the last sentence: I think you meant "Unauthorized usage of attribute type codes ..."

[Ballot comment]
>                        RADIUS Design Guidelines

  Since this document actually describes design guidelines for RADIUS
  *attributes*, the title isn't really accurate. Maybe "Design
  Guidelines for RADIUS Attributes"?


Section 1., paragraph 5:
>    Reviewers of RADIUS spcifications are expected to be familiar with

  Nit: s/spcifications/specifications/


Section 2.1.1, paragraph 3:
>    Even when packets are less than 4096 octets, they may be larger than
>    the Path Maximum Transmission Unit (PMTU).  Any packet larger than
>    the PMTU will be fragmented, making communications more brittle as
>    firewalls and filtering devices often discard fragments.  Transport
>    of fragmented UDP packets appears to be a poorly tested code path on
>    network devices.  Some devices appear to be incapable of transporting
>    fragmented UDP packets, making it difficult to deploy RADIUS in a
>    network where those devices are deployed.  We RECOMMEND that RADIUS
>    messages be kept as small possible.

  Thanks for addressing my comment from 2009 in the new version!
  (You may also want to point the reader at RFC5405, Section 3.2 here.)


Section 3.2.3., paragraph 4:
>        administator to enter the data as well-known types, rather than

  Nit: s/administator/administrator/


Section 5., paragraph 6:
>    IPSec.  See [RFC3579] Section 4, and [RFC3580] Section 5 for a more

  Nit: s/IPSec./IPsec./


Appendix A, paragraph 15:
>    Section A.2.2 descibes more complex data types which should be

  Nit: s/descibes/describes/

[Ballot comment]
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.

[Ballot discuss]
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?

[Ballot comment]
The section on complex attributes IMO bypasses some of the considerations.
Let me say that I agree with the recommendation to avoid complex
attributes. But I think there can be cases where it really does not
matter what the contents of an attribute are, and the format of a string
carried in an attribute does not lead to code changes. For instance, when
the string is something configured at the other end and fed to a different
software component in another. As an example, I wouldn't think Radius
code needs to understand filters; it should be able to pass them on down
to something like ipfilter or iptables.

[Ballot comment]
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...

[Ballot comment]
I have a question about some parts that look a lot like editorial
requirements for future Internet-Drafts:

Section 2.1.3 (paragraph beginning with "If the RADIUS Server") seems
to suggest that complex data types are OK if they're split to two
Internet-Drafts (and only one of these drafts mentions the word
"RADIUS").

Section 2.1.5 (1st paragraph) seems to say that if you define a
protocol and RADIUS attributes for it, you can't do that in a single
Internet-Draft, but need two.

Both of these are certainly possible design guidelines (and have
been followed to some degree), but could you provide some
background on why the WG decided to include these largely
editorial recommendations?

[Ballot comment]
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.

[Ballot comment]
This is a fine document. Some 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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

message from the WG Chair: There are still issues open on this.  Now that we have new boilerplate, it will be
possible to submit a new draft addressing them.  Then we can have a two
week WG "last look" to confirm consensus on the changes, and send it on
to the IESG.

Proto write-up from proto-shepherd Bernard Aboba

Title:  RADIUS Design Guidelines
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt

Status: Best Current Practice

Response to template:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes. The ID has had 2 working group last calls.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No concerns. 

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

There is solid consensus behind this document.  The overall approach to the document has been extensively discussed, both in IETF meetings and on the mailing list.  Over a dozen people have commented on various aspects of the document during its development.  The issues raised in WG last call, available for inspection at http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -05 version of the document.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes. An output of the run on this revision of the ID by the online nits
checker:

idnits 2.08.10

tmp/draft-ietf-radext-design-05.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:

----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:

----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:

----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Best Current Practice

----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '8' on line 1431
    'The Text field consists of UTF-8 encoded 10646 [8] characters....'


    Summary: 0 errors (**), 0 warnings (==), 1 comment (--).


8) Does the document a) split references into normative/informative,
  and b) are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (Note: the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

The document does split references into normative and informative ones.
There are no normative references to IDs.

9) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

  This document provides guidelines for the design of attributes used
  by the Remote Authentication Dial In User Service (RADIUS) protocol.
  It is expected that these guidelines will prove useful to authors and
  reviewers of future RADIUS attribute specifications, both within the
  IETF as well as other Standards Development Organizations (SDOs).

  - Working Group Summary

    There have been 2 WGLCs on the document.  Much of the discussion on
    the document has centered around the design guidelines
    surrounding complex attributes, as well as the relationship of the
    RADIUS Vendor-Specific Attribute (VSA) and the Standard attribute
    space.  There was also considerable discussion relating to the
    process for review of RADIUS attributes specified by SDOs. 
    Ultimately, a consensus developed behind a model similar to that
    described in [RFC4663].