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

[Richard Pruss <[e-mail]>]

I do not think anything your response addresses the elegance difference
but the security point warrants some extra education, your comment was:
> With regard to security authorizations, both a) and b) are the same in
> the sense that L2 is fully available for unauthorized subscriber
> devices and hence some level of L3 access control is needed to keep
> unauthorized subscriber devices from inevitable abuse, as anyone can
> statically configure an IP address in both cases.
On the contrary we see that almost all SP's and most Enterprise ethernet
networks do not allow static IP address allocation as they simply use
DHCP and enforce that users use the address assigned to them. This is
enforced by a host of network features from vendors, the common Cisco
one in routers is DHCP Secured IP Address Assignment.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ftdsiaa.htm

At the layer 2 edge and in switches the same operation is commonly part
of the DHCP snooping security package and we call it IP Source Guard.
http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuration_guide_chapter09186a00801cddbc.html#1083306
To save you ready the URL's the operation in switches is described as:
"
Initially, all IP traffic on the port is blocked except for DHCP packets
that are captured by the DHCP snooping process. When a client receives a
valid IP address from the DHCP server, or when a static IP source
binding is configured by the user, a per-port and VLAN Access Control
List (PVACL) is installed on the port. This process restricts the client
IP traffic to those source IP addresses configured in the binding; any
IP traffic with a source IP address other than that in the IP source
binding will be filtered out. This filtering limits a host's ability to
attack the network by claiming a neighbor host's IP address.
"

With our customers' networks under constant attack we are under constant
pressure to deliver features that ensure and audit behaviour that was
once accepted on trust.

Cheers,
Ric

Yoshihiro Ohba wrote:
> On Mon, Mar 05, 2007 at 10:33:28AM +1000, Richard Pruss wrote:
>   
>> On one hand;
>> a) we can authenticate before allocating an subscriber IP address, host
>> configuration and network edge configuration and security authorizations.
>>
>> Or.
>> b1)On the other we can allocate a temporary subscriber IP address, host
>> configuration for a temporary context and network edge configuration for
>> a totally unknown user and security authorizations for someone who know
>> nothing about and somehow secure the layer 2 multi-point network they
>> are on from the inevitable abuse.
>>     
>
> Temporal host configuration and network edge configuration happens
> locally between the HGW and NAS without AAA interaction.  Also, I
> think that the network edge configuration for unauthorized subscriber
> devices can be statically configured on the NAS (e.g., always
> disabling IP forwarding for a pool of temporal IP addresses.)
>
> With regard to security authorizations, both a) and b) are the same in
> the sense that L2 is fully available for unauthorized subscriber
> devices and hence some level of L3 access control is needed to keep
> unauthorized subscriber devices from inevitable abuse, as anyone can
> statically configure an IP address in both cases.
>
>   
>> b2)Then you can renew the DHCP lease every 60 seconds putting an extra
>> load on everything involved.
>>     
>
> This is not needed if the client is authenticated within 60 seconds.
>
>   
>> b3) You authenticate with PANA
>> b4) You remove all the network edge configuration for now known user and
>> security authorizations and install new network edge configuration and
>> security authorizations.
>>     
>
> The installation part is commont to a) and b).  As I mentioned above,
> I think that the network edge configuration for an unauthorized
> subsciber device can be statically configured and does not have to be
> removed.
>
>   
>> b5) You wait for the user to renew.
>> b6) You reject that.
>> b7) Wait for the user to discover
>>     
>
> b5), b6) and b7) can be replaced with server-initiated DHCP force
> renew procedure.
>
>   
>> b8) You allocating an subscriber IP address and host configuration based
>> on what you installed in B4 and the MAC address in DHCP Discover.
>>     
>
> This is common to a) and b).
>
>   
>> I think the elegance of approach a) verses b1-7) is pretty clear,
>>     
>
> It is not clear to me if a) is elegant.  The only difference I can see
> (modulo the difference in authentication protocols) is one additonal
> DHCP before authentication and without AAA interaction in b).  This
> difference seems trivial to me.  Also, I am not sure how a) works when
> stateless IPv6 address autoconfiguration for IP address configuration.
>
> Regards,
> Yoshihiro Ohba
>
>
>
>
>   
>> Ric
>>
>> Yoshihiro Ohba wrote:
>>     
>>> Before authentication, it is possible for the NAS to assign a
>>> temporary IP address (for which IP forwarding is restricted) to the
>>> subscriber device using DHCP.  Once PANA authentication succeeds, the
>>> NAS has obtained subscriber-specific client configuration information
>>> and other authorization parameters from the AAA infrastructure.  After
>>> that, DHCP reconfiguration can be made using the subscriber-specific
>>> client configuration information to allow the subscriber device to
>>> change its IP address from the temporary one to the fully authorized
>>> one.  Please refer to draft-morand-pana-panaoverdsl for more
>>> information.
>>>
>>> Yoshihiro Ohba
>>>
>>>
>>> On Mon, Mar 05, 2007 at 09:04:17AM +1000, Richard Pruss wrote:
>>>   
>>>       
>>>> Possibly it would help you understand if you though of why the NAS
>>>> authenticates the subscriber; from section 3.1 of the draft
>>>> "
>>>> The NAS obtains per-subscriber client
>>>> configuration information either locally or from the AAA
>>>> infrastructure (which itself may consult external DHCP servers if
>>>> necessary) after authentication is successfully completed.
>>>> "
>>>> In wholesale DSL networks it is common to use the @domain portion of the
>>>> username to find retail ISP of the subscriber, they are then
>>>> authenticated by that ISP's AAA. This authentication returns
>>>> authorizations which in conjunction with the wholesale configuration in
>>>> the NAS determines the subscriber IP address, host configuration and
>>>> network edge configuration and security authorizations which is all
>>>> closely coupled to the retail domain.
>>>> From this perspective, PANA happens to late as the host already has it's
>>>> IP address, it would be in the correct IP forwarding context, the
>>>> network would already need to have some mechanisms for securing the
>>>> domain from layer 3 attacks independent of PANA and so on.
>>>>
>>>> Regards,
>>>> Ric
>>>>
>>>> Yoshihiro Ohba wrote:
>>>>     
>>>>         
>>>>> Hi,
>>>>>
>>>>> Let me ask the same fundamental question that I asked before for a
>>>>> similar draft related to DHCP and authentication.
>>>>>
>>>>> Is this WG chartered for developing a solution for network access
>>>>> authentication and authorization other than developing authentication
>>>>> mechanisms for DHCP?
>>>>>
>>>>> I am asking this because Introduction of
>>>>> draft-pruss-dhcp-auth-dsl-00.txt says:
>>>>>
>>>>> "
>>>>>    This document defines DHCP Options and procedures that allow for a
>>>>>    CHAP-based authentication exchange to occur in DHCP in order to
>>>>>    enable smooth migration from PPP sessions to IP sessions in a DSL
>>>>>    Broadband network environment.  Primary goals are integration of
>>>>>    authentication in such a way that it will operate seamlessly with
>>>>>    existing RADIUS-based AAA infrastructure and ATM or Ethernet based
>>>>>    DSL Networks.  As such, only the termination points of PPP in the DSL
>>>>>    network are affected, both of which are devices that would logically
>>>>>    need to be updated in any transition from PPP to IP sessions.
>>>>> "
>>>>>
>>>>> Also, I fail to see a reason for IETF to work on combining DHCP and
>>>>> network access authentication even as experimental and for the purpose
>>>>> of the primary goals stated above.  I believe that the primary goals
>>>>> can be achieved by simply using PANA running EAP-MD5 between HGW and
>>>>> NAS.  In this case, NAS is acting as EAP authenticator co-located with
>>>>> EAP server for EAP-MD5, where the EAP server is acting as a protocol
>>>>> translator that converts credentials carried in EAP-MD5 into RADIUS
>>>>> attributes or field (i.e., CHAP-Password and CHAP-Challenge or RADIUS
>>>>> Request Authenticator field) used for carrying CHAP credentials, and
>>>>> vise versa.  If an algorithm other than MD5 is used for CHAP, it is
>>>>> also possible to define an experimental EAP method to interwork with
>>>>> non-MD5 CHAP algorithms and again let the EAP server on the NAS act as
>>>>> a protocol translator.  I think these workarounds are sufficient to
>>>>> work with existing RADIUS-based AAA infrastructure and ATM or Ethernet
>>>>> based DSL Networks and still allows smooth migration from PPP session
>>>>> to IP session with EAP.
>>>>>
>>>>> The bottomline is, host configuration and network access
>>>>> authentication are two different problems that are better solved by
>>>>> separate protocols.
>>>>>
>>>>> Regards,
>>>>> Yoshihiro Ohba
>>>>>
>>>>> _______________________________________________
>>>>> dhcwg mailing list
>>>>> [e-mail]
>>>>> https://www1.ietf.org/mailman/listinfo/dhcwg
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>   
>>>       
>
>   

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