[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Sumary of feedback on draft-ietf-dhc-agentopt-radius-07.txt
Thanks Bernard and other AAA-doctors.
So it seems we have 3 issues left. It feels (but I am not 100% sure)
that you would want me to keep a DISCUSS for those (A DISCUSS means
that we MUST get a fix or an acceptable answer before the doc gets
approved. It does indeed delay approval, so we have to be aware of that).
Any comments on this? I.e. do we really want to get all 3 remaining
issues resolved? We (in IESG) aks ourselves for std track documents:
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
So must the 3 issues be resolved before we can consider this documenty
"a reasonable basis..."
I would appreciate answers to that question asap, so that I can forward the
below to the DHC WG on Monday.
Thanks,
Bert
> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: vrijdag 23 juli 2004 20:58
> To: aaa-doctors@ops.ietf.org
> Subject: Sumary of feedback on draft-ietf-dhc-agentopt-radius-07.txt
>
>
> On April 28, 2004, Bert Wijnen sent a message to the AAA-Doctors list
> requesting a review of draft-ietf-dhc-agentopt-radius-06.txt:
> http://ops.ietf.org/lists/aaa-doctors/2004/msg00005.html
>
> Comments came back from the following individuals and were
> incorporated in
> Draft Tracker on May 24, 2004:
>
> 1. Bernard Aboba:
> http://ops.ietf.org/lists/aaa-doctors/2004/msg00006.html
>
> 2. David Nelson:
> http://ops.ietf.org/lists/aaa-doctors/2004/msg00007.html
>
> 3. Greg Weber:
> http://ops.ietf.org/lists/aaa-doctors/2004/msg00008.html
>
> 4. Ashwin Palekar:
> http://ops.ietf.org/lists/aaa-doctors/2004/msg00009.html
>
> 5. Paul Funk:
> http://ops.ietf.org/lists/aaa-doctors/2004/msg00010.html
> http://ops.ietf.org/lists/aaa-doctors/2004/msg00011.html
>
> A reply was received from Ralph Droms on June 23, 2004:
> http://ops.ietf.org/lists/aaa-doctors/2004/msg00038.html
>
> This message summarizes the AAA Doctor response to
> Ralph's reply.
>
> SUMMARY
>
> A total of 9 issues were raised. Based on the AAA-Doctor
> responses, 6 of those issue are now resolved, while 3
> remain open. The status of the issues is as follows:
>
> Issue Title Status
> ------ ----- ------
>
> 1 Negotiation Open
> 2 Truncation Open
> 3 Normative Language Open
> 4 Conflicts Resolved in -07
> 5 Compatibility Resolved in -07
> 6 Authz Lifetime Resolved in -07
> 7 Correlation Resolved in -07
> 8 New Attribute Resolved in -07
> 9 Editorial Issues Resolved in -07
>
>
> DETAILED ISSUE STATUS
>
> 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."
>
> 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."
>
> 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."
>
> 4. Conflicts between DHCP and RADIUS server IP address
> allocation (David
> Nelson)
>
> This is a request for clarification of the relationship between RADIUS
> server IP address allocation (via Framed-IP-Address) and DHCP server
> allocation.
>
> Ralph's reply:
>
> "The table in section 4 lists the attributes that can be used with the
> RADIUS Attributes sub-option, and specifically does not include
> Framed-IP-Address. Is that sufficient? Also, wouldn't
> Framed-IP-Address typically not be used with 802.1X authentication?
>
> AAA-Doctor response: Issue resolved in -07.
>
> "Perhaps it could be stated explicitly that if the Framed-IP-Address
> is returned the DHCP relay will ignore it."
>
> 5. Compatibility with User-Name privacy & Multiple identities (David
> Nelson, Ashwin Palekar)
>
> The question here relates to situations in which the User-Name is kept
> private ("@example.com") or in which the EAP identity is
> different from
> the User-Name. For example, there is a new proposal for addition of a
> "billable identity" attribute in RADEXT WG. Should this new "billable
> identity" attribute be included in the list in Section 4?
>
> Ralph's reply:
>
> "Many DHCP services make use of different pieces of information about
> the DHCP client to determine the exact configuration information,
> including the assigned IP address, to be returned to the client. The
> intent of this sub-option is to make attributes supplied by the RADIUS
> server, such as the User-Name, available to the DHCP server as part of
> the information available about the DHCP client.
>
> AAA-Doctor response: Issue resolved in -07.
>
> "I can see that a DHCP server might make sensible use of a
> User-Name, for example by looking up the group membership of the user
> and making host configuration policy decisions based on that group
> membership. I guess my concern here was that *other* uses
> could be made
> of the User-Name information, which would put DHCP servers in the role
> of AAA servers. IMHO, that would be a Bad Idea (tm). Since it seems
> inappropriate to attempt to place restrictions on DHCP server
> implementation issues in an "over-the-wire" protocol
> document, I'll not
> push this issue further, even though I still have nagging doubts."
>
> 6. Lifetime of authorization data (Greg Weber)
> This comment relates to how long the authorization data may
> be cached at
> the NAS before it goes stale. It is possible that the Session-Time
> attribute may help with this.
>
> Ralph's reply:
>
> "We assumed that the NAS would only insert the attributes received
> from the RADIUS for the duration of the 802.1X session. We can
> clarify if necessary. While we recognize there is no guarantee that
> DHCP will be used with 802.1X, we expect that there will be many cases
> in which the DHCP will be used through an 802.1X authorized port."
>
> AAA-Doctor response: Issue resolved in -07.
>
> "I went through the -07 draft. I believe the issues that I
> raised are resolved or can otherwise be closed.
>
> Regarding the authorization data lifetime, the draft proposes
> behavior that seems analogous to the use of the Class attribute
> in service provider deployments that use separate servers for
> authentication and accounting. The authentication server may
> return one or more Class attributes to the NAS without knowing
> whether they are actually used by the accounting server to
> which they are eventally sent; and the Class attributes are
> cached for the life of the session. So, I think it's reasonable
> to say the RADIUS attributes suboption data is also cached for
> the duration of the user session."
>
> 7. Correlation (Greg Weber, David Nelson)
> This comment relates to how RADIUS & DHCP requests can be linked,
> presumably for debugging purposes. Section 4 includes
> Acct-Session-Id or Acct-Multi-Session-Id in the list of potential
> attributes, so this may be part of the answer.
>
> Ralph's reply:
>
> "No guidance is needed because 802.1X enables forwarding on a single
> port switch port for a single host. Any DHCP messages
> received on that
> port then presumably were sent by the just authorized host."
>
> AAA-Doctor response: Issue resolved in -07.
>
> "IMHO, the answer to the question raised in the comment is
> "Yes, in many
> cases the correlation will be by MAC address". The notion of
> one-station-one-switch-port, is a special case of 802.1X (albeit the
> design-center). In general, there are the shared media cases to be
> considered. Certainly for any 802.11 access points, and even
> for 802.3
> switch ports with multiple attached stations, via a hub or
> VoIP phone."
>
> 8. Alternative approach: New RADIUS attribute for DHCP options (Ashwin
> Palekar, Paul Funk)
>
> This comment suggests the creation of a new RADIUS attribute
> in order to
> allow the server to explicitly indicate which attributes are
> to be sent to
> the DHCP server. It may relate to Issue #1 in that if such an
> attribute
> were created, it might be possible for the NAS to use it to indicate
> support for the specification.
>
> Ralph's reply:
>
> "Yes, the use of a new DHCP-user-class attribute would be an
> alternative design. The first draft of this specification included a
> specific options for the User-Name and a new User-Class attribute. We
> were given wise counsel by the dhc WG to avoid the requirement of
> establishing a new registry. Therefore, the current design reuses the
> existing attributes for simplicity."
>
> AAA-Doctor response: Issue Resolved.
>
> 9. Editorial issues (David Nelson)
>
> This issue related to an editorial NIT within one of the figures.
>
> AAA-Doctor response: Issue resolved in -07.
>