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

[Gyan Mishra <[e-mail]>]

Hi Ketan

Responses in-line



On Thu, Mar 17, 2022 at 1:15 PM Ketan Talaulikar <[e-mail]>
wrote:

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

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*