Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

["Bernie Volz (volz)" <[e-mail]>]

Hi Ian:

Thanks … suggested text changes look good. I would think it best to reference 3315bis … hopefully it won’t hold up publication of this draft since it may take RFC Editor a bit longer to process the 3315bis document, but they also will have a head start. (If it does hold it up and we need to expedite release of this draft as an RFC, we can always ask for reference to change to 3315.)


  *   Bernie

From: Ian Farrer <[e-mail]>
Date: Tuesday, May 8, 2018 at 10:10 AM
To: Bernie Volz <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

Hi Bernie,

Many thanks for the review. I’ve had a look through your comments and they all look straightforward enough. They will be in the next version with Tomek’s comments.

Here’s my suggestions in response to a couple of your comments:

SECTION 9:

-          More of a question – do the new options or procedures add any new or different considerations? If not, great.

There is one case that I think is missed. I’ve update the Security Considerations section to add the following text:

      A rogue client could attempt to use the mechanism described
      in "Changing the Bound IPv6 Softwire Source Address” to redirect IPv4 traffic
      intended for another client to itself. This would be performed by
      sending a DHCPREQUEST message for another client's active IPv4
      lease containing the attacker's softwire IPv6 address in
      OPTION_DHCP4O6_S46_SADDR.

      For such an attack to be effective, the attacker would
      need to know both the client identifier and active IPv4
      address lease currently in use by another client. The risk
      of this can be reduced by using a client identifier format
      which is not easily guessable, e.g. by including a time
      component for when the client identifier was generated
      (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).


-          And, it is rather odd that DHCPv4 (RFC2131) and DHCPv6 (draft-ietf-dhc-rfc3315bis) aren’t referenced in the document. They are implicit because RFC7341 is referenced, but not always clear that this is the best way to go. But I didn’t find any easy way to incorporate these references directly.

I’ve added the following to Section 4. Solution Overview:

In order to provision a softwire, both IPv6 and IPv4 configuration
needs to be passed to the client. To map this to the DHCP 4o6
configuration process, the IPv6 configuration is carried in
DHCPv6 options [I-D.ietf-dhc-rfc3315bis], carried
inside the DHCPv6 message DHCPV4-RESPONSE (21)
sent by the server.

And:

IPv4 configuration is carried in DHCPv4 messages <xref target="RFC2131"/>,
(inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism
described in <xref target="RFC7341"/>.

The normative refs. are updated with these as well.

BTW, should I be referencing RFC3315 or the -bis version as normative at this stage?

Thanks,
Ian