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

[Ketan Talaulikar <[e-mail]>]

Hi Tony,

Indeed, perhaps you might have lost the thread here ;-)

Things are pretty simple (unless one wants to over-complicate) and covered
in the base SRv6 standards-track RFC8754. Let me put it down here:

   1.  Any packet entering the SR domain and destined to a SID within
       the SR domain is dropped.  This may be realized with the
       following logic.  Other methods with equivalent outcome are
       considered compliant:

       *  Allocate all the SIDs from a block S/s

       *  Configure each external interface of each edge node of the
          domain with an inbound infrastructure access list (IACL) that
          drops any incoming packet with a destination address in S/s

       *  Failure to implement this method of ingress filtering exposes
          the SR domain to source-routing attacks, as described and
          referenced in [RFC5095
<https://datatracker.ietf.org/doc/html/rfc5095>]


I can understand the argument that someone that is doing this manually on
router CLIs today could miss this on some interface. But with the
templates, automation, and other tools available today, I find it hard to
agree when this filtering is called "complex", "not possible" and
"handwaving". Especially, when operators have already done this in their
deployments.

@Erik Kline <[e-mail]>
In any case, none of this is being newly introduced in the document under
discussion nor changed by it.

Thanks,
Ketan


On Thu, Feb 17, 2022 at 4:19 PM Tony Przygienda <[e-mail]> wrote:

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