Re: [Int-area] DCHP-based authentication for DSL?

[Yoshihiro Ohba <[e-mail]>]

On Tue, Nov 06, 2007 at 09:20:14AM -0500, Eric Voit (evoit) wrote:
> > From: Ralph Droms, November 05, 2007 9:36 PM
> > 
> > No, PANA would not require changes to the DHCP client 
> > behavior if the first hop relay agent is configured to 
> > discard DHCP messages until PANA authentication is complete.  
> 
> I am assuming you are talking about discarding DHCP messages for the
> second DHCP assigned IP address when the lease for the first address
> expires.  In old PANA threads such as:
> http://www1.ietf.org/mail-archive/web/pana/current/msg00376.html
> They worried quite a bit about uncoordinated state machines resulting in
> slow client logon.  Up to 30 second delays were mentioned. 
> 
> Since random duration global IP address assignment delays of up to 30
> seconds is not acceptable, I am expect that PANA has fixed this.  Could
> one of the PANA people explain how?  

I am not sure what exact PANA deployment scenario is being discussed
here, but 30 seconds delay mentioned in the old PANA thread is between
the time when DHCP is started and the time when an IPv4 link-local
address is configured after DHCP timeouts.

> 
> BTW: even with the DHCP message for the 1st IP address, there are PANA
> drafts which require DHCP client modifications.  For example:
> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-dhc-paa-opt
> ion-05.txt
> "defines new DHCPv4 and DHCPv6 options that contain a list of IP
> addresses to locate one or more of PANA Authentication Agents (PAA)."

This is the default method for obtaining PAA's IP address.  This does
not mean this is the only way.  PANA allows other methods for
configuring PAA's IP address if defined.  Also, a particular
deployment where PAA always resides in access router may simply use
default gateway address as PAA's address and I believe all DHCP
clients understands Router option.

> > Presumably whatever mechanism is used to allow IP traffic 
> > after PANA authentication could also trigger the relay agent 
> > to allow DHCP forwarding.
> 
> This would again result in DHCP Timeouts unless coordination of the
> client state machine is occurring.  (And even if there is coordination
> with the client, there is ugly system behavior if the 2nd client DHCP
> message is initiated before the relay agent has completed updating its
> filters!)

I am not sure what coordination of the client state machine exactly
means, but to avoid the ugly behavior, a PAA implementation can delay
returning PANA authentication result until relay agent completes
filtering installation.

Yoshihiro Ohba



> 
> Eric
>  
> > Of course, I'm speculating wildly here about implementation 
> > details without the benefit of any system architecture docs...
> > 
> > - Ralph
> > 
> > On Nov 5, 2007, at Nov 5, 2007,8:33 PM, Richard Pruss wrote:
> > 
> > >
> > >
> > > Bernard Aboba wrote, around 6/11/07 11:11 AM:
> > >>> But let's have a fair evaluation.  If we decide that PANA 
> > fits the 
> > >>> requirements perfectly, the above objections apply 
> > equally well to 
> > >>> it.
> > >>
> > >> Actually, I'm not clear that the objections apply equally well to 
> > >> PANA.
> > >>
> > >> On the Windows platform at least, there is an API that permits 
> > >> integration of new EAP lower layers.  That means that PANA support 
> > >> can be added by a third party with no required changes to the 
> > >> operating system.
> > >>
> > >> Since DHCP/EAP requires change to the DHCP state machine, the work 
> > >> required would be considerably greater.
> > >>
> > >>
> > >>
> > > Does PANA not also require changes to the DHCP state 
> > machine to stop 
> > > it running until PANA has authenticated on the link local address?
> > >
> > >
> > > _______________________________________________
> > > Int-area mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/int-area
> > 
> > 
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/int-area
> > 
> 
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/int-area
> 
> 


_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area