Subject: RE: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication

From: pavan_kurapati <[email-masked]>
Date: Fri, 2 Nov 2007 17:43:41 +0530

Hi,

I think it is a good idea to extend DHCP for providing subscriber authentication given that other approaches are more complex. I think most of the service providers supply their own Residential Gateways and it is RGs which initiate PPPoE/DHCP. Those who use their modems in plain bridging mode and rely on 3rd party devices (including PCs and other routers) may have to continue with PPP for the migration.  Coming to the alternative approaches

1. PANA needs considerable re-work like PANA snooping on DSLAM to install L2 filters, and PANA support on RG,BNG and also a tweak in the way DHCP functions.
2. There are some deployments which use 802.1x directly and let the DSLAM talk to AAA  and do the authentication. In this case, RG initiates 802.1x and DSLAM acts as authenticator. But it is always preferred to have the authentication done at BRAS than at the DSLAM. So, 802.1x in its current form may not be suitable for all the service providers offering DSL service.

Ofcourse, if 802.1af is available which enables forwarding 802.1x frames to BRAS, then this looks more efficient than changing DHCP. It depends on how long it takes to become a standard.

Thanks,
Pavan Kurapati

________________________________________
From: Ralph Droms [[email-masked]]
Sent: Wednesday, October 31, 2007 6:43 PM
To: [email-masked]
Subject: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication

Second try - still soliciting expert DHCP input (as well as any other
input you might care to provide) from dhc WG members...

There is a lengthy discussion about rechartering the dhc WG to take
on the DHCP authentication proposals in draft-pruss-dhcp-auth-
dsl-01.txt and draft-zhao-dhc-user-authentication-02 in the int-
[email-masked] mailing list.  Both of these drafts have been submitted
for to the WG for review in the past, and neither, to date, has been
accepted as a dhc WG work iterm.  I've included a copy of the initial
posting, http://www1.ietf.org/mail-archive/web/int-area/current/
msg00957.html, below.  Because this discussion may lead to the
rechartering of the dhc WG to take on either or both of these drafts
as new work items, those of you not on the int-area mailing list
should consider reviewing the e-mail thread and contributing to the
discussion.

- Ralph

=====
To: Internet Area <int-area at ietf.org>
Subject: [Int-area] DCHP-based authentication for DSL?
From: Jari Arkko <jari.arkko at piuha.net>
Date: Thu, 04 Oct 2007 23:22:15 +0300

We talked about the DSL requirements earlier on this list. Now
they have sent us a liaison statement regarding what they would
like to do:

"At this time, we would like to make the IETF aware that during
our most recent DSL Forum quarterly meeting, the Architecture
and Transport Working Group agreed to seriously consider adopting
a mechanism such as that proposed in draft-pruss-dhcp-auth-dsl-01.txt
or draft-zhao-dhc-user-authentication-02. We understand that the authors
of these specifications intend to produce a combined document soon.
The DSL Forum formally requests that the IETF adopt this as a work
item, and would appreciate being advised of progress as soon as
possible.

Our next quarterly meeting is December 10-13, in Lisbon, Portugal."

How do we feel about this? Is this a good idea, considering the DSL
architecture? How will it affect DHCP the protocol? How would
you go about making DHCP extensions so that they work best
for all possible environments and not just DSL? Is anyone
already working on the combined draft promised above? Are
there any other choices that we should recommend instead?

I would like to hold the discussion on this in this list until
we've determined that the DHCP protocol is the right tool
for the job. If it is, we can recharter DHC WG again to add
the actual development work there. (DHC is right now
being rechartered but that recharting is mostly a cleanup
and not the addition of functionality to do this.)

Jari

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 2 Nov 2007 14:50:27 +0200

Hi, 

> 1. PANA needs considerable re-work like PANA snooping on DSLAM to install
> L2 filters, 

How is setting up a different filter on the devices that already know how to
setup filters considered a "considerable re-work"? I'd appreciate if you can
tell us how this is anything more than simply setting up a filter rule.

> and PANA support on RG,BNG 

I hope you are aware that what appears like saving PANA implementation on RG
and BNG are in fact coming back in the form of DHCP growing PANA from within
-- with all the problems associated with that unfortunate merger.

> and also a tweak in the way DHCP
> functions.

Please explain this one. I'm not sure what you are referring to.

Thanks.

Alper

---

From: pavan_kurapati <[email-masked]>
Date: Mon, 5 Nov 2007 10:16:13 +0530

Hi Alper,

Please find replies inline

Thanks,
Pavan
________________________________________
From: Alper Yegin [[email-masked]]
Sent: Friday, November 02, 2007 6:20 PM
To: pavan_kurapati; [email-masked]
Subject: RE: [dhcwg] Discussion of dhc WG rechartering for DHCP         authentication

Hi,

>tell us how this is anything more than simply setting up a filter rule.

I was talking about introducing another element in DSLAMs to apply filters (IP/MAC) based on PANA in addition to what it does by doing DHCP snooping.   I am not saying that it is not doable. I am just saying that it is an additional work whereas there is no change required in case of DHCP based solution.

>Please explain this one. I'm not sure what you are referring to.

After receiving DHCP offer, the client takes the offered IP address and PAA address and initiate PANA (instead of doing traditional Request/Ack process and then make use of the IP address). This is one tweak. And then based on PANA result you restart the DHCP Discover process and take the other IP address. So, isnt there a change in the way DHCP is done?

Thanks.

Alper

---

From: Richard Pruss <[email-masked]>
Date: Mon, 05 Nov 2007 15:15:38 +1000

> tell us how this is anything more than simply setting up a filter rule.
The devices currently install these filters based on DHCP snooping.  In
our proposal current architecture use of the DHCP ack will still trigger
drive the source address verification on the first network hop, exactly
as they do today.

With PANA, these devices which are the whole of the transmission edge
would all need to get a new PANA snooping enabled code base, with all
the filtering use cases around that.  New ideas like authenticated and
unauthenticated IP addresses and policy for those need to be hooked to
new filters that operate on IP streams. A snooping version of PANA or
some sort of PANA grafting to a policy distribution mechanisms.

That more new stuff than I care to count can charitably called
"considerable re-work", more it should be pretty obvious from ethernet 
security is not the application for PANA.  This application is deeply 
entwined with layer 2, PANA is clearly aimed at IP authentication and is 
not a layer 2 or in the DHCP Auth case layer 2.5 application.

I wonder why you keep driving this square peg into a round hole.  The
first entry of the PANA FAQ is that PANA is layer 2 agnostic and you
seem determined to undo that.
http://www.toshiba.com/tari/pana/pana-faq.txt

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 5 Nov 2007 21:19:22 +0200

Hi Pavan,

> I was talking about introducing another element in DSLAMs to apply filters
> (IP/MAC) based on PANA in addition to what it does by doing DHCP snooping.
> I am not saying that it is not doable. I am just saying that it is an
> additional work whereas there is no change required in case of DHCP based
> solution.

"Additional work" seems a fair statement, not the "considerable re-work"
that you used before.

> After receiving DHCP offer, the client takes the offered IP address and
> PAA address and initiate PANA (instead of doing traditional Request/Ack
> process and then make use of the IP address). This is one tweak. And then
> based on PANA result you restart the DHCP Discover process and take the
> other IP address. So, isnt there a change in the way DHCP is done?

I guess you are considering a call flow where a temporary IP address is
assigned using DHCP, instead of configuring a link-local IP address. OK,
even in that case, I don't see why you stop short of completing the full
DHCP for pre-PANA address. 

You can either do:

1. CPE configures a link-local address
2. CPE discovers PAA (via DHCP or some other mechanism)
3. CPE runs PANA
4. CPE configures "session IP address" using DHCP

Or,

1. CPE configures a pre-PANA IP address using DHCP
2. CPE runs PANA
3. CPE configures "session IP address" using DHCP

I cannot think of why you'd need a tweak for DHCP.

Alper

> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely for the use of the addressee(s). If you are not the intended
> recipient, please notify the sender by e-mail and delete the original
> message. Further, you are not to copy, disclose, or distribute this e-mail
> or its contents to any other person and any such actions are unlawful.
> This e-mail may contain viruses. Infosys has taken every reasonable
> precaution to minimize this risk, but is not liable for any damage you may
> sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Infosys reserves
> the right to monitor and review the content of all messages sent to or
> from this e-mail address. Messages sent to or from this e-mail address may
> be stored on the Infosys e-mail system.

---

From: Richard Pruss <[email-masked]>
Date: Tue, 06 Nov 2007 11:50:24 +1000

Should this conversation not move to the int-area?

> 3. CPE configures "session IP address" using DHCP
The PANA idea if using short lease/long lease DHCP address switching in 
DSL deployments is simply not feasible.  BRAS's with over 60K 
subscribers are common and many providers have central city pops of more 
than a million subscribers.

During a pop restart the 60 second lease on a million subscribers would 
at best result in a sustained load of more than 16000 DHCP requests / 
second smashing through the relays and into the DHCP servers until the 
users had gradually authenticated.

- Ric

---

From: Ralph Droms <[email-masked]>
Date: Mon, 5 Nov 2007 21:37:28 -0500

Does the short lease/long lease scenario scale the DHCP server load  
by more than a factor of two?

- Ralph

On Nov 5, 2007, at Nov 5, 2007,8:50 PM, Richard Pruss wrote:

> The PANA idea if using short lease/long lease DHCP address  
> switching in DSL deployments is simply not feasible.  BRAS's with  
> over 60K subscribers are common and many providers have central  
> city pops of more than a million subscribers.
>
> During a pop restart the 60 second lease on a million subscribers  
> would at best result in a sustained load of more than 16000 DHCP  
> requests / second smashing through the relays and into the DHCP  
> servers until the users had gradually authenticated.
>
> - Ric
>

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 7 Nov 2007 13:04:20 +0200

First of all, there is no way use of PANA would lead to more DHCP traffic.
How can that be true when carrying EAP over DHCP always at the minimum
contribute 2 additional round-trips just for the sake of transporting EAP?  

In the worst case (DHCP-configured pre-PANA address), there are two round
trips for that 1st DHCP. Even in that case PANA is no worse than DHCP-auth.

And then there are better cases, e.g. use of link-local address as pre-PANA
address, rapid commit, etc.

As for your 11-msg PANA call flow count, the example you used is the most
verbose one. If you turn on the optimizations (agent-side initiation,
piggybacking) it reduces to 2 round trips.

So, in the worst case scenario (full dhcp, pana, another full dhcp), PANA
has additional 2 round-trips. By kicking in more optimized deployment
choices, this difference can be diminished.

Alper

> -----Original Message-----
> From: Eric Voit (evoit) [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2007 5:40 AM
> To: Ralph Droms (rdroms)
> Cc: [email-masked]; Internet Area
> Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering
> forDHCPauthentication
> 
> > From: Ralph Droms, November 05, 2007 9:37 PM
> >
> > Does the short lease/long lease scenario scale the DHCP
> > server load by more than a factor of two?
> 
> Ralph,
> 
> The messages the DHCP servers will double.
> The messages with L3 edge (BRAS) will more than double.
> The messages with the CPE will more than triple.
> 
> (Below is some rough math. I might have missed a message or two, but the
> general trend is what I am trying to show.)
> 
> -----------------------------------------
> CPE Messages
> -----------------------------------------
> DHCP Auth, assuming a 2 message EAP Method, the messages used by EAP
> would be equal
> + 6 Messages (draft-pruss-dhcp-auth-dsl-01)
> 
> PANA+DHCP Method
> + 4 Messages: DHCP 1st IP address
> ~ (+2) DHCP renews per 60 seconds until authenticated
> + 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1)
> + 4 Messages: DHCP 2nd IP address
> 
> -----------------------------------------
> L3 Edge (BRAS) Messages
> -----------------------------------------
> DHCP Auth, EAP Method
> + 8 Messages (draft-pruss-dhcp-auth-dsl-01)
> 
> PANA Method
> + 4 Messages: DHCP 1st IP address
> ~ (+2) DHCP renews per 60 seconds until authenticated
> + 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1)
> + 2 messages min for validating with EAP Server
> + 4 Messages: DHCP 2nd IP address
> 
> -----------------------------------------
> L2 Edge (DSLAM or Access Switch) Messages
> -----------------------------------------
> DHCP Auth, EAP Method
> + 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01)
> 
> PANA+DHCP Method
> + 4 Messages Snooped: DHCP 1st IP address
> ~ (+2) DHCP renews per 60 seconds until authenticated
> If snooping: 11 Messages PANA (draft-ietf-pana-pana-18, section 4.1)
> Else if explicit policy distribution like ANCP, ~4 messages (one policy
> per address)
> + 4 Messages Snooped: DHCP 2nd IP address
> 
> 
> Eric
> 
> 
> > - Ralph
> >
> 
> 
> Int-area mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/int-area

---

From: Ralph Droms <[email-masked]>
Date: Wed, 7 Nov 2007 07:06:15 -0500

Eric - I was mostly responding to Ric's description of the excessive  
load on DHCP servers in the short-lease/long-lease scenario.  As I  
understand the short-lease/long-lease scenario, if we assume that  
authentication takes place in the short-lease window, the load on the  
DHCP servers would double.  Significant, sure, but not game-changing  
in the way Ric implied.

- Ralph

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 13 Nov 2007 00:33:40 +0200

> Doubling the load on the DHCP servers probably will not change the game.
> 
> The extra load on the L3 Edge/BRAS could easily change the game (and
> hence the emails from Peter (Redback) & Bill (Juniper)).

Hmmm... I followed up this feedback with Bill Welch in more technical
detail, and if you remember it ended with a "And yes your observation is
correct, the DHCP auth solution with EAP has the same issues."

http://www1.ietf.org/mail-archive/web/int-area/current/msg01129.html

Alper

> 
> The extra complexity with the CPE has always been my biggest concern,
> and is why I entered the thread many weeks ago.
> 
> Eric
> 
> 
> > From: Ralph Droms, November 07, 2007 7:06 AM
> >
> > Eric - I was mostly responding to Ric's description of the
> > excessive load on DHCP servers in the short-lease/long-lease
> > scenario.  As I understand the short-lease/long-lease
> > scenario, if we assume that authentication takes place in the
> > short-lease window, the load on the DHCP servers would
> > double.  Significant, sure, but not game-changing in the way
> > Ric implied.
> >
> > - Ralph
> >
> > > (Below is some rough math. I might have missed a message or
> > two, but
> > > the general trend is what I am trying to show.)
> > >
> > > ~ (+2) DHCP renews per 60 seconds until authenticated If
> > snooping: 11
> > > Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else
> > if explicit
> > > policy distribution like ANCP, ~4 messages (one policy per address)

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 13 Nov 2007 00:52:59 +0200

> > From: Alper Yegin, November 07, 2007 6:04 AM
> >
> ? You say below "full dhcp, pana, another full dhcp".  Sounds like
> doubling the DHCP traffic to me.

If you compare it with EAP/DHCP, which adds at least two additional
round-trips to usual DHCP, then you'd see even in that worst case (for PANA)
scenario, the DHCP traffic using PANA is same as that of EAP/DHCP solution.

> But there is another issue.  It is very normal for AAA servers to take
> time for all the sessions to authenticate after a BRAS reboot or
> pop-wide power failure.  PANA has the potential to introduce a large
> amount of additional DHCP traffic simply due to short lease timer renews
> being requested prior to authentication completion.

You seem to assume the short leases are too short. 

> This sounds like a pretty effective distributed denial of service attack
> to me.
> 
> > How can that be true when carrying EAP over DHCP always at
> > the minimum contribute 2 additional round-trips just for the
> > sake of transporting EAP?
> 
> I was trying to make the EAP method equivalent between the two cases.
> Am I missing something?

Yes. Ric said dedicated DHCP messages will carry EAP and in the very best
case that means two additional round-trips of DHCP for the sake of shuttling
EAP.

> > In the worst case (DHCP-configured pre-PANA address), there
> > are two round trips for that 1st DHCP. Even in that case PANA
> > is no worse than DHCP-auth.
> >
> > And then there are better cases, e.g. use of link-local
> > address as pre-PANA address, rapid commit, etc.
> >
> > As for your 11-msg PANA call flow count, the example you used
> > is the most verbose one. If you turn on the optimizations
> > (agent-side initiation,
> I chose the best message flow I could find within
> draft-ietf-pana-pana-18.  As I read your words above, I cannot match all
> the potential variations to the DSLF requirements.  Is there another

What requirements are you referring to? The ones that DSLF provided to IETF
does not really seem to talk about variations you are referring to. 

> documented DHCP+PANA message flow somewhere which meets the DSLF
> requirements which I should use instead?

Have you read the PANA spec? 

All these optimizations are documented there. Of course you cannot find call
flows depicting every possible scenario in this IETF document.  

Alper

> 
> Eric
> 
> >
> > So, in the worst case scenario (full dhcp, pana, another full
> > dhcp), PANA has additional 2 round-trips. By kicking in more
> > optimized deployment choices, this difference can be diminished.
> >
> >
> > Alper
> >

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 14 Nov 2007 00:51:41 +0200

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.

Thanks.

Alper

> Peter
> > From: Alper Yegin [mailto:[email-masked]]
> > Sent: 12. november 2007 14:34
> > To: 'Eric Voit (evoit)'; 'Ralph Droms (rdroms)'
> > Cc: [email-masked]; 'Internet Area'
> > Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc
> > WGrecharteringforDHCPauthentication
> >

---

From: Richard Pruss <[email-masked]>
Date: Wed, 14 Nov 2007 09:23:43 +1000

> would help us understand the level of impact, and let us see if we can
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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 7 Nov 2007 08:04:59 -0500

Hi Ralph,

The extra load on the L3 Edge/BRAS could easily chanFrom [email-masked] Wed Nov 14 08:11:20 2007
Content-class: urn:content-classes:message
Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering
	forDHCPauthentication
Date: Wed, 7 Nov 2007 08:04:59 -0500
From: "Eric Voit (evoit)" <[email-masked]>
To: "Ralph Droms (rdroms)" <[email-masked]>
Cc: [email-masked], Internet Area <[email-masked]>

Hi Ralph,

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 7 Nov 2007 09:43:31 -0500

>.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA7EdSWV005213; 
	Wed, 7 Nov 2007 14:42:43 GMT
Content-class: urn:content-classes:message
Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering
	forDHCPauthentication
Date: Wed, 7 Nov 2007 09:43:31 -0500
From: "Eric Voit (evoit)" <[email-masked]>
To: "Alper Yegin" <[email-masked]>
Cc: [email-masked], Internet Area <[email-masked]>,
	"Ralph Droms \(rdroms\)" <[email-masked]>

 

Eric

 

Eric

---

From: "Peter Arberg" <[email-masked]>
Date: Mon, 12 Nov 2007 15:13:59 -0800

I do not think you and Bill were talking about the same issues
in the email.

Peter

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 6 Nov 2007 22:39:43 -0500

Ralph,

PANA+DHCP Method

PANA Method

PANA+DHCP Method

Eric

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 15 Nov 2007 01:23:01 +0200

Hi,

 

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

---

From: Richard Pruss <[email-masked]>
Date: Thu, 15 Nov 2007 15:16:19 +1000

Alper Yegin wrote, around 15/11/07 9:23 AM:
> 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.

> spoofed addresses to the layer 2 switches and would be dropped.
> 
> 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.

> 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.

> 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.

> 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.
> 
> 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

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 17 Nov 2007 01:45:32 +0200

> > you don't attempt to configure an IP address using DHCP prior to

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

> > And btw, somehow I see IPv6 is being characterized as a "future" thing

NTT. Since 2001.

> 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.

> > 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."

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

> > 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
> > Alper> Sorry I couldn't follow this. What latency is that 60+? DHCP

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

> > for retranmissions, the answer is at least "more", if not "a lot more".
> 
> 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

Disagree, as explained throughout this thread.

Alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Nov 2007 20:21:41 +0100

(I have a certain oppinion on DHCPAuthentication vs PANA as well but it
  seems many things have been already told.)

Alper Yegin wrote:
[...]
>> This is one thing I would love to learn I am wrong about, please 

NERIM in France since about 2003.

But Alper - can you cite how NTT is doing it?  How many customers?  How
many addresses delivered to customer?  What kind of addresses are
delivered?   What transition mechanism?  I can for NERIM.

I'm talking from a 2001 experience of actually picking up the phone and
calling NTT and asking them for IPv6 access.

All these things are important in order to really answer the question
raised above.

It may all be in that 'residential' keyword.  How much 'residential' is
a SOHO?  What does 'residential' really mean in Japanese?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 20 Nov 2007 00:26:23 +0200

Hi Alex,

I need to let NTT folks answer that.

Meanwhile, the point I was trying to make is, IPv6 over DSL is not a future
thing that we can blindly ignore. Tossing the ball back to DSLF is just a
recipe for avoiding discussions. 

Alper

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Saturday, November 17, 2007 9:22 PM
> To: Alper Yegin
> Cc: [email-masked]; [email-masked]; 'Internet Area'
> Subject: Re: [Int-area] Re: [dhcwg] Discussion of dhc

---

From: Shin Miyakawa <[email-masked]>
Date: Tue, 20 Nov 2007 12:24:03 +0900 (JST)

From: "Alper Yegin" <[email-masked]>
Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication
Date: Tue, 20 Nov 2007 00:26:23 +0200

> I need to let NTT folks answer that.

Which means Me , Alper ? :-p

> > But Alper - can you cite how NTT is doing it?  

http://www.ipv6style.jp/en/statistics/services/index.shtml

is a good reference what we're doing in Japan. Not only by NTT.

Talking about ISP service, please see 

http://www.v6.ntt.net/index_e.html

> > How many customers?  

We can not disclose without proper permission from company, sorry about that.

> > How many addresses delivered to customer?  
> > What kind of addresses are delivered?   

Please look at RFC4241.
Actually, we've modified a bit in addition to this model.
Basically, we've added RA onto the uplink between CPE and Access Concentrator
because of some operating system like Windows Vista uses the strong model
for its network design.

If I could have a chance, I am grad to tell about our architecture
in Vancouvor in some proper place.

> >What transition mechanism?  

No transition mechanism.

Also,  we've already commercialized "softwire" service named "OCNIPv6".
Basically, this is as same as we've discussed within SOFTWIRE WG of IETF.

> > a SOHO?  What does 'residential' really mean in Japanese?

SOHO as well as just an apartment or house.

One my house in Tokyo had been equipped with residential IPv6/v4 dual ADSL
service from my own company.

I believe that this is residential :-)

(Now I personally am using FTTH service from NTT as well with IPv6 
softwire commercial service on it.)

Best regards,

Shin Miyakawa
NTT Communications Corporation

---

From: Shin Miyakawa <[email-masked]>
Date: Tue, 20 Nov 2007 12:26:13 +0900 (JST)

(due to some technical problem, I missed int-area ML. so
please forgive me to send this message again.)

Please look at RFC4241.

No transition mechanism.

Best regards,

Shin Miyakawa

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Nov 2007 16:53:35 +0200

Ric, Alper,

"SAVA" as in the IETF effort? Or the specific approach that DSL networks
use to guard against address spoofing? I think the latter... lets keep
the SAVA arguments out of this discussion. There's a BOF in this IETF
about this, and it is far too early to state anything about the end
results. But so far all the designs we have talked about in that group
for IPv6 have involved support for both stateless and DHCP.

Jari