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 <rob...@raszuk.net> 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 <j...@juniper.net> wrote: > >> Further to this point: >> >> > On Feb 18, 2022, at 3:32 PM, John Scudder <j...@juniper.net> wrote: >> > >> >> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar <ketant.i...@gmail.com> >> 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
