[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DISCUSS and Sumary of feedback on draft-ietf-dhc-agentopt-rad ius-07.txt
I'd like to hear the reaction of the AAA doctors rather sooner than
later.
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.
>