[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DISCUSS and Sumary of feedback on draft-ietf-dhc-agentopt-radius- 07.txt
Ralph, this is the result.
I have recorded my discuss in ID-tracker as follows:
DISCUSS:
1. Truncation issue.
The truncation issue raises objections from several reviewers,
and other objections related to the inability of the RADIUS
server to determine that the lower MTU was in effect.
As a result, it seems that the truncation issue is the
fundamental problem here.
Eliminating the 253 byte limitation is necessary in order
for this mechanism to be robust.
See detailed issues 1 and 2 from the AAA-doctor review
summary (review of revision 07).
There are a number of ways in which this can be handled.
Paul Funk has made a suggestion about enabling long options
and is probably the most general way.
But the DHC WG may also have other ideas on how to fix this.
If I understand the discussion correctly then the original
purpose of this specification was to allow a RADIUS server
to send a Framed-Pool or Framed-IPv6-Pool attribute to
802.11 APs, much as it does today in dialup networking
situations. The idea was to allow existing RADIUS server
functionality to be used with new media without the
needs for changes to RADIUS servers, proxies, etc.
Restricting RADIUS servers to 253 octets of attributes without
a means of informing them of the restriction, or limiting
inter-domain use of RADIUS (something which is widely deployed
today) in order to use an existing RADIUS server facility
takes us fairly far from the original design goals.
In particular, in large networks with many RADIUS clients,
it can be quite difficult to keep track of the capabilities
of each client. Frequently the capabilities can vary by the
characteristics of the client, the firmware load, etc.
In that kind of environment, requiring the RADIUS server to
keep track of whether the client implements the DHCP options
draft, and therefore whether the MTU needs to be lowered can
be a large administrative burden.
2. Normative language updating or contradicting RFC 2865.
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).
The issue can be resolved if the above sentence gets 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."
-- End of DISCUSS text ---
Here follows a summary by Bernard. Based on that and on some follow on
checks and email discussions I have recorded the above DISCUSS.
I propose that it is best to at least post my above DISCUSS to the DHC WG
mailing list. Feel free to also post additional material from below.
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.