[spring] Re: Second WG Last Call: draft-ietf-spring-srv6-s ecurity-14 (Ends 2026-06-02)
Nick Buraglio <[email protected]> Fri, 29 May 2026 17:58:57 -0500
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <CACMsEX8=v91Qi_nne_SOMv0Z4m29SF5x5wOcN1JOhKTPnDX0xA@mail.gmail.com> |
--===============1427410124639119021== Content-Type: multipart/alternative; boundary="000000000000cd9a590652fcca13" --000000000000cd9a590652fcca13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 21, 2026 at 7:58=E2=80=AFAM Bal=C3=A1zs Varga A <balazs.a.varga= @ericsson.com> wrote: > Hi, > > I support the publication of draft-ietf-spring-srv6-security-14. It > provides important aspects of SRv6 networking. > > Comment for a possible consideration: > - pointing to MACSec (using it for communication integrity regarding > SRv6-specifics) > Upper layers like ESP or TLS may protect the user data. However, in the > scope of SRV6, only the elements considered > to route the packet needs to be considered, whereas such packet header > fields change during the forwarding. HMAC > has its own limitations (listed properly in the document). Assuming SRV6 > links are protected by MACsec, passively > listening or spoofing or manipulating packet can only be performed by an > attacker that has compromised a node. > If MACsec is not deployed, then any on path attacker can perform such > techniques. So, communication integrity > regarding SRv6-specifics can be provided by MACsec. Maybe worth to state > this clearly in the document > (i.e., lower layer may help here). > I want us to be careful here. I do think that we should probably put in a bit about MACsec, but does that open the door to including things like optical level encryption over wavelengths on WDM paths? Here is what I propose, without going to deep into the technology, under section 7.5: NEW: ## Layer 2 Mitigation In some circumstances it may be possible to mitigate passive listening and packet insertion by leveraging [MACsec] to encrypt traffic at the media access control (MAC) layer by using encryption between two connected devices. This methodology prevents unauthorized access to traffic over a given point to point path by encrypting and authenticating data in motion at Layer 2 of the OSI model. Much like the encryption mechanisms noted for protocol communication and management access, this level of protection can provide integrity and authenticity to all higher layer communications over a given layer 2 path. This will require some changes to the table as well, and since MACsec could potentially cover most of these, we'd need to add something like this: OLD: +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Attacks | Mitigation Methods | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Modification attack (6.2.1) | Trusted domains and filtering (7.1)| | | Encapsulation of packets (7.2) | | | HMAC (7.3) | +-------------------------------+------------------------------------+ | Passive listening (6.2.2) | Trusted domains and filtering (7.1)| | | Encapsulation of packets (7.2) | +-------------------------------+------------------------------------+ | Packet insertion and | Trusted domains and filtering (7.1)| | replaying (6.2.3) | Encapsulation of packets (7.2) | | | HMAC (7.3) | +-------------------------------+------------------------------------+ | Control plane attacks (6.3) | Control plane mitigations (7.4) | +-------------------------------+------------------------------------+ | Management plane attacks (6.4)| Management plane mitigations (7.5) | +-------------------------------+------------------------------------+ NEW: +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Attacks | Mitigation Methods | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Modification attack (6.2.1) | Trusted domains and filtering (7.1)| | | Encapsulation of packets (7.2) | | | HMAC (7.3) | | | MACsec (7.6) | +-------------------------------+------------------------------------+ | Passive listening (6.2.2) | Trusted domains and filtering (7.1)| | | Encapsulation of packets (7.2) | | | MACsec (7.6) | +-------------------------------+------------------------------------+ | Packet insertion and | Trusted domains and filtering (7.1)| | replaying (6.2.3) | Encapsulation of packets (7.2) | | | HMAC (7.3) | | | MACsec (7.6) | +-------------------------------+------------------------------------+ | Control plane attacks (6.3) | Control plane mitigations (7.4) | | | MACsec (7.6) | +-------------------------------+------------------------------------+ | Management plane attacks (6.4)| Management plane mitigations (7.5) | | | MACsec (7.6) | +-------------------------------+------------------------------------+ > > Minor (& subjective) comments: > - insertion: maybe injection might be a more appropriate term (e.g., > Section 4. Threat Terminology) > I leave this to the group to decide. I am happy with the current terminology but if others have very strong opinions we can change it. > - resource exhaustion: maybe worth to add a special form of DoS, where a > modified path causes drop of time sensitive packets, as too late packets > are considered invalid (Section 5. Effect) > We currently have: OLD: Resource exhaustion: compromising the availability of the system can be achieved by sending SRv6-enabled packets to/through victim nodes in a way that results in a negative performance impact of the victim systems (e.g., = [ RFC9098 <https://buraglio.github.io/draft-bdmgct-spring-srv6-security/draft-ietf-sp= ring-srv6-security.html#RFC9098>]). For example, network programming can be used in some cases to manipulate segment endpoints to perform unnecessary functions that consume processing resources. Resource exhaustion may in severe cases cause Denial of Service (DoS). NEW: Resource exhaustion: compromising the availability of the system can be achieved by sending SRv6-enabled packets to/through victim nodes in a way that results in a negative performance impact of the victim systems (e.g., = [ RFC9098 <https://buraglio.github.io/draft-bdmgct-spring-srv6-security/draft-ietf-sp= ring-srv6-security.html#RFC9098>]). For example, network programming can be used in some cases to manipulate segment endpoints to perform unnecessary functions that consume processing resources, or cause drops of time sensitive packets which can cause too late packets which are considered invalid resulting in those packets being considered invalid. Resource exhaustion may in severe cases cause Denial of Service (DoS). - packet deletion: maybe packet drop would be a better term (e.g., Section > 6.1. Attack Abstractions) > I leave this to the group to decide. I am happy with the current terminology but if others have very strong opinions we can change it. > > Thanks & Cheers > Bala'zs > > -----Original Message----- > From: Alvaro Retana via Datatracker <[email protected]> > Sent: Monday, May 18, 2026 9:45 PM > To: [email protected]; [email protected]; > [email protected]; [email protected] > Cc: [email protected]; [email protected] > Subject: [spring] Second WG Last Call: draft-ietf-spring-srv6-security-14 > (Ends 2026-06-02) > > 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 > to 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 o= f > 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 > > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --000000000000cd9a590652fcca13 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 7:58=E2=80=AFAM Bal=C3=A1zs Varga A <<a href=3D"mailto:balazs.a= [email protected]">[email protected]</a>> wrote:<br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> I support the publication of draft-ietf-spring-srv6-security-14. It provide= s important aspects of SRv6 networking.<br> <br> Comment for a possible consideration:<br> - pointing to MACSec (using it for communication integrity regarding SRv6-s= pecifics)<br> Upper layers like ESP or TLS may protect the user data. However, in the sco= pe of SRV6, only the elements considered<br> to route the packet needs to be considered, whereas such packet header fiel= ds change during the forwarding. HMAC<br> has its own limitations (listed properly in the document). Assuming SRV6 li= nks are protected by MACsec, passively<br> listening or spoofing or manipulating packet can only be performed by an at= tacker that has compromised a node.<br> If MACsec is not deployed, then any on path attacker can perform such techn= iques. So, communication integrity<br> regarding SRv6-specifics can be provided by MACsec. Maybe worth to state th= is clearly in the document<br> (i.e., lower layer may help here).<br></blockquote><div><br></div><div>I wa= nt us to be careful here. I do think that we should probably put in a bit a= bout MACsec, but does that open the door to=C2=A0 including things like opt= ical level encryption=C2=A0over wavelengths on WDM paths?=C2=A0=C2=A0</div>= <div><br></div><div>Here is what I propose, without going to deep into the = technology, under section 7.5:=C2=A0</div><div><br></div><div>NEW:=C2=A0</d= iv><div><font style=3D"background-color:rgb(255,255,255)" color=3D"#000000"= face=3D"arial, sans-serif"><br></font></div><div><div style=3D"line-height= :18px;white-space:pre"><div style=3D""><div style=3D"line-height:18px"><div= style=3D""><font color=3D"#000000" style=3D"background-color:rgb(255,255,2= 55)" face=3D"arial, sans-serif">## Layer 2 Mitigation</font></div><font col= or=3D"#000000" style=3D"background-color:rgb(255,255,255)" face=3D"arial, s= ans-serif"><br></font><div style=3D""><font color=3D"#000000" style=3D"back= ground-color:rgb(255,255,255)"><font style=3D"" face=3D"arial, sans-serif">= In some circumstances it may be possible to mitigate passive listening and = packet insertion by leveraging [MACsec] to encrypt traffic at the media acc= ess control (MAC) layer by using encryption between two connected devices. = </font></font></div><div style=3D""><font color=3D"#000000" style=3D"backgr= ound-color:rgb(255,255,255)" face=3D"arial, sans-serif">This methodology pr= events unauthorized access to traffic over a given point to point path by e= ncrypting and authenticating data in motion at Layer 2 of the OSI model. Mu= ch like the encryption mechanisms noted for protocol communication and mana= gement access, this level of protection can provide integrity and authentic= ity to all higher layer communications over a given layer 2 path. </font></= div></div></div><div style=3D"font-size:12px"><font style=3D"background-col= or:rgb(255,255,255)" color=3D"#000000" face=3D"arial, sans-serif"><br></fon= t></div><div style=3D"font-size:12px"><font style=3D"background-color:rgb(2= 55,255,255)" color=3D"#000000" face=3D"arial, sans-serif">This will require= some changes to the table as well, and since MACsec could potentially cove= r most of these, we'd need to add something like this:</font></div><div= style=3D"font-size:12px"><font style=3D"background-color:rgb(255,255,255)"= color=3D"#000000" face=3D"arial, sans-serif"><br></font></div><div style= =3D"font-size:12px"><font style=3D"background-color:rgb(255,255,255)" color= =3D"#000000" face=3D"arial, sans-serif">OLD: </font></div><div style=3D"fon= t-size:12px"><font style=3D"background-color:rgb(255,255,255)" color=3D"#00= 0000" face=3D"arial, sans-serif"><br></font></div><div style=3D"font-size:1= 2px"><div style=3D"font-family:Menlo,Monaco,"Courier New",monospa= ce;line-height:18px"><div style=3D""><br></div><div style=3D""><span style= =3D"background-color:rgb(255,255,255)"><font color=3D"#000000">+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+</font></span></div><div styl= e=3D""><span style=3D"background-color:rgb(255,255,255)"><font color=3D"#00= 0000">| Attacks | Mitigation Methods = |</font></span></div><div style=3D""><span style=3D"background-color:rgb(25= 5,255,255)"><font color=3D"#000000">+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+</font></span></div><div style=3D""><span style=3D"backg= round-color:rgb(255,255,255)"><font color=3D"#000000">| Modification attack= (6.2.1) | Trusted domains and filtering (7.1)|</font></span></div><div s= tyle=3D""><span style=3D"background-color:rgb(255,255,255)"><font color=3D"= #000000">| | Encapsulation of packets (7.2) = |</font></span></div><div style=3D""><span style=3D"background-color:rgb= (255,255,255)"><font color=3D"#000000">| | HM= AC (7.3) |</font></span></div><div style=3D""><span= style=3D"background-color:rgb(255,255,255)"><font color=3D"#000000">+-----= --------------------------+------------------------------------+</font></sp= an></div><div style=3D""><span style=3D"background-color:rgb(255,255,255)">= <font color=3D"#000000">| Passive listening (6.2.2) | Trusted domains a= nd filtering (7.1)|</font></span></div><div style=3D""><span style=3D"backg= round-color:rgb(255,255,255)"><font color=3D"#000000">| = | Encapsulation of packets (7.2) |</font></span></div><div s= tyle=3D""><span style=3D"background-color:rgb(255,255,255)"><font color=3D"= #000000">+-------------------------------+---------------------------------= ---+</font></span></div><div style=3D""><span style=3D"background-color:rgb= (255,255,255)"><font color=3D"#000000">| Packet insertion and | Tr= usted domains and filtering (7.1)|</font></span></div><div style=3D""><span= style=3D"background-color:rgb(255,255,255)"><font color=3D"#000000">| repl= aying (6.2.3) | Encapsulation of packets (7.2) |</font></sp= an></div><div style=3D""><span style=3D"background-color:rgb(255,255,255)">= <font color=3D"#000000">| | HMAC (7.3) = |</font></span></div><div style=3D""><span style=3D"backg= round-color:rgb(255,255,255)"><font color=3D"#000000">+--------------------= -----------+------------------------------------+</font></span></div><div s= tyle=3D""><span style=3D"background-color:rgb(255,255,255)"><font color=3D"= #000000">| Control plane attacks (6.3) | Control plane mitigations (7.4) = |</font></span></div><div style=3D""><span style=3D"background-color:rgb= (255,255,255)"><font color=3D"#000000">+-------------------------------+---= ---------------------------------+</font></span></div><div style=3D""><span= style=3D"background-color:rgb(255,255,255)"><font color=3D"#000000">| Mana= gement plane attacks (6.4)| Management plane mitigations (7.5) |</font></sp= an></div><div style=3D""><span style=3D"background-color:rgb(255,255,255)">= <font color=3D"#000000">+-------------------------------+------------------= ------------------+</font></span></div></div></div><div style=3D"font-size:= 12px"><font style=3D"background-color:rgb(255,255,255)" color=3D"#000000" f= ace=3D"arial, sans-serif"><br></font></div><div style=3D"font-size:12px"><f= ont style=3D"background-color:rgb(255,255,255)" color=3D"#000000" face=3D"a= rial, sans-serif">NEW:</font></div><div style=3D"font-size:12px"><br></div>= <div style=3D"font-size:12px"><div style=3D"font-family:Menlo,Monaco,"= Courier New",monospace;line-height:18px"><div style=3D""><font color= =3D"#000000" style=3D"background-color:rgb(255,255,255)">+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+</font></div><div style=3D""><font = color=3D"#000000" style=3D"background-color:rgb(255,255,255)">| Attacks = | Mitigation Methods |</font></div><div = style=3D""><font color=3D"#000000" style=3D"background-color:rgb(255,255,25= 5)">+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+</font></div><= div style=3D""><font color=3D"#000000" style=3D"background-color:rgb(255,25= 5,255)">| Modification attack (6.2.1) | Trusted domains and filtering (7.= 1)|</font></div><div style=3D""><font color=3D"#000000" style=3D"background= -color:rgb(255,255,255)">| | Encapsulation of= packets (7.2) |</font></div><div style=3D""><font color=3D"#000000" st= yle=3D"background-color:rgb(255,255,255)">| |= HMAC (7.3) |</font></div><div style=3D""><font col= or=3D"#000000" style=3D"background-color:rgb(255,255,255)">| = | MACsec (7.6) |</font></div><div sty= le=3D""><font color=3D"#000000" style=3D"background-color:rgb(255,255,255)"= >+-------------------------------+------------------------------------+</fo= nt></div><div style=3D""><font color=3D"#000000" style=3D"background-color:= rgb(255,255,255)">| Passive listening (6.2.2) | Trusted domains and fil= tering (7.1)|</font></div><div style=3D""><font color=3D"#000000" style=3D"= background-color:rgb(255,255,255)">| | Encaps= ulation of packets (7.2) |</font></div><div style=3D""><div><font color= =3D"#000000">| | MACsec (7.6) = |</font></div></div><div style=3D""><font color=3D"#000000" style=3D= "background-color:rgb(255,255,255)">+-------------------------------+------= ------------------------------+</font></div><div style=3D""><font color=3D"= #000000" style=3D"background-color:rgb(255,255,255)">| Packet insertion and= | Trusted domains and filtering (7.1)|</font></div><div style=3D"= "><font color=3D"#000000" style=3D"background-color:rgb(255,255,255)">| rep= laying (6.2.3) | Encapsulation of packets (7.2) |</font></d= iv><div style=3D""><font color=3D"#000000" style=3D"background-color:rgb(25= 5,255,255)">| | HMAC (7.3) = |</font></div><div style=3D""><div><font color=3D"#000000">| = | MACsec (7.6) |</font></div></= div><div style=3D""><font color=3D"#000000" style=3D"background-color:rgb(2= 55,255,255)">+-------------------------------+-----------------------------= -------+</font></div><div style=3D""><font color=3D"#000000" style=3D"backg= round-color:rgb(255,255,255)">| Control plane attacks (6.3) | Control pla= ne mitigations (7.4) |</font></div><div style=3D""><div><font color=3D"#= 000000">| | MACsec (7.6) = |</font></div></div><div style=3D""><font color=3D"#000000" style=3D"back= ground-color:rgb(255,255,255)">+-------------------------------+-----------= -------------------------+</font></div><div style=3D""><font color=3D"#0000= 00" style=3D"background-color:rgb(255,255,255)">| Management plane attacks = (6.4)| Management plane mitigations (7.5) |</font></div><div style=3D""><di= v><font color=3D"#000000">| | MACsec (7.6) = |</font></div></div><div style=3D""><font color=3D"#000= 000" style=3D"background-color:rgb(255,255,255)">+-------------------------= ------+------------------------------------+</font></div></div></div></div>= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Minor (& subjective) comments:<br> - insertion: maybe injection might be a more appropriate term (e.g., Sectio= n 4. Threat Terminology)<br></blockquote><div>=C2=A0</div><div>I leave this= to the group to decide. I am happy with the current terminology but if oth= ers have very strong opinions we can change it.=C2=A0</div><div>=C2=A0</div= ><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border= -left:1px solid rgb(204,204,204);padding-left:1ex"> - resource exhaustion: maybe worth to add a special form of DoS, where a mo= dified path causes drop of time sensitive packets, as too late packets are = considered invalid (Section 5. Effect)<br> </blockquote><div>We currently have:</div><div><br></div><div>OLD:</div><di= v><span style=3D"color:rgb(0,0,0);font-family:arial,sans-serif"><br></span>= </div><div><span style=3D"color:rgb(0,0,0);font-family:arial,sans-serif">Re= source exhaustion: compromising the availability of the system can be achie= ved by sending SRv6-enabled packets to/through victim nodes in a way that r= esults in a negative performance impact of the victim systems (e.g.,=C2=A0[= </span><a href=3D"https://buraglio.github.io/draft-bdmgct-spring-srv6-secur= ity/draft-ietf-spring-srv6-security.html#RFC9098" class=3D"gmail-cite gmail= -xref" style=3D"font-family:arial,sans-serif;text-decoration-line:none">RFC= 9098</a><span style=3D"color:rgb(0,0,0);font-family:arial,sans-serif">]). F= or example, network programming can be used in some cases to manipulate seg= ment endpoints to perform unnecessary functions that consume processing res= ources. Resource exhaustion may in severe cases cause Denial of Service (Do= S).</span></div><div><br></div><div>NEW:=C2=A0</div><div><span style=3D"col= or:rgb(0,0,0);font-family:arial,sans-serif">Resource exhaustion: compromisi= ng the availability of the system can be achieved by sending SRv6-enabled p= ackets to/through victim nodes in a way that results in a negative performa= nce impact of the victim systems (e.g.,=C2=A0[</span><a href=3D"https://bur= aglio.github.io/draft-bdmgct-spring-srv6-security/draft-ietf-spring-srv6-se= curity.html#RFC9098" class=3D"gmail-cite gmail-xref" style=3D"font-family:a= rial,sans-serif;text-decoration-line:none">RFC9098</a><span style=3D"color:= rgb(0,0,0);font-family:arial,sans-serif">]). For example, network programmi= ng can be used in some cases to manipulate segment endpoints to perform unn= ecessary functions that consume processing resources,=C2=A0or cause drops o= f time sensitive=C2=A0packets which can cause too late packets which are co= nsidered invalid resulting in those packets being considered invalid. Resou= rce exhaustion may in severe cases cause Denial of Service (DoS).=C2=A0</sp= an></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">-= packet deletion: maybe packet drop would be a better term (e.g., Section 6= .1. Attack Abstractions)<br></blockquote><div><br></div><div>I leave this t= o the group to decide. I am happy with the current terminology but if other= s have very strong opinions we can change it.=C2=A0</div><br class=3D"gmail= -Apple-interchange-newline"><div>=C2=A0</div><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex"> <br> Thanks & Cheers<br> Bala'zs<br> <br> -----Original Message-----<br> From: Alvaro Retana via Datatracker <<a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a>><br> Sent: Monday, May 18, 2026 9:45 PM<br> To: <a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a>; <a href=3D"mailto:spri= [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><br> Cc: <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]<= /a>; <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><b= r> Subject: [spring] Second WG Last Call: draft-ietf-spring-srv6-security-14 (= Ends 2026-06-02)<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=A0SRv6 is a traffic engineering, encapsulation and steering mech= anism<br> =C2=A0 =C2=A0utilizing IPv6 addresses to identify segments in a pre-defined= <br> =C2=A0 =C2=A0policy.=C2=A0 This document discusses security considerations = in SRv6<br> =C2=A0 =C2=A0networks, including the potential threats and the possible mit= igation<br> =C2=A0 =C2=A0methods.=C2=A0 The document does not define any new security p= rotocols or<br> =C2=A0 =C2=A0extensions to existing protocols.<br> <br> File can be retrieved from:<br> <br> Please review and indicate your support or objection to proceed with the pu= blication of this document by replying to this email keeping <a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a> in copy. Objecti= ons should be explained and suggestions to resolve them are highly apprecia= ted.<br> <br> Authors, and WG participants in general, are reminded of the Intellectual P= roperty Rights (IPR) disclosure obligations described in BCP 79 [1].<br> Appropriate IPR disclosures required for full conformance with the provisio= ns 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 = found at [3].<br> <br> Thank you.<br> <br> [1] <a href=3D"https://datatracker.ietf.org/doc/bcp78/" rel=3D"noreferrer" = target=3D"_blank">https://datatracker.ietf.org/doc/bcp78/</a><br> [2] <a href=3D"https://datatracker.ietf.org/doc/bcp79/" rel=3D"noreferrer" = target=3D"_blank">https://datatracker.ietf.org/doc/bcp79/</a><br> [3] <a href=3D"https://datatracker.ietf.org/doc/rfc6701/" rel=3D"noreferrer= " 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= /" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/dr= aft-ietf-spring-srv6-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" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/archive/= id/draft-ietf-spring-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" rel=3D"noreferrer" target=3D"_blank">https://author-tools.i= etf.org/iddiff?url2=3Ddraft-ietf-spring-srv6-security-14</a><br> <br> _______________________________________________<br> spring mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank"= >[email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" ta= rget=3D"_blank">[email protected]</a><br> </blockquote></div></div> --000000000000cd9a590652fcca13-- --===============1427410124639119021== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK --===============1427410124639119021==--