Alper Yegin wrote, around 15/11/07 9:23 AM:
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.
<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.
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.
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.
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.
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.
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. 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.
- Ric
Alper
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
