Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

[Gyan Mishra <[e-mail]>]

Hi Andrew

On Sat, Feb 12, 2022 at 9:41 PM Gyan Mishra <[e-mail]> wrote:

> Hi Andrew,
>
> On Sat, Feb 12, 2022 at 5:13 PM Andrew - IETF <[e-mail]>
> wrote:
>
>> Hi Gyan,
>>
>>
>>
>> A few clarifications on your clarifications – see responses inline:
>>
>> RFC8402 Section 8.2 explicitly prohibits sending SRv6 traffic beyond the
>> borders of a domain and over the general internet.  Making use of traffic
>> destined for an address within the SRGB of another network isn’t permitted
>> as per:
>>
>>  Gyan> The purpose of the domain boundary filters is to protect the SRv6
>> nodes within the “underlay” by filtering external traffic at the boundary
>> edges any traffic destined to any IPv6 destination address within the SRGB
>> or SRLB which would be underlay node connected interfaces IGP routable not
>> in BGP. This is done for any internet or intranet MPLS domain today to
>> secure the domain trust boundary.
>>
>> Andrew> Can I presume when referring to the SRGB/SRLB here you are
>> referring to the function part of the address or function+argument portion
>> of the SID’s?
>>
>>         Gyan> Yes
>
>> I point out that the difference between SRv6 and MPLS/SR-MPLS is that you
>> cannot “Route” towards a label – you can route towards an IPv6 address.
>>
>>        Gyan> Understood
>
>> If my assumptions are correct on the above – there seems to be an
>> assumption here that there is differentiation between the locator and the
>> function+argument parts of the SID – and these things are advertised
>> separately and then some how assembled.
>>
>>        Gyan> That is all described in detail by this SRv6 BGP based
> service overlay draft.  See the introduction which states the egress PE
> signals the SRv6 service SID L3 service SID for BE service with BGP overlay
> service route or for SRV6-TR the egress PE colors the overlay service route
> with BGP tunnel encapsulation attribute color extended community SR-TE
> candidate path steering.  So nothing is advertised separately and the
> overlay egress PE signaling for SRv6-BE or SRv6-TE is how the SRv6 L3
> service SID is FUNCT field is encoded with L3 vpn route equivalence to MPLS
> label stack VPN label.
>
>> Except – I know of no draft text that says that, nor have I ever seen
>> that behavior in the wild.  If my assumptions are accurate and that is what
>> you are saying, can you point me to the text that defines this reassembly.
>>
>>
>
>> As regards the BGP – it goes further still:
>>
>> <Snip>
>>
>>
>>
>>  Gyan> This is not a BGP related just IGP underlay related.  BGP prefix
>> sid attribute is used to encode SRv6 L3 service TLVs within the SR domain
>> basically mapping the VPN and GRT BGP AFI/SAFI into the Function field of
>> SRv6 SID equivalent to MPLS VPN service label bottom of stack.  However
>> this is only within the SRv6 domain and once the packet leaves the SRv6
>> domain it’s native BGP AFI/SAFI encoding and not in SRv6 SID.  So even
>> though SRv6 SID contains the BGP service label encoding it is not BGP
>> overlay encoding that needs to be secured providing transitivity.
>>
>> Andrew> Again, I’m pretty unsure that I’m fully understanding what you
>> are saying here.  You seem to be saying that once a SID – including its
>> function/locator leave the domain – they cease to be SID’s and are just
>> normal addresses – and only become SID’s by dint of the fact that they are
>> inside the domain.  This would imply that a destination on the internet –
>> suddenly transmutes to something else when it crosses the domain boundary.
>> I would this is an unclear argument that seems to assume behavior not
>> stated in this document, or other SRv6 documents that I have read – and I’m
>> not sure that I agree with this assertion (if I am interpreting you
>> correctly).  I am drawing my interpretations here from the fact that you
>> are bringing up the IGP – and seem to be implying that a locator is
>> announced and some how combined with IGP information, and there is some
>> kinda split / reassembly of the destination.
>>
>>       Gyan> A good way to help describe what I am saying is that the BGP
> AFI/SAFI 1/128 is identical between MPLS/SR-MPLS and SRv6.  What is
> different is the data plane encoding where in MPLS the L3 VPN service label
> is encoded in the Bottom of Stack, where with SRv6  L3 VPN label equivalent
> is encoded in the SRv6 SID Function field.  When a packet egresses exits an
> MPLS domain the  PE performs label disposition POP of the label stack and
> similarly with SRv6 with the egress PE the SRv6 outer header with SRH is
> removed so with that the SRv6 L3 Service TLV encoded in the BGP prefix SID
> attribute is removed as well and the native IP packet os forwarded to the
> CE.
>

     Gyan> I described VPN overlay SAFI 128, however for both Global
Section 5.3 and 5.4 AFI 1 SAFI 1 and AFI 2 SAFI 1 unicast there is no label
so nothing encoded into the SRv6 SID FUNC field. For MPLS Global GRT their
is no encapsulation as it’s native  routing, however for SRv6 the source
node still performs encapsulation for both SRv6-BE w/o SRH and SRv6-TE w/
SRH.  Encapsulation at the source node is requirement for SRV6 for path
steering regardless of GRT or VPN overlay.

>
> Gyan> SR provides a means of stateless traffic steering in the underlay
>> framework using IGP extension to provide the SID distribution  for both
>> SR-MPLS and SRv6.  The SID distribution is done via the IGP extensions as
>> part of the underlay.  The underlay is not routable reachable from outside
>> the domain and even in MPLS TTL propagation is disabled to hide the
>> visibility.  One big difference between MPLS and SRv6 is that the SR source
>> node encapsulates the PE-CE AC payload in IPv6 outer header for both VPN
>> overlay and GRT traffic so they are both treated the same where MPLS with
>> GRT the customer traffic is natively routed and no overlay encapsulation.
>> However in both cases of course we have a BGP overlay RIB which carry the
>> internet or intranet table and that is transitory traffic and is not
>> filtered at the trust boundary.
>>
>> So the trust boundary filtering is primary goal is to protect the
>> underlay nodes and not interfere with the transitory BGP routing
>> reachability.
>>
>>
>>
>> Andrew> However, if all assumptions I have made in the above are correct,
>> and we are back to border filtering, that still leaves the question of the
>> fact that the SID’s are exposed (albeit as addresses) – which still leads
>> to the problem of the fact that this seems to rely on perfect bgp filtering
>> in combination with perfect border filtering, and a failure in either that
>> could have catastrophic consequences.
>>
>>
>      Gyan> As explained above no SRv6 SIDs are exposed.  As there is still
> encapsulation on SRv6 source node and decapsulation on egress PE just as we
> have with VPN SAFI 128 we don’t need border filtering at all due to this
> encapsulation and decapsulation.
>
>> Thanks
>>
>>
>>
>> Andrew
>>
>>
>>
>> *From:* Gyan Mishra <[e-mail]>
>> *Sent:* Saturday, February 12, 2022 10:18 PM
>> *To:* Robert Raszuk <[e-mail]>
>> *Cc:* Andrew - IETF <[e-mail]>; BESS <[e-mail]>;
>> Bocci, Matthew (Nokia - GB) <[e-mail]>; The IESG <
>> [e-mail]>; Warren Kumari <[e-mail]>; [e-mail];
>> [e-mail]
>> *Subject:* Re: [bess] Warren Kumari's Discuss on
>> draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
>>
>>
>>
>>
>>
>> Hi Robert / All
>>
>>
>>
>> For service providers and enterprises using GRT or VRF to carry the
>> internet or intra internet  routing table using MPLS today or SR-MPLS that
>> would like to use SRv6 to provide the same service.
>>
>>
>>
>> Section.  5.1 and 5.2 cover the VPN case in which the customer traffic is
>> in VRF overlay and the SRv6 transport layer is a closed domain.
>>
>>
>>
>> Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
>> encoding.  In this case using GRT transport underlay layer now carry’s the
>> customer routes and that is what Warren and Andrew concern is as far as BGP
>> leaks.
>>
>>
>>
>> So when GRT is used the same edge filtering protection mechanisms used
>> today for MPLS and SR-MPLS would apply to SRv6 for GRT use case.
>>
>>
>>
>> I don’t think we are saying 5.3 or 5.4 should not be allowed but just to
>> tighten up verbiage as far securing the domain.
>>
>>
>>
>> As far as the SRv6 domain is concerned even with GRT the domain is still
>> closed at the PE ingress and egress points which is where the concern is
>> for BGP leaks.  The BGP Prefix SID encoding the SRv6 L3 service TLVs would,
>> the encoding would only be present in the SRv6 SID Function field within
>> the closed domain, and once you exit the SRv6 domain at the ingress or
>> egress endpoints the SRv6 L3 service TLVs would now be carried natively in
>> BGP and not in the SRv6 BGP prefix SID encoding.
>>
>>
>>
>>    When an egress PE is enabled for BGP Services over SRv6 data-plane,
>>
>>    it signals one or more SRv6 Service SIDs enclosed in SRv6 Service
>>
>>    TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs
>>
>>    defined in [RFC4760 <https://datatracker.ietf.org/doc/html/rfc4760>] [RFC4659 <https://datatracker.ietf.org/doc/html/rfc4659>] [RFC8950 <https://datatracker.ietf.org/doc/html/rfc8950>] [RFC7432 <https://datatracker.ietf.org/doc/html/rfc7432>] [RFC4364 <https://datatracker.ietf.org/doc/html/rfc4364>]
>>
>>    [RFC9136 <https://datatracker.ietf.org/doc/html/rfc9136>] where applicable as described in Section 5 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services#section-5> and Section 6 <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services#section-6>.
>>
>>
>>
>> So as far as SRv6 SID leaking there would not be any leaking outside the
>> SRv6 domain.
>>
>>
>>
>> However as the GRT carry internet or intranet BGP RIB the SP AS is of
>> course transitive so entire table is propagated.  That’s not a leak.
>>
>>
>>
>> I think we just need to maybe tighten up the verbiage on securing the PE
>> edges of the SRv6 domain.
>>
>>
>>
>> Kind Regards
>>
>>
>>
>> Gyan
>>
>>
>>
>>
>>
>> On Sat, Feb 12, 2022 at 1:37 PM Robert Raszuk <[e-mail]> wrote:
>>
>> Hi Andrew,
>>
>>
>>
>> When I read Warren's note Iooked at this text from section 2 which says:
>>
>>
>>
>> - - -
>>
>>
>>
>>    The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix-
>>    SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2
>>    services.
>>
>>    o  SRv6 L3 Service TLV: This TLV encodes Service SID information for
>>       SRv6 based L3 services.  It corresponds to the equivalent
>>       functionality provided by an MPLS Label when received with a Layer
>>       3 service route as defined in [RFC4364] [RFC4659] [RFC8950]
>>       [RFC9136].  Some SRv6 Endpoint behaviors which MAY be encoded, but
>>       not limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc.
>>
>>    o  SRv6 L2 Service TLV: This TLV encodes Service SID information for
>>       SRv6 based L2 services.  It corresponds to the equivalent
>>       functionality provided by an MPLS Label1 for Ethernet VPN (EVPN)
>>       Route-Types as defined in [RFC7432].  Some SRv6 Endpoint behaviors
>>       which MAY be encoded, but not limited to, are End.DX2, End.DX2V,
>>       End.DT2U, End.DT2M etc.
>>
>>    When an egress PE is enabled for BGP Services over SRv6 data-plane,
>>    it signals one or more SRv6 Service SIDs enclosed in SRv6 Service
>>    TLV(s) within the BGP Prefix-SID Attribute attached to MP-BGP NLRIs
>>    defined in [RFC4760] [RFC4659] [RFC8950] [RFC7432] [RFC4364]
>>    [RFC9136] where applicable as described in Section 5 and Section 6.
>>
>>    The support for BGP Multicast VPN (MVPN) Services [RFC6513] with SRv6
>>    is outside the scope of this document.
>>
>>
>>
>> - - -
>>
>>
>>
>> This limits the overlay signalling to non global SAFIs mainly SAFI 128
>> and SAFI 70.
>>
>>
>>
>> To your note SAFI 4 is private and never exchanged in the wild. Also SAFI
>> 2 is multicast which is out of scope of this draft.
>>
>>
>>
>> The only thing which we need to sync on is indeed section 5.4 and use of
>> global IPv6 AFI 2 & SAFI 1
>>
>>
>>
>> Many thx,
>>
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Feb 12, 2022 at 7:11 PM Andrew - IETF <[e-mail]>
>> wrote:
>>
>> Robert,
>>
>>
>>
>> I have to say that I have very similar readings on parts of the draft.
>>
>>
>>
>> Let’s look at it –
>>
>>
>>
>> 5.1 uses the IPv4-VPN NLRI – That would seem to indicate AFI 1 / SAFI 4
>>
>> 5.2 – Uses AFI 2 / SAFI 4 from my reading
>>
>> 5.3 – According to RFC8950 – allows advertisement over SAFI 1, 2 or 4
>>
>> 5.4 – To my reading – very much refers to AFI 2 / SAFI 1.
>>
>>
>>
>> I would agree if this document limited itself to 5.1 and 5.2 – it doesn’t
>> – and therefore I have to agree with the thoughts expressed in Warrens
>> Discuss.  If I am wrong about 5.3 and 5.4, let’s chat and help me
>> understand this better, and then lets potentially see if we can work up
>> some wording that would clarify this if that is what is required.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Andrew
>>
>>
>>
>>
>>
>> *From:* iesg <[e-mail]> *On Behalf Of *Robert Raszuk
>> *Sent:* Saturday, February 12, 2022 8:26 PM
>> *To:* Warren Kumari <[e-mail]>
>> *Cc:* Bocci, Matthew (Nokia - GB) <[e-mail]>;
>> [e-mail]; [e-mail]; The IESG <
>> [e-mail]>; BESS <[e-mail]>
>> *Subject:* Re: Warren Kumari's Discuss on
>> draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
>>
>>
>>
>> Hi Warren,
>>
>>
>>
>> Thank you for your Discuss. But before we start discussing it perhaps it
>> would be good to align on what this document really defines as I am sensing
>> from your description there can be some disconnect (modulo some text may be
>> indeed misleading in the draft).
>>
>>
>>
>> You said:
>>
>>
>>
>> > However, we all know that BGP leaks happen -- and when they do, the
>> SID’s
>> > contained in the leak will be logged by various systems and hence
>> available to
>> > the public into perpetuity.
>>
>>
>>
>> I think the term BGP is used here a bit too broadly.
>>
>>
>>
>> Leaks do happen but only within global AFI/SAFIs. This draft defines
>> extensions for L3VPN and L2VPNs SAFIs which are not used to peer outside of
>> a domain, collection of domains under same administration +
>> of course inter-as also could happen.
>>
>>
>>
>> With that being said I do not see risk that due to leaking there could be
>> a situation where customer networks are exposed in any way externally -
>> leaving alone that to even get at the transport level to the customer
>> facing PE is also filtered and never allowed from outside. But this is out
>> of scope of this document as here the focus is not on underlay but overlay.
>>
>>
>>
>> Now when I re-read this I see why there is a little piece perhaps
>> misleading. The draft makes a claim that it is applicable to RFC8950 which
>> defines use of NHv6 with both unicast and VPN AFs. That needs to be made
>> clear that it is applicable to the latter only. If other co-authors believe
>> this is applicable to the former your DISCUSS section would indeed be
>> valid.
>>
>>
>>
>> Many thx,
>>
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Feb 12, 2022 at 12:05 AM Warren Kumari via Datatracker <
>> [e-mail]> wrote:
>>
>> Warren Kumari has entered the following ballot position for
>> draft-ietf-bess-srv6-services-10: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> The Security Considerations section says: "The service flows between PE
>> routers
>> using SRv6 SIDs advertised via BGP are expected to be limited within the
>> trusted SR domain (e.g., within a single AS or between multiple ASes
>> within a
>> single provider network).  Precaution should be taken to ensure that the
>> BGP
>> service information (including associated SRv6 SID) advertised via BGP
>> sessions
>> are limited to peers within this trusted SR domain." This is related to
>> (from
>> RFC8402): "Therefore, by default, the explicit routing information MUST
>> NOT be
>> leaked through the boundaries of the administered domain."
>>
>> However, we all know that BGP leaks happen -- and when they do, the SID’s
>> contained in the leak will be logged by various systems and hence
>> available to
>> the public into perpetuity.
>>
>> While the document states that border filtering should protect against
>> traffic
>> injection, this does not cover the case of internal compromise. Sure,
>> there is
>> the argument that once there is an internally compromised system, all
>> bets are
>> off -- but with this, an attacker that knows the SIDs in e.g inject
>> traffic
>> into a VPN. This seems to me to significantly expand the attack surface to
>> include the customer's networks too.
>>
>> Not only does an operator have to ensure that BGP leaks never occur, they
>> have
>> to then ensure that at no point can there be any filter lapses at any
>> border
>> node, and be able to guarantee the security of every device, server and
>> machine
>> within the domain in order for a secure posture to be maintained. Simply
>> saying
>> that precautions should be taken to make sure that route leak don't
>> occur, when
>> the consequences of doing so are a: severe and b: hard to recover from
>> seems to
>> not really cover it. In addition, it seems that the blast radius from a
>> missing
>> ACL seems much larger if it allows injections.
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I'm still reviewing the document, but wanted to get an initial ballot in,
>> so
>> that we could start discussing it. Hopefully someone can help my
>> understand how
>> this doesn't expand the consequences of a BGP leak.
>>
>> _______________________________________________
>> BESS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bess
>>
>> --
>>
>> [image: Image removed by sender.] <http://www.verizon.com>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>> *M 301 502-1347*
>>
>>
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *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*
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*