Hi Ketan Responses in-line
On Thu, Mar 17, 2022 at 1:15 PM Ketan Talaulikar <[email protected]> wrote: > Hi Gyan, > > Please check inline below for responses. > > > On Wed, Mar 16, 2022 at 8:08 PM Gyan Mishra <[email protected]> wrote: > >> >> Hi Ketan >> >> I reviewed the updated security considerations section and the update >> looks good. As well section 10.3 Data plane considerations and read again >> the referenced documents security considerations section of RFC 8402, RFC >> 8986, RFC 8754 and RFC 8996. All looks very good. >> >> One question I had was that if operators only advertises the SRv6 summary >> block B:N::/48 to the internet, the summarization route would not contain >> the embedded BGP Prefix SID attribute encoding of L2 and L3 Service SID in >> the FUNCT field of the SRv6 SID. >> >> If you agree with what I have stated , then that would limit the exposure >> drastically related to service SID leakage to the internet. >> > > KT> I agree. However, an even better approach is simply not even > advertising the reachability for the SRv6 summary block on the Internet. > This way, it becomes challenging for someone on the Internet to send > packets to any SRv6 Locators/SIDs belonging to the provider. Also, as > discussed in RFC8986, the allocation of SRv6 Block from the ULA space is > another technique to mitigate this. > > Gyan> Can we add that in the considerations section as I think that will help with John and Warrens security concerns with sid leakage. > >> The security exposure is related to only the inter-as peering lateral, >> provider or RS peering and not customer peering as the SRv6 source node >> encapsulates customer traffic into payload of outer IPv6 header. So I >> think customer PE-CE edge peering would not be a security issue. >> >> Also another thought is that within an SRv6 domain as next hop self is >> used internally on any inter-as lateral, provider or RS ties which is done >> on both ends of the peering between operators, does the SRv6 B:N::/48 >> underlay block even need to be advertised externally. >> > > KT> It doesn't and should not be advertised externally. > Gyan> Excellent. I think explicit verbiage to block externally would be good. > > >> As the BGP overlay is what holds the internet table and that is all that >> needs transitivity for internet route reachability. That would further >> reduce the exposure of data plane service sid encoding in SRv6 SID leaking >> to the internet. >> > > KT> Correct. > > >> >> As far as SRv6 service capabilities draft below, my thoughts are as any >> parallel multi transport that exists would only be done within the confines >> of a domain within the same operators Administrative domain and not between >> providers which would also be limited during a transition from brown field >> MPLS or SR-MPLS to a parallel Green field SRv6 transport. As this use case >> is all within the same domain, careful design is on the onus of the >> operator as relates to SRv6 to MPLS BGP overlay interoperability for SAFI >> 128. So I don’t see this as a major issue for operators as all the careful >> considerations will be taken for that interoperability as well as there are >> many underlying solutions for SRv6 to MPLS or SR-MPLS interoperability. >> >> This is more of an interoperability issue use case that could be >> considered orthogonal to this draft that only exists within an operators >> network during migration. >> >> >> https://datatracker.ietf.org/doc/html/draft-lz-bess-srv6-service-capability-02 >> > > KT> Agree that this topic is orthogonal but is also somewhat complex and > we (WG) need to continue work on this separate from this base document. > Gyan> Understood. Thanks > > Thanks, > Ketan > > >> >> >> Kind Regards >> >> Gyan >> >> On Sat, Mar 5, 2022 at 4:40 AM Ketan Talaulikar <[email protected]> >> wrote: >> >>> Hi John, >>> >>> We've just posted an update to the draft to address the comments raised >>> and to clarify the security considerations. >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-12 >>> >>> Thanks, >>> Ketan >>> >>> >>> On Thu, Feb 24, 2022 at 3:42 PM Robert Raszuk <[email protected]> wrote: >>> >>>> Hi John, >>>> >>>> You have highlighted below a very important point. It was discussed >>>> among co-authors, but perhaps not sufficiently during the BESS process as >>>> the issue is really not a BESS WG problem. >>>> >>>> In BGP protocol any new service deployment using existing AFI/SAFI is >>>> not easy. Especially when you are modifying content of MP_REACH or >>>> MP_UNREACH NLRI attributes. Main reason being is that using capabilities >>>> only goes one hop. In full mesh it all works perfect, but the moment you >>>> put RR in between BGP speakers things are getting ugly as capabilities are >>>> not traversing BGP nodes. /* Even in full mesh mixing transports for the >>>> same service is a serious challenge for routers when say multihomes sites >>>> are advertised from different PEs with different transport options */. >>>> >>>> Imagine RR signals SRv6 Service Capability to the PE. Then this PE >>>> happily sends a new format of the UPDATE messages. Well as today we also do >>>> not have a notion of conditional capabilities (only send when received from >>>> all) so if some of the RR peers do not support it you end up in partial >>>> service. One can argue that in this case the only deterministic model is to >>>> push the configuration from the management station and control partial >>>> deployment of the new service from mgmt layer. >>>> >>>> The natural alternative would be to never modify NLRI format once >>>> shipped by RFC. When needed issue a new SAFI. Yes that is an option (and >>>> has always been) but it also comes with its own set of issues. New SAFI is >>>> really great to define for new service/feature etc ... Here however in the >>>> context of this discussion we are changing transport for existing service. >>>> And just like it was the case with MPLS over UDP or tunnel attribute etc >>>> ... using a new SAFI would be very hard to deploy as there would need to be >>>> well defined behaviour of BGP speakers receiving duplicate information for >>>> the same VPN prefixes or receiving at one time only from single SAFI then a >>>> bit later from the other one .. Of course one solution is to permit only >>>> one SAFI for a given service at any given time, but that seems way too >>>> restrictive too. >>>> >>>> So to summarize while I am personally a huge proponent of new SAFI and >>>> new capabilities to be defines for new service here I do have some >>>> reservations. It seems to me that deployment of new transport for VPN >>>> service should be either network management driven or enabled when all >>>> participating PEs support it. Enabling it automagically with one hop >>>> capabilities seems to me like not a good thing as the data being sent in >>>> the UPDATES is not optional and dropping it means dropping actual routes. >>>> >>>> So at the current time the subject draft took a management approach. >>>> >>>> Many thx, >>>> Robert. >>>> >>>> On Thu, Feb 24, 2022 at 2:04 AM John Scudder <[email protected]> wrote: >>>> >>>>> Further to this point: >>>>> >>>>> > On Feb 18, 2022, at 3:32 PM, John Scudder <[email protected]> wrote: >>>>> > >>>>> >> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar < >>>>> [email protected]> wrote: >>>>> >> >>>>> >>> 2. One area of concern I would have hoped IDR might have looked >>>>> into is, the >>>>> >>> document makes a creative use of the MPLS Label field of the NLRI >>>>> to carry the >>>>> >>> Function part of the SID. This means the SID is effectively split >>>>> across the >>>>> >>> NLRI and the Prefix-SID attribute. What are the potential error >>>>> modes if the >>>>> >>> Prefix-SID attribute should be lost from the route, while the NLRI >>>>> is retained? >>>>> >>> >>>>> >>> (An obvious way of addressing this particular concern would be to >>>>> define a new >>>>> >>> NLRI type with the desired semantics, instead of creatively >>>>> repurposing fields >>>>> >>> within an existing NLRI type contrary to their definitions. Such >>>>> an NLRI type >>>>> >>> would, for example, presumably state in its specification that if >>>>> it was >>>>> >>> received without an accompanying Prefix-SID attribute, that would >>>>> constitute an >>>>> >>> error.) >>>>> >>> >>>>> >> KT> This document follows the approach similar as taken for >>>>> extending MPLS EVPN RFC7432 by RFC8365. >>>>> > >>>>> > I take it you’re referring to RFC 8365 §5.1.3 which talks about >>>>> using the MPLS Label field (or MPLS1 Label field) to carry the VNI in the >>>>> presence of a BGP Encapsulation Extended Community? Yes, that seems like a >>>>> pretty close analogue. And given this particular trick is only with >>>>> VPN-type address families one can also argue that there’s not a risk of >>>>> affected routes leaking into the big-I Internet, which is the typical >>>>> associated concern. >>>>> >>>>> In a separate reply, the authors of >>>>> draft-lz-bess-srv6-service-capability-02 pointed out that it provides a >>>>> critique of bess-srv6-services which is similar to this discuss point. >>>>> (The >>>>> authors dropped the IESG from the cc, so I’m following up here instead of >>>>> to their original note.) >>>>> >>>>> On first reading, the critique in >>>>> draft-lz-bess-srv6-service-capability-02 seems well argued and responsive >>>>> to my question above about potential error modes. In section 3 of their >>>>> draft, the authors provide a worked scenario where a VPN route carrying a >>>>> SRv6 service SID using the Transposition scheme, if received by an >>>>> MPLS-only PE, could result in misdelivered traffic. At minimum, that seems >>>>> worth surfacing in the Security Considerations section, since historically >>>>> we’ve considered misdelivered VPN traffic to be a Bad Thing that could >>>>> expose confidential information. >>>>> >>>>> The authors do acknowledge that bess-srv6-services proposes a >>>>> mitigation: >>>>> >>>>> To avoid these problems, [I-D.ietf-bess-srv6-services] specifies >>>>> that >>>>> implementations SHOULD provide a mechanism to control advertisement >>>>> of SRv6-based BGP service routes on a per neighbor and per service >>>>> basis. >>>>> >>>>> but they go on to argue that this mitigation isn’t fit for purpose: >>>>> >>>>> The above method may be feasible in small-scale networks, but are >>>>> not >>>>> applicable to large-scale networks. >>>>> >>>>> [etc] >>>>> >>>>> It’s not my preference to get into the minutiae of this argument as >>>>> part of this discuss. However, I’d like to ask: was this consideration >>>>> something the WG discussed? I looked for discussion of >>>>> draft-lz-bess-srv6-service-capability in the archives and didn’t find >>>>> much — >>>>> >>>>> - When an earlier version was posted to the list it resulted only in >>>>> discussion between the original author, Liu Yao, and Eduard Metz, who >>>>> became co-author, but there wasn’t any discussion I saw of the actual >>>>> issue >>>>> that the draft identified, but rather refinement of the mitigation it >>>>> proposes (which I don’t want to discuss in this note). >>>>> - There was an agenda slot request for the draft at IETF-111. It was >>>>> on the agenda in the “if time allows” section. I assume time did NOT allow >>>>> because I don’t see mention of it in the minutes. (I did find the slides, >>>>> slides 3 and 4 summarize the critique, >>>>> https://datatracker.ietf.org/meeting/111/materials/slides-111-bess-sessa-srv6-service-capability-00 >>>>> ). >>>>> >>>>> But of course, the issue raised might have been discussed by the WG in >>>>> a different thread, that doesn’t match a search for >>>>> draft-lz-bess-srv6-service-capability. If so, I’d appreciate a pointer to >>>>> it. >>>>> >>>>> If there wasn’t any discussion in the WG of the authors’ critique, I >>>>> think it deserves to be discussed a bit as part of this thread. In >>>>> particular, does the “this is the same as the trick EVPN does in RFC 8365” >>>>> reply apply equally? Probably it does, although that might boil down to >>>>> “gosh, we should have caught this when publishing 8365, shouldn’t we?” >>>>> >>>>> Even if the outcome of the discussion is that the limitation was >>>>> discussed by the WG/isn’t a big deal because reasons/maybe it’s a big deal >>>>> but we’ll fix it in a followup… as I mentioned earlier, covering it in the >>>>> Security Considerations seems worthwhile. >>>>> >>>>> Thanks, >>>>> >>>>> —John >>>> >>>> _______________________________________________ >>> BESS mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/bess >>> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> *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
