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

[Ketan Talaulikar <[e-mail]>]

Hi Gyan,

Please check inline below for responses.


On Wed, Mar 16, 2022 at 8:08 PM Gyan Mishra <[e-mail]> 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.


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


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

Thanks,
Ketan


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