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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Fri, 11 Feb 2022 15:05:03 -0800

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.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 12 Feb 2022 18:26:13 +0100

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

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

---

From: Andrew - IETF <[email-masked]>
Date: Sat, 12 Feb 2022 18:11:42 +0000

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 <[email-masked]> On Behalf Of Robert Raszuk
Sent: Saturday, February 12, 2022 8:26 PM
To: Warren Kumari <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; BESS <[email-masked]>
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).

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 <[email-masked]<mailto:[email-masked]>> wrote:
Warren Kumari has entered the following ballot position for
draft-ietf-bess-srv6-services-10: Discuss

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/<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/<https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 12 Feb 2022 19:36:44 +0100

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 <[email-masked]>
wrote:

> 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 <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Saturday, February 12, 2022 8:26 PM
> *To:* Warren Kumari <[email-masked]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[email-masked]>;
> [email-masked]; [email-masked]; The IESG <
> [email-masked]>; BESS <[email-masked]>
> *Subject:* Re: Warren Kumari's Discuss on
> draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
>
>
>
> Hi Warren,
>
>
>
> 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 -

---

From: Andrew - IETF <[email-masked]>
Date: Sat, 12 Feb 2022 18:51:09 +0000

Hi Robert,

5.3 Also opens the door to SAFI 1 – since you can v6 over v4 using AFI  1  / SAFI 1 using what is defined in RFC8950, in fact, it is explicit.

Section 5.3 is titled Global IPv4 over SRv6 core – this correlates with the example in section 6.1 of RFC8950 – which states:

   The extensions defined in this document may be used as discussed in

   [RFC5565<https://datatracker.ietf.org/doc/html/rfc5565>] for the interconnection of IPv4 islands over an IPv6

   backbone.  In this application, Address Family Border Routers (AFBRs;

   as defined in [RFC4925<https://datatracker.ietf.org/doc/html/rfc4925>]) advertise IPv4 NLRI in the MP_REACH_NLRI

   along with an IPv6 next hop.

   The MP_REACH_NLRI is encoded with:

   *  AFI = 1

   *  SAFI = 1

   *  Length of Next Hop Address field = 16 (or 32)

   *  Next Hop Address = IPv6 address of the next hop

   *  NLRI = IPv4 routes

   During BGP Capability Advertisement, the PE routers would include the

   following fields in the Capabilities Optional Parameter:

   *  Capability Code set to "Extended Next Hop Encoding"

   *  Capability Value containing <NLRI AFI=1, NLRI SAFI=1, Nexthop

      AFI=2>

As I say, if you were to remove the references to global and 5.3/5.4 which explicitly reference it and bring SAFI 1 into play – there would be far less concern from my side, I can’t speak for anyone else, but that would be my feeling

Thanks

Andrew

From: Robert Raszuk <[email-masked]>
Sent: Saturday, February 12, 2022 9:37 PM
To: Andrew - IETF <[email-masked]>
Cc: Warren Kumari <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; BESS <[email-masked]>
Subject: Re: Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

Hi Andrew,

- - -

- - -

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 <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Let’s look at it –

Thanks

Andrew

From: iesg <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Saturday, February 12, 2022 8:26 PM
To: Warren Kumari <[email-masked]<mailto:[email-masked]>>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; BESS <[email-masked]<mailto:[email-masked]>>
Subject: Re: Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

Hi Warren,

Many thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 12 Feb 2022 14:17:37 -0500

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 <[email-masked]> wrote:

> 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.
>
>> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Andrew - IETF <[email-masked]>
Date: Sat, 12 Feb 2022 19:42:31 +0000

Gyan,

However what you say then raises additional concerns.

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:

   SR domain boundary routers MUST filter any external traffic destined
   to an address within the SRGB of the trusted domain or the SRLB of
   the specific boundary router.  External traffic is any traffic
   received from an interface connected to a node outside the domain of
   trust.

As regards the BGP – it goes further still:

   From a network-protection standpoint, there is an assumed trust model
   such that any node adding an SRH to the packet is assumed to be
   allowed to do so.  Therefore, by default, the explicit routing
   information MUST NOT be leaked through the boundaries of the
   administered domain.

Now, I may be misunderstanding here – but – if at any point the announcements lead to traffic flowing towards a SID from outside the administered domain – that violates 8402.  If the SID’s are in BGP prefix’s that are transitive and find their way onto the general internet – that also violates 8402.

Now, this could be a misunderstanding on my part – so I’d welcome clarification if I am incorrect in what I am seeing here – which may also lead to text which is clearer (as a note, I ran this past several operators who had very similar readings to what I had – so – if it’s a matter of misunderstanding, we really do need to find a way to clarify it, if its not a misunderstanding, then we need to find a way to rectify it for security purposes and to bring it in-line with RFC8402.

Thanks

Andrew

From: Gyan Mishra <[email-masked]>
Sent: Saturday, February 12, 2022 10:18 PM
To: Robert Raszuk <[email-masked]>
Cc: Andrew - IETF <[email-masked]>; BESS <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>; The IESG <[email-masked]>; Warren Kumari <[email-masked]>; [email-masked]; [email-masked]
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.

   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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andrew,

- - -

- - -

Many thx,
R.

On Sat, Feb 12, 2022 at 7:11 PM Andrew - IETF <[email-masked]> wrote:
Robert,

Let’s look at it –

Thanks

Andrew

Hi Warren,

Many thx,
R.

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://www.ietf.org/mailman/listinfo/bess>
--

[Image removed by sender.]<http://www.verizon.com>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 12 Feb 2022 22:23:08 +0100

Gyan,

> customer routes and that is what Warren and Andrew concern is as far as BGP

I would have the same concern so would VPN customers. No one is selling L2
or L3 VPN service to them distributing their reachability in the global
routing table. They can do that all by themselves and there is lot's of
really solid tools or products to do that already without being locked to a
single telco.

> today for MPLS and SR-MPLS would apply to SRv6 for GRT use case.

Not possible. It is not about filtering ... it is all about using globally
routable SAFI vs private SAFIs to distribute customer's reachability, IMO
that should still be OTT only.

> tighten up verbiage as far securing the domain.

BGP filtering or policy is in hands of many people. As has been proven you
can not tighten them strong enough not to leak. The only natural way to
tighten them is to use different plane to distribute private information
what in this context means at least different BGP SAFI.

So no - I do not agree with your observations.

However I am for providing overlay reachability over global IPv6 Internet
to interconnect customer sites. But routing within those sites should not
be traversing Internet routers and using SAFI 1.

Rgs,
Robert.

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 12 Feb 2022 16:28:28 -0500

Hi Andrew

Responses in-line

On Sat, Feb 12, 2022 at 2:42 PM Andrew - IETF <[email-masked]>
wrote:

> 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.
>
>  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.
>
> 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.
>
> Now, I may be misunderstanding here – but – if at any point the
> announcements lead to traffic flowing towards a SID from outside the
> administered domain – that violates 8402.  If the SID’s are in BGP prefix’s
> that are transitive and find their way onto the general internet – that
> also violates 8402.
>
>  Gyan> As long as  the infrastructure  filters are applied at the trust
> boundary protection of the underlay SRv6 nodes there is no issue and that
> verbiage just needs to be clear in this draft following *RFC 8402.*
>
> Now, this could be a misunderstanding on my part – so I’d welcome
> clarification if I am incorrect in what I am seeing here – which may also
> lead to text which is clearer (as a note, I ran this past several operators
> who had very similar readings to what I had – so – if it’s a matter of
> misunderstanding, we really do need to find a way to clarify it, if its not
> a misunderstanding, then we need to find a way to rectify it for security
> purposes and to bring it in-line with RFC8402.
>
>  Gyan> Understood.  We can update the verbiage to make it crystal clear.
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Saturday, February 12, 2022 10:18 PM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* Andrew - IETF <[email-masked]>; BESS <[email-masked]>;
> Bocci, Matthew (Nokia - GB) <[email-masked]>; The IESG <
> [email-masked]>; Warren Kumari <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [bess] Warren Kumari's Discuss on
>    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>.
>
>
>
> *From:* iesg <[email-masked]> *On Behalf Of *Robert Raszuk
>  <http://www.verizon.com>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Andrew - IETF <[email-masked]>
Date: Sat, 12 Feb 2022 22:12:54 +0000

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

Andrew

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, February 12, 2022 10:18 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Andrew - IETF <[email-masked]<mailto:[email-masked]>>; BESS <[email-masked]<mailto:[email-masked]>>; Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>; Warren Kumari <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

Hi Robert / All

Kind Regards

Gyan

- - -

- - -

Many thx,
R.

Let’s look at it –

Thanks

Andrew

Hi Warren,

Many thx,
R.

Gyan Mishra

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 12 Feb 2022 21:41:00 -0500

Hi Andrew,

On Sat, Feb 12, 2022 at 5:13 PM Andrew - IETF <[email-masked]>
wrote:

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

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

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

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 12 Feb 2022 23:14:55 -0500

Hi Andrew

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

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

     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.

>> So the trust boundary filtering is primary goal is to protect the
>> underlay nodes and not interfere with the transitory BGP routing
>> reachability.
>>
>>
>>
>      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
>>
>>
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 12 Feb 2022 23:47:22 -0500

Hi Robert

> really solid tools or products to do that already without being locked to a

Gyan> MPLS provides the capability for GRT native routing  SAFI 1 as well
as SAFI 128, so in my opinion both should be supported by SRV6 as operators
look to use SRv6 for a variety of use cases. That’s my point as there
should be complete feature parity between MPLS and SRv6 as to AFI / SAFI
support.  Global Internet routing would not be the best use case for SAFI 1
GRT due to the attack vector - agreed, but enterprise networks with
internal customers where there is a trust level is a huge use case.

> that should still be OTT only.

    Gyan> As SRv6 source node is requirement to encapsulation with IPv6
outer header and decapsulation at egress PE for SRv6-BE and SRv6-TE path
steering the security issue brought up related to 5.3 and 5.4 is not an
issue requiring filtering per RFC 8402.  So routable and private SAFI
scenario would be the same now due to encapsulation overlay for both.  Do
you agree ?

> So no - I do not agree with your observations.

   Gyan> I am not promoting use of SAFI 1 however I SRv6 should provide
complete parity with MPLS to support both SAFI 1 and 128. There  are plenty
of use cases for SAFI 1 and it should be supported with SRv6.

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 13 Feb 2022 13:48:06 +0100

Gyan,

MPLS is never sent in SAFI 1.

Thx,
R.

On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra <[email-masked]> wrote:

>> I would have the same concern so would VPN customers. No one is selling
>> L2 or L3 VPN service to them distributing their reachability in the global
>> Not possible. It is not about filtering ... it is all about using
>> globally routable SAFI vs private SAFIs to distribute customer's
>> reachability, IMO that should still be OTT only.
>>
>
>> BGP filtering or policy is in hands of many people. As has been proven
>> you can not tighten them strong enough not to leak. The only natural way to

---

From: Andrew - IETF <[email-masked]>
Date: Sun, 13 Feb 2022 13:50:24 +0000

+1

This is something I was a little confused about since its been referenced in these emails time and again, and I was wondering if I had missed something, but, I’ve checked to be 100%  certain, RFC8950 which is what this document refers to explicitly states that the NLRI encoding  of the destination must not change – and since the IPv4 NLRI leaves no provision for labels – and  makes it clear that SAFI 4 is used for MPLS – MPLS doesn’t fall into SAFI 1.
In fact, what is described in 5.3 only results from the nature of SRv6, it states:

   SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV.  The
   SRv6 Endpoint behavior of the SRv6 SID is entirely up to the

   originator of the advertisement.  In practice, the SRv6 Endpoint

   behavior is End.DX4 or End.DT4.

Since 5.3 can operate in SAFI 1 (it explicitly refers to Global IPv4 over SRv6 core – which by correlation to 8950 is SAFI 1) and based on the wording of the above, this actually puts MPLS type functionality into SAFI 1 where it never was before, by using the SID as a normal address which is then dealt with as a SID inside the domain.  But no – this is not providing equal functionality for MPLS – this is extending MPLS style functionality into SAFI 1, which, if my reading of Warren’s discuss is accurate, is pretty much the essence of the problem.

Thanks

Andrew

From: Robert Raszuk <[email-masked]>
Sent: Sunday, February 13, 2022 3:48 PM
To: Gyan Mishra <[email-masked]>
Cc: Andrew - IETF <[email-masked]>; BESS <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>; The IESG <[email-masked]>; Warren Kumari <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

Gyan,

Thx,
R.

On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert

On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

I would have the same concern so would VPN customers. No one is selling L2 or L3 VPN service to them distributing their reachability in the global routing table. They can do that all by themselves and there is lot's of really solid tools or products to do that already without being locked to a single telco.

Gyan> MPLS provides the capability for GRT native routing  SAFI 1 as well as SAFI 128, so in my opinion both should be supported by SRV6 as operators look to use SRv6 for a variety of use cases. That’s my point as there should be complete feature parity between MPLS and SRv6 as to AFI / SAFI support.  Global Internet routing would not be the best use case for SAFI 1 GRT due to the attack vector - agreed, but enterprise networks with internal customers where there is a trust level is a huge use case.

Not possible. It is not about filtering ... it is all about using globally routable SAFI vs private SAFIs to distribute customer's reachability, IMO that should still be OTT only.

    Gyan> As SRv6 source node is requirement to encapsulation with IPv6 outer header and decapsulation at egress PE for SRv6-BE and SRv6-TE path steering the security issue brought up related to 5.3 and 5.4 is not an issue requiring filtering per RFC 8402.  So routable and private SAFI scenario would be the same now due to encapsulation overlay for both.  Do you agree ?

BGP filtering or policy is in hands of many people. As has been proven you can not tighten them strong enough not to leak. The only natural way to tighten them is to use different plane to distribute private information what in this context means at least different BGP SAFI.

   Gyan> I am not promoting use of SAFI 1 however I SRv6 should provide complete parity with MPLS to support both SAFI 1 and 128. There  are plenty of use cases for SAFI 1 and it should be supported with SRv6.

However I am for providing overlay reachability over global IPv6 Internet to interconnect customer sites. But routing within those sites should not be traversing Internet routers and using SAFI 1.

Rgs,
Robert.

--

Gyan Mishra

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 13 Feb 2022 15:25:19 +0100

Hi Andrew,

Most of what you say is true, so is my statement that MPLS labels are never
carried in SAFI 1 in BGP.

However, let me explain why I think a bit different view may work better
here ...

First let's clearly divide MPLS labels used for transport (which create
actual LSPs) from MPLS labels used for services (which are used to demux
packets at the egress PEs into appropriate context tables - typically VRFs
but not only (can be directly CEs too))

So the draft in the discussion is about overlay VPN services and therefore
the analogy made to MPLS labels are only related to SAFI 128 or SAFI 70.
Nothing here travels in unicast SAFI 1 nor in any IGP. So in the context of
this draft we should never allow to put the new attribute neither in SAFI 1
nor even SAFI 4.

But now comes the part which makes this discussion mangled ... unlike in
MPLS where LSPs need to be signalled in SRv6 you do not need any signalling
and IPv6 reachability is all that is needed for transport. So in SRv6 what
is in MPLS world signalled in LDP or RSVP-TE or SAFI 4 is indeed carried in
AFI 2 & SAFI 1.  /* SAFI 4 comes helpful when you build hierarchical LSPs
but in this discussion it is completely irrelevant. */

So I can see why some people may have thought oh since transport in SRv6
comes for free let's load it with services in an attribute and be done. Yes
I can see that flattening this make it potentially easier (one less SAFI to
enable), but I am not sure we have reached a broad agreement here. This
comes as a consequence of moving service prefixes from MP_REACH_NLRI
(perhaps new format and new SAFI) to an attribute.

Thx,
R.

On Sun, Feb 13, 2022 at 2:50 PM Andrew - IETF <[email-masked]>
wrote:

> +1
>
>
>
> This is something I was a little confused about since its been referenced
> in these emails time and again, and I was wondering if I had missed
> something, but, I’ve checked to be 100%  certain, RFC8950 which is what
> this document refers to explicitly states that the NLRI encoding  of the
> destination must not change – and since the IPv4 NLRI leaves no provision
> for labels – and  makes it clear that SAFI 4 is used for MPLS – MPLS
> doesn’t fall into SAFI 1.
>
> Since 5.3 can operate in SAFI 1 (it explicitly refers to Global IPv4 over
> SRv6 core – which by correlation to 8950 is SAFI 1) and based on the
> wording of the above, this actually puts MPLS type functionality into SAFI
> 1 where it never was before, by using the SID as a normal address which is
> then dealt with as a SID inside the domain.  But no – this is not providing
> equal functionality for MPLS – this is extending MPLS style functionality
> into SAFI 1, which, if my reading of Warren’s discuss is accurate, is
> pretty much the essence of the problem.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Sunday, February 13, 2022 3:48 PM
> *To:* Gyan Mishra <[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 13 Feb 2022 13:21:10 -0500

Hi Robert

I am not saying MPLS is sent in SAFI 1.

Let me try to explain.

In the use case we are discussing in section 5.3 and 5.4  is when there is
no VPN overlay as the PE-CE AC sits in the global routing table native BGP
unlabeled prefixes and the label stack is just a single label deep with the
topmost transport label.  In that scenario 5.4 is IPv6 unicast SAFI 1 NLRI
is carried over an IPv6 core transport label LSP.

In the MPLS analogy use case of global table routing  there is no bottom of
stack service label as is required for L3 VPN where we have a label as we
have an VPN overlay present. So the BGP routes are carried in the BGP RIB
natively in the global routing table unlabeled.  So that is what we are
talking about for the 5.4 use case now with SRv6 no VPN label and so NO
SRv6 L3 service TLV encoded in BGP prefix SID attribute.  The MPLS label
stack L3 VPN service label in SRv6 scenario in FUNCT field is now not
present with SAFI 1 IPV6 Unicast “Global IPv6 over IPv6 core”.

In section 5.1 and 5.2 BGP-LU SAFI 4 is required
because the SRv6 L3 Service TLV for L3 VPN overlay service route must
encoded in BGP prefix SID as it must be sent as labeled.

So in section 5.3 Global IPv4 over SRv6 core is similar to a 6PE RFC 4798
scenario analogy where the IPv6 prefixes are carried over an IPv4 core with
IPv4 signaled LSP with additional bottom of stack label as IPV6 prefixes
are labeled with BGP-LU SAFI 4  2/4 and must be sent labeled due to PHP
requirement as stated in RFC 4798.

So we have in section 5.3 the same scenario as 6PE but now over SRv6 using
RFC 8950 IPv6 next hop encoding to carry the BGP LU SAFI 4 labeled IPv4
prefixes.

So in 5.3 that section would need to be updated to state that BGP-LU
labeled IPv4 prefixes is necessary with encoded SRv6 L3 service TLV in BGP
prefix SID attribute so the IPv4 prefixes can be sent as labeled prefixes
over SRv6 core.

Upon exiting the SRv6 domain at the egress PE the outer IPv6 header is
removed that contains the SRv6 programming endpoint behavior semantics with
native payload forwarded by the PE to the CE similar to MPLS label
disposition at egress PE exiting the domain.

So here no issue with filtering as once you exit the domain the SRv6
forwarding plane semantics are stripped from the packet.

Hopefully this clarifies.

Many Thanks,

Gyan

On Sun, Feb 13, 2022 at 7:48 AM Robert Raszuk <[email-masked]> wrote:

>>> However I am for providing overlay reachability over global IPv6
>>> Internet to interconnect customer sites. But routing within those sites
>>> should not be traversing Internet routers and using SAFI 1.
>>>
>>> Rgs,
>>> Robert.
>>>
>>> --
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 14 Feb 2022 11:24:20 +0530

Hi Warren/All,

This draft specifies broadly two types of BGP Services over SRv6:

A) VPN Services (L3VPN & EVPN) - Sec 5.1, 5.2 & 6
B) Global Internet Services - Sec 5.3, 5.4

As explained by my co-author Robert, the operations and mechanisms for VPN
services are similar to what we've had with MPLS. I believe we are all on
the same page on this one based on the discussions between Andrew and
Robert and that there is no new concern as far as (A).

Now (B) does bring in filtering aspects (as mentioned in the security
considerations) to ensure that the SRv6 block that is meant for use
internal to the operator's network (i.e. SR domain) does not get
leaked/advertised out from the default table on the Internet Border Router
(IBR) over to an eBGP peer. This is similar to the precautions that
operators take today to prevent their infrastructure addresses from being
leaked to the Internet. The filters in BGP are also accompanied by ACLs at
the IBRs to prevent traffic destined for those infrastructure IPs from
entering into the operator network. This is the same in the case of SRv6 as
well.

I hope that clarifies and we can update the text to convey these aspects
better.

Thanks,
Ketan

On Sun, Feb 13, 2022 at 12:21 AM Andrew - IETF <[email-masked]>
wrote:

> Hi Robert,
>
>
>
> 5.3 Also opens the door to SAFI 1 – since you can v6 over v4 using AFI  1
>  / SAFI 1 using what is defined in RFC8950, in fact, it is explicit.
>
>
>
> Section 5.3 is titled Global IPv4 over SRv6 core – this correlates with
> the example in section 6.1 of RFC8950 – which states:
>
>
>
>
>
>    [RFC5565 <https://datatracker.ietf.org/doc/html/rfc5565>] for the interconnection of IPv4 islands over an IPv6
>
>    as defined in [RFC4925 <https://datatracker.ietf.org/doc/html/rfc4925>]) advertise IPv4 NLRI in the MP_REACH_NLRI
>
> As I say, if you were to remove the references to global and 5.3/5.4 which
> explicitly reference it and bring SAFI 1 into play – there would be far
> less concern from my side, I can’t speak for anyone else, but that would be
> my feeling
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
> *Sent:* Saturday, February 12, 2022 9:37 PM
> *To:* Andrew - IETF <[email-masked]>
> *Cc:* Warren Kumari <[email-masked]>; Bocci, Matthew (Nokia - GB) <
> [email-masked]>; [email-masked];
> [email-masked]; The IESG <[email-masked]>; BESS <[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Feb 2022 02:47:18 -0500

Hi Ketan

I agree with you that for B section 5.3 and 5.4  IPv4 and IPv6 global table
over SRv6 core does bring filtering aspects to the security considerations
to ensure that the operators SRv6 infrastructure block does not get leaked
from the global table to the internet over eBGP peer as well as
infrastructure ACLs to prevent access to SRv6 infrastructure IPs per RFC
8402 section 8.2.

I don’t see any other security issues other than what is described in RFC
8402 section 8.2.

I agree as well that this security consideration is no different then
precautions taken today on an operators network.

Kind Regards

Gyan

On Mon, Feb 14, 2022 at 12:55 AM Ketan Talaulikar <[email-masked]>
wrote:

>> As I say, if you were to remove the references to global and 5.3/5.4
>> which explicitly reference it and bring SAFI 1 into play – there would be
>> far less concern from my side, I can’t speak for anyone else, but that
>> would be my feeling
>>
>>
>>
>> Thanks
>>
>>
>>
>> Andrew
>>
>>
>>
>>
>>
>>
>>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Feb 2022 09:14:13 -0600

> Robert and that there is no new concern as far as (A).

Actually, no, I don't think that we are -- if I, as an attacker, somehow
know that VPN x uses MPLS labels Y, that's interesting, but not
particularly valuable -- because of the "fail closed" nature of MPLS (it's
a different protocol, and needs explicit and intentional action to enable
on an interface)  it's really hard for me to "inject" an MPLS packet and
route it into your network. With SRv6, if the SIDs leak, I can construct a
normal v6 packet and route it towards you. Yes, handwave handwave the RFCs
say that you MUST filter at your edges and that the filtering MUST always
be perfect handwave limited domain handwave -- but it's putting a large
amount of faith in operator perfection.

Also, if I, as an attacker get access to a "server" in the provider network
(noc workstation, billing machine, random admin PC, etc), with MPLS it's
very unlikely to be part of the MPLS domain, but  an SRv6 domain is much
more likely to be "squishy" and more likely to encompass parts of the
"enterprise" type systems.

W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Feb 2022 16:27:55 +0100

Hi Warren,

I am very sorry but I see folks are completely mixing transport layer and
service layer.

In RFC4364 you can use MPLS label for service demux and IP transport to get
to remote egress PE via any IP network including Internet.

There is nothing in L3VPNs like enabling MPLS on interface as mandatory
prerequisite. Yes many folks are confused about this and I see the same
confusion here. The service plane is completely separate from transport
layer from day one.

Kind regards,
Robert

On Thu, Feb 17, 2022 at 4:14 PM Warren Kumari <[email-masked]> wrote:

>> As explained by my co-author Robert, the operations and mechanisms for
>> VPN services are similar to what we've had with MPLS. I believe we are all
>> on the same page on this one based on the discussions between Andrew and
> Also, if I, as an attacker get access to a "server" in the provider
> network (noc workstation, billing machine, random admin PC, etc), with MPLS
> it's very unlikely to be part of the MPLS domain, but  an SRv6 domain is
> much more likely to be "squishy" and more likely to encompass parts of the
>>> 5.3 Also opens the door to SAFI 1 – since you can v6 over v4 using AFI
>>>  1  / SAFI 1 using what is defined in RFC8950, in fact, it is explicit.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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
>>> 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 -
>>> Please refer to
>>> https://www.ietf.org/blog/handling-iesg-ballot-positions/

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 17 Feb 2022 15:41:01 +0000

Hi all,

+1 for Robert.
Yes, especially when MPLS in GRE or MPLS in UDP is deployed, packets carrying MPLS labels can traverse all IP-reachable networks and reach remote PEs.

BR,
Shunwan

From: Robert Raszuk [mailto:[email-masked]]
Sent: Thursday, February 17, 2022 11:28 PM
To: Warren Kumari <[email-masked]>
Cc: Ketan Talaulikar <[email-masked]>; Andrew - IETF <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; BESS <[email-masked]>
Subject: Re: Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

Hi Warren,

I am very sorry but I see folks are completely mixing transport layer and service layer.

In RFC4364 you can use MPLS label for service demux and IP transport to get to remote egress PE via any IP network including Internet.

There is nothing in L3VPNs like enabling MPLS on interface as mandatory prerequisite. Yes many folks are confused about this and I see the same confusion here. The service plane is completely separate from transport layer from day one.

Kind regards,
Robert

On Thu, Feb 17, 2022 at 4:14 PM Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Feb 13, 2022 at 11:54 PM Ketan Talaulikar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Warren/All,

As explained by my co-author Robert, the operations and mechanisms for VPN services are similar to what we've had with MPLS. I believe we are all on the same page on this one based on the discussions between Andrew and Robert and that there is no new concern as far as (A).

Actually, no, I don't think that we are -- if I, as an attacker, somehow know that VPN x uses MPLS labels Y, that's interesting, but not particularly valuable -- because of the "fail closed" nature of MPLS (it's a different protocol, and needs explicit and intentional action to enable on an interface)  it's really hard for me to "inject" an MPLS packet and route it into your network. With SRv6, if the SIDs leak, I can construct a normal v6 packet and route it towards you. Yes, handwave handwave the RFCs say that you MUST filter at your edges and that the filtering MUST always be perfect handwave limited domain handwave -- but it's putting a large amount of faith in operator perfection.

Also, if I, as an attacker get access to a "server" in the provider network (noc workstation, billing machine, random admin PC, etc), with MPLS it's very unlikely to be part of the MPLS domain, but  an SRv6 domain is much more likely to be "squishy" and more likely to encompass parts of the "enterprise" type systems.

W

Now (B) does bring in filtering aspects (as mentioned in the security considerations) to ensure that the SRv6 block that is meant for use internal to the operator's network (i.e. SR domain) does not get leaked/advertised out from the default table on the Internet Border Router (IBR) over to an eBGP peer. This is similar to the precautions that operators take today to prevent their infrastructure addresses from being leaked to the Internet. The filters in BGP are also accompanied by ACLs at the IBRs to prevent traffic destined for those infrastructure IPs from entering into the operator network. This is the same in the case of SRv6 as well.

I hope that clarifies and we can update the text to convey these aspects better.

Thanks,
Ketan

On Sun, Feb 13, 2022 at 12:21 AM Andrew - IETF <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

   *  AFI = 1

   *  SAFI = 1

   *  NLRI = IPv4 routes

      AFI=2>

Thanks

Andrew

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, February 12, 2022 9:37 PM
To: Andrew - IETF <[email-masked]<mailto:[email-masked]>>
Cc: Warren Kumari <[email-masked]<mailto:[email-masked]>>; Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; BESS <[email-masked]<mailto:[email-masked]>>
Subject: Re: Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)

Hi Andrew,

- - -

- - -

Many thx,
R.

Let’s look at it –

Thanks

Andrew

Hi Warren,

Many thx,
R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Feb 2022 11:05:14 -0500

I would presume that the general policy (which does not apply to SRv6) 
that nodes should not decapsulate  tunnel packets without configuration 
or special exemption would mean that an arbitrary MPLS node will not 
decapsualte a GRE packet and process its MPLS content.  Otherwise, all 
tunnels become major security risks.

Yours,
Joel

On 2/17/2022 10:41 AM, Zhuangshunwan wrote:
> Hi all,
> 
> +1 for Robert.
> 
> Yes, especially when MPLS in GRE or MPLS in UDP is deployed, packets 
> carrying MPLS labels can traverse all IP-reachable networks and reach 
> remote PEs.
> 
> BR,
> 
> Shunwan
> 
> *From:*Robert Raszuk [mailto:[email-masked]]
> *Sent:* Thursday, February 17, 2022 11:28 PM
> *Cc:* Ketan Talaulikar <[email-masked]>; Andrew - IETF 
> <[email-masked]>; Bocci, Matthew (Nokia - GB) 
> <[email-masked]>; [email-masked]; 
> In RFC4364 you can use MPLS label for service demux and IP transport to 
> get to remote egress PE via any IP network including Internet.
> 
>     On Sun, Feb 13, 2022 at 11:54 PM Ketan Talaulikar
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Hi Warren/All,
> 
>         As explained by my co-author Robert, the operations and
>         mechanisms for VPN services are similar to what we've had with
>         MPLS. I believe we are all on the same page on this one based on
>         the discussions between Andrew and Robert and that there is no
>         new concern as far as (A).
> 
>     Actually, no, I don't think that we are -- if I, as an attacker,
>     somehow know that VPN x uses MPLS labels Y, that's interesting, but
>     not particularly valuable -- because of the "fail closed" nature of
>     MPLS (it's a different protocol, and needs explicit and intentional
>     action to enable on an interface)  it's really hard for me to
>     "inject" an MPLS packet and route it into your network. With SRv6,
>     if the SIDs leak, I can construct a normal v6 packet and route it
>     towards you. Yes, handwave handwave the RFCs say that you MUST
>     filter at your edges and that the filtering MUST always be perfect
>     handwave limited domain handwave -- but it's putting a large amount
>     of faith in operator perfection.
> 
>     network (noc workstation, billing machine, random admin PC, etc),
>     with MPLS it's very unlikely to be part of the MPLS domain, but  an
>     SRv6 domain is much more likely to be "squishy" and more likely to
>     encompass parts of the "enterprise" type systems.
> 
>     W
> 
>         Now (B) does bring in filtering aspects (as mentioned in the
>         security considerations) to ensure that the SRv6 block that is
>         meant for use internal to the operator's network (i.e. SR
>         domain) does not get leaked/advertised out from the default
>         table on the Internet Border Router (IBR) over to an eBGP peer.
>         This is similar to the precautions that operators take today to
>         prevent their infrastructure addresses from being leaked to the
>         Internet. The filters in BGP are also accompanied by ACLs at the
>         IBRs to prevent traffic destined for those infrastructure IPs
>         from entering into the operator network. This is the same in the
>         case of SRv6 as well.
> 
>         On Sun, Feb 13, 2022 at 12:21 AM Andrew - IETF
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Hi Robert,
> 
>             5.3 Also opens the door to SAFI 1 – since you can v6 over v4
>             using AFI  1  / SAFI 1 using what is defined in RFC8950, in
>             fact, it is explicit.
> 
>             Section 5.3 is titled Global IPv4 over SRv6 core – this
>             correlates with the example in section 6.1 of RFC8950 –
>             which states:
> 
>                 [RFC5565
>             <https://datatracker.ietf.org/doc/html/rfc5565>] for the
>             interconnection of IPv4 islands over an IPv6
> 
>                 as defined in [RFC4925
>             <https://datatracker.ietf.org/doc/html/rfc4925>]) advertise
>             IPv4 NLRI in the MP_REACH_NLRI
> 
>             As I say, if you were to remove the references to global and
>             5.3/5.4 which explicitly reference it and bring SAFI 1 into
>             play – there would be far less concern from my side, I can’t
>             speak for anyone else, but that would be my feeling
> 
>             Thanks
> 
>             Andrew
> 
>             *From:*Robert Raszuk <[email-masked]
>             <mailto:[email-masked]>>
>             *To:* Andrew - IETF <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:* Warren Kumari <[email-masked]
>             <mailto:[email-masked]>>; Bocci, Matthew (Nokia - GB)
>             <[email-masked] <mailto:[email-masked]>>;
>             <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>; The IESG
>             <[email-masked] <mailto:[email-masked]>>; BESS <[email-masked]
>             <mailto:[email-masked]>>
>             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
>             <[email-masked] <mailto:[email-masked]>>
>             wrote:
> 
>                 Robert,
> 
>                 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 <[email-masked]
>                 <mailto:[email-masked]>> *On Behalf Of *Robert Raszuk
>                 *To:* Warren Kumari <[email-masked]
>                 <mailto:[email-masked]>>
>                 *Cc:* Bocci, Matthew (Nokia - GB)
>                 <[email-masked]
>                 <mailto:[email-masked]>>;
>                 <mailto:[email-masked]>;
>                 [email-masked] <mailto:[email-masked]>; The
>                 IESG <[email-masked] <mailto:[email-masked]>>; BESS
>                 <[email-masked] <mailto:[email-masked]>>
>                 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:
> 
>                 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 +
>                 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 <[email-masked] <mailto:[email-masked]>>
>                 wrote:
> 
>                     <https://www.ietf.org/blog/handling-iesg-ballot-positions>
>                     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services>
> 
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Feb 2022 11:11:45 -0500

I would have to dig for it, but there is general guidance that nodes 
should not decapsulate IP tunnels that they don't know about.  (There 
are exceptions, such as LISP.  But neither GRE nor MPLS in UDP have such 
exceptions.)  Conceptually, SRv6 introduces a generic exception for SRv6 
SIDs within the limited domain.  But still says to check that the packet 
you are receiving at least claims to be from within the limited domain.

This has nothing to do with sr-policy.

Yours,
Joel

On 2/17/2022 11:06 AM, Robert Raszuk wrote:
> Joel,
> 
> But we are back to per src policy then right ?
> 
> Frankly I never saw such a policy on egress PEs and I did see L3VPNs or 
> L2VPNs running over IP. The protection is applied on ingress you your 
> domain.
> 
> Thx,
> R.
> 
> 
> On Thu, Feb 17, 2022 at 5:03 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > *From:*Robert Raszuk [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      > *To:* Warren Kumari <[email-masked] <mailto:[email-masked]>>
>      > *Cc:* Ketan Talaulikar <[email-masked]
>     <mailto:[email-masked]>>; Andrew - IETF
>      > I am very sorry but I see folks are completely mixing transport
>     layer
>      > and service layer.
>      >
>      > On Thu, Feb 17, 2022 at 4:14 PM Warren Kumari <[email-masked]
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >         Hi Warren/All,
>      >
>      >         I hope that clarifies and we can update the text to
>     convey these
>      >         aspects better.
>      >
>      >         Thanks,
>      >
>      >         Ketan
>      >
>      >         <[email-masked] <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >             Hi Robert,
>      >
>      >                 The extensions defined in this document may be
>     used as
>      >             discussed in
>      >
>      >                 [RFC5565
>      >             <https://datatracker.ietf.org/doc/html/rfc5565
>     <https://datatracker.ietf.org/doc/html/rfc5565>>] for the
>      >             <https://datatracker.ietf.org/doc/html/rfc4925
>     <https://datatracker.ietf.org/doc/html/rfc4925>>]) advertise
>      >                 *  Capability Value containing <NLRI AFI=1, NLRI
>     SAFI=1,
>      >             Nexthop
>      >
>      >                    AFI=2>
>      >
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>; Bocci, Matthew (Nokia - GB)
>      >             <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>;
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>;
>      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; The IESG
>      >             <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; BESS <[email-masked]
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>>
>      >             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.
>      >
>      >                    functionality provided by an MPLS Label when
>     received
>      >             with a Layer
>      >                    [RFC9136].  Some SRv6 Endpoint behaviors which
>     MAY be
>      >             encoded, but
>      >                    functionality provided by an MPLS Label1 for
>     Ethernet
>      >             VPN (EVPN)
>      >                 When an egress PE is enabled for BGP Services
>     over SRv6
>      >             data-plane,
>      >                 TLV(s) within the BGP Prefix-SID Attribute
>     attached to
>      >             MP-BGP NLRIs
>      >                 [RFC9136] where applicable as described in
>     Section 5 and
>      >             Section 6.
>      >
>      >             <[email-masked]
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >             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.3 – According to RFC8950 – allows advertisement
>     over
>      >                 SAFI 1, 2 or 4
>      >
>     <mailto:[email-masked]>
>      >                 <mailto:[email-masked]
>     <mailto:[email-masked]>>> *On Behalf Of *Robert Raszuk
>     <mailto:[email-masked]>
>      >                 <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >                 <mailto:[email-masked]
>     <mailto:[email-masked]>>>;
>     <mailto:[email-masked]>
>      >                 <mailto:[email-masked]
>     <mailto:[email-masked]>>;
>      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; The
>      >                 IESG <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; BESS
>      >                 <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >                 > 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.
>      >
>      >                 Datatracker <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >                 wrote:
>      >
>      >                     When responding, please keep the subject line
>     intact
>      >                     and reply to all
>     <https://www.ietf.org/blog/handling-iesg-ballot-positions/>
>      >                   
>       <https://www.ietf.org/blog/handling-iesg-ballot-positions
>     <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/>
>      >                   
>       <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services
>     <https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services>>
>      >
>      >
>      >
>      >                   
>      >                     using SRv6 SIDs advertised via BGP are
>     expected to
>      >                     be limited within the
>      >                     service information (including associated
>     SRv6 SID)
>      >                     advertised via BGP sessions
>      >                     are limited to peers within this trusted SR
>     domain."
>      >                     This is related to (from
>      >                     injection, this does not cover the case of
>     internal
>      >                     compromise. Sure, there is
>      >                     into a VPN. This seems to me to significantly
>     expand
>      >                     the attack surface to
>      >                     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
>      >                     not really cover it. In addition, it seems
>     that the
>      >                     blast radius from a missing
>      >                     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
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/bess>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Feb 2022 17:18:13 +0100

Joel,

There was a lot of effort by various vendors put in place to help automate
protection of the domain from getting any external packet to the
infrastructure addresses.

Typically I have seen two models in SPs:

* automatic ACL protection at the data plane for all infra targets
(sometimes with exceptions of ICMP)

* putting Internet into a VPN itself hence limiting to what comes from
Internet stays in the special VPN dedicated for it.

I have not seen much individual protection done at the L2 or L3 VPNs PEs to
selectively decapsulate. But it could be done too.

However all of this is about transport layer, while this draft is mainly
about service layer so to me this is out of topic if you see the layer
decoupling.

BESS :),
Robert.

On Thu, Feb 17, 2022 at 5:11 PM Joel M. Halpern <[email-masked]> wrote:

> >      > *To:* Warren Kumari <[email-masked] <mailto:[email-masked]
> >>