Speaking as individual contributor. Thank you for the document and in particular for the new -09.
With regards to §7.1 " Trusted Domains and Filtering" I think that in the general case there may be multiple SRv6 domains: -a- totally separated (e.g., SP A & SP B with no interconnection). Usually, this is the assumed case. -b- hierarchical (à la Carrier's carrier). §7.1.2 is referring to this case -c- overlapping. E.g., with one node belonging to two SRv6 domains. (could be a mobile SRv6 domain and a packet SRv6 domain with some nodes belonging in both. Could also be one internal domain (P, PE node), and another domain for PE and customers/CE (with a reduced set of segments, e.g., a few bindings segments offered as API). §7.1.3 can probably be read to cover this. I feel that at minimal, the texts from this document should cover all cases, and should be generally applicable. This may require to carefully craft some wording. Ideally, in my opinion, the document would explicitly touch on this point. Please find below some proposed minimal changes " SRv6 is deployed within a trusted domain" seems to only cover a single "SRv6" (domain). OLD: the current document assumes that SRv6 is deployed within a trusted domain NEW: the document assumes that the SRv6 domain is a trusted domain §7.1.3 In general, the boundary of the domain seems to be at the interface level, rather than at the node level. (In particular, but not limited to, a node part of multiple SRv6 domains) May be OLD: The IPv6 destination address can be filtered at the SR ingress node NEW: The IPv6 destination address can be filtered at the external interface of the SR ingress node of the SRv6 domain. (as a side effect, this highlight that the filter is applied on a per interface basis, which can be less scalable for some hardware). §7.1.3 In the scope of deployment "-b-", may be this section could say that the filter/@block is associated to the/one SRv6 domain. (and different SRv6 domains have different a block/filter) May be §7.3 (HMAC) could also cover this. E.g. OLD: the same key might be reused by multiple systems NEW: the same key might be reused by multiple systems of a SRv6 domain (but definitely not the same key for different domains, including on the same system/node) BTW, this sentence starts with the term "node" and finish by using the term "systems". It's not clear to me what distinction is implied. If none, may I suggest using the same term? (e.g. node) §7.2 " Encapsulation of packets at the SR ingress node and decapsulation at the SR egress node mitigates the ability of external attackers to attack the domain and also allows for encapsulation of both IPv4 and IPv6 packets." Again, node boundary is not enough: decapsulation at the SR egress node, followed by a lookup on that node does not provides protection. We need decapsulation on the egress followed by the sending of the packet outside of the SRv6 domain without further lookup. MPLS has some similar security consideration and possibly https://datatracker.ietf.org/doc/html/rfc4364#section-6 may be of some help. §7.3 (HMAC TLV) "An internal attacker who does not have access to the pre-shared key can capture legitimate packets, and later replay the SRH and HMAC from these recorded packets." Agreed. May be adding "for the lifetime of the pre-shared key validity." (possibly adding that a mitigation would be to change the key periodically/frequently.) Thanks, Regards, --Bruno -----Original Message----- From: [email protected] <[email protected]> Sent: Thursday, November 6, 2025 3:39 PM To: [email protected] Cc: [email protected] Subject: [spring] I-D Action: draft-ietf-spring-srv6-security-09.txt Internet-Draft draft-ietf-spring-srv6-security-09.txt is now available. It is a work item of the Source Packet Routing in Networking (SPRING) WG of the IETF. Title: Segment Routing IPv6 Security Considerations Authors: Nick Buraglio Tal Mizrahi Tian Tong Luis M. Contreras Fernando Gont Name: draft-ietf-spring-srv6-security-09.txt Pages: 30 Dates: 2025-11-06 Abstract: SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-spring-srv6-security-09.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-srv6-security-09 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected] ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
