Here is my review comments on this I-D. Putting aside all the issues that
have been already raised, just concentrating on the text in this I-D...


- DHCP client on "home network devices" scenario missing, despite clear
indication in the I-D that this is a valid scenario.

- In Figure 1, is there a DHCP relay on both AN and NAS? If only NAS has it,
can the AN still insert DHCP option 82? 

- Figure 2 cannot deliver IP address to HGW via DHCPOFFER as the IP address
is only known after the RADIUS Access Accept. But this violates RFC 2131, as
DHCPOFFER must provide the IP address.

- In Figure 3, NAS inserts CHAP option in the DHCPOFFER. I don't think DHCP
relays are allowed to inject options towards the DHCP clients.

- In Figure 3, DHCP server receives the DHCPREQUEST but does not respond to
it. NAS (DHCP relay) becomes the entity that generates DHCPACK/NAK. This
totally breaks DHCP.

- Multi-round DHCPEAP is wedged into the current DHCP state machine,
effectively altering it.

- In Figure 4, EAP retransmission can cause the DHCP server to transmit
unsolicited DHCPEAP. This again breaks the usual request-response type DHCP
state machine.

- Regarding Figure 4, I-D states:

	The message following this exchange is a DHCP Offer, sent unchanged
	by the Server.

That's not true, as the DHCPOFFER carries EAP result.

- In Figure 5, NAS (DHCP relay) is generating a DHCP message. This is not
compliant with DHCP.

- In Figure 5, when the NAS receives a retransmitted EAP message over
RADIUS, what should it do? Would it send the DHCP client an unsolicited DHCP
message from DHCP relay? 

- In Figure 5, how is the EAP re-authentication initiated by the AAA server
handled?

- With the DHCP relay generating messages and otherwise adding options in
both ways, end-to-end model is broken. RFC 3118 cannot be used.

- In Figure 5, DHCP relay "caches" the DHCPDISCOVER message, goes on with a
multiple round-trips of DHCPEAP with the client, and then "releases" the
DHCPDISCOVER message towards the DHCP server. Very strange
behavior.......... 

- In Figure 5, DHCP server never sees DHCPREQUEST. Because DHCPREQUEST is
consumed by the DHCP relay. This is just broken.

- How does this solution guarantee orderly delivery of EAP payloads?

- IETF would not standardize anything with MD5. This was already said, not
sure why this is still hanging around.


We had published an I-D for securing DHCP using EAP-generated keys.
draft-yegin-eap-boot-rfc3118. As you can see, that does not require mixing
up DHCP and EAP protocols.

Overall, this proposal suffers the obvious consequences that'd arise when
one stacks up two distinctly unrelated protocols where
	- State machines do not match
	- End-points do not match
	- Call flows do not match
	- External interactions do not match

These are fundamental issues...

Alper




_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area