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

[Tony Przygienda <[e-mail]>]

Ketan, yepp, 5.1.2 is roughly the CUG via ACL, add to it per service
protection (as in some external A can talk to service X but external B
cannot which now starts to push you into fragment the SRv6 "prefix" into
"per service space" if you want to aggregate), multiply that by the
downstream-upstream if you want to cross providers AFAIS (as in BGP
flowspec up/down shorewalling) and you have a pretty nice combinatorial
space. And BTW, source address is easily spoofed given the lack of BCP
implementations in the real world and with source routing technology one
can land those packets in unexpected places via unexpected routes. All that
looks to me like nothing comparable to a leaked internal loopback today
which was my whole point as in fallacy by  faulty analogy.

Unless I lost the thread completely which, given the amount of machinery
fielded by now ;-) could be excusable ...

-- tony


On Thu, Feb 17, 2022 at 11:37 AM Ketan Talaulikar <[e-mail]>
wrote:

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