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

[Richard Pruss <[e-mail]>]

On 25/11/2009, at 8:03 PM, Alper Yegin wrote:

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

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.


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

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.

>
>
> ------------
>
>   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]
>
But it works... very well actually.

> ------------
>
> 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.
You write about state machines as if they are holy temples where  
mysterious things happen.

>
> ------------
>
> 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??
>
Section 8.1.2

> ------------
>
> 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?
>
No, the client understands what is happening.  This is one advantage  
of doing DHCP auth
verses something like 802.1x.

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

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.


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

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

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

No it will not.

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

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg