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

From: "Ben Campbell" <[email-masked]>
Date: Mon, 26 Sep 2016 14:58:14 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-softwire-unified-cpe-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-softwire-unified-cpe/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Abstract and Title: Neither the Abstract or Title seem to describe the
contents of the draft. It seems to be about prioritization among multiple
s46 mechanisms. It might be worth mentioning that in the abstract. (Also,
the title header for pages 2+ does not match the title page title)

- 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.)

---

From: <[email-masked]>
Date: Tue, 27 Sep 2016 09:44:02 +0000

Dear Ben, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Ben Campbell [mailto:[email-masked]]
> Envoyé : lundi 26 septembre 2016 23:58
> À : The IESG
> Cc : [email-masked]; Yong Cui; softwire-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06:
> (with COMMENT)
> 
> s46 mechanisms. It might be worth mentioning that in the abstract. 

[Med] Mirja raised a similar comment. This will be updated.

(Also,
> the title header for pages 2+ does not match the title page title)

[Med] Thank you for catching this. Will be fixed.

> 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.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 27 Sep 2016 09:37:02 -0500

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

Ben.

On 27 Sep 2016, at 4:44, [email-masked] wrote:

> [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.
>

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.

---

From: <[email-masked]>
Date: Tue, 27 Sep 2016 15:02:26 +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:[email-masked]]
Envoyé : mardi 27 septembre 2016 16:37
À : BOUCADAIR Mohamed IMT/OLN
Cc : The IESG; [email-masked]; Yong Cui; [email-masked]; [email-masked]
Objet : Re: Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06: (with COMMENT)

Ben.

On 27 Sep 2016, at 4:44, [email-masked]<mailto:[email-masked]> wrote:

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.