|
I've looked at
draft-ietf-dhc-agentopt-radius-06.txt. Here’s my review: 1. “a RADIUS server SHOULD send only those attributes for which the relay agent can ensure that either the relay agent or the DHCP server will provide the associated service. “Comment 1: How does the RADIUS server know that the DHCP server will provide the associated service?2. “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.” # Attribute --- --------- 1 User-Name (RFC 2865 [3]) 4 NAS-IP-Address (RFC 2865) 6 Service-Type (RFC 2865) 25 Class (RFC 2865) 26 Vendor-Specific (RFC 2865) 27 Session-Timeout (RFC 2865) 30 Called-Station-Id (RFC 2865) 31 Calling-Station-Id (RFC 2865) 32 NAS-Identifier (RFC 2865) 44 Acct-Session-Id (RFC 2866 [5]) 50 Acct-Multi-Session-Id (RFC 2866) 87 NAS-Port-Id (RFC 2869 [6]) 88 Framed-Pool (RFC 2869) 100 Framed-IPv6-Pool (RFC 3162 [8])Comment 2: Newer EAP authentication protocols allow the RADIUS server to authenticate multiple identities. What if the RADIUS server is authenticating multiple identities user and machine? Which identity should it return?Comment 3: The para possibly imposes a major constraint on RADIUS implementations by requiring them to return User-Name attribute. Not all RADIUS servers return this attribute.Comment 4: The para requires the DHCP relay agent to send many RADIUS attributes to the DHCP server. In addition, the interoperability impact is unclear if the DHCP relay does not forward certain attributes (like Vendor-Specific). Instead, can’t we achieve the same thing if the RADIUS server returns one additional RADIUS attribute (DHCP-user-class) specifically designed to be handled by DHCP relay-agents. The DHCP relay agent only forwards the single attribute DHCP-user-class to the DHCP server. The DHCP server can then assign configuration options based on this option.Regards,Ashwin
|