Alan DeKok wrote:
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".
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.
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.
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.
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.
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.
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.
That is a tribute to EAP and something the community should be happy
about as the alternative was that all those were doing there own
Authentication Protocols.
-Ric
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
