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

[[e-mail]]

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) <[e-mail]> wrote:
> 
> 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
>