Thanks for the input, comments inline. On Tue, Oct 20, 2026 at 5:27 PM Deb Cooley via Datatracker <[email protected]> wrote:
> Deb Cooley has entered the following ballot position for > draft-ietf-spring-srv6-security-19: 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/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to Christian Huitema for their multiple secdir reviews. > > Please note, even though I deferred this draft for the next telechat, the > topic > area is outside my expertise. I've attempted to explain my thoughts on > this > topic, but I'm happy to chat about it, if that helps. > > In Sections 5&6 there is a mix of attack and mitigation. If you can > separate > these out (mitigations belong in Section 7), it might make it cleaner. > I believe we had this model in prior early drafts and the WG felt that this structure was more digestible as a reference document. > > There is little discussion of attacking one plane to enable the attacker on > another plane. Adding a node via the management plane, to allow the > attacker > more capability on a node he owns, for example. > We describe this somewhat in 6.3.4.2, using the PCE to manipulate SR paths. If you've got some more suggestions we'd be happy to include them. Section 5, masquerade bullet: 1. It is interesting to see that packet > insertion is not considered to be a form of masquerade. 2. I also would > have > thought that attacking the management plane to add the attacker's node > into the > SR would enable a masquerade attack. > Our logic here was to describe those specifically since they are something notable in this context. Spoofing, etc. all fall under the masquerade umbrella and are treated as a unique consideration due to the nature of a WAN. But yes, you're right, there are masquerade attacks that aren't necessarily defined in that way in this document, but instead are independently called out. > Section 5, Communication Integrity and Confidentiality: If this is saying > that > the data above the SR over IPv6 layer is always protected (both integrity > and > confidentiality), then fine. But that is not what these two bullets > imply. > The attack can be done by a passive attacker unless the underlying data is > protected. It appears to me that protecting the data is a mitigation, not > a > precondition. Note: this has to be true for data, control and management > information. > Does this improve the message? OLD: - Communication Integrity: SRv6 attacks may cause packets to be forwarded through paths that the attacker controls, which may facilitate other attacks that compromise the integrity of user data. Integrity protection of user data, which is implemented in higher layers, avoids these aspects, and therefore communication integrity is not within the scope of this document. NEW: - Communication Integrity: SRv6 attacks may cause packets to be forwarded through paths that the attacker controls, which may facilitate other attacks that compromise the integrity of user data. When integrity protection is applied at higher layers, it mitigates this exposure; in its absence, an on-path attacker may modify payload data undetected. Since higher-layer integrity protection is outside the SRv6 layer, it is not within the scope of this document, but its absence increases the impact of path-manipulation attacks. Section 6.1, passive listening: [note this is an area where unprotected > data > (on whatever plane) would be compromised.] What you describe as collecting > network topology, I would call 'traffic analysis' which includes mapping > the > network, keeping track of who talks to who, and at what frequency. How > much of > that is possible on a SR over IPv6 network, I don't know. > (https://en.wikipedia.org/wiki/Traffic_analysis) > It's certainly possible with the right tooling and access. As a WAN engineer when I hear "Traffic Analysis" my brain goes to "Searching PCAPs to find misbehaving $stuff", but I think the definitions are functionally the same and it's likely by experience bias, if traffic analysis is the more industry appropriate term, we can change it. I would say, however, that after changing and reading through the sections it does read quite oddly, at least to me. It feels like it needs a qualifier like "unauthorized" or "prohibited" or something. > Section 6.1, packet modification: If the packets are protected, then this > should be harder to do. Unless the goal is DOS. > 6.2.1.2 does address this, if you would like to see more we can probably find some text to expand it. > > Section 6.2.3.2, para 2: If this isn't required, then it is a mitigation. > 7.1 (referenced) does lay out the limited domain details including the mitigation filtering details. Are there additional details that should be included here? > > Section 6.4.1, para 3: Adding an attacker enables masquerade inside the > domain > boundaries. > I probably need more context here. > > Section 7.3: It is unclear to me what the HMAC is doing with respect to > preventing modification or replay of packets. Why would one turn on this > optional feature? Surely it should be a mitigation. > How does this sound? OLD: Using an HMAC in an SR domain can mitigate some of the SR Modification Attacks (Section 6.2.1). The following aspects of the HMAC should be considered: NEW: Using an HMAC in an SR domain can mitigate some of the SR Modification Attacks (Section 6.2.1). Specifically, the HMAC provides cryptographic integrity verification of those SRH fields, enabling a receiving SRv6 node to detect unauthorized modification by an on-path attacker who does not possess the pre-shared key. However, several limitations constrain its effectiveness as a general security mechanism:
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
