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. 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. 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. 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. 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) Section 6.1, packet modification: If the packets are protected, then this should be harder to do. Unless the goal is DOS. Section 6.2.3.2, para 2: If this isn't required, then it is a mitigation. Section 6.4.1, para 3: Adding an attacker enables masquerade inside the domain boundaries. 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. _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
