Richard Pruss wrote: >> But does DHCP have to carry the authentication itself, or just the >> notification that authentication is required? i.e. Can't the DHCP >> server just say "you must do PANA/EAPoL before I give you a lease". > > When we work through the details of the system for authenticate later > with PANA/EAPoL or Web Authentication, some problems arise here are some: > 1. @Domain in the authentication is typically used by wholesale DSL > providers to choose which ISP and thus IP address domain you are in. If > you get that information after the IP address needs to be allocated, you > need to do some two step hack to re-address the client after authentication.
Yes, it's a problem. Can't the DHCP relay just respond to the DISCOVER with a response "Authentication required"? It doesn't have to assign a lease. As you pointed out, it *can't* assign a lease until after authentication has succeeded. The "DHCP authentication required" response could be a DHCP OFFER packet, with some new options. The endpoint would interpret those options as requesting authentication. The switch would interpret the DHCP offer as it does today: "the lease is not yet assigned, do not forward IP traffic". > 2. DHCP auth is far more about getting configuration information from > very large existing AAA databases (currently used for PPPoE and the SP > operations processes around those) and correctly configuring the Host > and the NAS with that information than "Authentication". Authenticating > later does not solve the real problem of getting the client information > from the AAA databases without changing the AAA and operational > infrastructure supporting millions of live users. I see it is valuable to tie DHCP parameters to a particular authentication session. This is a known problem in 802.1x wired authentication today, where the end device does not know that 802.1x is required, and does not know which authentication domain to use. It would be wonderful to use DHCP to carry the information that authentication is required. It would be wonderful to use DHCP to carry information about the authentication domain. It would be very bad to use DHCP as a transport protocol for authentication. > 3. The current proposal requires a change to the Home Gateway and NAS > but as it uses functions in the system that assume DHCP other solutions > would be needed for: > 3.1 Line ID - currently the DSLAM or first hop L2 switch (in MetroE) > marks the residential line into Option 82 in DHCP (or PPP tag in PPPoE) > this is used to support the credentials in authentication (Something you > are, Something you know, etc.) or at least inform the choice of > configuration. This would mean that we would need some new mechanism to > snoop PANA and insert Line ID. When I evaluated this PANA could not be > snooped but Alper tells me this has changed. This kind of thing is done already for EAPoL (or 802.1x). The switch collects the EAPoL traffic from the EAP client, packages it into a RADIUS request, and adds a set of auxiliary information like port, line ID, port MAC address, etc. This solution is available in most switches, and is widely deployed. It also means that the policy enforcement point is the L2 switch, which prevents a number of local network attacks from unauthenticated endpoints. > 3.2 Source Address Verification, ARP protection, Layer 2 VLAN security > policies - Most vendors now snoop the DHCP as the major mechanism > informing the layer 2 protections against a host of bad behaviours. As > we move content that was behind the NAS to in front of the NAS these > protections are even more important not just for Layer 2 but also for > any Layer 3 content devices like VOD pumps etc. With the DHCP auth > proposal the DHCP transaction continues in this function but with the > PANA/EAPol approach we would need a policy distribution mechanism to > contact the L2 edge and change the policies post authentication. If the L2 edge is acting as an authentication proxy, it can be informed of the policies when authentication succeeds. These include VLAN information, etc. Those policies can be much more complex than what can be inferred by snooping DHCP. The policies are also explicit, whereas with DHCP they are implicit. (e.g. assignment of IP means allowing only that IP) > 3.3 Introducing changes to the DSLAMs and L2 switches is far more > expensive for the SP to migrate to and the vendors to impliment. If the deployed DSLAMs and L2 switches already support 802.1x, then the proposal outlined here would likely not require changes to the switches. It would require small changes to a DHCP server, and small changes to the DHCP clients. If, however, the equipment does not support 802.1x, then the solution becomes more complicated. I'm concerned, though, about *not* using an existing solution simply because it has deployment costs. Adding EAP to DHCP also has deployment costs, and is yet another overlapping solution to the network access problem. Alan DeKok. _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
