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

["Maglione Roberta" <[e-mail]>]

Hi All,
	I did attend dhc wg session this morning and I have a couple of
comments on the discussion that took place on
draft-pruss-dhcp-auth-dsl-00.txt: from a Service Provider perspective we
are interesting, for a DSL scenario, in a simple and scalable solution
that is able to speed up the migration from PPP based access model to a
pure IP based access model keeping the same functionalities provided by
PPP especially in terms of AAA. Main reasons why we are moving from PPP
to IP sessions are scalability and "always-on" connections requirements.

Also looking at the work done in DSL Forum in WT-146 we think DHCP with
authentication could be a good candidate approach for this problem and
from the preliminary analysis that we did this approach could satisfy
the service requirements that we have, at same time we are open to
discuss our requirements and compare dhcp with authentication with other
possible approaches.

Thanks,
Roberta

--------------------------------------------------------------------
Roberta Maglione
Telecom Italia - T.IE.AFT.BI
Broadband Network Services Innovation
Via G. Reiss Romoli 274
10148 Torino - Italy
Phone: [phone]
e-mail: [e-mail]
-------------------------------------------------------------------

> -----Original Message-----
> From: Richard Pruss [mailto:ric at cisco.com]
> Sent: Monday, March 05, 2007 9:57 PM
> To: Yoshihiro Ohba
> Cc: dhcwg at ietf.org
> 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_configur
at
> 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
> >>>>>>> dhcwg at ietf.org
> >>>>>>> https://www1.ietf.org/mailman/listinfo/dhcwg
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
> >
>
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [e-mail].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------
                        

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