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

[<[e-mail]>]

Dear Ben, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Ben Campbell [mailto:[e-mail]]
> Envoyé : lundi 26 septembre 2016 23:58
> À : The IESG
> Cc : [e-mail]; Yong Cui; softwire-
> [e-mail]; [e-mail]; [e-mail]
> Objet : Ben Campbell's No Objection on draft-ietf-softwire-unified-cpe-06:
> (with COMMENT)
> 
> 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. 

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

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