[spring] Re: [SRv6OPS] Second WG Last Call: draft-ietf -spring-srv6-security-14 (Ends 2026-06-02)
Nick Buraglio <[email protected]> Fri, 29 May 2026 18:05:37 -0500
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <CACMsEX-VcemjD2qtk8yycRPKo0GNowgAuUoD-vFw_ZDqkg8AgQ@mail.gmail.com> |
--===============3850711579971594576== Content-Type: multipart/alternative; boundary="000000000000c28f620652fce2a2" --000000000000c28f620652fce2a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 21, 2026 at 12:53=E2=80=AFPM Andrew Stone (Nokia) < [email protected]> wrote: > Hi SPRING WG, Authors > > I support publication of the document. It's well-written and an easy read= , > and I appreciate how tricky it must have been to balance scoping the > document to SRv6 without bleeding into other technology security > considerations. > > Some minor non-blocking comments and feedback: > > > Introduction: > > The list of segments is in the SRH and may not be processed at each hop i= n > the case of non-SR capable hops. So Perhaps: > > OLD > "list of segments that are processed at each hop along the signaled path" > > NEW > "list of segments that are processed at each SR capable hop along the > signaled path" > > (or replace /capable/supporting/supported/aware etc. or equivalent) > > > > Section 6.3.4.1 > > Not sure I fully agree with this statement of "single point of failure" > depending on the definition of single point of failure. PCE/PCECC can be > designed with its own logical distribution/redundancy/ha. So, while it's > logically one attack surface from a PCE component perspective, the > implementation doesn't necessarily mean "one box" or single-point failure > nore does it mean the attack on the single instance is an attack on the > entire network (RFC4655). Likewise, not all PCCs in a SR domain may be > talking to the same PCE instance. I absolutely do agree however that it i= s > a centralized, focal point for many network element(s) and thus is a key > attack vector. Perhaps an adjustment to the text such as.... > > > OLD > Centralized control plane architectures, such as those based on the Path > Computation Element (PCE) [RFC4655] and PCE as a Central Controller (PCEC= C) > [RFC8283], inherently introduce a single point of failure. This > centralization may present a security vulnerability, particularly with > respect to denial-of-service (DoS) attacks targeting the controller. > Furthermore, the central controller becomes a focal point for potential > interception or manipulation of control messages exchanged with individua= l > Network Elements (NEs), thereby increasing the risk of compromise to the > overall network control infrastructure. > > NEW > Centralized control plane architectures, such as those based on the Path > Computation Element (PCE) [RFC4655] and PCE as a Central Controller (PCEC= C) > [RFC8283], inherently introduce a focal point for attacks against the > controller, such as denial-of-service (DoS), or attacks against one or ma= ny > network element(s) under control of the PCE/PCCC in an SR domain, thereby > increasing the risk of compromise to the overall network control > infrastructure. > > Agreed, added. > > Section 7.4: > > reference I-D.ietf-pce-segment-routing-policy-cp can be updated to RFC986= 2 > Done. > > > Thanks > Andrew > > *From: *Alvaro Retana via Datatracker <[email protected]> > *Date: *Monday, May 18, 2026 at 3:45=E2=80=AFPM > *To: *[email protected] < > [email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]>; [email protected]= m > <[email protected]> > *Cc: *[email protected] <[email protected]>; [email protected] <[email protected]> > *Subject: *[SRv6OPS] Second WG Last Call: > draft-ietf-spring-srv6-security-14 (Ends 2026-06-02) > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > This message starts a Second WG Last Call for: > draft-ietf-spring-srv6-security-14 > > This Working Group Last Call ends on 2026-06-02 > > 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. > > File can be retrieved from: > > Please review and indicate your support or objection to proceed with the > publication of this document by replying to this email keeping > [email protected] in copy. Objections should be explained and suggestions t= o > resolve them are highly appreciated. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [1]. > Appropriate IPR disclosures required for full conformance with the > provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can b= e > found at [3]. > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > 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-14.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-spring-srv6-securi= ty-14 > > _______________________________________________ > SRv6OPS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --000000000000c28f620652fce2a2 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 Thu, May 21,= 2026 at 12:53=E2=80=AFPM Andrew Stone (Nokia) <<a href=3D"mailto:andrew= [email protected]">[email protected]</a>> wrote:<br></div><blockquot= e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid rgb(204,204,204);padding-left:1ex"> <div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> Hi SPRING WG, Authors</div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c= olor:rgb(0,0,0)"> I support publication of the document. It's well-written and an easy re= ad, and I appreciate how tricky it must have been to balance scoping the do= cument to SRv6 without bleeding into other technology security consideratio= ns.</div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c= olor:rgb(0,0,0)"> Some minor non-blocking comments and feedback:</div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c= olor:rgb(0,0,0)"> Introduction:=C2=A0</div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> The list of segments is in the SRH and may not be processed at each hop in = the case of non-SR capable hops. So Perhaps:=C2=A0</div> <div style=3D"direction:ltr;margin-right:40px;margin-left:40px;font-family:= Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> OLD</div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> "list of segments that are processed at each hop along the signaled pa= th"</div> <div style=3D"direction:ltr;margin-right:40px;margin-left:40px;font-family:= Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> NEW</div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> "list of segments that are processed at each SR capable hop along the = signaled path"</div> <div style=3D"direction:ltr;margin-right:40px;margin-left:40px;font-family:= Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"margin-right:80px;margin-left:80px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> (or replace /capable/supporting/supported/aware etc. or equivalent)</div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c= olor:rgb(0,0,0)"> Section 6.3.4.1</div> <div style=3D"direction:ltr;margin-right:40px;margin-left:40px;font-family:= Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> Not sure I fully agree with this statement of "single point of failure= " depending on the definition of single point of failure. PCE/PCECC ca= n be designed with its own logical distribution/redundancy/ha. So, while it= 's logically one attack surface from a PCE component perspective, the implementation doesn't necessarily mean &qu= ot;one box" or single-point failure nore does it mean the attack on th= e single instance is an attack on the entire network (RFC4655). Likewise, n= ot all PCCs in a SR domain may be talking to the same PCE instance. I absolutely do agree however that it is a centralized,= focal point for many network element(s) and thus is a key attack vector. P= erhaps an adjustment to the text such as....</div> <div style=3D"direction:ltr;margin-right:40px;margin-left:40px;font-family:= Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"direction:ltr;margin-right:40px;margin-left:40px;font-family:= Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> OLD</div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> Centralized control plane architectures, such as those based on the Path Co= mputation Element (PCE) [RFC4655] and PCE as a Central Controller (PCECC) [= RFC8283], inherently introduce a single point of failure. This centralizati= on may present a security vulnerability, particularly with respect to denial-of-service (DoS) attacks targeting the= controller. Furthermore, the central controller becomes a focal point for = potential interception or manipulation of control messages exchanged with i= ndividual Network Elements (NEs), thereby increasing the risk of compromise to the overall network control i= nfrastructure.</div> <div style=3D"direction:ltr;margin-right:40px;margin-left:40px;font-family:= Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> NEW</div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> Centralized control plane architectures, such as those based on the Path Co= mputation Element (PCE) [RFC4655] and PCE as a Central Controller (PCECC) [= RFC8283], inherently introduce a focal point for attacks against the contro= ller, such as denial-of-service (DoS), or attacks against one or many network element(s) under control of = the PCE/PCCC in an SR domain, thereby increasing the risk of compromise to = the overall network control infrastructure.=C2=A0</div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br></div></div></blockquote><div>Agreed, added.=C2=A0=C2=A0</div><blockquo= te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = solid rgb(204,204,204);padding-left:1ex"><div><div style=3D"direction:ltr;f= ont-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)= "> </div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c= olor:rgb(0,0,0)"> Section 7.4:=C2=A0</div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"margin-right:40px;margin-left:40px;font-family:Aptos,Arial,He= lvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> reference I-D.ietf-pce-segment-routing-policy-cp can be updated to RFC9862<= /div></div></blockquote><div><br></div><div>Done.=C2=A0=C2=A0</div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex"><div> <div style=3D"direction:ltr;margin-right:40px;margin-left:40px;font-family:= Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"direction:ltr;margin-right:40px;margin-left:40px;font-family:= Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> <br> </div> <div style=3D"direction:ltr;margin-right:40px;margin-left:0px;font-family:A= ptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> Thanks</div> <div style=3D"direction:ltr;margin-right:40px;margin-left:0px;font-family:A= ptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"> Andrew</div> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div> <div id=3D"m_-2137715162935633588mail-editor-reference-message-container" s= tyle=3D"color:inherit;background-color:inherit"> <div style=3D"direction:ltr"> </div> <div style=3D"padding:3pt 0in 0in;border-width:1pt medium medium;border-sty= le:solid none none;border-color:rgb(181,196,223) currentcolor currentcolor"= > <div style=3D"text-align:left;font-family:Aptos;font-size:12pt;color:black"= > <b>From: </b>Alvaro Retana via Datatracker <<a href=3D"mailto:noreply@ie= tf.org" target=3D"_blank">[email protected]</a>><br> <b>Date: </b>Monday, May 18, 2026 at 3:45=E2=80=AFPM<br> <b>To: </b><a href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a> <<a href=3D"m= ailto:[email protected]" target=3D"_blank">draft-iet= [email protected]</a>>; <a href=3D"mailto:spring-chairs@ie= tf.org" target=3D"_blank">[email protected]</a> <<a href=3D"mailto:= [email protected]" target=3D"_blank">[email protected]</a>>; <= a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a> <= ;<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&g= t;; <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a> = <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&= gt;<br> <b>Cc: </b><a href=3D"mailto:[email protected]" target=3D"_blank">srv6ops@ie= tf.org</a> <<a href=3D"mailto:[email protected]" target=3D"_blank">srv6op= [email protected]</a>>; <a href=3D"mailto:[email protected]" target=3D"_blank">ipv6= @ietf.org</a> <<a href=3D"mailto:[email protected]" target=3D"_blank">ipv6@i= etf.org</a>><br> <b>Subject: </b>[SRv6OPS] Second WG Last Call: draft-ietf-spring-srv6-secur= ity-14 (Ends 2026-06-02)<br> <br> </div> </div> <div style=3D"font-size:11pt"><br> CAUTION: This is an external email. Please be very careful when clicking li= nks or opening attachments. See the URL <a href=3D"http://nok.it/ext" targe= t=3D"_blank">nok.it/ext</a> for additional information.<br> <br> <br> <br> This message starts a Second WG Last Call for:<br> draft-ietf-spring-srv6-security-14<br> <br> This Working Group Last Call ends on 2026-06-02<br> <br> Abstract:<br> =C2=A0=C2=A0 SRv6 is a traffic engineering, encapsulation and steering mech= anism<br> =C2=A0=C2=A0 utilizing IPv6 addresses to identify segments in a pre-defined= <br> =C2=A0=C2=A0 policy.=C2=A0 This document discusses security considerations = in SRv6<br> =C2=A0=C2=A0 networks, including the potential threats and the possible mit= igation<br> =C2=A0=C2=A0 methods.=C2=A0 The document does not define any new security p= rotocols or<br> =C2=A0=C2=A0 extensions to existing protocols.<br> <br> File can be retrieved from:<br> <br> Please review and indicate your support or objection to proceed with the<br= > publication of this document by replying to this email keeping<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a> in= copy. Objections should be explained and suggestions to<br> resolve them are highly appreciated.<br> <br> Authors, and WG participants in general, are reminded of the Intellectual<b= r> Property Rights (IPR) disclosure obligations described in BCP 79 [1].<br> Appropriate IPR disclosures required for full conformance with the provisio= ns<br> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.<br> Sanctions available for application to violators of IETF IPR Policy can be<= br> found at [3].<br> <br> Thank you.<br> <br> [1] <a href=3D"https://datatracker.ietf.org/doc/bcp78/" target=3D"_blank"> https://datatracker.ietf.org/doc/bcp78/</a><br> [2] <a href=3D"https://datatracker.ietf.org/doc/bcp79/" target=3D"_blank"> https://datatracker.ietf.org/doc/bcp79/</a><br> [3] <a href=3D"https://datatracker.ietf.org/doc/rfc6701/" target=3D"_blank"= > https://datatracker.ietf.org/doc/rfc6701/</a><br> <br> The IETF datatracker status page for this Internet-Draft is:<br> <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security= /" target=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-spring-srv= 6-security/</a><br> <br> There is also an HTML version available at:<br> <a href=3D"https://www.ietf.org/archive/id/draft-ietf-spring-srv6-security-= 14.html" target=3D"_blank">https://www.ietf.org/archive/id/draft-ietf-sprin= g-srv6-security-14.html</a><br> <br> A diff from the previous version is available at:<br> <a href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-spring-sr= v6-security-14" target=3D"_blank">https://author-tools.ietf.org/iddiff?url2= =3Ddraft-ietf-spring-srv6-security-14</a><br> <br> _______________________________________________<br> SRv6OPS mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" t= arget=3D"_blank">[email protected]</a></div> </div> </div> </blockquote></div></div> --000000000000c28f620652fce2a2-- --===============3850711579971594576== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK --===============3850711579971594576==--