> > 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 _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
