Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt

Hi Morand,

MORAND Lionel RD-CORE-ISS wrote:
> I will be also interested by the answer to this question ;)
> Beyond never-ending discussions on optional alternative possible potential solutions for access authentication, it would be very helpful to understand where we are going, what should be done and what should not be done in this area within IETF.
>   
Well there is a premise in section 2.4 of draft-aboba-ip-config-00 that 
because it is common for hosts to support more than one link layer the 
IP host configuration mechanisms be independent of the underlying lower 
layer.  This is a little like saying it would be easier for houses to 
fly if there foundations where not dependent on the ground, it is very 
true but not very helpful.  In truth IP host configuration is very 
dependent on things like what host it is, what it is authorised for and 
where on the network it is connected and so we need mechanisms to take 
those into account prior to allocating an IP address.

In PPP the authentication was used to configure the host and the NAS.  
In DSL, without PPP,  there is a split between the Layer 3 edge and the 
Layer 2 edge.  During the initialization sequence of a client we need to 
configure and secure both of those.  Also in DSL multiple layer 3 
services can be deployed in the layer 2 area, while we still have an 
architecture where one point is authoritative for the area, both in 
terms of authorizations and in terms of allocating IP addresses, we need 
make sure the other service on the layer 2 are reachable and secured 
from attack.

Now in section 2.4 of the draft-aboba-ip-config-00 we come to the crux 
of the problem;
"

Avoidance of lower layer dependencies also applies even where the
   lower layer in question may be link independent. For example, while

   Extensible Authentication Protocol (EAP) [RFC3748] may be run over
   any link satisfying the requirements of [RFC3748] Section 3.1, many
   link layers do not support EAP and therefore Internet layer
   configuration mechanisms with EAP dependencies would not usable on
   all links that support IP.

"
In Ethernet the only current mechanism for transporting EAP is 802.1X 
and it does not get forwarded through the Home Gateway if run from a 
subscriber PC or through the Access Node if run from the Home Gateway.
My draft is how we intend to implement this in the absence of EAP 
mechanism that traverses the path.
> I have a specific question about the network configuration chosen as working assumption:
>
> why do you consider a DHCP server in the NAS while typical dsl network configurations rely on a DHCP relay agent in the NAS and an external DHCP server (distinct from the NAS) in DHCP-based environment?
>   
Well caught.  I use the word server for lack of knowing a better word 
for representing what  Cisco, and I know Juniper do, which is more like 
a proxy than a relay function.  The NAS looks like the DHCP server to 
the DHCP client but in truth we proxy all the DHCP transaction pieces to 
a real DHCP server.  We do this for many reasons when we want to have 
all the DHCP messages addressed to the NAS.

We also support the DHCP server function in the NAS but that is rarely 
deployed in anything but very small networks in Service Provider.
> Could the proposed DHCP-based CHAP authentication work if the DHCP server is not in the NAS? 
>   
Yes.

-Ric
> BR,
>
> Lionel
>
>
>   
>> -----Message d'origine-----
>> De : Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] 
>> Envoyé : lundi 5 mars 2007 23:02
>> À : Richard Pruss
>> Cc : dhcwg@ietf.org; Yoshihiro Ohba
>> Objet : Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt
>>
>> A direct question is, how does your draft fit Section 2.5 of 
>> draft-aboba-ip-config-00.txt?
>>
>> Yoshihiro Ohba
>>
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dhcwg
>>
>>
>>     
>
>   

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg