inline with [nb] On Wed, Dec 10, 2025 at 9:58 AM <[email protected]> wrote:
> [Speaking as individual contributor.] > > > > Thank you Nick. > > Please see below one follow up [Bruno] > > > > *From:* Nick Buraglio <[email protected]> > *Sent:* Tuesday, December 9, 2025 9:24 PM > *To:* DECRAENE Bruno INNOV/NET <[email protected]> > *Cc:* [email protected]; [email protected] > *Subject:* Re: raft-ietf-spring-srv6-security-09 > > > > > > > > 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. > > > […] > > > §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." > 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]
