< as a co-author of RFC9252 > Hi Sasha,
Please look at https://www.rfc-editor.org/rfc/rfc9252.html#section-9 (if you haven't done so already) and see if there are any further gaps to be considered that are SRv6-specific. Documenting security aspects for services in general for MPLS and other IP-based overlays (e.g., IP-in-IP, VXLAN, GENEVE, etc.) may be an entirely different topic. I hope this helps. Thanks, Ketan On Fri, Sep 4, 2026 at 7:57 PM James Guichard <james.n.guichard= [email protected]> wrote: > Hi Sasha, > > It is difficult to cover all possibilities in a single document; I agree > that perhaps a separate document focused solely on overlay security is a > good idea if someone wants to tackle it. > > Jim > > *From: *Alexander Vainshtein <[email protected]> > *Date: *Friday, September 4, 2026 at 10:01 AM > *To: *Alvaro Retana <[email protected]>; > [email protected] < > [email protected]> > *Cc: *[email protected] <[email protected]>; [email protected] <[email protected]>; > James Guichard <[email protected]> > *Subject: *Re: [EXTERNAL] Re: [bess] Security aspects of SRv6-based > overlay services > > Alvaro, > Lots of thanks for your email. > > I agree that the draft cannot- and should not - mention all specific > attacks. > > But I find it strange that the draft is focused on underlay aspects of > SRv6 and seems to ignore attacks on overlay services - be it data plane, > control plane, or management plane. > > One possible aspect is impact on services that use MPLS underlay in hybrid > deployment scenarios. My guess (FWIW) that attacks on SRv6 underlay would > not affect MPLS underlay and vice versa. But attacks on SRv6overlay (as in > my example) could affect services that use MPLS overlay (and vice versa). > > One possibility to resolve this could be to say that the draft is focused > on SRv6 underlay security while overlay security would be considered in a > separate document. > > My 2c, > Sasha > > > > > Get Outlook for Android <https://aka.ms/AAb9ysg> > > ------------------------------ > *From:* Alvaro Retana <[email protected]> > *Sent:* Friday, September 4, 2026 4:34:49 PM > *To:* [email protected] < > [email protected]>; Alexander Vainshtein < > [email protected]> > *Cc:* [email protected] <[email protected]>; [email protected] <[email protected]>; > James Guichard <[email protected]> > *Subject:* [EXTERNAL] Re: [bess] Security aspects of SRv6-based overlay > services > > [+ Jim: the draft is in IETF LC.] > > Sasha: > > Yes, the risk you describe is a BGP attack that could affect SRv6 services. > > §6.3 covers this topic (deletion/modification), but doesn’t mention your > specific example — it can’t list them all! I’ll leave it to the authors. > > Thanks! > > Alvaro. > > On September 4, 2026 at 3:14:01 AM, Alexander Vainshtein ( > [email protected]) wrote: > > Hi all, > I have briefly looked up the current version of the draft. > > I am not a security expert, but it seems that the draft deals with > security aspects of SRv6 *underlay. * > I wonder if SRv6 "service SIDs" and the way they are advertised in BGP do > not introduce any special vulnerabilities. > > E.g., a compromised Route Reflector could modify (or simply discard) the > BGP Prefix SID Attribute in routes of such families as VPN-IP or EVPN - > with a devastating effect on the services., while such an attack would not > have any impact on IP-VPN and EVPN services over MPLS underlay. > > What, if anything, do I miss? > > Regards, > Sasha > > > Get Outlook for Android <https://aka.ms/AAb9ysg> > > > *Disclaimer* > > This e-mail together with any attachments may contain information of > Ribbon Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all copies, > including any attachments. > _______________________________________________ > BESS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
