Alper Yegin wrote, around 14/11/07 8:51 AM:
Hi,
It is clear that any solution which requires a temporary ip-address
will create more turn on a BRAS, and the subscriber setup rate will
very likely go down compared to a solution which will finish
authentication before ip-address allocation.
Can you please elaborate on the impact of using a link-local or
DHCP-assigned IP address prior to running access authentication? Details
would help us understand the level of impact, and let us see if we can
identify any remedies.
Well if you use link local you need to stop the DHCP client stack which
means changing the DHCP stack which you have said is scary many times.
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.
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.
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.
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."
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.
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".
Alper
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
