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

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 02 Mar 2007 15:28:44 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Richard Pruss <[email-masked]>
Date: Mon, 05 Mar 2007 09:04:17 +1000

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 4 Mar 2007 18:56:37 -0500

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

---

From: Richard Pruss <[email-masked]>
Date: Mon, 05 Mar 2007 12:02:06 +1000

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.
b2)Then you can renew the DHCP lease every 60 seconds putting an extra
load on everything involved.
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.
b5) You wait for the user to renew.
b6) You reject that.
b7) Wait for the user to discover
b8) You allocating an subscriber IP address and host configuration based
on what you installed in B4 and the MAC address in DHCP Discover.

I think the elegance of approach a) verses b1-7) is pretty clear,
Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 4 Mar 2007 21:23:13 -0500

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

> load on everything involved.

This is not needed if the client is authenticated within 60 seconds.

> security authorizations and install new network edge configuration and

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.

> b7) Wait for the user to discover

b5), b6) and b7) can be replaced with server-initiated DHCP force
renew procedure.

> 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

---

From: Richard Pruss <[email-masked]>
Date: Mon, 05 Mar 2007 13:10:08 +1000

I do not think anything your response addresses the elegance difference
> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 4 Mar 2007 22:46:09 -0500

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.

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.

Regards,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 5 Mar 2007 12:05:27 +0200

> I think the elegance of approach a) verses b1-7) is pretty clear,

I just see this as DHCP giving birth to L3 version of PPP (one protocol does
all).

I think IAB draft "Principles of Internet Host Configuration" is pretty
clear on such an approach:

2.5.  Configuration is Not Access Control

   Network access authentication is a distinct problem from Internet
   host configuration.  Network access authentication is best handled
   independently of the configuration mechanisms in use for the Internet
   and higher layers.

   For example, attempting to control access by requiring authentication
   in order to obtain configuration parameters (such as an IP address)
   has little value if the user can manually configure the host.  Having
   an Internet (or higher) layer protocol authenticate clients is
   appropriate to prevent resource exhaustion of a scarce resource on
   the server, but not for preventing rogue hosts from obtaining access
   to a link.  Note that client authentication is not required for
   Stateless DHCPv6 [RFC3736] since it does not result in allocation of
   any limited resources on the server.

Alper

---

From: Richard Pruss <[email-masked]>
Date: Tue, 06 Mar 2007 05:56:49 +1000

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

> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 05 Mar 2007 17:02:00 -0500

A direct question is, how does your draft fit Section 2.5 of
draft-aboba-ip-config-00.txt?

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 6 Mar 2007 03:24:35 +0200

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:[email-masked]]
> Sent: Monday, March 05, 2007 9:57 PM
> To: Yoshihiro Ohba
> Cc: [email-masked]
> Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt
> 
> Yoshihiro Ohba wrote:
> http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configurat
> ion_guide_chapter09186a00801cddbc.html#1083306