Subject: Issue 311: IESG DISCUSS comments

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Sep 2009 16:40:58 -0700

HTML clipboardIssue 311: IESG DISCUSS comments

Submitter name: Jari Arkko  

Submitter email address: [email-masked] 

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: Discuss

 EMAILING FOR THE GREATER GOOD
Join me

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Sep 2009 17:27:20 +0200

> beginning of the document would have been appropriate.

  Can a BCP update a standards track document?

> - Does RADIUS dictionary software support the VSA format for 16 bits, 8

  Most common RADIUS implementations support both.

>   Code = 17, Contents = ABCDEF0011... Now you couldn't do that.

  The key is that VSAs depend on a Vendor-Id.  See below.

> - Can a vendor who moved from 8 bits to 16 bits deal with this?

  Suggested text to resolve this issue:

Although [RFC2865] does not mandate it, implementations commonly
assume that the Vendor Id can be used as a key to determine the
on-the-wire format of a VSA.  Vendors therefore SHOULD NOT use
multiple formats for VSAs that are associated with a particular Vendor
Id.  A vendor wishing to use multiple VSA formats, SHOULD request one
Vendor Id for each VSA format that they will use.

> is no reason why IETF couldn't use its own vendor code, for instance.

  Yes.  I don't see a need to mention that in this document.

> different solutions to the same generic problem, as opposed to finding

  Section 3.1.3 says:

   Any new RADIUS attributes or values intended for interoperable use
   across a broad spectrum of the Internet Community SHOULD follow the
   normal IETF process, and SHOULD result in allocations from the RADIUS
   standard space.

> to make the convention explicit.

 RFC 2865 Section 5 already states explicitly that trailing '\0' bytes
are not to be used.

>   possible. See RFC5405 Section 3.2.

  Suggested text in 2.1.1:

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

> byte order" while others are "most significant octet first". Is there a reason

  Tradition.  I suggest changing all references to use "in network byte
order".

> make allocations except following IETF process as defined by RFC 3575.

  I think that's what the above text says.  Maybe the text could say:

	... recommend against SELF allocation ...

  The idea is to tell the SDOs that it's a bad idea to avoid IANA.

>   ID nits complains that reference [8] appears in Appendix B.6 but not

  It's a quote from another document.

>   RECOMMENDED) before those terms are defined in Section 1.3.

  The simplest thing to do is to move Section 1.1 to be after the
current Section 1.3.

>   The acronym AAA should be expanded.

  OK, fixed.

>   Appendix A.5, not about Section A.5.

  OK, fixed.

> is difficult to read/understand.

  I suggest the following re-write:

* The RADIUS protocol is stateless;
* Provisioning of services is not possible within an
  Access-Reject;
* There is a distinction between authorization checks and user
  authentication;
* The protocol provices for authentication and integrity
  protection of packets;
* The RADIUS protocol is a Request/Response protocol;
* The protocol defines packet length restrictions.

> large amounts of data could fail and result in denial of service, lost

  Suggested text:

Implementations not following the suggestions outlined in this
document may be subject to a problems such as ambiguous protocol
decoding, packet loss leading to loss of billing information, and
denial of service attacks.

> readers. Recommend providing a more explicit pointer.

  It should say "IETF process" instead of "the above procedure".

  Alan DeKok.

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

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Sep 2009 10:13:07 +0200

Bernard Aboba wrote:
> You might also mention that firewalls and other filtering devices often
> discard fragments.

  OK.

> Jari is correct that allocation requests will be handled according to
> RFC 3575,
> but as part of the Expert Review process, Design Guidelines will
> presumably be
> consulted.  So while self-allocation is certainly not a good practice,
> the whole
> point of IANA allocation is to enable consistent allocation.  Perhaps
> the text
> can be clear that the recommendations are relevant to Expert Reviewers
> appointed under the IANA considerations of RFC 3575, not for IANA itself.

  OK.  I suggest adding a first bullet about this point to the IANA
considerations section:

...
affects the IANA, which:

* includes specific guidelines for Expert Reviewers appointed
  under the IANA considerations of [RFC3575]
* includes guidelines that recommend against self allocation from
  ...

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 Sep 2009 09:48:03 -0700

looks good.

> Date: Fri, 4 Sep 2009 10:13:07 +0200
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: Issue 311: IESG DISCUSS comments
> 
> Bernard Aboba wrote: