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

[Gyan Mishra]

Hi Robert

On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk  wrote:

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

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

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

   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*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Gyan Mishra]

Hi Andrew

On Sat, Feb 12, 2022 at 9:41 PM Gyan Mishra  wrote:

> Hi Andrew,
>
> On Sat, Feb 12, 2022 at 5:13 PM Andrew - IETF 
> 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:
>>
>> 
>>
>>
>>
>>  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 sour

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

[Gyan Mishra]

Hi Andrew,

On Sat, Feb 12, 2022 at 5:13 PM Andrew - IETF 
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:
>
> 
>
>
>
>  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> 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

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

[Andrew - IETF]

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:


 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 mailto:hayabusa...@gmail.com>>
Sent: Saturday, February 12, 2022 10:18 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Andrew - IETF mailto:andrew-i...@liquid.tech>>; 
BESS mailto:bess@ietf.org>>; Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>; The IESG 
mailto:i...@ietf.org>>; Warren Kumari 
mailto:war...@kumari.net>>; 
bess-cha...@ietf.org; 
draft-ietf-bess-srv6-servi...@ietf.org
Subject: Re: [bess] Warren Kuma

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

[Gyan Mishra]

Hi Andrew

Responses in-line

On Sat, Feb 12, 2022 at 2:42 PM Andrew - IETF 
wrote:

> 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:
>
>  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.
>
>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:
>
>  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.
>
>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.
>
> 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 
> *Sent:* Saturday, February 12, 2022 10:18 PM
> *To:* Robert Raszuk 
> *Cc:* Andrew - IETF ; BESS ;
> Bocci, Matthew (Nokia - GB) ; The IESG <
> i...@ietf.org>; Warren Kumari ; bess-cha...@ietf.org;
> draft-ietf-bess-srv6-servi...@ietf.org
> *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.
>

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

[Robert Raszuk]

Gyan,

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

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.

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

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.

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

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.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Andrew - IETF]

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 
Sent: Saturday, February 12, 2022 10:18 PM
To: Robert Raszuk 
Cc: Andrew - IETF ; BESS ; Bocci, 
Matthew (Nokia - GB) ; The IESG ; 
Warren Kumari ; bess-cha...@ietf.org; 
draft-ietf-bess-srv6-servi...@ietf.org
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] 
[RFC4659] 
[RFC8950] 
[RFC7432] 
[RFC4364]

   [RFC9136] where applicable as 
described in Section 
5
 and 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 
mailto:rob...@raszuk.net>> 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

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

[Gyan Mishra]

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
] [RFC4659
] [RFC8950
] [RFC7432
] [RFC4364
]
   [RFC9136 ] where
applicable as described in Section 5

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

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

[Andrew - IETF]

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] for the 
interconnection of IPv4 islands over an IPv6

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

   as defined in [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 

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 
Sent: Saturday, February 12, 2022 9:37 PM
To: Andrew - IETF 
Cc: Warren Kumari ; Bocci, Matthew (Nokia - GB) 
; draft-ietf-bess-srv6-servi...@ietf.org; 
bess-cha...@ietf.org; The IESG ; BESS 
Subject: Re: Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with 
DISCUSS and COMMENT)

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 
mailto:andrew-i...@liquid.tech>> 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 mailto:iesg-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Saturday, February 12, 2022 8:26 PM
To: Warren Kumari mailto:war...@kumari.net>>
Cc: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>; 
draft-ietf-bess-srv6-servi...@ietf.org;
 bess-cha...@ietf.org; The IESG 
mailto:i...@ietf.org>>; BESS 
mailto:bess@ietf.org>>
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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Luc André Burdet]

Hi Anoop,
Thanks for your detailed review, I have posted -04 addressing these comments.

>>Timestamp Fractional Seconds (17 bits)
This threw me off for a bit...
>> Now that I double check, the figure is wrong!  It uses only 7 bits for the 
>> Type which looks like it should be 8 bits.  So it looks like Timestamp 
>> Fractional Seconds should be 16 bits.
...but you actually hit onto a critical misalignment in the figure !

I have moved the whole description section up into the encoding/extcomm as 
descriptive text of the fields themselves. Nice catch, thank you !

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: Anoop Ghanwani 
Date: Friday, February 4, 2022 at 12:50
To: Bocci, Matthew (Nokia - GB) 
Cc: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
, bess-cha...@ietf.org 
Subject: Re: [bess] WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
I support publication of the document as an RFC.  However, I think there are 
some editorial nits that need to be addressed (see below).

Anoop

==

Abstract

performed via a simple signaling between the recovered PE
   and each PEs in the multi-homing group.
->
performed via simple signaling between the recovered PE
   and each of the other PEs in the multi-homing group.


Multiple sections

multi-homing Ethernet Segment ->
multi-homed Ethernet Segment

Ethernet-Segment ->
Ethernet Segment

There are some instances of use of ES (section 3.2).  Either ES should be 
spelled out and used throughout or, which is what I would do, replace the 2 
instances of ES in Section 3.2 with Ethernet Segment.

It would also be good to provide captions for all figures since it makes it 
easy to reference.


Section 1

EVPN solution [RFC7432]
->
The EVPN specification [RFC7432]

and it is performed via a
   simple signaling between the recovered PE and each PE in the multi-
   homing group.
->
and it is performed via
   simple signaling between the recovered PE and each of the other PEs in the 
multi-
   homing group.



Section 2
The current state of art (Highest Random Weight)
->
The current state of art HRW (Highest Random Weight)

duplication of DF roles for a give VLAN is possible.
->
duplication of DF roles for a given VLAN is possible.


Section 3.1

   -  A simple uni-directional signaling is all needed
->
   -  A simple uni-directional signaling is all that is needed

-  (e.g .NTP, PTP, etc.)
->
-  (e.g. NTP, PTP, etc.)


Section 3.2
It would be good to explicitly explain the fields below the figure, e.g.
Timestamp Seconds (32 bits): ...
Timestamp Fractional Seconds (17 bits): ... (provide details on how this part 
is created)
If this is omitted because it is in some other doc, then provide a reference.

[Looks like the figure is wrong about length for Timestamp Fractional Seconds 
which is why it would help to have a description as above.]

PEs in the ES [there are 2 instances]
->
PEs attached to the Ethernet Segment

want the DF type be of HRW
->
want the DF type to be HRW

"The use
   of a 32-bit seconds and 16-bit fractional seconds yields adequate
   precision of 15 microseconds (2^-16 s)."
The figure shows 17 bits for fractional seconds.  Now that I double check, the 
figure is wrong!  It uses only 7 bits for the Type which looks like it should 
be 8 bits.  So it looks like Timestamp Fractional Seconds should be 16 bits.


Section 3.4

   -  PE2, it starts its 3sec peering timer as per RFC7432
->
   -  PE2, starts its 3 sec peering timer as per RFC7432

[RFC7432] aims of favouring traffic black hole over duplicate traffic
(Missing period at end of sentence.)

Spell out first use of NDF.

becomes a no-op
->
becomes a non-issue.

The usage of
   SCT approach remedies to the exposed problem with the usage of
   peering timer.  The 3 seconds timer window is shorthen to few
   milliseconds.
->
The usage of
   SCT approach remedies the problem with the usage of the
   peering timer.  The 3 second timer window is shortened to a few
   milliseconds.


Section 3.5

modulus based
->
modulo-based

running an baseline DF election
->
running a baseline DF election

shall simply discard unrecognized new SCT BGP extended community.
->
will simply disregard the new SCT BGP extended community.

"...all PEs in the Ethernet-Segment may revert back to the RFC7432 timer 
approach."
Is this a "may" or should it be a "must"?

On Mon, Jan 31, 2022 at 5:58 AM Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this document, please 
respond to this email a

[bess] I-D Action: draft-ietf-bess-evpn-fast-df-recovery-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Fast Recovery for EVPN Designated Forwarder Election
Authors : Patrice Brissette
  Ali Sajassi
  Luc Andre Burdet
  John Drake
  Jorge Rabadan
Filename: draft-ietf-bess-evpn-fast-df-recovery-04.txt
Pages   : 11
Date: 2022-02-12

Abstract:
   Ethernet Virtual Private Network (EVPN) solution provides Designated
   Forwarder election procedures for multihomed Ethernet Segments.
   These procedures have been enhanced further by applying Highest
   Random Weight (HRW) Algorithm for Designated Forwarded election in
   order to avoid unnecessary DF status changes upon a failure.  This
   draft improves these procedures by providing a fast Designated
   Forwarder (DF) election upon recovery of the failed link or node
   associated with the multihomed Ethernet Segment.  The solution is
   independent of number of EVIs associated with that Ethernet Segment
   and it is performed via a simple signaling between the recovered PE
   and each of the other PEs in the multihoming group.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-df-recovery-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-fast-df-recovery-04


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Robert Raszuk]

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 
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  *On Behalf Of * Robert Raszuk
> *Sent:* Saturday, February 12, 2022 8:26 PM
> *To:* Warren Kumari 
> *Cc:* Bocci, Matthew (Nokia - GB) ;
> draft-ietf-bess-srv6-servi...@ietf.org; bess-cha...@ietf.org; The IESG <
> i...@ietf.org>; BESS 
> *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 <
> nore...@ietf.org> 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 l

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

[Andrew - IETF]

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  On Behalf Of Robert Raszuk
Sent: Saturday, February 12, 2022 8:26 PM
To: Warren Kumari 
Cc: Bocci, Matthew (Nokia - GB) ; 
draft-ietf-bess-srv6-servi...@ietf.org; bess-cha...@ietf.org; The IESG 
; BESS 
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 
mailto:nore...@ietf.org>> 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 postur

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

[Robert Raszuk]

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 <
nore...@ietf.org> 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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess