RE: DISCUSS and Sumary of feedback on draft-ietf-dhc-agentopt-rad ius-07.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Ralph, it seems to me that the changes you have suggested/proposed below
do at least address the concern of "truth in advertising" or "setting correct
expectations". But I do not see an answer that really addresses my
biggest DISCUSS issue and that is the truncation issue.

Thanks,
Bert 

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: vrijdag 30 juli 2004 14:25
> To: Wijnen, Bert (Bert)
> Cc: Thomas Narten (E-mail); Margaret Wasserman (E-mail); David Kessens
> (E-mail); Aaa-Doctors (E-mail)
> Subject: Re: DISCUSS and Sumary of feedback on
> draft-ietf-dhc-agentopt-radius-07.txt 
> 
> 
> 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.
>