Subject: [bess] Roman Danyliw's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 19 May 2021 13:02:50 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-10: 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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

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

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

RFC8402 tells us:

(a)“Segment Routing domain (SR domain): the set of nodes participating in the
source-based routing model …

(a.1) “These nodes may be connected to the same physical infrastructure (e.g.,
a Service Provider's network).”

(a.2) “They may as well be remotely connected to each other (e.g., an 
enterprise VPN or an overlay).”

(b) “By default, SR operates within a trusted domain.  Traffic MUST be filtered
at the domain boundaries.” My understanding of this document is that it is an
enabling capability to help establish SR domains of the like described in
(a.2).  What I see missing is text that provides the confidence suggested by
the language of “trusted domain” in (b).

-- Section 1 hints at various VPN technologies perhaps being used  “The various
ASes that provide connectivity between the Ingress and Egress   Domains could
each be constructed differently and use different technologies such as IP, MPLS
with global table routing native BGP to the edge, MPLS IP VPN, SR-MPLS IP VPN,
or SRv6 IP VPN.”  However, the security properties of all of those aren’t clear
to a degree that would seem consistent with being a “trusted domain”.  For
example, saying “IP” might suggest that naked IP packets with SR headers (with
no additional security primitives) could be dropped onto the open Internet, or
at least through networks not under the control the “data centers” use case
suggested by the name of the document.

-- The discussion at
https://mailarchive.ietf.org/arch/msg/bess/zY783PgnXSCp6GNSRF4kY0diLYs/ around
the forwarding plane trust model is also informative.   It is noted that that
the “transit nodes of the AS are not part of the domain.”  I could agree, but
only to the degree that the SR packets are tunneled in such as way that
suggested a trusted domain at least of equal security as (a.1).

I think language is needed to describe the normative security requirements of
the tunnels that will be created on top of the routes enables by this work to
substantiate the claim that at a “trusted domain” is being maintained.  This
has some overlap with John’s text about clarify the proposed trust model.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Daniel Migault for the SECDIR review.

I support John DISCUSS positions.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 May 2021 22:04:06 +0100

Hi Roman,

> DISCUSS:
> ------------------------------------------------------------------
>
> RFC8402 tells us:
>
> (a)“Segment Routing domain (SR domain): the set of nodes participating
> in the source-based routing model …
>
> (a.1) “These nodes may be connected to the same physical infrastructure
> (e.g., a Service Provider's network).”
>
> (b) “By default, SR operates within a trusted domain.  Traffic MUST be 
> filtered at the domain boundaries.”
>
> My understanding of this document is that it is an enabling capability
> to help establish SR domains of the like described in (a.2).  What I see
> missing is text that provides the confidence suggested by the language
> of “trusted domain” in (b).

So, recalibrating to the whole "we meant site when we said domain" thing in many of the conversations with other ADs...

You're right. This document provides a mechanism for connecting participating nodes that are remote.

I never understood, "By default, SR operates within a trusted domain." To me that reads like, "If you want to, you can configure your domain to be untrusted" as if that is something someone might choose to do when they have the option of a trusted domain. But I digress!

I am not sufficiently a security expert to know what language would provide confidence. And, actually, I'm not quite sure what the question is. Are you asking "What stops a rogue gateway advertising itself, effectively impersonating a site in the SR domain?"

To continue...

> suggested by the name of the document.

I would have thought the security properties of the routing protocol (in this case BGP) more important than the properties of the core network data plane protocols. 

I wonder whether there is a misconception of the applicability of SR in the wider Internet, and the definition of "SR domain" from 8402. For example, in SRv6, the SR nodes may form part of a trusted domain, but the packets are just IP packets that happen to carry an SRH, so the packets can be (and are!) forwarded through a native IP network. This is a form of tunnelling (because the SRH is not examined except at the addressed destination), but the packets are "out there".

But back to the VPN model. The VPN sites may run a proprietary protocol that could be considered dangerous if released to the Internet. The VPN sites form a trusted domain because they will not leak that protocol into the Internet. However, the VPN shares packets across the Internet by tunnelling them. The VPN can be supported by a whole host of tunnelling protocols (MPLS, IPsec, GRE, IP-in-IP, etc.). All of these tunnelling mechanisms rely on:
- the integrity of the tunnels 
- the security of the routing protocol used to determine the tunnel end points
- the security of the signaling protocols used to establish the tunnels
- the security of the routing protocols used to determine the site membership
But the core network does not form part of the trust domain.

Except! In a multi-AS case, the ASBRs are tunnel end points (or tunnel stitching points) and do participate in the trust model.

Now I have to ask: in what way is what we are suggesting different from the multi-AS VPN trust model?

> suggested a trusted domain at least of equal security as (a.1).

So, a tunnel is not as secure as a physical link. Indeed, a router is not as secure as a physical link. Yet we route traffic and use tunnels.

I am obviously not seeing the problem!

How do networks stop traffic from being injected into tunnels? Largely speaking, they do it by noting that traffic from outside the network is not allowed to enter the network using tunnel addresses (or encapsulations). Why is what we are describing any different from any type of tunnelling technology?

Or maybe "trusted domain" means an entirely different thing to you than it meant to the authors of 8402 in the SR context where, I believe, they meant "everyone in the domain is believed to be playing SR in the same way, and that SR traffic will not be injected into the SR domain from outside."

> has some overlap with John’s text about clarify the proposed trust model.

This brings me back to the idea that a packet might be injected into the SR domain from outside. To do this, a packet containing an SRH would have to be introduced into one of the tunnels. Obviously a rogue router can always introduce traffic, and this particular weakness is generally discarded because a rogue router can do far worse things, and because end-to-end protections are assumed to provide adequate protection. So we're left with packets being somehow forwarded into the network in a way that they will be introduced into the tunnel and appear to be genuine.

There are three cases:
1. The packet reaches a router in disguise, the outer encapsulation is stripped, and the packet is forwarded onto the tunnel. As far as I am aware all tunnelling technologies prohibit the concept of a "discovered interface." For example, if an IP destination (a router) discovers that the payload of an IP packet is an MPLS packet that it is not configured to expect, it will blow a whistle and stamp its foot.
2. The packet enters the network using the tunnelling encapsulation so that it is routed into the tunnel. I believe that networks generally filter at the edges for exactly this (just as the SR domain does).
3. The packet is a native IP packet carrying an SRH and is routed into the network to a destination that will process the SRH. But in this case, the packet has come from outside the SR domain, so the packet will be filtered.

I wish I could come up with a simple normative security requirement that would satisfy you, but I lack the skill.

Best,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 May 2021 22:25:19 +0100

Hi again Roman,

Just a couple of additional comments in line.

Hoping to find a way forward.

Thanks,
Adrian

> So, recalibrating to the whole "we meant site when we said domain"
> thing in many of the conversations with other ADs...

Note that -11 has moved over to the "site" terminology. I believe this substantially helps clarify the contrast between an 8402 "SR domain" (the collection of all participating SR nodes), and "site" (the end networks akin to VPN sites).

> I never understood, "By default, SR operates within a trusted domain." To me
> that reads like, "If you want to, you can configure your domain to be untrusted"
> as if that is something someone might choose to do when they have the option
> of a trusted domain. But I digress!
>
> I am not sufficiently a security expert to know what language would provide
> confidence. And, actually, I'm not quite sure what the question is. Are you
> asking "What stops a rogue gateway advertising itself, effectively impersonating
> a site in the SR domain?"

So, please look at the Security considerations section in -11. But also have a skim of the response to Ben just sent. I think this may also help with your Discuss because it adds some clarity on trusted domains. In particular, the domains (ASes) between GWs and ASBRs are tunnels, and encryption can be run over tunnels. Further, GW-to-GW encryption can be used. And, lastly, end-to-end encryption can be used.

> I would have thought the security properties of the routing protocol (in this case
> BGP) more important than the properties of the core network data plane protocols. 

As above: tunnels and encryption.
But...

> I wonder whether there is a misconception of the applicability of SR in the wider
> Internet, and the definition of "SR domain" from 8402. For example, in SRv6, the
> SR nodes may form part of a trusted domain, but the packets are just IP packets
> that happen to carry an SRH, so the packets can be (and are!) forwarded through
> a native IP network. This is a form of tunnelling (because the SRH is not examined
> except at the addressed destination), but the packets are "out there".
>
> But back to the VPN model. The VPN sites may run a proprietary protocol that
> could be considered dangerous if released to the Internet. The VPN sites form
> a trusted domain because they will not leak that protocol into the Internet.
> However, the VPN shares packets across the Internet by tunnelling them. The 
> VPN can be supported by a whole host of tunnelling protocols (MPLS, IPsec,
> GRE, IP-in-IP, etc.). All of these tunnelling mechanisms rely on:
> Except! In a multi-AS case, the ASBRs are tunnel end points (or tunnel stitching
> points) and do participate in the trust model.
>
> So, a tunnel is not as secure as a physical link. Indeed, a router is not as secure
> as a physical link. Yet we route traffic and use tunnels.
>
> How do networks stop traffic from being injected into tunnels? Largely speaking,
> they do it by noting that traffic from outside the network is not allowed to enter
> the network using tunnel addresses (or encapsulations). Why is what we are
> describing any different from any type of tunnelling technology?
>
> Or maybe "trusted domain" means an entirely different thing to you than it
> meant to the authors of 8402 in the SR context where, I believe, they meant
> "everyone in the domain is believed to be playing SR in the same way, and
> that SR traffic will not be injected into the SR domain from outside."
>
> This brings me back to the idea that a packet might be injected into the SR
> domain from outside. To do this, a packet containing an SRH would have to
> be introduced into one of the tunnels. Obviously a rogue router can always
> introduce traffic, and this particular weakness is generally discarded because
> a rogue router can do far worse things, and because end-to-end protections
> are assumed to provide adequate protection. So we're left with packets being
> somehow forwarded into the network in a way that they will be introduced
> into the tunnel and appear to be genuine.
>
> There are three cases:
> 1. The packet reaches a router in disguise, the outer encapsulation is stripped,
>     and the packet is forwarded onto the tunnel. As far as I am aware all
>     tunnelling technologies prohibit the concept of a "discovered interface." For
>     example, if an IP destination (a router) discovers that the payload of an IP
>     packet is an MPLS packet that it is not configured to expect, it will blow a
>     whistle and stamp its foot.
> 2. The packet enters the network using the tunnelling encapsulation so that it
>      is routed into the tunnel. I believe that networks generally filter at the edges
>     for exactly this (just as the SR domain does).
> 3. The packet is a native IP packet carrying an SRH and is routed into the
>     network to a destination that will process the SRH. But in this case, the
>     packet has come from outside the SR domain, so the packet will be filtered.
>