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

[Roman Danyliw <[e-mail]>]

Hi Adrian!

> -----Original Message-----
> From: Adrian Farrel <[e-mail]>
> Sent: Friday, May 28, 2021 5:25 PM
> To: [e-mail]; Roman Danyliw <[e-mail]>; 'The IESG'
> <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; 'Matthew Bocci' <[e-mail]>
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-bess-datacenter-gateway-
> 10: (with DISCUSS and COMMENT)
> 
> 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.

All the details below are helpful, but I'm responding in this part of the threat since it calls out the relevant text.  Thanks for adding the new language in -11.  I think it strikes the right balance about being vague to enable flexibility but clearly states the guiding principle of the need to secure the tunnels moving the traffic when run over untrusted networks.  I've cleared my ballot.

Regards,
Roman


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