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

[Iljitsch van Beijnum <[e-mail]>]

On 6 nov 2007, at 16:28, Yoshihiro Ohba wrote:

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

Apparently my message from earlier today (yesterday by the time this  
reaches the net) didn't make it, so once again:

A lot of this complexity can be avoided by using IPv6 link-local  
addresses, because those are created independently from "real" address  
assignment. This is of course only helpful if IPv6 is spoken on both  
ends, so that would leave the Windows 98 case out in the cold.

I believe it would be orders of magnitude easier to add PANA  
capability to a commercial OS because PANA doesn't need special access  
to the network and doesn't clash with existing capabilities. You could  
probably even run it from a browser as a java applet.

DHCP delays could be avoided by the DSLAM caching DHCP requests from  
unauthenticated hosts and only responding to those when the  
authentication has completed. However, if a short delay is unavoidable  
I don't think that's a show stopper, usually people connect after  
rebooting or some such, a process that takes a lot more time than  
having to wait for a DHCP retransmit or two.

And last but not least: I'm still waiting to hear how the DSL Forum or  
others intend to address IPv6. Apart from simply needing this  
capability in the near future, the prospect of having to rehash all of  
this in short order to add IPv6 isn't very atractive.




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



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