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

From: [email-masked]
Date: Tue, 8 May 2018 16:10:29 +0200

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 May 2018 14:39:45 +0000

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 <[email-masked]>
Date: Tuesday, May 8, 2018 at 10:10 AM
To: Bernie Volz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

Hi Bernie,

SECTION 9:

And:

Thanks,
Ian

---

From: [email-masked]
Date: Wed, 9 May 2018 09:53:09 +0200

Hi Bernie,

Thanks. I’ll still with 3315bis for now then.

BTW - I’ve added another paragraph to the Sec. Considerations section reading:

   A client may attempt to overload the server by sending multiple
   source address update messages (see Section 7.2.1) in a short time
   frame.  This risk can be reduced by implementing a server policy
   enforcing a minimum time interval between client address changes as
   described in Section 8.1.

DOS prevention was the reason for including the minimum time in the first place, so I think it makes sense to list it here.

Cheers,
Ian

> On 8. May 2018, at 16:39, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi Ian:
>  
> Bernie