Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>
>> Further to this point:
>>
>> > On Feb 18, 2022, at 3:32 PM, John Scudder <[e-mail]> wrote:
>> >
>> >> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar <[e-mail]>
>> 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
>
>