Hi Robert, 5.3 Also opens the door to SAFI 1 – since you can v6 over v4 using AFI 1 / SAFI 1 using what is defined in RFC8950, in fact, it is explicit.
Section 5.3 is titled Global IPv4 over SRv6 core – this correlates with the example in section 6.1 of RFC8950 – which states: The extensions defined in this document may be used as discussed in [RFC5565<https://datatracker.ietf.org/doc/html/rfc5565>] for the interconnection of IPv4 islands over an IPv6 backbone. In this application, Address Family Border Routers (AFBRs; as defined in [RFC4925<https://datatracker.ietf.org/doc/html/rfc4925>]) advertise IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 next hop. The MP_REACH_NLRI is encoded with: * AFI = 1 * SAFI = 1 * Length of Next Hop Address field = 16 (or 32) * Next Hop Address = IPv6 address of the next hop * NLRI = IPv4 routes During BGP Capability Advertisement, the PE routers would include the following fields in the Capabilities Optional Parameter: * Capability Code set to "Extended Next Hop Encoding" * Capability Value containing <NLRI AFI=1, NLRI SAFI=1, Nexthop AFI=2> As I say, if you were to remove the references to global and 5.3/5.4 which explicitly reference it and bring SAFI 1 into play – there would be far less concern from my side, I can’t speak for anyone else, but that would be my feeling Thanks Andrew From: Robert Raszuk <rob...@raszuk.net> Sent: Saturday, February 12, 2022 9:37 PM To: Andrew - IETF <andrew-i...@liquid.tech> Cc: Warren Kumari <war...@kumari.net>; Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>; draft-ietf-bess-srv6-servi...@ietf.org; bess-cha...@ietf.org; The IESG <i...@ietf.org>; BESS <bess@ietf.org> Subject: Re: Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT) 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 <andrew-i...@liquid.tech<mailto:andrew-i...@liquid.tech>> 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 <iesg-boun...@ietf.org<mailto:iesg-boun...@ietf.org>> On Behalf Of Robert Raszuk Sent: Saturday, February 12, 2022 8:26 PM To: Warren Kumari <war...@kumari.net<mailto:war...@kumari.net>> Cc: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>; draft-ietf-bess-srv6-servi...@ietf.org<mailto:draft-ietf-bess-srv6-servi...@ietf.org>; bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; The IESG <i...@ietf.org<mailto:i...@ietf.org>>; BESS <bess@ietf.org<mailto:bess@ietf.org>> 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 <nore...@ietf.org<mailto:nore...@ietf.org>> 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/<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/<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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
