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

["Alper Yegin" <[e-mail]>]

Apparently this thread is not meant to be technically constructive.
There is no point in getting sucked into confusion by trying to explain
things.

Alper


> -----Original Message-----
> From: Richard Pruss [mailto:[e-mail]]
> Sent: Monday, March 05, 2007 9:57 PM
> To: Yoshihiro Ohba
> Cc: [e-mail]
> Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt
> 
> Yoshihiro Ohba wrote:
> > Thank you for the URLs.  But what is missing in my statement while
> > especially I mentioned "some level of L3 access control"?  For
> > example, "all IP traffic on the port is blocked except for DHCP
> > packets" is a form of L3 access control.
> >
> So in what you saying is that in addition to the 7 steps of complexity
> that your proposal also needs a whole new layer of L3 access control
> signalling so that once you have achieved the panacea of being PANA
> authenticated the L3 access control, which is currently being controled
> by DHCP messages.
> Sounds to me as if you are just desperately trying to find some real
> application for PANA.
> 
> Possibly you should consider national border controls for IP as the
> perfect PANA application. It seems ill suited to other applications but
> for putting up a random check-point in the middle of the internet where
> you need to present your L3 national passport, PANA seems perfect.
> 
> >
> > I am not sure what is your definition of the term "elegant", but IMO,
> > if it is so elegant, then it should work with stateless IPv6 address
> > autoconfiguration as well.
> >
> A future revision of this ID will work with DHCPv6, and, yes, I am only
> targeting DHCP-based environments as this is a DHCP-based extension.
> Stateless autoconfig is out of scope, though of course DHCP-PD with
> stateless autoconfig behind an RG would still work here.
> 
> Regards,
> Ric
> 
> > Regards,
> > Yoshihiro Ohba
> >
> > On Mon, Mar 05, 2007 at 01:10:08PM +1000, Richard Pruss wrote:
> >
> >> 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/1
> 22t/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_configurat
> ion_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


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