This is a review of Ric's draft from the point of view of its technical content. Not about whether it is needed, if there are better alternatives, match to DSL Forum requirements, etc.
Is the draft suggesting one or both approaches (CHAP and EAP)? I would argue that we should select at most one. If the CHAP model is sufficient for the PPPoE migration to happen, this speaks strongly in favor of it. However, if we can satisfy the migration concerns even with EAP then it would be a more general mechanism, and selecting that might make more sense. It concerns me that DHCP DISCOVER and OFFER are separated by the possibly lengthy DHCP EAP exchange (multiple roundtrips across the world in the worst case). This seems to change the way the regular messages operate; a normal client might already have given up. RFC 4284 reference needs a big disclaimer about its limitations, or no reference at all. Is there a true need to replicate PPPOE PADO functionality? Section 5.2 carries EAP Success in DHCP OFFER but Section 6.3 talks only about carrying EAP messages in DHCP EAP. Some details may be missing here. Can all link layers and networks where this is run satisfy MTU>=1020 which is required by EAP? If not, you need a fragmentation mechanism... I would argue that the EAP-based approach should employ binding between the EAP exchange and the actual DHCP operation, perhaps using something similar to what Section 8.2 outlines with RFC 3118 keying. In fact, I would be interested in making this mandatory to implement and perhaps even to use. What credentials and EAP methods would a DSL deployment moving from PPPoE use, and would this be possible. I.e., this would require mutually authenticating EAP and key generating EAP methods. Section 8.2 suggests that EMSK be used to derive RFC 3118 keys. I think this is inappropriate, but I cannot find the other draft that this draft suggests will describe this in detail. In any case, if one EAP run is used for one application separately from any other L2 or other use, I do not actually see any reason to avoid the use of MSK. Using MSK would have the advantage of avoiding new AAA servers and new AAA specifications on how to derive and use EMSK for this purpose. Current systems do not transport EMSK. The draft is rather brief on what assumptions it makes about the applicability of this method. For instance, employing it in a point-to-point like environment where non-DHCP traffic (e.g., stateless IPv6) is prohibited provides some amount of network access control functionality. However, running it on an Ethernet or Wireless LAN would provide only security for the DHCP exchange itself. (And in the current version of the draft, not even that because there is no binding to the DHCP transaction.) How are different sessions separated from each other? Presumably on the DSL case you would only hear about this particular client on the same virtual interface, but what if this is run in a plain old wired Ethernet? Note that the identifiers in EAP packets are probably too short for this. Is it possible for the two endpoints to be come confused about what the state is? E.g., client reboots, server thinks it should keep resending EAP requests? Its likely that a state machine is needed for this. If keys are used in the process to bind the EAP run and DHCP OFFER/ACK together, is there a possibility that the two endpoints become confused about which keys should be used? E.g., move client between two DSL lines. Note that there may be scenarios where these things are run over wireless, such as Wimax deployments attempting to model DSL. Its likely that some key identification would be needed for this. Maybe its in the other draft that does not exist yet... I would like to see the IPv4 and IPv6 versions of DHCP addressed at the same time. Jari _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
