IPv6 Destination Option for Congestion Exposure (ConEx)
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Brian Haberman Discuss
I support the publication of this document given the need for experimentation in this area. However, there is one point that I would like to discuss... Section 3 contains R-1 which says that this marking "needs to be visible to all ConEx-capable nodes on the path." Additionally, Section 5 says that the choice of using an IPv6 Destination Option precludes non-ConEx-capable devices from having to deal with the extension header. However, RFC 2460 clearly says that Destination Options are not inspected by intermediate devices. We all know that a variety of intermediate devices ignore the rule in 2460. Given that, I would like this document to explicitly state that it does not abide by the rule in 2460 so that implementations that do follow 2460 but want to support this approach know to update all their extension header processing code.
* Why does the word "foo" appear in the middle of Section 4? * Do you want the Option Type description in Section 4 to have a value = TBD construct so that the IANA-assigned value can be inserted?
Kathleen Moriarty Discuss
I think this should be easy to address, but wanted to discuss options for the text in section 7. Since there is text that says IPsec Authentication should be used when integrity protection and the section goes on to also discuss encryption, shouldn't there be a similar statement that says IPsec encryption should be used when there is a need to protect confidentiality? Also, in reading this, I think because of the selected wording, I was thinking that it wasn't clear enough on the need/recommendation for authentication or encryption with IPsec since there are options for both to be set to NULL/none. You can have a NULL cipher-suite and you can also have authentication set to none to allow for opportunistic security negotiations (fairly new RFC for the latter). There's no need to mention these options explicitly, but rather to make it clear that IPsec can be used to provide authentication and encryption. So I think one additional sentence and some possible rewording in this section would be helpful.
For the Security Considerations section, I'd just ask that you add in "IPsec" when AH and ESP are first mentioned so this is clear.
Martin Stiemerling Yes
Jari Arkko No Objection
The resolution from the Robert Spark's Gen-ART review needs to be folded in to the document before it is approved. Also, as noted in Ron Bonica's Gen-ART review and by Brian Haberman on the IESG review, there is a concern for using Destination Options this way. I wanted to be on record that I too am concerned about that. I'm not blocking on that comment because this is for Experiment RFC. But it is a cause for concern, even with the other option (HBH options) also has downsides.
Alia Atlas No Objection
I support Brian's Discuss.
Deborah Brungard No Objection
Ben Campbell No Objection
Thanks for including the paragraphs on the purpose of the experiment! There is an IPR declaration that lists this as an "associated draft". I'm not sure what to make of that, but it was not mentioned in the shepherd review. IDNits mentions some unused references.
Benoit Claise No Objection
As mentiond by Scott in his OPS-DIR review: As an experiment this should have few operational concerns for any network not involved in the experiment but if the technology becomes standardized at some later time it will add somewhat to the complexity of configuring network devices (i.e. routers). Bottom line, technology-wise this ID seems ready to publish. But I do have some comments on the use of rfc 2119 terminology in the ID. I do not think I’ve seen a case where a document says SHOULD NOT and MAY in the same paragraph referring to the same thing: As with any destination option, an ingress tunnel endpoint will not natively copy the CDO when adding an encapsulating outer IP header. In general an ingress tunnel SHOULD NOT copy the CDO to the outer header as this would changed the number of bytes that would be counted. However, it MAY copy the CDO to the outer header in order to facilitate visibility by subsequent on-path ConEx functions if the configuration of the tunnel ingress and the ConEx nodes is co- ordinated. This trades off the performance of ConEx functions against that of tunnel processing. I suggest that this be reworded to say something like “SHOULD NOT unless xxx, in which case it MAY xxx” The next paragraph says An egress tunnel endpoint SHOULD ignore any CDO on decapsulation of an outer IP header. The information in any inner CDO will always be considered correct, even if it differs from any outer CDO. Therefore, the decapsulator can strip the outer CDO without comparison to the inner. Why is this a SHOULD rather than a MUST? imo, SHOULDs should only be used when there is a known reason that an otherwise MUST behavior might not be followed – in that case the reason should be explained
Stephen Farrell No Objection
- section 7: "If the transport network cannot be trusted, IPsec Authentication should be used to ensure integrity of the ConEx information." Hmm. Transport networks cannot be trusted so the first condition is always met. That means you are saying IPsec should be used. I don't see how the key management required is going to happen and even if it did, would that affect conex calculations? I'm ok with an experiment on that basis though, but it'd be better if the real relationship between this and IPsec were more fully fleshed out somewhere as part of the experiment. - The secdir review  touches on similar issues. I'm not sure if that got a response, but it raises a good point that seems to me to deserve a response.  https://www.ietf.org/mail-archive/web/secdir/current/msg05957.html
Joel Jaeggli No Objection
Barry Leiba No Objection
Terry Manderson No Objection
Alvaro Retana No Objection
Section 4. (ConEx Destination Option (CDO)) defines the Option Length field by saying: "The sender MUST set this field to 1 but ConEx-aware nodes MUST accept an option length of 1 or more.” Maybe I just don’t understand the subtlety in that statement, but if all the senders use 1, why would the receiver want to accept any other value? To me it just seems like that would be an error/malformed option.