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

[Gyan Mishra <[e-mail]>]

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.

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.  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.

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


Kind Regards

Gyan

On Sat, Mar 5, 2022 at 4:40 AM Ketan Talaulikar <[e-mail]>
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 <[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
>>
>> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*