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).” > > (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... 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... > -- 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. 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. Best, Adrian _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
