Subject: [dhcwg] draft-jjmb-dhcp-eap-auth-analysis

From: "Alper Yegin" <[email-masked]>
Date: Fri, 5 Feb 2010 12:29:44 +0200

Thank you for the revision of this I-D.

7.2.  Applicability

   As to the question of applicability of the statement in question, it

   is not really the case that configuration and authentication are

   being done by the same protocol.  Configuration is being done by

   DHCP.  Authentication is being done by EAP.  True, DHCP is being used

   as a transport for the EAP protocol, but it is not the case that DHCP

   itself is being used for authentication and authorization.

When we slice and dice the protocol in that way, even PPP does not look like
the same protocol is used for both authentication and configuration (and
many other things). Of course at the payload level (EAP vs. IP configuration
options) they diverge, but they are using the same DHCP.

   In addition, existing network access authentication protocols that

   work over layer three do use DHCP to configure the node prior to

   authentication in cases, such as this, where the authentication agent

   is not available on the local link.

In all cases today, the NAS is in the same IP subnet. Hence a link-local
IPv4/IPv6 address is sufficient to reach it. There is no need to use DHCP
prior to access authentication when L3 solutions are used.

   Once the node is configured, in order to get new DHCP configuration

   information based on the authentication and authorization results, a

   second DHCP transaction must be done.  In order for this to work,

   essentially the same mechanisms being proposed in Authentication

   Extensions for the Dynamic Host Configuration Protocol

   [I-D.pruss-dhcp-auth-dsl] are needed - the DHCP server or DHCP relay

   agent must have access to the results of the authentication.  And the

   DHCP protocol itself provides no mechanism for reconfiguring

   subsequent to a successful layer three authentication.  Hence the

   difference between such a protocol and the one being proposed is

   minor, and largely serves to make the configuration/authentication

   process slower and more awkward.

Second DHCP is not necessary. 

Alper

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Feb 2010 12:39:24 -0500

On Feb 5, 2010, at 5:29 AM, Alper Yegin wrote:
> When we slice and dice the protocol in that way, even PPP does not look like the same protocol is used for both authentication and configuration (and many other things). Of course at the payload level (EAP vs. IP configuration options) they diverge, but they are using the same DHCP.

That's true.   Do you feel that this contradicts the basic point being made here?

> In all cases today, the NAS is in the same IP subnet. Hence a link-local IPv4/IPv6 address is sufficient to reach it. There is no need to use DHCP prior to access authentication when L3 solutions are used.

It's my understanding that this isn't precisely applicable, but I don't understand the technical details well enough to really clarify the issue.   Ric, can you comment on this?

> Second DHCP is not necessary.

DHCP after authentication, using information acquired during authentication is.   So if what I said is factually incorrect, it should be restated, but I think the fundamental point still holds.

Thanks for the comments!

---

From: Richard Pruss <[email-masked]>
Date: Mon, 8 Feb 2010 09:27:25 +1000

> It's my understanding that this isn't precisely applicable, but I don't understand the technical details well enough to really clarify the issue.   Ric, can you comment on this?

Sure, if there is a solid dependable 1-1 relationship between the DSLAM port and a virtual-ethernet port on the NAS , no authentication is strictly needed and many (mostly smaller) networks run like this.

Of course what is wrong is the arrogant _all_ in Alper's comment.

There are many reasons that this wire like behaviour is does not always apply:
a) Regulatory devisions - in a few networks I have encountered - the access and internet are separate services with separate controlling parties
b) Layer 2 resources - many progressive networks are deploying video streaming services prior to the NAS (in addition to multicast) to give better quality service by being closer and less bandwith constrained
c) Ad-Hoc access points - many DSL networks off wireless hotspot points which are simply DSL points with wireless access points where your DSL login works when you away from him
d)  N-1 VLAN aggregation - for cost reasons many networks do not run 1-1 VLAN all the way through from DSLAM to NAS's
e) Access Chaos - in networks with much more than 1 million subscribers - they rarely have orderly good track of who is connected where in the access - there are some rare exceptions but typically different
areas are run by different groups and in some cases even different companies - depending on 1-1 VLAN to will understood billable customer record simply is not the norm in large networks
f) Many very large operators run PPPoE today and want to keep the username and password model as they have databases, order entry, billing and thousands of procedures and staff trained in there status quo, they
do not want to try change all of this to a system that tracs customers into VLANs.

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 8 Feb 2010 10:49:04 +0200

Hi Ted,

That's true.   Do you feel that this contradicts the basic point being made
here?

Alper> I think so. The analysis I-D claims same protocol is NOT used for
both configuration and access authentication, because one is DHCP the other
is EAP. 

Alper> Configuration and access authentication using different payload
containers is not an important detail, them using the same protocol DHCP is
the important thing. 

Alper> It is explained in more detail in RFC 5505. As you can see from
there, merely using a dedicated payload format does not change the fact
pointed out in there:

   Network access authentication and authorization is a distinct problem
   from Internet host configuration.  Therefore, network access
   authentication and authorization is best handled independently of the
   Internet and higher-layer configuration mechanisms.
 
   Having an Internet- or higher-layer protocol authenticate clients is
   appropriate to prevent resource exhaustion of a scarce resource on
   the server (such as IP addresses or prefixes), but not for preventing
   hosts from obtaining access to a link.  If the user can manually
   configure the host, requiring authentication in order to obtain
   configuration parameters (such as an IP address) has little value.
   Network administrators who wish to control access to a link can
   better achieve this using technologies like Port-Based Network Access
   Control [IEEE-802.1X <http://tools.ietf.org/html/rfc5505#ref-IEEE-802.1X>
].  Note that client authentication is not
   required for Stateless DHCPv6 [RFC3736
<http://tools.ietf.org/html/rfc3736> ] since it does not result in
   allocation of any limited resources on the server.

It's my understanding that this isn't precisely applicable, but I don't
understand the technical details well enough to really clarify the issue.
Ric, can you comment on this?

DHCP after authentication, using information acquired during authentication
is.   

Alper> Yes. But that does not have to be a "second DHCP". What I'm saying
is, you can run one PANA and one DHCP and be done with it. 

So if what I said is factually incorrect, it should be restated, but I think
the fundamental point still holds.

Thanks for the comments!

Alper> Thank you.

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 8 Feb 2010 10:57:18 +0200

I don't understand how any of this is relevant to the issue under
discussion.

Let me recap.

Analysis I-D states:

My point is, "authentication agent" (NAS) is in the same IP subnet. In other
words, if the node being authenticated (e.g., CPE) and the NAS were to
communicate using IP, then there would not be another IP router in between.
Hence, the assumption that "node needs to use DHCP prior to L3-based
authentication" is not true, because that node can use link-local IP
address, and even unspecified IP address (like DHCP does).

Alper

 

 

From: Richard Pruss [mailto:[email-masked]] 
Sent: Monday, February 08, 2010 1:27 AM
To: Ted Lemon
Cc: Alper Yegin; [email-masked]
Subject: Re: [dhcwg] draft-jjmb-dhcp-eap-auth-analysis

Sure, if there is a solid dependable 1-1 relationship between the DSLAM port
and a virtual-ethernet port on the NAS , no authentication is strictly
needed and many (mostly smaller) networks run like this.

There are many reasons that this wire like behaviour is does not always
apply:

a) Regulatory devisions - in a few networks I have encountered - the access
and internet are separate services with separate controlling parties

b) Layer 2 resources - many progressive networks are deploying video
streaming services prior to the NAS (in addition to multicast) to give
better quality service by being closer and less bandwith constrained

c) Ad-Hoc access points - many DSL networks off wireless hotspot points
which are simply DSL points with wireless access points where your DSL login
works when you away from him

d)  N-1 VLAN aggregation - for cost reasons many networks do not run 1-1
VLAN all the way through from DSLAM to NAS's

e) Access Chaos - in networks with much more than 1 million subscribers -
they rarely have orderly good track of who is connected where in the access
- there are some rare exceptions but typically different

areas are run by different groups and in some cases even different companies
- depending on 1-1 VLAN to will understood billable customer record simply
is not the norm in large networks

f) Many very large operators run PPPoE today and want to keep the username
and password model as they have databases, order entry, billing and
thousands of procedures and staff trained in there status quo, they

do not want to try change all of this to a system that tracs customers into
VLANs.

- Ric

---

From: Richard Pruss <[email-masked]>
Date: Mon, 8 Feb 2010 20:10:25 +1000

On 08/02/2010, at 6:57 PM, Alper Yegin wrote:

> My point is, “authentication agent” (NAS) is in the same IP subnet. In other words, if the node being authenticated (e.g., CPE) and the NAS were to communicate using IP, then there would not be another IP router in between. Hence, the assumption that “node needs to use DHCP prior to L3-based authentication” is not true, because that node can use link-local IP address, and even unspecified IP address (like DHCP does).
>  

No as always you are fractally wrong, that is wrong at all granularities of argument.
As I have explained to you many, many times over the years, that the security state of most modern switches are drive by DHCP, that means
that switches typically forward packets only for DHCP and return only DHCP packets to most end nodes until DHCP completes.

This means that no "link-local" rubbish or protocols with unspecified IP addresses or any other noise gets past the switches, this is done to
limit opportunities for spoof attacks and DOS attacks on layer 2.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 9 Feb 2010 10:52:34 +0200

Ric,

So your point is, legacy switches deployed in BBF networks today only allow
DHCP before authentication, and they are so untouchable that any acceptable
solution has to be built on DHCP, right? 

This does not make sense, because your I-D is introducing new DHCP messages.
The switches have to recognize them to filter properly. So, you also have to
touch the switches.

Alper

 

 

 

No as always you are fractally wrong, that is wrong at all granularities of
argument.

As I have explained to you many, many times over the years, that the
security state of most modern switches are drive by DHCP, that means

that switches typically forward packets only for DHCP and return only DHCP
packets to most end nodes until DHCP completes.

This means that no "link-local" rubbish or protocols with unspecified IP
addresses or any other noise gets past the switches, this is done to

---

From: Richard Pruss <[email-masked]>
Date: Tue, 9 Feb 2010 19:00:11 +1000

On 09/02/2010, at 6:52 PM, Alper Yegin wrote:

> Ric,
>  
> So your point is, legacy switches deployed in BBF networks today only allow DHCP before authentication, and they are so untouchable that any acceptable solution has to be built on DHCP, right?
>  
> This does not make sense, because your I-D is introducing new DHCP messages. The switches have to recognize them to filter properly. So, you also have to touch the switches.

Actually the draft works with many switches as is, some switches do require a minor update to extend the list of valid messages to cover the new ones but it is no big deal.

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 9 Feb 2010 17:14:13 +0200

Ric,

Actually the draft works with many switches as is,

Alper> How come? If those switches are filtering on DHCP packets, are they
programmed to allow any "unrecognized DHCP packet" (like the new DHCP EAP
packets would be)? Odd..

 some switches do require a minor update to extend the list of valid
messages to cover the new ones but it is no big deal.

Alper> Well, once you touch it (which is a big deal), I'm sure filtering on
other protocol types is not that a great deal. 

- Ric

Alper

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 9 Feb 2010 10:06:52 -0800

Speaking only to this point, and not trying to insert myself in your
other discussion points;

> The switches have to recognize them to filter properly. So, you also have to

If I were implementing a DHCP snooping switch, I would be looking for
DHCPACK's to create a cache of assigned IP address and client
information, and possibly doing some limited pre-caching on
DHCPOFFER's.

Because the IETF can and does (DHCPINFORM, DHCPFORCERENEW,
DHCPLEASEQUERY) extend the DHCPv4 protocol, I would probably pass any
unrecognized message on to the client untouched and without updating
my cache (I'm not sure what I would do with leasequery responses the
local switch did not solicit; it seems attractive to update the
cache but it opens a possible vector of attack to poison the cache).

Unfortunately DHCP snooping isn't formally documented at the IETF,
but I would characterize it as a bug if a switch didn't operate in
that way.  If we did formally document DHCP snooping, I would want
this to be a normative requirement.

Sort of like how certain DNS resolver libraries don't allow resolution
of new RR types, this is a bug or flaw in design that needs to be
addressed for the long term health of the protocol either way.

So these switches would have to be touched eventually with or without
draft-pruss-etc.

I don't mean to imply one should be swayed either way by this, rather
I want to point out you are discussing terms of scheduling this
correction rather than requiring or obviating it.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/