Subject: [dhcwg] comments on dhc-eap-auth-analysis-01

From: "Alper Yegin" <[email-masked]>
Date: Wed, 25 Nov 2009 12:03:34 +0200

This analysis will
   also cite architectural and best practice considerations for the
   authors to consider as part of this work.

IAB's RFC 5505 deserves being mentioned in this I-D particularly because it
states:

2.5. Configuration Is Not Access Control

   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. 

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

   [I-D.pruss-dhcp-auth-dsl] requires that end-user DHCP-based
   authentication must be handled independently in the case where both
   IPv4 and IPv6 service are present.  [I-D.pruss-dhcp-auth-dsl] is not
   clear as to how clients and servers handle conflicts where both IPv4
   and IPv6 are used simultaneously and further how conflicts are
   resolved when such scenarios arise.  See the beginning of section 5
   of [I-D.pruss-dhcp-auth-dsl].

In no other access network architectures the host/subscriber needs to be
authenticated/authorized for IPv4 and IPv6 separately. One major issue with
the proposed approach is it relies on the subscriber being authenticated
twice; but legacy AAA infrastructure expects one authorized session at a
time. So, this looks like either a double login attempt, or latter session
overwriting the former. This does not work. (please consider consulting
RADEXT and DIME WGs if you want a deeper analysis).

Also, what happens when DHCPv4 auth succeeds but not DHCPv6? Does that mean
only IPv4 service is authorized? What if there are multiple IPv4 addresses
allocated via DHCP? What is IPv6 uses stateless address auto-config? Etc.
etc.

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

   Hence, we strongly recommend that the proposed protocol be changed so
   that, after a successful DHCP/EAP exchange, the DHCP client restarts
   its state machine at the INIT state and sends a new DHCPDISCOVER,
   with a new transaction ID.

This is certainly a move in the right direction. The problem is the whole
thing this proposal is trying to do: inlining/coupling access authentication
with DHCP procedure. There is no value in doing that, and it breaks a lot of
things. The right thing is to decouple them, completely. Once they are
decoupled, people would realize that there is no point in hacking up DHCP to
do subscriber authentication.

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

   We recommend that each EAP message sourced by the client
   have a new transaction ID, which should then be returned in the
   response from the server.

The problem is, EAP requests are sourced by the network. Hence transaction
IDs generated by the client does not work. Wrong direction, totally
incompatible state machines between EAP and DHCP. [I think this is a perfect
example of how one cannot stack up any two arbitrary protocol]

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

Final DHCPEAP is sent one-way from network to client. What happens if it is
lost? How does this reflect on the state machines? 

One thing, this proposal is lacking any discussion on state machines. How do
EAP and DHCP state machines interact with each other? What changes are
needed on the standard DHCP state machines? There are 3 state machines as I
see: one on the host, one on the DHCP relay, one on the DHCP server. DHCP
relay is not a relay; it terminates and sources DHCP messages. And those
messages are wedged in the ongoing DHCP session between the host and DHCP
server. There is a unique state machine relationship here. I don't know how
this whole thing holds up, but a clear documentation of state machines would
reveal it.

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

EAP retransmissions are not taken into consideration at all. They require
DHCP server or DHCP relay to keep sourcing DHCP messages when there is no
outstanding request from the client...... Does this look like DHCP to
anyone??

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

DHCPDISCOVER is cached throughout the length of full EAP authentication;
which can take multiple round-trips and few seconds (even longer when user
input is required). Would this not cause a timeout and rexmit on the client?

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

   None of the ones which do not support fragmentation are likely to
   exceed even 100 bytes in normal usage , so implementations MAY set
   DHCP message size to the common DHCP relay practice of 576 limit with
   some risk of some new non-fragmenting EAP protocol not being
   supported, but the recommendation of this draft is to set the maximum
   message size to that of the interface MTU.

Risk? This I-D is defining an EAP transport that may not work for some type
of EAP methods? This cannot be acceptable. 

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

   NAS on receiving a DHCPDISCOVER with
   unknown option silently discards unknown message.  Alternatively NAS
   MAY ignore the unknown option, but still process the message and then
   reply to the DHCP client with traditional response.  

There should be one correct way. Which one is it?

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

dhcp-auth I-D should describe why RFC 5191 is not good enough and why IETF
and DHC WG shall embark on this work. 

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

dhcp-auth requires DHCP relay to strip off EAP payload before relaying the
DHCP message to the DHCP server.

When RFC 3118 is used, that'd cause problems. Because the message is getting
modified by a middle man (DHCP relay) and the authentication code will not
verify at the receiver (DHCP server). OK, maybe this does not apply to the
initial DHCP Discover as there is no security association is setup for RFC
3118; but the subsequent EAP re-authentications (the ones that happen after
the initial EAP authentication, and RFC 3118 kicked in) will break RFC 3118.

Alper

---

From: Richard Pruss <[email-masked]>
Date: Wed, 25 Nov 2009 21:39:09 +1000

>   Internet and higher-layer configuration mechanisms.

Except for 150 million PPPoE deployments, countless GGSN, SGSN and  
basically
most dense high scale modern SP edge technologies.
Why? .... because by collapsing the problem space better scale is  
achieved. Both in terms
of memory per session and number of transactions per session, thus  
total latency
for bring up the sessions from a cold start.

So yes in your academic tower this may be best Alper but in practical  
high scale edge networking
realities of memory, latency and synchronisation of enforcement with  
configuration
make single integrated steps far, far better.

Actually this can be handle by policy in the edge if you think about  
it for half
a sec.  So yes, they can be separate authorised policies to possibly  
even separate
edge elements, but at the same time it is just as easy for the first  
one to authorise
to authorise the second.

But it works... very well actually.

You write about state machines as if they are holy temples where  
mysterious things happen.

Section 8.1.2

No, the client understands what is happening.  This is one advantage  
of doing DHCP auth
verses something like 802.1x.

Name these EAP methods at risk.  This is typical academic point with  
no relevance to real deployment.

Also draft allows one to set MTU as high as you want.  We use 1152  
bytes, the risk being
some relays may not like that, but in the broadband edge their is no  
L3 relays before
the BNG and the L2 snooping relays all support full ethernet frame  
sizes in out tests.

Policy choice. In our implementation you can choose at deployment.

No it will not.

Yea, we have noted that DHCP relay is the wrong term for what we are  
doing. We
will call it DHCP proxy or if that gives you heart failure we will  
drop it from the doc
but most of the broadband the vendors do a DHCP proxy function in the  
BNG.

- Ric

>
> Alper
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Nov 2009 11:05:30 -0500

Nobody here has veto power over this draft.   Alper is allowed to state his objections, and whether or not he lives in a tower is not germane to the debate.   The text in RFC5505 should be considered and should be mentioned in the analysis draft, because it is a valid point.   However, it doesn't preclude advancing the dhcp/eap draft.   It's just a point to consider when deciding whether to advance it.

So could we please keep this businesslike?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Nov 2009 11:36:31 -0500

>   Internet and higher-layer configuration mechanisms. 

So as I was showering after reading this exchange, it occurred to me that as an innocent bystander, I'm missing part of the decision-making process that lead us to the point where you could raise this objection.

Because I agree completely that using DHCP prior to authentication is a bad idea.  I think the right solution to this problem is to authenticate using 802.1x and *then* and only then use DHCP.   This would solve Ric's requirement that authentication occur before the address allocation decision is made.

But Ric didn't choose that option, and I notice that you didn't choose it either in your draft in the now-defunct PANA working group.

It seems to me that as a layer two protocol, 802.1x would have to be done right at the edge of the network, but it could be done that way, and it would be a lot more elegant than either your solution, Alper, which does DHCP *before* authentication, or your solution, Ric, which piggybacks authentication on top of DHCP.

So this is a question both for you and for Ric: why didn't you use 802.1x?   I'm not asking this with the intention of criticizing your or Ric's decision-making process.   I believe that you chose not to use 802.1x for a good reason.  I just want you to walk me through the process that led you to make that particular choice.

---

From: Richard Pruss <[email-masked]>
Date: Thu, 26 Nov 2009 05:30:07 +1000

No I am sorry, how is it germane?  This is a proposal about DHCP.   
What about RFC 2516 or RFC 4423 or RFC 2865 or the host of other  
options we have discarded.
We have done pages of analysis and have tons of alternatives, I cannot  
see how any of that is germane to the debate.  Alper has her our  
reasons for
discarding his baby, no need to go through all of that again.

- Ric

On 26/11/2009, at 2:05 AM, Ted Lemon wrote:

> Nobody here has veto power over this draft.   Alper is allowed to  
> state his objections, and whether or not he lives in a tower is not  
> germane to the debate.   The text in RFC5505 should be considered  
> and should be mentioned in the analysis draft, because it is a valid  
> point.   However, it doesn't preclude advancing the dhcp/eap  
> draft.   It's just a point to consider when deciding whether to  
> advance it.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Nov 2009 15:23:51 -0500

On Nov 25, 2009, at 2:30 PM, Richard Pruss wrote:
> see how any of that is germane to the debate.

Until these discussions are in the analysis draft, we are doomed to repeat them.   I'm sorry we didn't capture them all to begin with, but at the time we had them we didn't realize we were going to need to do so (and, indeed, I am pretty sure that a lot of these discussions didn't happen in the DHC working group anyway, because I don't remember them).   So let's just do what needs to be done.

---

From: Alan Kavanagh <[email-masked]>
Date: Wed, 25 Nov 2009 15:39:17 -0500

I tend to agree with Ted here, It doesn't hurt us to have all the issues/alternatives documented in the analysis draft, at the very least it may help improve DHCP_Auth draft from Ric. And yes, other discussions have occurred outside the DHC WG so I am in favor of having all the issue/alternatives etc noted in one place.

Alan

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 26 Nov 2009 02:08:22 +0200

Ted,

IEEE 802.1X has an issue because that protocol has to terminate on the same
Ethernet segment. There are switches between the CPE and NAS in DSL
infrastructure. 

> and it would be a lot more elegant than either your solution, Alper,
> which does DHCP *before* authentication,

Not so. PaC can use IPv4 or IPv6 link-local address (and even unspecified IP
address) with PANA; and configure a DHCP address only after authentication.

Alper

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Wednesday, November 25, 2009 6:37 PM
> To: Alper Yegin
> Cc: 'dhc WG'
> So as I was showering after reading this exchange, it occurred to me
> that as an innocent bystander, I'm missing part of the decision-making
> process that lead us to the point where you could raise this objection.
> 
> Because I agree completely that using DHCP prior to authentication is a
> bad idea.  I think the right solution to this problem is to
> authenticate using 802.1x and *then* and only then use DHCP.   This
> would solve Ric's requirement that authentication occur before the
> address allocation decision is made.
> 
> But Ric didn't choose that option, and I notice that you didn't choose
> it either in your draft in the now-defunct PANA working group.
> 
> It seems to me that as a layer two protocol, 802.1x would have to be
> done right at the edge of the network, but it could be done that way,
> and it would be a lot more elegant than either your solution, Alper,
> which does DHCP *before* authentication, or your solution, Ric, which
> piggybacks authentication on top of DHCP.
> 
> So this is a question both for you and for Ric: why didn't you use
> 802.1x?   I'm not asking this with the intention of criticizing your or
> Ric's decision-making process.   I believe that you chose not to use
> 802.1x for a good reason.  I just want you to walk me through the
> process that led you to make that particular choice.

---

From: Richard Pruss <[email-masked]>
Date: Thu, 26 Nov 2009 16:18:53 +1000

On 26/11/2009, at 6:23 AM, Ted Lemon wrote:

>    So let's just do what needs to be done.
>

Well what I can offer is why we choose DHCP to extend as
opposed to many of the other approaches..
http://www.ietf.org/proceedings/09nov/slides/dhc-6.pdf

On slide 2 of my IETF presentation I lay out the current practice
of DHCP proxy into AAA.  This is how many deployments look
today with Option 82 information, being used in the NAS to get
information from AAA, to provision and authorise the end client.

What is not shown on this slide but is certainly often the case is the
both the DSLAM and the NAS only allow forwarding for an IP address
after the DHCP offer, also other attributes from RADIUS are used for  
provisioning the
edge session behaviour on the NAS.

So in current deployments DHCP provisions the client and the chain of  
network elements.

The problem is in migrations from PPPoE and 1-many access deployment
Option 82 simply is not enough.  Thus this draft was originally  
conceived as a small
extension to add the additional username and password to the existing  
practice.

DHCP auth basically is designed so one can take PPPoE out and swap  
with IP over Ethernet
without SP operational impact, like changes to order entry or AAA and  
billing system.

As to why not PANA, I leave that to the reader, but if you can see it  
straight off go look at the archives
I was once naive and thought people were asking genuine questions as  
opposed to
just trying to disrupt, and so I wrote many an email trying to explain  
the l2/l3 relationships
in the broadband edge and why PANA and some of the other alternatives  
do not fly.

- Ric

---

From: Richard Pruss <[email-masked]>
Date: Thu, 26 Nov 2009 16:40:43 +1000

> Ethernet segment. There are switches between the CPE and NAS in DSL

Correct some underlying technical issues are:
- 802.1x uses a broadcast mac that is terminated on the first switch
- 802.1x is port authentication is unsuited for situation where you  
want to
do multiple sessions, which may be all terminated on the same port on  
the aggregator

> address) with PANA; and configure a DHCP address only after  

Which as we have noted many times is totally incompatible with edge  
address security
and traffic enforcement, but hey what do we know.

- Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 26 Nov 2009 20:05:29 +0900

> information from AAA, to provision and authorise the end client.

It seems that the term "proxy" in slide 2 of your IETF 
presentation is used differently from what you mentioned in 
your other email: "DHCP proxies look like a server to the 
client and a client to the real DHCP server."  In slide 2, 
it's described as a proxy to *AAA*, not a proxy to *DHCP 
server*.  So I am confused.

In your slide 5, you explicitly mention DHCP relay (instead 
of DHCP proxy) implemented on BNG.  This (and any) DHCP 
relay can never be called as DHCP proxy if DHCP proxy 
maintains a state.

Yoshihiro Ohba

> DHCP auth basically is designed so one can take PPPoE out and swap with 
> IP over Ethernet
> in the broadband edge and why PANA and some of the other alternatives do 
> not fly.
> 
> - Ric
> 
> 
>

---

From: Richard Pruss <[email-masked]>
Date: Thu, 26 Nov 2009 21:11:53 +1000

On 26/11/2009, at 9:05 PM, Yoshihiro Ohba wrote:

> It seems that the term "proxy" in slide 2 of your IETF presentation  
> is used differently from what you mentioned in your other email:  
> "DHCP proxies look like a server to the client and a client to the  
> real DHCP server."  In slide 2, it's described as a proxy to *AAA*,  
> not a proxy to *DHCP server*.  So I am confused.
http://en.wikipedia.org/wiki/Proxy_server
"In computer networks, a proxy server is a server (a computer system  
or an application program) that acts as an intermediary for requests  
from clients seeking resources from other servers."

You can proxy to AAA for authorisation and IP address or you can go to  
DHCP for the IP address, it's a choice allot of DHCP proxy  
implementations offer.  Sorry that was definitely not clear from my  
slides or text.

>
> In your slide 5, you explicitly mention DHCP relay (instead of DHCP  
> proxy) implemented on BNG.  This (and any) DHCP relay can never be  
> called as DHCP proxy if DHCP proxy maintains a state.

Yep I should not use the term DHCP Relay.  I will remove it from the  
draft and the presentation next time I do it.

- Ric

>> after the DHCP offer, also other attributes from RADIUS are used  
>> for provisioning the
>> So in current deployments DHCP provisions the client and the chain  
>> of network elements.
>> extension to add the additional username and password to the  
>> existing practice.
>> without SP operational impact, like changes to order entry or AAA  
>> and billing system.
>> As to why not PANA, I leave that to the reader, but if you can see  
>> it straight off go look at the archives
>> I was once naive and thought people were asking genuine questions  
>> as opposed to
>> just trying to disrupt, and so I wrote many an email trying to  
>> explain the l2/l3 relationships
>> in the broadband edge and why PANA and some of the other  
>> alternatives do not fly.
>> - Ric

---

From: [email-masked]
Date: Thu, 26 Nov 2009 12:31:11 +0100 (CET)

> relay can never be called as DHCP proxy if DHCP proxy 

Not commenting on the thread as such - but this statement is wrong
in the context of existing DHCP implementations on BRAS (and other)
boxes. See for instance

http://www.juniper.net/techpubs/en_US/junose10.3/information-products/topic-collections/broadband-access/id-78582.html#id-78582

where what Juniper calls DHCP proxy for the E-series most definitely
maintains state.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 26 Nov 2009 23:29:26 +0900

> where what Juniper calls DHCP proxy for the E-series most definitely

My point is, if such an entity maintains a state, it's not a 
DHCP relay but something else.  That is why they are calling 
it a "DHCP relay proxy" instead of "DHCP relay" without any 
qualifier.  I don't even care if they call their box "a 
specical box that improves something related to DHCP relay", 
but it's not a DHCP relay.

Yoshihiro Ohba