RE: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication

> > Alper> If you are using link-local IP address prior to PANA, that means
> > you don't attempt to configure an IP address using DHCP prior to
> > successful completion of PANA. That does not alter DHCP state machine.
> 
> <RMP> Well do not run until after PANA state for DHCP is an alteration
> of the DHCP state machine and of course a change in the DHCP client.

Not starting the DHCP client is the simplest way. And that, obviously, has
no change whatsoever on the DHCP SM or client.

> > Secondly to run PANA with link local to the NAS, you need to re engineer
> > all the layer 2 SAVA security because the link local addresses look like
> > spoofed addresses to the layer 2 switches and would be dropped.
> >
> > Alper> This statement gives me the impression that L2 SAVA is based on
> > snooping DHCP only and it cannot be touched at all. Well, this cannot be
> > true if you consider IPv6. It has to deal with link-local IP addresses
> > and a lot more. See
> > http://ietf.org/internet-drafts/draft-baker-sava-implementation-00.txt.
> > And btw, somehow I see IPv6 is being characterized as a "future" thing
> > that does not exist today, but I know IPv6 is deployed in several DSL
> > networks.
> <RMP>  Fred is proposing how SAVA for IPv6 could possibly work one day
> in the future.  There is a huge difference between that and the IPv4
> SAVA which is deployed.  I know of no residential DSL services in the
> work.  This is one thing I would love to learn I am wrong about, please
> name a provider doing residential IPv6 over DSL.

NTT. Since 2001.

> > If you couple that with all the rest of the extra mess of PANA discovery
> > stuff then it is obvious that DHCP authentication it is much, much
> > cleaner and leaner.
> >
> > Alper> If you can provide a technical point regarding the discovery, we
> > can understand better.
> <RMP> Provide a side to side comparison of PANA verse DHCP Auth
> including L2 switches and SAVA security in L2 and it is very obvious. I
> notice you have been careful just to cast smoke over the number Eric put
> out but not provided your own.

I already provided the numbers in response to Eric's email. Let me know if
you have a specific question.

Meanwhile, I hope you are seeing the fundamental problem: You cannot reduce
DHCP "load" if you "overload" DHCP with EAP.

> > If you run DHCP-assigned address prior to authentication.  The whole
> > layer 2 network is exposed to attack by unauthenticated IP end-point.
> > The SAVA done by DSLAMs and first hop switches is eliminated because
> > unauthenticated  users have DHCP assigned addresses.
> >
> > Alper> I don't see anything wrong with SAVA there. Up until the host
> > reconfigures its IP address using second DHCP after successful PANA,
> > there is the pre-PANA address that SAVA system checks.
> >
> > Alper> And. unauthenticated IP end-point does not have be a thread,
> > because the network can limit that host's traffic to just "running PANA
> > with the PAA."
> <RMP> How?  Please specify which elements need to run what shiny new
> protocols and how this done.

There is no protocol in there. It's all filtering.

> > Not to mention thet obvious point that every renew during the
> > unauthenticated period is extra messaging which for 60K-500K  subscriber
> > access networks are effectively huge extra message loads on everything
> > in the DHCP path.
> >
> > Alper> As I have explained to Eric, if you are concerned about "load on
> > DHCP path", loading more things to DHCP like access authentication is
> > not going to help with reducing that load. This is fundamentally
> > contradicting.
> >
> > Plus the point that you are now saying that 60 seconds is too short for
> > the renew, which means that from around 10-15 second logins, which we
> > have today, the latency is going to 60 seconds +.
> >
> > Alper> Sorry I couldn't follow this. What latency is that 60+? DHCP
> > lease for the pre-PANA address shall be long enough to accommodate
> > typical access authentication latency in order to reduce the possibility
> > of renewals.
> <RMP>Latency from user line up until services is now some unspecified
> large number.

I didn't understand your point (or conclusion?).

> > Worse than that, the worst time for access is after a massive power
> > outage where we have heard of is 20 minutes during recoveries due to AAA
> > server loads and for this vulnerable time with PANA the DHCP has 20
> > extra renew per client which is millions of extra messages smashing
> > things up.
> >
> > Alper> Have you considered how many EAP/DHCP retransmissions are going
> > to occur due to EAP retranmissions during that 20 minutes? Assuming no
> > crazy EAP implementation or configuration would have a 60-second timeout
> > for retranmissions, the answer is at least "more", if not "a lot more".
> 
> <RMP>Assuming both proposals use the same EAP method through the AAA
> path, main difference is all the extra messages on the DHCP path to the
> server from PANA. Unless of course you fully couple PANA to the DHCP
> relay stack and do local caching for the relay responses as you have
> said in the past.  

I never said such a thing. I suspect you are confusing someone else's
statement about some other scenario/proposal.

> Which when one gets down to the real implementation
> impact of PANA has to do exactly the same things as DHCP Auth in the CPE
> and the BRAS DHCP stacks, and has the additional impacts to other
> elements that DHCP auth leaves untouched.

Disagree, as explained throughout this thread.

Alper

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg