Hi Ric,
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. Alper> This is not a hack and it is already available and used. If we go with IPv4 or IPv6 link-local address configuration before PANA authentication, changing from IPv4 link-local to non-link-local, or adding global IPv6 to link-local IPv6 is what we need and is already done on host stacks. 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. Alper> Performing PANA before configuring host via DHCP enables what you are seeking. 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. Alper> I understand how line identifier is used in the current systems, due to lack of any crypto-based authentication. I'm wondering if we still need that even if we are authenticating the subscribers via EAP? 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. Alper> As I understood earlier, L2 edge that performs per-packet access control relies on snooping DHCP messages to learn who is "authorized" to access the network. This is an implicit method. Based on this understanding... Alper> Since we'd be using DHCP after PANA, the L2 edges can keep relying on the same mechanism. Regards, Alper _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
