Re: [bess] Erik Kline's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS)

[Tony Przygienda <[e-mail]>]

>
>> 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