Hi Ketan, > On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar <ketant.i...@gmail.com> wrote: > >> 3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent >> discussion turned quickly to the assertion that no, they don’t, in VPN >> address >> families. Let’s accept that claim for the sake of conversation. It’s still >> the >> case that sometimes (often?) routes are distributed from VPN address families >> into the Global Internet table. When this is done, by default, all the path >> attributes come along for the ride. Anyone who thinks this is just a >> hypothetical case might want to look back to (for example) significant >> network >> outages that were caused around a decade ago by leakage of BGP Attribute 128 >> (ATTR_SET, RFC 6368) into the global Internet. >> >> The SIDs contained in these if-they-were-to-leak routes potentially give an >> attacker a means of directing packets into a VPN customer’s internal network. >> > KT> I believe we are getting now into implementation aspects when you bring > up handling of attributes during redistribution from VPN tables into the > default table.
I don’t think we can sweep this easily under the “it’s an implementation detail” rug — the fact is, AFAIK this *is* what implementations do (redistribute optional transitive attributes from VPN to default tables). This “implementation detail” is not, itself, an issue for draft-ietf-bess-srv6-services. What it is, is a perspective on "Precaution should be taken to ensure that the BGP service information (including associated SRv6 SID) advertised via BGP sessions are limited to peers within this trusted SR domain.” The argument was previously advanced that this is trivially achieved for VPN address families, I’m saying that’s not so, for the reasons given, and therefore the ramifications of leaks of the information you identify as sensitive, need to be considered (at minimum). > We can add some text in the security considerations to discuss this. Looking forward to seeing it, thank you. —John _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
