Re: [Softwires] Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Tue, 27 September 2016 14:37 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6629E12B229; Tue, 27 Sep 2016 07:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.215
X-Spam-Level:
X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.316] 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 FCvTlGRVicKv; Tue, 27 Sep 2016 07:37:10 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D153812B22C; Tue, 27 Sep 2016 07:37:02 -0700 (PDT)
Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u8REb1YL000125 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 27 Sep 2016 09:37:01 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21]
From: "Ben Campbell" <ben@nostrum.com>
To: mohamed.boucadair@orange.com
Date: Tue, 27 Sep 2016 09:37:02 -0500
Message-ID: <B90A9986-9C8D-4D4A-99AF-58CBA5AC6703@nostrum.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E2085F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <147492709451.4992.18088916849265763856.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933008E2085F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_3375E55D-3E36-4CF4-98A9-4404F70FE1A6_="
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/2Qo3T9g5K8B1K836fMHlCY_mtDU>
Cc: "draft-ietf-softwire-unified-cpe@ietf.org" <draft-ietf-softwire-unified-cpe@ietf.org>, "softwires@ietf.org" <softwires@ietf.org>, "softwire-chairs@ietf.org" <softwire-chairs@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>, The IESG <iesg@ietf.org>
Subject: Re: [Softwires] Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06: (with COMMENT)
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2016 14:37:12 -0000

Hi, thanks for the quick response! One comment below.

Ben.

On 27 Sep 2016, at 4:44, mohamed.boucadair@orange.com wrote:

> - section 3: "This may lead to setting a different IPv4 service
>>    continuity mechanism than the one initially preferred by the 
>> network
>>    side"
>>
>> Are there consequences of that that should be discussed? E.g. 
>> bid-down
>> attacks, ability to direct packets via a compromised path, etc? (I'm 
>> not
>> saying there are; I'm just asking.)
>>
>
> [Med] We didn't include examples of such consequences because those 
> attacks depend on the modification of other DHCPv6 options that are 
> not defined in this document. For example, the ability to direct 
> packets via a compromised path will require the modification of the 
> content of DHCPv6 Option #64 or #90 to redirect packets to an 
> illegitimate AFTR/BR.
>
> What about the following change:
>
> OLD:
>
>    Misbehaving intermediate nodes may alter the content of the S46
>    Priority Option.  This may lead to setting a different IPv4 service
>    continuity mechanism than the one initially preferred by the 
> network
>    side.
>
> NEW:
>
>    Misbehaving intermediate nodes may alter the content of the S46
>    Priority Option.  This may lead to setting a different IPv4 service
>    continuity mechanism than the one initially preferred by the 
> network
>    side. For example, a misbehaving node may alter the context of the 
> S46
>    Priority Option and other DHCPv6 options (e.g., DHCPv6 Option #64 
> or #90)
>    so that the traffic is intercepted by an illegitimate node.

That helps. I was thinking more in terms of the S46 priority option 
specifically, but I guess it doesn't hurt to mention others. If one can 
modify the DHCPv6 options in general, one can do plenty of mischief 
without S46 Priority. Does adding S46 priority add any _new_ issues to 
that? I suspect the answer is "no", but if so it would be worth saying 
that.