On Wed, Nov 12, 2025 at 10:21 AM <[email protected]> wrote:
> 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 > > Agreed, will adjust. > §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). > Agreed, will adjust. > > §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 > Agreed, will adjust to "the same key might be reused by multiple nodes of an SRv6 domain" Will also clarify "This key should not be the same key for different trusted domains, including those existing on the same node" > > (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) > Agreed and fixed. > > §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. > Without tryin to to re-create something that I suspect already exists, how does this sound? "Practices outlined in Section 5 of [RFC8754] should be followed to ensure exclusivity of use for any prefix configured for use within the given trusted domain." If I am mis-understanding the intent, please let me know. ref: https://www.rfc-editor.org/rfc/rfc8754#section-5 > > §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." > Agreed, added. > (possibly adding that a mitigation would be to change the key > periodically/frequently.) > I left this out unless there is a strong desire to include it, the thought being that is is implied by the term "lifetime", and that there is no mitigation listed for the other points in this section (readability / consistency) > > > 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]
