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