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

[Adrian Farrel <[e-mail]>]

Hi again Roman,

Just a couple of additional comments in line.

Hoping to find a way forward.

Thanks,
Adrian

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

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

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.

> To continue...
>
>> -- 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.
>
> 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:
> - 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?
>
>> -- 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).
>
> 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."
>
>> 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.
>
> 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.