Inline [Bruno2] From: Nick Buraglio <[email protected]> Sent: Thursday, December 11, 2025 4:52 PM To: DECRAENE Bruno INNOV/NET <[email protected]> Cc: [email protected]; [email protected] Subject: Re: draft-ietf-spring-srv6-security-09
inline with [nb] On Wed, Dec 10, 2025 at 9:58 AM <[email protected]<mailto:[email protected]>> wrote: [Speaking as individual contributor.] Thank you Nick. Please see below one follow up [Bruno] From: Nick Buraglio <[email protected]<mailto:[email protected]>> Sent: Tuesday, December 9, 2025 9:24 PM To: DECRAENE Bruno INNOV/NET <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: raft-ietf-spring-srv6-security-09 On Wed, Nov 12, 2025 at 10:21 AM <[email protected]<mailto:[email protected]>> wrote: Speaking as individual contributor. Thank you for the document and in particular for the new -09. […] §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 [Bruno] It’s not clear to me that section 5 of RFC8754 covers my point, and even the point of encapsulation introduced in draft-ietf-spring-srv6-security §7.2. (but I may have missed it as section 5 is relatively large). Let me propose some text to clarify my point, but please feel free to rephrase (as the sentence is getting long) §7.2 says “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.” draft-ietf-spring-srv6-security-09<https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-security-09#name-encapsulation-of-packets> OLD: decapsulation at the SR egress node NEW: decapsulation at the SR egress node followed by the forwarding of the inner packet outside of the SR domain (with no lookup on the inner IP packet) [nb] How does this sound as a complete paragraph? It's a bit long, perhaps I will wordsmith that a bit more. "Packets steered in an SR domain are often contained in an IPv6 encapsulation. Encapsulation of packets at the SR ingress node and decapsulation at the SR egress node followed by the forwarding of the inner packet to destinations outside the SR domain with no lookup on the inner IP packet mitigates the ability of external attackers to attack the domain, and allows for encapsulation of both IPv4 and IPv6 packets. Additionally, 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." [Bruno2] Thanks Nic. Works for me. Please feel free to further wordsmith. --Bruno Thank you --Bruno ____________________________________________________________________________________________________________ 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]
