Hi Tony, My apologies, but I am not able to understand your emails entirely. I wonder if this text below helps explain: https://datatracker.ietf.org/doc/html/rfc8754#section-5.1
Thanks, Ketan On Thu, Feb 17, 2022 at 3:40 PM Tony Przygienda <[email protected]> wrote: > > > >> >>> But I'm prepared to learn why this wouldn't work or would be somehow >>> worse. >>> >> >> KT> It isn't necessary nor required because SRv6 locators are just IPv6 >> prefixes that are already covered by IGP/BGP extensions for IPv6 routing. A >> provider that uses global IPv6 addresses in their infrastructure (e.g. for >> their BGP and other routing sessions, on their router links and loopback, >> for DHCP, AAA, etc.) already do routing for those prefixes via IGP/BGP. >> These are not advertised (nor leaked) out into the Internet since doing so >> can result in attacks on their internal network and infrastructure. They >> are protected via BGP configuration to stop leaks and then again by ACLs at >> Internet Border Routers to prevent attacks via the data path. This still >> remains the case to be done for SRv6 locators - they are similarly the >> service provider's "internal" infrastructure. >> >> > I'm confounded by the recent line of reasoning of SRv6 proponents. An > IPv6 address is NOT a service access point, it's a routable address, > history shows us that we can protect against services on the device being > attacked through that (though it took some work like proper ICMP handling). > SRv6 endpoints here are really service endpoints, unless we have a CUG > security architecture in place, how do we protect services here without > having CUG style filters on the whole edge? with SRv6 services giving > people a service access point and a tunneling technology where someone via > v6 routing can built a tunnel to hit the service is a different beast > altogether than protecting reachability (routable addresses) and I fear > pretty soon we're looking @ routers going very, very deep into the "IPv6" > packet to make sure there aren't some magic options on the packet > source-routing it in funky ways towards service endpoints that will accept > the packet. > > --- tony >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
