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

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 16 Feb 2022 22:03:14 -0800

Erik Kline has entered the following ballot position for
draft-ietf-bess-srv6-services-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have little to add to the DISCUSSes held by others beyond my support.

However, I would like to discuss having SRv6 control plane information, i.e.
SIDs and their behaviours etc., being isolated by associating it with
a separate SAFI.  Any other protocol element that needs to refer to such
information can make reference to it through context-appropriate extensions.

{AFI=IPv6, SAFI=unicast} is a valid way to advertise an SRv6 locator prefix,
for example, as that's just IPv6 forwarding information.  If SRv6-specific
information where separately advertised as {AFI=IPv6, SAFI=SRv6} then I
suspect it would be simpler to filter out that information, detect leaks,
and generally help the SRv6 domain fail closed more easily.

But I'm prepared to learn why this wouldn't work or would be somehow worse.

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 13:49:03 +0530

Hi Erik,

Thanks for your review and please check inline below for responses.

> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/

KT> This is what the draft proposes. We have existing BGP services (e.g.
L3VPN & EVPN) and we are introducing extensions for signaling of SRv6
specific context for them.

> and generally help the SRv6 domain fail closed more easily.

KT> This document does not cover nor discuss signaling of SRv6 locator
prefixes. That is already done today by IGPs with or without summarization
(or where necessary in multi-AS networks by BGP for IPv6 RFC 2545) and this
is all within a provider network. Nothing new is required for that.

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

Thanks,
Ketan

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 17 Feb 2022 11:09:55 +0100

> 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

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 16:07:22 +0530

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

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 17 Feb 2022 11:48:23 +0100

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

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 22:17:27 +0530

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 <[email-masked]>
In any case, none of this is being newly introduced in the document under
discussion nor changed by it.

Thanks,
Ketan