Re: DISCUSS and Sumary of feedback on draft-ietf-dhc-agentopt-radius-07.txt

[Ralph Droms <rdroms@cisco.com>]

Bert - I've included below a response to the comments from the aaa-doctors,
written in collaboration with John Schnizlein (the other co-author of the
draft).  We began composing this response earlier this week, after receiving
Bernard's summary, so in the interest of proceeding as quickly as possible,
we are forwarding this response rather than delaying the process by
re-editing it.

John and I have reviewed Bernard's summary of issues and agree
that issues 1, 2 and 3 remain open.  We think that those issues can be
resolved quickly, based on the helpful text suggested by Dave
Nelson.  Here are our proposed resolutions for the three issues:

1. Negotiation of NAS/RADIUS server support (David Nelson, Ashwin Palekar)
The issue raised is that the draft does not specify a mechanism by which
the RADIUS server can know if the NAS supports this specification.  This
issue is in part related to Issue 2, the MTU limitation and
Issue 8, which proposes addition of a RADIUS attribute that might
allow a NAS to signal support for this specification.

Ralph's reply:

"Because the RADIUS server and NAS are in the same administrative
domain, the RADIUS server can be configured to return the appropriate
attributes to the NAS, sized to fit in the RADIUS Attributes sub-option,
and the RADIUS server can be aware of whether the NAS is configured to
use the RADIUS Attributes sub-option.

AAA-Doctor response: Issue not resolved

"Today RADIUS is frequently used in situations in which the NAS and RADIUS
server are not within the same administrative domain. An example of this
are roaming arrangements between hotspot operators, which are becoming
increasingly common.  It may also be difficult for the RADIUS server to
be aware of the NAS capabilities in large heterogeneous networks where
the operator may deploy NASes from different vendors or utilizing
different firmware versions.  In these situations, keeping track of
the capabilities of each device can be a major challenge.

Without providing a mechanism by which the NAS can inform the
RADIUS server of its maximum supported MTU, in these circumstances
the RADIUS server cannot be assumed to be aware of the limitation."

Proposed resolution:

Add the following text (based on text suggested by Dave Nelson) to the
end of Section 1, Introduction, to make explicit the assumption that
the RADIUS and DHCP services are in the same administrative domain:

   The scope of applicability of this specification is such that
   robust interoperability is only guaranteed for RADIUS service
   implementations that exist within the same scope as the DHCP
   service implementation, i.e. within a single, localized
   administrative domain.  Global interoperability of this
   specification, across administrative domains, is not required.

Interoperability across administrative domains is not a requirement because
this mechanism, intended to transmit authentication and identity information
from the RADIUS service to the DHCP service, would not be used in a scenario
in which the RADIUS service and DHCP service were not in some way
coordinated by a common administration to make use of that shared information.

2. Handling of truncation (Bernard Aboba, David Nelson, Ashwin Palekar,
Paul Funk)

This issue relates to limiting the maximum size of the attributes
returned by the RADIUS server.  The comments suggest that the limitations
be relaxed.  This comment relates to Issue #1 in part because without
negotiation there is no way for a RADIUS server to know what that the
maximum packet size is less than the 4096 specified in RFC 2865.

Ralph's reply:

"While RFC 3396 enables encoding of long options in DHCP, it does not
specify the encoding of long relay agent option sub-options.
Therefore, the RADIUS Attributes sub-option is still contrained to
carry 253 octets of data."

AAA-Doctor response: Issue not resolved

"In -07, the number of attributes which may be included within the
sub-option has been substantially reduced.  However, the possibility
of exceeding the 255 octet MTU limitation remains.  Note that while
the draft imposes a limitation on *all* RADIUS attributes,
it would appear that the limitation applies only to the
total length of the attributes specified in Section 4:
User-Name, Service-Type, Class, Vendor-Specific, Session-Timeout,
Framed-Pool, Framed-IPv6-Pool.

The authors are correct in stating that "there is no standard for
encoding long relay agent option sub-options (the equivalent of
RFC 3396 for sub-options)", and in fact it would be necessary
to encode a long sub-option as well as a long outer DHCP
Relay option to overcome the 255 byte limitation.

However, it seems to me that this is an important enough problem
that a long sub-option mechanism should be defined. In a quick
read of RFC 3046, I didn't see that repeating a sub-option is
precluded.(though I won't guarantee I didn't miss it). If that's true,
the fragmentation of the RADIUS attributes sub-option could be
defined within this draft without violating any rules. Alternatively, a
separate draft for long sub-options (similar to RFC 3396) could be
proposed in conjunction with this draft.

I think eliminating the 255 byte limitation is necessary in order for
this mechanism to be robust."

Proposed resolution:

As a practical matter, due to the limit on the size of a DHCP message and
the observation that the relay agent inserts relay agent options without the
knowledge of the DHCP client, it is unlikely that a site using this
specification would configure the RADIUS and DHCP relay service to use a
RADIUS attributes sub-option longer than 255 bytes.  As the RADIUS service
and the DHCP service will be managed in the same administrative domain, the
RADIUS service can be configured to return attributes that will be
guaranteed to fit in the RADIUS attributes sub-option.

3. Normative language updating or contradicting RFC 2865 (Bernard Aboba,
David Nelson, Greg Weber)

In a number of places, the draft specifies changes to the behavior of RFC
2865, using normative language.  There are also places where the draft
contradicts itself with respect to use of attributes in Access-Requests
rather than in the Access-Accept.  This comment suggests that the
normative language be removed and that the contradictions be resolved.

Ralph's reply:

"The table in section 4 was derived from the list in RFC 3580.  We will
remove attributes 4, 30, 31, 32, 44, 50 and 87, which appear not to be
valid in Access-Accept messages.  There is no intent for the NAS to
supply any attributes to the DHCP relay, so there is no conflict with
the text quoted from Section 5."

AAA-Doctor response: Issue not resolved

"Section 4 of -07 states:

   The RADIUS server that implements this specification MUST be
   configured to return the User-Name and Class attributes to the NAS,
   and MAY return other attributes.

If it is desired that the RADIUS server change its behavior based
on the NAS implementation of this specification, then it is
necessary for the NAS to inform the RADIUS server that the
specification has been implemented (see Issue #1).  I'd suggest
that the above sentence be deleted, since Section 5 states:

   The relay agent SHOULD include the User-Name and Class attributes in
   the RADIUS Attributes sub-option if available, and MAY include other
   attributes."

Proposed resolution:

Change the first paragraph of section 4 to read:

   The RADIUS server that implements this specification SHOULD be
   configured to return the User-Name and Class attributes to the NAS,
   and MAY return other attributes.

Note that we suggesting changing this text, rather than deleting it,
because this text describes the behavior of the RADIUS server and the
text in section 5 applies to the behavior of the DHCP relay agent.

Add the following text (suggested by Dave Nelson) as a second
paragraph in Section 2, Terminology:

   The use of the standard keywords MUST, SHOULD, MUST NOT and SHOULD
   NOT within this specification are with respect to RADIUS clients
   and servers that implement the optional features of this
   specification, do not create any normative requirements outside of
   that scope and do not modify the base RADIUS specifications, such
   as RFC2865 or RFC2866.