[spring] Re: Second WG Last Call: draft-ietf-spring-srv6-s ecurity-14 (Ends 2026-06-02)
Nick Buraglio <[email protected]> Thu, 23 Jul 2026 09:59:11 -0500
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <CACMsEX9UPfuk1ZC8nVZDba-+i97O9f5ZaAJYxGaJW-S3E7pjsQ@mail.gmail.com> |
--===============0388304985664315671== Content-Type: multipart/alternative; boundary="00000000000058a8e506574880f2" --00000000000058a8e506574880f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 22, 2026 at 7:20=E2=80=AFPM Tom Hill <[email protected]> wrot= e: > On 2026-07-06 19:58, Alvaro Retana wrote: > > I would love a positive ack from the people who raised the > > issues/suggestions before moving forward. Specifically, Weiqiang and > > Tom. > > Positive review from the prior objections/suggested alterations that I > made, thank you to the authors for incorporating those. > > However, having read the entire document again top-to-bottom, > belligerently, I would suggest that the text of S7.2 is somewhat odd. > Generally this document goes to lengths to ensure that it is only > describing SRv6 problems, but in 7.2. we see: > > "7.2. Encapsulation of Packets > "Packets steered within an SR domain are typically encapsulated using > IPv6. Encapsulation at the SR ingress node, followed by decapsulation at > the SR egress node and forwarding of the inner packet without lookup, > provides two key benefits: > > "Mitigates external attacker capabilities against the domain > > "Supports encapsulation of both IPv4 and IPv6 packets > > "Practices outlined in Section 5 of [RFC8754] should be followed to > ensure exclusivity of use for any prefix configured within the trusted > domain." > > -- > > Primarily, the first line, "Packets steered within an SR domain are > typically encapsulated using IPv6." suggests that SR domains are > typically routed with SRv6? It might be true, but it's quite the > assertion to make here, and this document is only about SRv6 - so the > point is moot. > I think that's simply awkward wording. > > I am also not particularly sure that 'encapsulation of packets' is a > viable mitigation given that it is describing the intended operation of > SRv6, and nor do I believe that it is a viable way to protect against > external attacks -- because fundamentally the problem is that a router > *isn't capable* of distinguishing between SRv6 and IPv6 unless we give > it a mechanism to do so, hence draft-ravioli-trusted-domain-srv6, and > latterly this draft. > > I'd recommend removing S7.2 entirely, I think. > I don't think we want to remove that section because there is an important up reference to encapsulation in 7.1.2 that was flagged as a "Major Issue" in our Opsdir review that would be orphaned. Alternatively, we could restructure the section to address the inconsistency of "SR Domain" and provide some deeper detail that may make this make more sense. How about something like: OLD: Packets steered within an SRv6 domain are typically encapsulated using IPv6. Encapsulation at the SRv6 ingress node, followed by decapsulation at the SRv6 egress node and forwarding of the inner packet without lookup, provides two key benefits: - Mitigates external attacker capabilities against the domain - Supports encapsulation of both IPv4 and IPv6 packets Practices outlined in Section 5 of [RFC8754] should be followed to ensure exclusivity of use for any prefix configured within the trusted domain. NEW: In SRv6 deployments, an operator may steer traffic using IPv6-in-IPv6 encapsulation, imposing a new outer IPv6 header and SRH at the SR ingress node rather than processing SRH/SIDs on packets received directly from untrusted-facing interfaces. This is a specific case of the trusted-domain filtering discussed in Section 7.1: because the outer header and SRH are always originated by a trusted node, forwarding decisions within the domain never depend on header fields supplied by an untrusted source. Decapsulating and forwarding the inner packet without a second lookup at the SR egress node also prevents internal SR-domain information such as segment lists, SIDs, and/or TLVs from being exposed beyond the domain boundary. As discussed in Section 7.1.2, this practice also addresses the case of a packet carrying an SRH while only transiting rather than terminating within the domain. Encapsulation does not by itself protect against an attacker capable of injecting packets that satisfy the domain's boundary-filtering criteria (Section 7.1.3); it is complementary to, but not a substitute for, boundary filtering. Practices outlined in Section 5 of [RFC8754] describe this deployment model, including the address-range exclusivity assumptions its security properties depend on. If we wanted we could also mention T.Encaps behavior of RFC 8986, but I don't know that it's necessary here. I think the above text relays the message fairly well. Thoughts? > Otherwise I'm happy to proceed with the draft. > > Tom > > > --00000000000058a8e506574880f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 22,= 2026 at 7:20=E2=80=AFPM Tom Hill <<a href=3D"mailto:[email protected]= ">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex">On 2026-07-06 19:58, Alvaro Retana wrote:<br> > I would love a positive ack from the people who raised the<br> > issues/suggestions before moving forward.=C2=A0 Specifically, Weiqiang= and <br> > Tom.<br> <br> Positive review from the prior objections/suggested alterations that I <br> made, thank you to the authors for incorporating those.<br> <br> However, having read the entire document again top-to-bottom, <br> belligerently, I would suggest that the text of S7.2 is somewhat odd. <br> Generally this document goes to lengths to ensure that it is only <br> describing SRv6 problems, but in 7.2. we see:<br> <br> "7.2. Encapsulation of Packets<br> "Packets steered within an SR domain are typically encapsulated using = <br> IPv6. Encapsulation at the SR ingress node, followed by decapsulation at <b= r> the SR egress node and forwarding of the inner packet without lookup, <br> provides two key benefits:<br> <br> "Mitigates external attacker capabilities against the domain<br> <br> "Supports encapsulation of both IPv4 and IPv6 packets<br> <br> "Practices outlined in Section 5 of [RFC8754] should be followed to <b= r> ensure exclusivity of use for any prefix configured within the trusted <br> domain."<br> <br> --<br> <br> Primarily, the first line, "Packets steered within an SR domain are <b= r> typically encapsulated using IPv6." suggests that SR domains are <br> typically routed with SRv6? It might be true, but it's quite the <br> assertion to make here, and this document is only about SRv6 - so the <br> point is moot.<br></blockquote><div><br></div><div>I think that's simpl= y awkward wording.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_q= uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2= 04);padding-left:1ex"> <br> I am also not particularly sure that 'encapsulation of packets' is = a <br> viable mitigation given that it is describing the intended operation of <br= > SRv6, and nor do I believe that it is a viable way to protect against <br> external attacks -- because fundamentally the problem is that a router <br> *isn't capable* of distinguishing between SRv6 and IPv6 unless we give = <br> it a mechanism to do so, hence draft-ravioli-trusted-domain-srv6, and <br> latterly this draft.<br> <br> I'd recommend removing S7.2 entirely, I think.<br></blockquote><div><br= ></div><div>I don't think we want to remove that section because there = is an important up reference to encapsulation in 7.1.2 that was flagged as = a "Major Issue" in our Opsdir review that would be orphaned. Alte= rnatively, we could restructure the section to address the inconsistency of= "SR Domain" and provide some deeper detail that may make this ma= ke more sense. How about something like:=C2=A0</div><div><br></div><div>OLD= :=C2=A0</div><div><br></div><div> <p class=3D"gmail-p1" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue"">Packets steered within an SRv6 domain are typically encap= sulated using IPv6. Encapsulation at the SRv6 ingress node, followed by dec= apsulation at the SRv6 egress node and forwarding of the inner packet witho= ut lookup, provides two key benefits: <span class=3D"gmail-Apple-converted-= space">=C2=A0</span></p> <p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue";min-height:15px"><br></p> <p class=3D"gmail-p1" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue"">- Mitigates external attacker capabilities against the do= main</p> <p class=3D"gmail-p1" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue"">- Supports encapsulation of both IPv4 and IPv6 packets</p= > <p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue";min-height:15px"><br></p> <p class=3D"gmail-p1" style=3D"margin:0px;font-style:normal;font-variant:no= rmal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;f= ont-stretch:normal;font-size:13px;line-height:normal;font-family:"Helv= etica Neue"">Practices outlined in Section 5 of [RFC8754] should be fo= llowed to ensure exclusivity of use for any prefix configured within the tr= usted domain.</p></div><div><br></div><div>NEW:</div><p class=3D"gmail-p1" = style=3D"margin:0px;font:13px "Helvetica Neue";min-height:15px"><= br></p><p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;font-var= iant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:n= ormal;font-weight:normal;font-stretch:normal;line-height:normal"><font face= =3D"arial, sans-serif">In SRv6 deployments, an operator may steer traffic u= sing IPv6-in-IPv6 encapsulation, imposing a new outer IPv6 header and SRH a= t the SR ingress node rather than processing SRH/SIDs on packets received d= irectly from untrusted-facing interfaces.</font></p><p class=3D"gmail-p2" s= tyle=3D"margin:0px;font-style:normal;font-variant:normal;font-size-adjust:n= one;font-kerning:auto;font-feature-settings:normal;font-weight:normal;font-= stretch:normal;line-height:normal"><font face=3D"arial, sans-serif">This is= a specific case of the trusted-domain filtering discussed in Section 7.1:= =C2=A0</font></p><p class=3D"gmail-p2" style=3D"margin:0px;font-style:norma= l;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-= settings:normal;font-weight:normal;font-stretch:normal;line-height:normal">= <span style=3D"font-family:arial,sans-serif;background-color:transparent">b= ecause the outer header and SRH are always originated by a trusted node, fo= rwarding decisions within the domain never depend on header fields supplied= by an untrusted source. Decapsulating and forwarding the inner packet with= out a second lookup at the SR egress node also prevents internal SR-domain = information such as segment lists, SIDs, and/or TLVs from being exposed bey= ond the domain boundary.</span></p><p class=3D"gmail-p2" style=3D"margin:0p= x;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:= auto;font-feature-settings:normal;font-weight:normal;font-stretch:normal;li= ne-height:normal"><span style=3D"font-family:arial,sans-serif;background-co= lor:transparent"><br></span></p><p class=3D"gmail-p2" style=3D"margin:0px;f= ont-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:aut= o;font-feature-settings:normal;font-weight:normal;font-stretch:normal;line-= height:normal"><font face=3D"arial, sans-serif">As discussed in Section 7.1= .2, this practice also addresses the case of a packet carrying an SRH while= only transiting rather than terminating within the domain. Encapsulation d= oes not by itself protect against an attacker capable of injecting packets = that satisfy the domain's boundary-filtering criteria (Section 7.1.3); = it is complementary to, but not a substitute for, boundary filtering.</font= ></p><p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;font-varia= nt:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:nor= mal;font-weight:normal;font-stretch:normal;line-height:normal"><font face= =3D"arial, sans-serif"><br></font></p><p dir=3D"ltr" style=3D"box-sizing:bo= rder-box;border-width:0px;border-style:solid;margin:0px;padding:0px;outline= -color:rgb(85,152,231);background-color:rgb(32,32,31)"> </p><p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;font-varian= t:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:norm= al;font-stretch:normal;line-height:normal"><font face=3D"arial, sans-serif"= >Practices outlined in Section 5 of=C2=A0[RFC8754] describe this deployment= model, including the address-range exclusivity assumptions its security pr= operties depend on.=C2=A0</font></p><p class=3D"gmail-p2" style=3D"margin:0= px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning= :auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-= height:normal;font-family:"Helvetica Neue""><br></p><p class=3D"g= mail-p2" style=3D"margin:0px;font-style:normal;font-variant:normal;font-siz= e-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:n= ormal;font-size:13px;line-height:normal;font-family:"Helvetica Neue&qu= ot;"><br></p><p class=3D"gmail-p2" style=3D"margin:0px;font-style:normal;fo= nt-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-sett= ings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-fami= ly:"Helvetica Neue"">If we wanted we could also mention=C2=A0<spa= n style=3D"font-family:arial,sans-serif;font-size:small;background-color:tr= ansparent">T.Encaps behavior of RFC 8986, but I don't know that it'= s necessary=C2=A0here. I think the above text relays the message fairly wel= l. Thoughts?=C2=A0=C2=A0</span><span style=3D"font-family:arial,sans-serif;= font-size:small;background-color:transparent">=C2=A0</span></p><p class=3D"= gmail-p2" style=3D"margin:0px;font-style:normal;font-variant:normal;font-si= ze-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:= normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue&q= uot;"><br></p><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Otherwise I'm happy to proceed with the draft.<br> <br> Tom<br> <br> <br> </blockquote></div></div> --00000000000058a8e506574880f2-- --===============0388304985664315671== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK --===============0388304985664315671==--