[spring] Re: [SRv6OPS] Second WG Last Call: draft-ietf -spring-srv6-security-14 (Ends 2026-06-02)
Alvaro Retana <[email protected]> Thu, 4 Jun 2026 10:25:47 -0500
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <CAMMESsxH_iMdrSjsdF9=mjB8Us7KF7yDR8JBnfe9-RucH-v6Dw@mail.gmail.com> |
--===============4816977396127625500== Content-Type: multipart/alternative; boundary="000000000000a78a5206536f2841" --000000000000a78a5206536f2841 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Speaking as a participant.] I agree with Tom=E2=80=99s points and suggestions. Most uses of =E2=80=9Cdomain=E2=80=9D in the draft are qualified to indicat= e that they refer to an =E2=80=9CSR domain=E2=80=9D (for example), avoiding confusion. = There are still a couple of cases where =E2=80=9Cdomain=E2=80=9D is not qualified; please t= ake a look. Thanks! Alvaro. On June 2, 2026 at 9:36:53=E2=80=AFAM, Tom Hill ([email protected]) wrote= : On 2026-06-02 14:20, Tom Hill wrote: > Hi Weiqiang, Nick, > > On 2026-05-29 22:47, Nick Buraglio wrote: >> On Tue, May 19, 2026 at 11:53=E2=80=AFPM Weiqiang Cheng < >> [email protected]> wrote: >>> Two minor comments to help define scope earlier: >>> >>> 1. >>> >>> Section 2 could note that inter-SR-domain scenarios are out of >>> scope >>> (as already stated in Section 4). >>> 2. >>> >>> The point that SRv6 inherits IPv6 vulnerabilities but that this is >>> out >>> of scope (currently in Section 6.2.4) could also be mentioned in >>> Section 2 >>> or the introduction. >>> >> How does this sound? >> OLD: >> We note that SRv6 is under active development and, as such, the above >> documents might not cover all protocols employed in an SRv6 >> deployment. >> >> NEW: >> Inter-Domain Segment Routing scenarios are out of scope for this >> document >> as are existing and future protocol specific IPv6 vulnerabilities. >> Additionally, we note that SRv6 is under active development and, as >> such, >> the above documents might not cover all protocols employed in an SRv6 >> deployment. >> >> >> We can leave the existing statements further in the document unless >> the WG >> feels that they are unnecessary. > > Per RFC8402 S8, if you take that a 'domain' is the "trusted domain", > e.g. "By default, SR operates within a trusted domain. Traffic MUST be > filtered at the domain boundaries." then by that assumption there is no > such definition of 'Inter-domain SRv6', because it violates Section 8 > of RFC8402 as written. > > If you take "inter-domain" to mean any EPE boundary (per RFC8402, S4.2) > then I don't think should be out of scope of this document, as it is > entirely valid for an operator to have multiple eBGP boundaries within > their trusted domain (for reasons of acquisition, blast radius, etc.) > and for us to be concerned about the security of those deployments. > > Irrespective of the assumption made, I do not believe that it is for > this document to define "inter-domain SRv6", and thus we should not do > so (especially at this late stage). Detailing the security > considerations of SRv6 domains that exceed the trusted domains of the > operator would be nebulous, and there-in lies one of the reasons that > this document exists; it builds upon the clear statement made in S4.2 > of RFC8402. > > I do not support this proposed change to the document. Further to the above, I think we can make the text in the last paragraph of Section 4 of this draft, somewhat clearer of its intention - please do let me know if I have perceived that intent correctly. OLD TEXT: Inter-SR-domain scenarios are out of scope, including cases where multiple SR instances exist under the same administrative entity but are logically or operationally distinct; such cases are treated as separate SR domains for the purposes of this draft. Specifically, an attack on one domain that is invoked from within a different domain is considered an external attack in the context of the current document. NEW TEXT: SRv6 deployments that exceed their trusted domain (per [RFC8402, Section 4.2) including cases where multiple SR instances exist under the same administrative entitty, but are logically or operationally distinct, are out of the scope of this document. Where an attack originates from within a different trusted domain it is considered an external attack in the context of this document. --=20 This appears to me at least to have fewer uses of ambiguous terms, and much more clearly defines the scope of this document. Tom --000000000000a78a5206536f2841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id= =3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:13px;m= argin:0px;line-height:auto">[Speaking as a participant.]</div><div id=3D"bl= oop_customfont" style=3D"font-family:Helvetica,Arial;font-size:13px;margin:= 0px;line-height:auto"><br></div><div id=3D"bloop_customfont" style=3D"font-= family:Helvetica,Arial;font-size:13px;margin:0px;line-height:auto">I agree = with Tom=E2=80=99s points and suggestions.</div><div id=3D"bloop_customfont= " style=3D"font-family:Helvetica,Arial;font-size:13px;margin:0px;line-heigh= t:auto"><br></div><div id=3D"bloop_customfont" style=3D"font-family:Helveti= ca,Arial;font-size:13px;margin:0px;line-height:auto"><br></div><div id=3D"b= loop_customfont" style=3D"font-family:Helvetica,Arial;font-size:13px;margin= :0px;line-height:auto">Most uses of =E2=80=9Cdomain=E2=80=9D in the draft a= re qualified to indicate that they refer to an =E2=80=9CSR domain=E2=80=9D = (for example), avoiding confusion.=C2=A0 There are still a couple of cases = where =E2=80=9Cdomain=E2=80=9D is not qualified; please take a look.</div><= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:= 13px;margin:0px;line-height:auto"><br></div><div id=3D"bloop_customfont" st= yle=3D"font-family:Helvetica,Arial;font-size:13px;margin:0px;line-height:au= to">Thanks!</div><div id=3D"bloop_customfont" style=3D"font-family:Helvetic= a,Arial;font-size:13px;margin:0px;line-height:auto"><br></div><div id=3D"bl= oop_customfont" style=3D"font-family:Helvetica,Arial;font-size:13px;margin:= 0px;line-height:auto">Alvaro.</div> <br><p class=3D"airmail_on">On June 2, = 2026 at 9:36:53=E2=80=AFAM, Tom Hill (<a href=3D"mailto:[email protected]= ">[email protected]</a>) wrote:</p> <blockquote type=3D"cite" class=3D"cl= ean_bq"><span><div><div></div><div>On 2026-06-02 14:20, Tom Hill wrote: <br>> Hi Weiqiang, Nick, <br>> =20 <br>> On 2026-05-29 22:47, Nick Buraglio wrote: <br>>> On Tue, May 19, 2026 at 11:53=E2=80=AFPM Weiqiang Cheng < <br>>> <a href=3D"mailto:[email protected]">chengweiqiang= @chinamobile.com</a>> wrote: <br>>>> Two minor comments to help define scope earlier: <br>>>> =20 <br>>>> 1. <br>>>> =20 <br>>>> Section 2 could note that inter-SR-domain scenarios are= out of =20 <br>>>> scope <br>>>> (as already stated in Section 4). <br>>>> 2. <br>>>> =20 <br>>>> The point that SRv6 inherits IPv6 vulnerabilities but t= hat this is =20 <br>>>> out <br>>>> of scope (currently in Section 6.2.4) could also be men= tioned in =20 <br>>>> Section 2 <br>>>> or the introduction. <br>>>> =20 <br>>> How does this sound? <br>>> OLD: <br>>> We note that SRv6 is under active development and, as such, th= e above <br>>> documents might not cover all protocols employed in an SRv6 = =20 <br>>> deployment. <br>>> =20 <br>>> NEW: <br>>> Inter-Domain Segment Routing scenarios are out of scope for th= is =20 <br>>> document <br>>> as are existing and future protocol specific IPv6 vulnerabilit= ies. <br>>> Additionally, we note that SRv6 is under active development an= d, as =20 <br>>> such, <br>>> the above documents might not cover all protocols employed in = an SRv6 <br>>> deployment. <br>>> =20 <br>>> =20 <br>>> We can leave the existing statements further in the document u= nless =20 <br>>> the WG <br>>> feels that they are unnecessary. <br>> =20 <br>> Per RFC8402 S8, if you take that a 'domain' is the "t= rusted domain", =20 <br>> e.g. "By default, SR operates within a trusted domain. Traff= ic MUST be =20 <br>> filtered at the domain boundaries." then by that assumption t= here is no =20 <br>> such definition of 'Inter-domain SRv6', because it violate= s Section 8 =20 <br>> of RFC8402 as written. <br>> =20 <br>> If you take "inter-domain" to mean any EPE boundary (per= RFC8402, S4.2) =20 <br>> then I don't think should be out of scope of this document, as= it is =20 <br>> entirely valid for an operator to have multiple eBGP boundaries wi= thin =20 <br>> their trusted domain (for reasons of acquisition, blast radius, et= c.) =20 <br>> and for us to be concerned about the security of those deployments= . <br>> =20 <br>> Irrespective of the assumption made, I do not believe that it is f= or =20 <br>> this document to define "inter-domain SRv6", and thus we= should not do =20 <br>> so (especially at this late stage). Detailing the security =20 <br>> considerations of SRv6 domains that exceed the trusted domains of = the =20 <br>> operator would be nebulous, and there-in lies one of the reasons t= hat =20 <br>> this document exists; it builds upon the clear statement made in S= 4.2 =20 <br>> of RFC8402. <br>> =20 <br>> I do not support this proposed change to the document. <br> <br>Further to the above, I think we can make the text in the last paragrap= h =20 <br>of Section 4 of this draft, somewhat clearer of its intention - please = =20 <br>do let me know if I have perceived that intent correctly. <br> <br>OLD TEXT: Inter-SR-domain scenarios are out of scope, including cases = =20 <br>where <br> multiple SR instances exist under the same administrative entity bu= t <br> are logically or operationally distinct; such cases are treated as <br> separate SR domains for the purposes of this draft. Specifically, = an <br> attack on one domain that is invoked from within a different domain <br> is considered an external attack in the context of the current <br> document. <br> <br>NEW TEXT: SRv6 deployments that exceed their trusted domain (per =20 <br>[RFC8402, Section 4.2) including cases where multiple SR instances exis= t =20 <br>under the same administrative entitty, but are logically or =20 <br>operationally distinct, are out of the scope of this document. Where an= =20 <br>attack originates from within a different trusted domain it is =20 <br>considered an external attack in the context of this document. <br> <br>-- =20 <br> <br>This appears to me at least to have fewer uses of ambiguous terms, and = =20 <br>much more clearly defines the scope of this document. <br> <br>Tom <br> <br> <br></div></div></span></blockquote> <div id=3D"bloop_sign_1780586510208444= 160" class=3D"bloop_sign"></div> --000000000000a78a5206536f2841-- --===============4816977396127625500== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK --===============4816977396127625500==--