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

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]> 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
>