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

ianfarrer@gmx.com Tue, 08 May 2018 14:10 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389A912E89C; Tue, 8 May 2018 07:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcOoJsnRqmSV; Tue, 8 May 2018 07:10:40 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E275512E894; Tue, 8 May 2018 07:10:36 -0700 (PDT)
Received: from ians-mbp.lan ([80.159.240.37]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MDFB2-1f67ha3wMO-00Gcad; Tue, 08 May 2018 16:10:31 +0200
From: ianfarrer@gmx.com
Message-Id: <5AC34DC3-5F29-4A2D-9DE0-B50CFE92E040@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BC58A837-905F-49B1-B99F-3AA0D2740B2A"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Tue, 08 May 2018 16:10:29 +0200
In-Reply-To: <290a895002ca49929fa0b3f7c7fa77ca@XCH-ALN-003.cisco.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org" <draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org>, "softwires@ietf.org" <softwires@ietf.org>
To: "Bernie Volz (volz)" <volz@cisco.com>
References: <35d79f1b7eba44ebbd1166abdec3f75e@XCH-ALN-003.cisco.com> <6101fb2ad0f94af9a87be709056cdaeb@XCH-ALN-003.cisco.com> <290a895002ca49929fa0b3f7c7fa77ca@XCH-ALN-003.cisco.com>
X-Mailer: Apple Mail (2.3445.6.18)
X-Provags-ID: V03:K1:zBpjOwyWl4gVkqDgeJWhBi+ewACZuBPPhPpI0q65tf6dNiFQI6D bgjflTOH+BJDGjxtGOne7lfDduJNhWsxA4c2Q/4DC3+WGBewbd33PqzNJ/AHidjtx1+MOp2 g1noboFJbO8ne1XrwdwSA/6ml3cbT7bqgVoLhH3BQZSuQGOpk5bgQ7C6ysXJsKE85gahbPp zGGMAhWq0n54e8/Sa/nkA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:4GSgudl+3WY=:z1kA4tYwRTRLwLxj2BHjwX REoZxRmKxzNHMWEwIKuq4pbpVphguOFhOerQzojdCaqrO3AdR8a8SAENTIhA1AKNfY5GXZhsj WdyrLz2KlHwC/n+/Su7HNcgBMSBoOiJrXAO91i5g9Ss0D30DLGUdWR/ftTuJYVgmivPiCaalC +umw5ghF3/86vWVUJ84UpCWcs4izsaH4k5umE56tetLwyCeWfd32qk3FzBE9HZTLul9WJRhFo Ndp07KLSchF9F4YyxfHwN2+zmtH7ZVn+2xIdIDMSx8XuuI5Xdu9fg6S+55q5AI8El3q6mwT+G /FIA285o/A43XB+y45oD8EcdqUscHpinA4ToW7nqxqzlc3p9N7Vp1ugDB/I2xt2l4i1U31HOn 4HLxYWWaFYgkIiAgTOP9hxjeEBixcHFP3FHGLyjolbmPpO+ubgUrHgLsPdAop/11UnIKn1F2w nQ4mUr7ker/YaJz3Z0dzVy0Gv2lXrOwBQDcVHxKU5Em+fItOkiVP4Q32RWN0xDKFDhDe8IEt8 gKQwaT6JEu522bAkZVL0VIb4DnLCG83vQa+eGq16a6YSIFbr1fXOE6XGs2/eGIZ+yYRn57yAt gRUnD1ABC/aSPah8ljbctVEuL4mBhVRtA1Za1ekWMHltwBcgAX9SbJgOIplorVbSFRsRSPYmQ D5gqm79y9itXCOM+cNZpkd3afPkY+SCc+QasnJkcIYyFIdC4nTlcFkM6a0em00VF9cKbWbdpY hxglTrk2QNBDP0MIMKy1HZVOgINaD+AdpMYLiOj6SykLz0dfEAZjBgIiWSQJwqrIAyo3QYfM9 Wd/B9xB
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/-3ePX1matODMihQc6tVw1ZSiOn0>
Subject: Re: [dhcwg] [Softwires] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 May 2018 14:10:43 -0000

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