Benjamin Kaduk has entered the following ballot position for draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document presents a couple use cases for the new IE 46 codepoints, but both are in the context of monitoring the rollout of a migration of control-plane technology. Are there steady-state use cases for these values? Section 2 Another use case is to monitor MPLS control plane migrations from dynamic BGP labels [RFC8277] to BGP Prefix-SIDs in the context of Seamless MPLS SR described in Section 4.6 of [I-D.hegde-spring-mpls-seamless-sr]. I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of maturity to be a good reference here (and thus, that this example is worth including). For example, the referenced section refers to "option A", "option B", and "option C" but I couldn't find where in the document these options were enumerated as such. (Maybe it's supposed to be what's described in sections 4.1.{1,2,3}; maybe not.) (Further aside about that draft: it also isn't using the RFC 8174 version of the BCP 14 boilerplate, and has more authors than recommended by the RFC Series Editor statement on authorship, https://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html .) Section 5 If pressed to come up with new security considerations from this work, I would submit that conveying information about what control-plane protocol is in use gives an attacker information to use in planning an attack on that control plane. But the attacker would need to have access to the IPFIX information in order to do so, and RFCs 7012 and 7011 are clear that the mechanism for conveying the IPFIX data has to provide confidentiality protection, so it seems that endpoint compromise would be needed for the attacker to actually gain access, and it's hard to come up with a realistic scenario involving endpoint compromise where these new codepoints are key to an attack. In short, it doesn't really seem like a consideration that's relevant enough to be worth mentioning in this document, so I'm okay with leaving this section as-is. The most that I would suggest changing is to add the word "significant", for "no significant extra security considerations". NITS Section 1 Four new routing protocol extensions, OSPFv2 Extensions [RFC8665], I suggest dropping the word "new", which is a relative term and will be less and less applicable over time. Also, [I-D.ali-spring-sr-traffic-accounting] describes how IP Flow Information Export [RFC7012] can be leveraged to account traffic to MPLS SR label dimensions within a Segment Routing domain. I don't understand the word "dimensions" in this context. (It doesn't appear in the referenced documents, either, which suggests that a different word may have been intended.) _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
