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

<mohamed.boucadair@orange.com> Tue, 27 September 2016 15:02 UTC

Return-Path: <mohamed.boucadair@orange.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 04FC012B25A; Tue, 27 Sep 2016 08:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 DfPrUEnyuswr; Tue, 27 Sep 2016 08:02:44 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E9412B26D; Tue, 27 Sep 2016 08:02:29 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4D48F22CD71; Tue, 27 Sep 2016 17:02:27 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.13]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1B21F35C06D; Tue, 27 Sep 2016 17:02:27 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0301.000; Tue, 27 Sep 2016 17:02:26 +0200
From: mohamed.boucadair@orange.com
To: Ben Campbell <ben@nostrum.com>
Thread-Topic: Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06: (with COMMENT)
Thread-Index: AQHSGMyfjeNFQIek00eMwX+gDPxtcqCNbf5w
Date: Tue, 27 Sep 2016 15:02:26 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008E20CF4@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <147492709451.4992.18088916849265763856.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933008E2085F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <B90A9986-9C8D-4D4A-99AF-58CBA5AC6703@nostrum.com>
In-Reply-To: <B90A9986-9C8D-4D4A-99AF-58CBA5AC6703@nostrum.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008E20CF4OPEXCLILMA3corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/rmGen1Dlw3pxHql7HEp_Vaz-GCs>
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 15:02:49 -0000

Re-,

>From where I stand, I don't see NEW issues that are specific to the priority option.

I updated the text to record this:

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.  Also, a misbehaving node may alter the content 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.
   Those attacks are not unique to the S46 Priority Option but are
   applicable to any DHCPv6 option that can be altered by a misbehaving
   intermediate node.

Cheers,
Med

De : Ben Campbell [mailto:ben@nostrum.com]
Envoyé : mardi 27 septembre 2016 16:37
À : BOUCADAIR Mohamed IMT/OLN
Cc : The IESG; draft-ietf-softwire-unified-cpe@ietf.org; Yong Cui; softwire-chairs@ietf.org; softwires@ietf.org
Objet : Re: Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06: (with COMMENT)


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

Ben.

On 27 Sep 2016, at 4:44, mohamed.boucadair@orange.com<mailto: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.