Hi Andrew Responses in-line
On Sat, Feb 12, 2022 at 2:42 PM Andrew - IETF <[email protected]> wrote: > Gyan, > > > > However what you say then raises additional concerns. > > > > RFC8402 Section 8.2 explicitly prohibits sending SRv6 traffic beyond the > borders of a domain and over the general internet. Making use of traffic > destined for an address within the SRGB of another network isn’t permitted > as per: > > Gyan> The purpose of the domain boundary filters is to protect the SRv6 > nodes within the “underlay” by filtering external traffic at the boundary > edges any traffic destined to any IPv6 destination address within the SRGB > or SRLB which would be underlay node connected interfaces IGP routable not > in BGP. This is done for any internet or intranet MPLS domain today to > secure the domain trust boundary. > > SR domain boundary routers MUST filter any external traffic destined > > to an address within the SRGB of the trusted domain or the SRLB of > > the specific boundary router. External traffic is any traffic > > received from an interface connected to a node outside the domain of > > trust. > > > > As regards the BGP – it goes further still: > > Gyan> This is not a BGP related just IGP underlay related. BGP prefix > sid attribute is used to encode SRv6 L3 service TLVs within the SR domain > basically mapping the VPN and GRT BGP AFI/SAFI into the Function field of > SRv6 SID equivalent to MPLS VPN service label bottom of stack. However > this is only within the SRv6 domain and once the packet leaves the SRv6 > domain it’s native BGP AFI/SAFI encoding and not in SRv6 SID. So even > though SRv6 SID contains the BGP service label encoding it is not BGP > overlay encoding that needs to be secured providing transitivity. > > From a network-protection standpoint, there is an assumed trust model > > such that any node adding an SRH to the packet is assumed to be > > allowed to do so. Therefore, by default, the explicit routing > > information MUST NOT be leaked through the boundaries of the > > administered domain. > > Gyan> SR provides a means of stateless traffic steering in the underlay > framework using IGP extension to provide the SID distribution for both > SR-MPLS and SRv6. The SID distribution is done via the IGP extensions as > part of the underlay. The underlay is not routable reachable from outside > the domain and even in MPLS TTL propagation is disabled to hide the > visibility. One big difference between MPLS and SRv6 is that the SR source > node encapsulates the PE-CE AC payload in IPv6 outer header for both VPN > overlay and GRT traffic so they are both treated the same where MPLS with > GRT the customer traffic is natively routed and no overlay encapsulation. > However in both cases of course we have a BGP overlay RIB which carry the > internet or intranet table and that is transitory traffic and is not > filtered at the trust boundary. > So the trust boundary filtering is primary goal is to protect the underlay > nodes and not interfere with the transitory BGP routing reachability. > > Now, I may be misunderstanding here – but – if at any point the > announcements lead to traffic flowing towards a SID from outside the > administered domain – that violates 8402. If the SID’s are in BGP prefix’s > that are transitive and find their way onto the general internet – that > also violates 8402. > > Gyan> As long as the infrastructure filters are applied at the trust > boundary protection of the underlay SRv6 nodes there is no issue and that > verbiage just needs to be clear in this draft following *RFC 8402.* > > Now, this could be a misunderstanding on my part – so I’d welcome > clarification if I am incorrect in what I am seeing here – which may also > lead to text which is clearer (as a note, I ran this past several operators > who had very similar readings to what I had – so – if it’s a matter of > misunderstanding, we really do need to find a way to clarify it, if its not > a misunderstanding, then we need to find a way to rectify it for security > purposes and to bring it in-line with RFC8402. > > Gyan> Understood. We can update the verbiage to make it crystal clear. > > Thanks > > > > Andrew > > > > > > *From:* Gyan Mishra <[email protected]> > *Sent:* Saturday, February 12, 2022 10:18 PM > *To:* Robert Raszuk <[email protected]> > *Cc:* Andrew - IETF <[email protected]>; BESS <[email protected]>; > Bocci, Matthew (Nokia - GB) <[email protected]>; The IESG < > [email protected]>; Warren Kumari <[email protected]>; [email protected]; > [email protected] > *Subject:* Re: [bess] Warren Kumari's Discuss on > draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT) > > > > > > Hi Robert / All > > > > For service providers and enterprises using GRT or VRF to carry the > internet or intra internet routing table using MPLS today or SR-MPLS that > would like to use SRv6 to provide the same service. > > > > Section. 5.1 and 5.2 cover the VPN case in which the customer traffic is > in VRF overlay and the SRv6 transport layer is a closed domain. > > > > Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop > encoding. In this case using GRT transport underlay layer now carry’s the > customer routes and that is what Warren and Andrew concern is as far as BGP > leaks. > > > > So when GRT is used the same edge filtering protection mechanisms used > today for MPLS and SR-MPLS would apply to SRv6 for GRT use case. > > > > I don’t think we are saying 5.3 or 5.4 should not be allowed but just to > tighten up verbiage as far securing the domain. > > > > As far as the SRv6 domain is concerned even with GRT the domain is still > closed at the PE ingress and egress points which is where the concern is > for BGP leaks. The BGP Prefix SID encoding the SRv6 L3 service TLVs would, > the encoding would only be present in the SRv6 SID Function field within > the closed domain, and once you exit the SRv6 domain at the ingress or > egress endpoints the SRv6 L3 service TLVs would now be carried natively in > BGP and not in the SRv6 BGP prefix SID encoding. > > > > When an egress PE is enabled for BGP Services over SRv6 data-plane, > > it signals one or more SRv6 Service SIDs enclosed in SRv6 Service > > TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs > > defined in [RFC4760 <https://datatracker.ietf.org/doc/html/rfc4760>] > [RFC4659 <https://datatracker.ietf.org/doc/html/rfc4659>] [RFC8950 > <https://datatracker.ietf.org/doc/html/rfc8950>] [RFC7432 > <https://datatracker.ietf.org/doc/html/rfc7432>] [RFC4364 > <https://datatracker.ietf.org/doc/html/rfc4364>] > > [RFC9136 <https://datatracker.ietf.org/doc/html/rfc9136>] where applicable > as described in Section 5 > <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services#section-5> > and Section 6 > <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services#section-6>. > > > > So as far as SRv6 SID leaking there would not be any leaking outside the > SRv6 domain. > > > > However as the GRT carry internet or intranet BGP RIB the SP AS is of > course transitive so entire table is propagated. That’s not a leak. > > > > I think we just need to maybe tighten up the verbiage on securing the PE > edges of the SRv6 domain. > > > > Kind Regards > > > > Gyan > > > > > > On Sat, Feb 12, 2022 at 1:37 PM Robert Raszuk <[email protected]> wrote: > > Hi Andrew, > > > > When I read Warren's note Iooked at this text from section 2 which says: > > > > - - - > > > > The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix- > SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2 > services. > > o SRv6 L3 Service TLV: This TLV encodes Service SID information for > SRv6 based L3 services. It corresponds to the equivalent > functionality provided by an MPLS Label when received with a Layer > 3 service route as defined in [RFC4364] [RFC4659] [RFC8950] > [RFC9136]. Some SRv6 Endpoint behaviors which MAY be encoded, but > not limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc. > > o SRv6 L2 Service TLV: This TLV encodes Service SID information for > SRv6 based L2 services. It corresponds to the equivalent > functionality provided by an MPLS Label1 for Ethernet VPN (EVPN) > Route-Types as defined in [RFC7432]. Some SRv6 Endpoint behaviors > which MAY be encoded, but not limited to, are End.DX2, End.DX2V, > End.DT2U, End.DT2M etc. > > When an egress PE is enabled for BGP Services over SRv6 data-plane, > it signals one or more SRv6 Service SIDs enclosed in SRv6 Service > TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs > defined in [RFC4760] [RFC4659] [RFC8950] [RFC7432] [RFC4364] > [RFC9136] where applicable as described in Section 5 and Section 6. > > The support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6 > is outside the scope of this document. > > > > - - - > > > > This limits the overlay signalling to non global SAFIs mainly SAFI 128 and > SAFI 70. > > > > To your note SAFI 4 is private and never exchanged in the wild. Also SAFI > 2 is multicast which is out of scope of this draft. > > > > The only thing which we need to sync on is indeed section 5.4 and use of > global IPv6 AFI 2 & SAFI 1 > > > > Many thx, > > R. > > > > > > > > > > On Sat, Feb 12, 2022 at 7:11 PM Andrew - IETF <[email protected]> > wrote: > > Robert, > > > > I have to say that I have very similar readings on parts of the draft. > > > > Let’s look at it – > > > > 5.1 uses the IPv4-VPN NLRI – That would seem to indicate AFI 1 / SAFI 4 > > 5.2 – Uses AFI 2 / SAFI 4 from my reading > > 5.3 – According to RFC8950 – allows advertisement over SAFI 1, 2 or 4 > > 5.4 – To my reading – very much refers to AFI 2 / SAFI 1. > > > > I would agree if this document limited itself to 5.1 and 5.2 – it doesn’t > – and therefore I have to agree with the thoughts expressed in Warrens > Discuss. If I am wrong about 5.3 and 5.4, let’s chat and help me > understand this better, and then lets potentially see if we can work up > some wording that would clarify this if that is what is required. > > > > Thanks > > > > Andrew > > > > > > *From:* iesg <[email protected]> *On Behalf Of *Robert Raszuk > *Sent:* Saturday, February 12, 2022 8:26 PM > *To:* Warren Kumari <[email protected]> > *Cc:* Bocci, Matthew (Nokia - GB) <[email protected]>; > [email protected]; [email protected]; The IESG < > [email protected]>; BESS <[email protected]> > *Subject:* Re: Warren Kumari's Discuss on > draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT) > > > > Hi Warren, > > > > Thank you for your Discuss. But before we start discussing it perhaps it > would be good to align on what this document really defines as I am sensing > from your description there can be some disconnect (modulo some text may be > indeed misleading in the draft). > > > > You said: > > > > > However, we all know that BGP leaks happen -- and when they do, the SID’s > > contained in the leak will be logged by various systems and hence > available to > > the public into perpetuity. > > > > I think the term BGP is used here a bit too broadly. > > > > Leaks do happen but only within global AFI/SAFIs. This draft defines > extensions for L3VPN and L2VPNs SAFIs which are not used to peer outside of > a domain, collection of domains under same administration + > of course inter-as also could happen. > > > > With that being said I do not see risk that due to leaking there could be > a situation where customer networks are exposed in any way externally - > leaving alone that to even get at the transport level to the customer > facing PE is also filtered and never allowed from outside. But this is out > of scope of this document as here the focus is not on underlay but overlay. > > > > Now when I re-read this I see why there is a little piece perhaps > misleading. The draft makes a claim that it is applicable to RFC8950 which > defines use of NHv6 with both unicast and VPN AFs. That needs to be made > clear that it is applicable to the latter only. If other co-authors believe > this is applicable to the former your DISCUSS section would indeed be > valid. > > > > Many thx, > > R. > > > > > > > > > > On Sat, Feb 12, 2022 at 12:05 AM Warren Kumari via Datatracker < > [email protected]> wrote: > > Warren Kumari has entered the following ballot position for > draft-ietf-bess-srv6-services-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/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: > ---------------------------------------------------------------------- > > The Security Considerations section says: "The service flows between PE > routers > using SRv6 SIDs advertised via BGP are expected to be limited within the > trusted SR domain (e.g., within a single AS or between multiple ASes > within a > single provider network). Precaution should be taken to ensure that the > BGP > service information (including associated SRv6 SID) advertised via BGP > sessions > are limited to peers within this trusted SR domain." This is related to > (from > RFC8402): "Therefore, by default, the explicit routing information MUST > NOT be > leaked through the boundaries of the administered domain." > > However, we all know that BGP leaks happen -- and when they do, the SID’s > contained in the leak will be logged by various systems and hence > available to > the public into perpetuity. > > While the document states that border filtering should protect against > traffic > injection, this does not cover the case of internal compromise. Sure, > there is > the argument that once there is an internally compromised system, all bets > are > off -- but with this, an attacker that knows the SIDs in e.g inject traffic > into a VPN. This seems to me to significantly expand the attack surface to > include the customer's networks too. > > Not only does an operator have to ensure that BGP leaks never occur, they > have > to then ensure that at no point can there be any filter lapses at any > border > node, and be able to guarantee the security of every device, server and > machine > within the domain in order for a secure posture to be maintained. Simply > saying > that precautions should be taken to make sure that route leak don't occur, > when > the consequences of doing so are a: severe and b: hard to recover from > seems to > not really cover it. In addition, it seems that the blast radius from a > missing > ACL seems much larger if it allows injections. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm still reviewing the document, but wanted to get an initial ballot in, > so > that we could start discussing it. Hopefully someone can help my > understand how > this doesn't expand the consequences of a BGP leak. > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > -- > > [image: Image removed by sender.] <http://www.verizon.com> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
