Richard Pruss wrote: > I think you have misunderstood the draft, possibly I was not clear > enough, two points of clarification for you concerns: > 1. In the draft the DHCP server is the NAS and it has layer 2 restricted > relationship with the device offering credentials. There is no > technical difference between where this is running and where and PPPoE > is used, the only difference is that after authentication, services like > multicast can be introduced from Layer 2 devices before the NAS, which > is why providers want to move from PPPoE.
I do agree that DHCP has to be part of the solution to this problem. Most clients will do DHCP before anything else, so putting some kind of tie in to authentication requirements in DHCP is very useful. 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". > 2. In the second option in the draft one may run EAP over DHCP which can > be as encrypted and signed to your hearts content. i.e. Yet another transport layer for EAP. We already have PPP, EAPoL, PANA, RADIUS, Diameter, etc. to carry EAP. I'm wary of adding one more. And my issue isn't the signing and encrypting part. It's that we already have solutions to these problems. The protocols exist, and in some cases, are deployed on tens of millions of clients. Rather than updating the DHCP stack to do EAP, it would seem to be much easier to have the DHCP stack *inform* the rest of the system that authentication was required. The system could then do PPPoE, PANA, EAPoL, or whatever else was appropriate for the link. Alan DeKok. _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
