Subject: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

From: Linda Dunbar <[email-masked]>
Date: Wed, 9 Oct 2019 20:25:57 +0000

Dear authors:
draft-ietf-idr-tunnel-encaps specifies the The Tunnel Encapsulation attribute as an optional transitive BGP Path
attribute, with code point 23.
Does it mean Tunnel Encapsulation Attribute is listed at the same level as MP_REACH_NLRI (Code Point 14) in the Path Attributes lists shown in the following captured packets from Wireshark? If a Destination address is already listed in the MP_RACH_NLRI, is it listed again in the Tunnel Encap subTLV (if it can be reached via some tunnel, such as VxLAN/GRE/?

Does the Tunnel Encapsulation Attributes have the same fields as MP_REACH_NLRI (RFC4760)?
Or the Tunnel Encapsulation Attributes is the "Network Layer Reachability Information" field of MP_REACH_NLRI?

Thank you very much,

Linda Dunbar

---

From: Srihari Sangli <[email-masked]>
Date: Thu, 17 Oct 2019 05:31:25 +0000

Linda,

I’m not sure if I understand your question completely. Pls see comments inline.

On 10/10/19, 1:56 AM Linda Dunbar from [email-masked]<mailto:[email-masked]> said >

Dear authors:

Yes, that’ right.

Does it mean Tunnel Encapsulation Attribute is listed at the same level as MP_REACH_NLRI (Code Point 14) in the Path Attributes lists shown in the following captured packets from Wireshark?

Like you mention, the Tunnel Encapsulation Attribute is a Path attribute, so it is a matter to displaying all the path attributes, one can display in the ascending order of the Code Points.

If a Destination address is already listed in the MP_RACH_NLRI, is it listed again in the Tunnel Encap subTLV (if it can be reached via some tunnel, such as VxLAN/GRE/?

I’m not clear what you mean here. The MP_REACH provides the reachability information while the Tunnel Encapsulation Attribute provides the Tunnel details (remote-endpoint, encapsulation, etc). The presence of Tunnel Encapsulation attribute in an update that carries MP_REACH attribute indicates the data path destined for prefixes encoded in the NLRI field of MP_REACH.

Thanks.

srihari…

Does the Tunnel Encapsulation Attributes have the same fields as MP_REACH_NLRI (RFC4760)?
Or the Tunnel Encapsulation Attributes is the “Network Layer Reachability Information” field of MP_REACH_NLRI?

Thank you very much,

Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Oct 2019 09:47:12 +0200

Hey Srihari,

> The presence of Tunnel Encapsulation attribute in an update that carries
MP_REACH
> attribute indicates the data path destined for prefixes encoded in the
NLRI field of MP_REACH.

My reading of Linda's point was a question regarding the case where for
prefix A NLRI points to
next hop NH_1 but tunnel endpoint says go to NH_2.

Is such update still valid ?

Has tunnel encapsulation attribute power to "overrule" BGP next hop from
MP_REACH ?

When BGP best path runs and validates NH_1 is basic next hop validation
also performed on
NH_2 before considering this path as valid ?

When BGP selects such path as best and installs it to RIB does it install
it with NH_1 or NH_2 ? Note that both next hops may be reachable via local
IGP or even going further could be recursive via yet more BGP routes.

Many thx,
Robert.

If a Destination address is already listed in the MP_RACH_NLRI, is it
> listed again in the Tunnel Encap subTLV (if it can be reached via some
> tunnel, such as VxLAN/GRE/?
>
>
>
> I’m not clear what you mean here. The MP_REACH provides the reachability
> information while the Tunnel Encapsulation Attribute provides the Tunnel
> details (remote-endpoint, encapsulation, etc). The presence of Tunnel
> Encapsulation attribute in an update that carries MP_REACH attribute
> indicates the data path destined for prefixes encoded in the NLRI field of
> MP_REACH.
>
>
>
> Thanks.
>
> srihari…
>

---

From: Srihari Sangli <[email-masked]>
Date: Thu, 17 Oct 2019 08:08:11 +0000

Hi Robert,

My reading of Linda's point was a question regarding the case where for prefix A NLRI points to
next hop NH_1 but tunnel endpoint says go to NH_2.

Has tunnel encapsulation attribute power to "overrule" BGP next hop from MP_REACH ?

The draft in Section 5 explains this. If the update has a valid Tunnel Encapsulation attribute and if any of the tunnel(s) is considered to be feasible, then it MUST use the tunnel. That means in your example, such an update is valid and NH_2 should be used.

Hope this helps. Thanks.

srihari…

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Oct 2019 10:25:13 +0200

Srihari,

Can you comment on the expected BGP next hop validation behaviour ?

Can you also comment on the next hop BGP is installing the prefixes to RIB
with ?

Is tunnel endpoint now the NH BGP is asking RIB to track ?

None of those seems to be described in section 5 of the draft. How do you
even know on sender side that all remote BGP speakers will honor tunnel
encapsulation attribute and will actually use end-point from its mandatory
TLV instead of NLRI next hop ?

Linda,

Perhaps for your use case much cleaner solution would be to just
use Encapsulation Extended Community as defined in RFC 5512 section 4.5
instead of tunnel attribute ?

Thx,
R.

On Thu, Oct 17, 2019 at 10:08 AM Srihari Sangli <[email-masked]> wrote:

> The draft in Section 5 explains this. If the update has a valid Tunnel
> Encapsulation attribute and if any of the tunnel(s) is considered to be
> feasible, then it MUST use the tunnel. That means in your example, such an
> update is valid and NH_2 should be used.
>
>
>
> Hope this helps. Thanks.
>
>
>
> srihari…
>
>
>
>
>
>

---

From: Ondrej Zajicek <[email-masked]>
Date: Thu, 17 Oct 2019 11:33:08 +0200

> Is tunnel endpoint now the NH BGP is asking RIB to track ?

My impression of the draft is that handling of BGP NH and address from
Tunnel Encap attribute is different. BGP NH is tracked in RIB and
recursivery resolved, could be used to daisy-chain encapsulation in RIB
(section 7). In contrast, the address from the Tunnel attribute is just
passed to FIB as encapsulation action argument.

But it is true that this part of the draft is a bit blurry and would
definitely need more clear wording.

-- 
Ondrej 'Santiago' Zajicek (email: [email-masked])

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Oct 2019 06:30:54 -0400

Well indeed the draft is very underspecified in this space.

The fun starts when next hop from NLRI is unreachable while tunnel end
point is. Does it mean that given path is not going to be considered for
best path selection ?

And we can go further ... say bgp uses selective next hops and is set to
only consider /24 and higher and NH from NLRI does not meet those criteria
... but tunnel endpoint is reachable over default route - what happens then
?

See what strikes me the most is the mandatory nature of endpoint TLV and no
good description of various cases when NH in NLRI != Tunnel endpoint
address. If there are equal tunnel endpoint may be optional.

Thx,
R.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 17 Oct 2019 23:06:45 +0000

One of the things that is strikingly problematic in allowing BGP NH and Tunnel Endpoint to be different is that it could be used as an attack vector (node A advertises a route with NH =A & tunnel endpoint = node B, so node B gets bombarded with unwanted traffic (in fact, node B may not even have any BGP, or not have a particular BGP route, or..).

This would be a big red flag for many of us.

--
Cheers,
Rajiv

PS: Now, what if node A uses two IPv6 addresses – one as the NH, and the other as the tunnel endpoint. That’s a legit case, one could argue.

From: Idr <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Thursday, October 17, 2019 at 6:32 AM
To: Ondrej Zajicek <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Linda Dunbar <[email-masked]>, Srihari Sangli <ssangli=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

Well indeed the draft is very underspecified in this space..

The fun starts when next hop from NLRI is unreachable while tunnel end point is. Does it mean that given path is not going to be considered for best path selection ?

And we can go further ... say bgp uses selective next hops and is set to only consider /24 and higher and NH from NLRI does not meet those criteria ... but tunnel endpoint is reachable over default route - what happens then ?

See what strikes me the most is the mandatory nature of endpoint TLV and no good description of various cases when NH in NLRI != Tunnel endpoint address. If there are equal tunnel endpoint may be optional.

Thx,
R.

On Thu, Oct 17, 2019 at 5:33 AM Ondrej Zajicek <[email-masked]<mailto:[email-masked]>> wrote:

--
Ondrej 'Santiago' Zajicek (email: [email-masked]<mailto:[email-masked]>)

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Oct 2019 01:22:25 +0200

Great point Rajiv !

Security consideration section lightly suggests to use BGP Origin
Validation or even BGPSEC... well great !

But it does not define any behaviour when result of BGP Origin validation
against tunnel attribute will now be different from results when compared
against NLRI validation.

What do we do then ?

Not only this breaks all current show commands and accept/reject policies
being applied to NLRI Origin Validation, but also reopens all
implementations how Origin Validation works and how do we mark validated
routes.

- - - -

So for all proponents of Tunnel Encapsulation Attribute - I would like to
post a single question:

Why don't we use basic BGP recursion (in any AFI/SAFI required) and simply
advertise within each applicable SAFI an NLRI = NH of endpoint/customer
routes with NH = Tunnel Endpoint while attaching to such
UPDATE  Encapsulation Extended Community indicating type of tunnels and
parameters required ?

What use cases would not be addressed by doing just that ?

Thx,
R.

On Fri, Oct 18, 2019 at 1:06 AM Rajiv Asati (rajiva) <[email-masked]>
wrote:

>
>
> One of the things that is strikingly problematic in allowing BGP NH and
> Tunnel Endpoint to be different is that it could be used as an attack
> vector (node A advertises a route with NH =A & tunnel endpoint = node B, so
> node B gets bombarded with unwanted traffic (in fact, node B may not even
> have any BGP, or not have a particular BGP route, or..).
>
>
>
> PS: Now, what if node A uses two IPv6 addresses – one as the NH, and the
> other as the tunnel endpoint. That’s a legit case, one could argue.
>
>
>
>
>
> *From: *Idr <[email-masked]> on behalf of "[email-masked]" <
> [email-masked]>
> *Date: *Thursday, October 17, 2019 at 6:32 AM
> *To: *Ondrej Zajicek <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Linda Dunbar <
> [email-masked]>, Srihari Sangli <ssangli=
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Idr] Can one Destination Address appear in both Tunnel
> Encap Attribute and in MP_REACH_NLRI ?
>
>
>
> See what strikes me the most is the mandatory nature of endpoint TLV and
> no good description of various cases when NH in NLRI != Tunnel endpoint

---

From: Keyur Patel <[email-masked]>
Date: Fri, 18 Oct 2019 00:30:27 +0000

Hi Rajiv,

Section 13 paragraph 5th states about performing origin validation on IP Address of Tunnel Endpoint to help avoid attack vectors your describing (in an event where the tunnel endpoint address is different than a nexthop across inter-as.

<snip>
Before sending a packet through the tunnel identified in a particular
   TLV of a Tunnel Encapsulation attribute, it may be advisable to use
   BGP Origin Validation to obtain the following additional assurances:

   o  the origin AS of the route carrying the Tunnel Encapsulation
      attribute is correct;

   o  the origin AS of the route to the IP address specified in the
      Tunnel Endpoint sub-TLV is correct, and is the same AS that is
      specified in the Tunnel Endpoint sub-TLV.
</snip>

Regards,
Keyur

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thursday, October 17, 2019 at 4:07 PM
To: Robert Raszuk <[email-masked]>, Ondrej Zajicek <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Linda Dunbar <[email-masked]>, Srihari Sangli <ssangli=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

--
Cheers,
Rajiv

Thx,
R.

---

From: Keyur Patel <[email-masked]>
Date: Fri, 18 Oct 2019 00:43:00 +0000

Robert,

comments inlined #Keyur

From: Robert Raszuk <[email-masked]>
Date: Thursday, October 17, 2019 at 4:22 PM
To: "Rajiv Asati (rajiva)" <[email-masked]>
Cc: Ondrej Zajicek <[email-masked]>, "[email-masked]" <[email-masked]>, Linda Dunbar <[email-masked]>, Srihari Sangli <ssangli=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, October 17, 2019 at 4:22 PM

Great point Rajiv !

Security consideration section lightly suggests to use BGP Origin Validation or even BGPSEC... well great !

But it does not define any behaviour when result of BGP Origin validation against tunnel attribute will now be different from results when compared against NLRI validation.

What do we do then ?

Not only this breaks all current show commands and accept/reject policies being applied to NLRI Origin Validation, but also reopens all implementations how Origin Validation works and how do we mark validated routes.

#Keyur: I believe you mean “show commands and accept/reject policies that are tunnel based needs to be augmented”. 😊
- - - -

So for all proponents of Tunnel Encapsulation Attribute - I would like to post a single question:

Why don't we use basic BGP recursion (in any AFI/SAFI required) and simply advertise within each applicable SAFI an NLRI = NH of endpoint/customer routes with NH = Tunnel Endpoint while attaching to such UPDATE  Encapsulation Extended Community indicating type of tunnels and parameters required ?

#Keyur: You can still announce the tunnel endpoint (underlay) route using tunnel endpoint attribute. The attribute gives you a common placeholder to carry tunnel parameters (including endpoint) and specifically as and when parameters grow beyond size of community/ext community/large community.
Regards,
Keyur

Thx,
R.

On Fri, Oct 18, 2019 at 1:06 AM Rajiv Asati (rajiva) <[email-masked]<mailto:[email-masked]>> wrote:

--
Cheers,
Rajiv

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 17, 2019 at 6:32 AM
To: Ondrej Zajicek <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Linda Dunbar <[email-masked]<mailto:[email-masked]>>, Srihari Sangli <ssangli=[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Oct 2019 11:00:33 +0200

Hey Keyur,

> #Keyur: You can still announce the tunnel endpoint (underlay) route using
> tunnel endpoint attribute. The attribute gives you a common placeholder to
> carry tunnel parameters (including endpoint) and specifically as and when
> parameters grow beyond size of community/ext community/large community.
>

Size is a fair point .. while type of the encap will easily fit in
communities some other associated info may not.

But in the case I described there is no need to put tunnel endpoint address
in the tunnel attribute. How about you update the draft and make tunnel
endpoint address TLV optional - and if not present next hop is used as
tunnel endpoint ?

Of course most if not all of other observations still apply :)  And the
point here is that to get consistent implementations draft should add
perhaps even a new paragraph on how to handle difference in next hop
validation vs tunnel endpoint validation. Is in the case of presence of
reachable (or poor man's check existing in the RIB) tunnel endpoint address
BGP next hop validation and tracking still making sense ? Then how to
address similar "collisions" with Origin Validation results ?

Thx,
r.

---

From: Keyur Patel <[email-masked]>
Date: Fri, 18 Oct 2019 16:03:42 +0000

Robert,

Comments inlined #Keyur1

From: Robert Raszuk <[email-masked]>
Date: Friday, October 18, 2019 at 2:00 AM
To: Keyur Patel <[email-masked]>
Cc: "Rajiv Asati (rajiva)" <[email-masked]>, Ondrej Zajicek <[email-masked]>, "[email-masked]" <[email-masked]>, Linda Dunbar <[email-masked]>, Srihari Sangli <ssangli=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

Hey Keyur,

Size is a fair point .. while type of the encap will easily fit in communities some other associated info may not.

But in the case I described there is no need to put tunnel endpoint address in the tunnel attribute. How about you update the draft and make tunnel endpoint address TLV optional - and if not present next hop is used as tunnel endpoint ?

#Keyur1:  This has been debated before afair. You don’t want different encapsulations to be handled in different ways. There is benefit in having them within a common placeholder (which is actually cheap and further solves any interdependencies if mandated).

Of course most if not all of other observations still apply :)  And the point here is that to get consistent implementations draft should add perhaps even a new paragraph on how to handle difference in next hop validation vs tunnel endpoint validation.

#Keyur1: Please note that the implementations are already there in various forms.

Is in the case of presence of reachable (or poor man's check existing in the RIB) tunnel endpoint address BGP next hop validation and tracking still making sense ?

#Keyur1: Agree. Then again section 5 does refer to reachability aspects of the tunnel endpoint. IMHO, the specifics of tracking of tunnel ip address is an implementation detail.

Then how to address similar "collisions" with Origin Validation results ?

#Keyur1: Collisions of origin validation result is usually a matter of network specific policies mandated by operators (They may permit or may deny making a specific tunnel ineligible).

Regards,
Keyur

Thx,
r.

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 22 Oct 2019 20:25:49 +0000

Srihari and Robert,

Thank you very much for the discussion.

Your explanation indicates that the tunnel information described in Tunnel Path Attributes are applicable to all the NLRI listed in the MP-NLRI Path Attributes, correct?
For example, D1/D2/D3/D4 all have R2 as Next Hop, and R2 supports GRE and VxLAN.  The Update from R2 will have D1, D2, D3, D4 listed in the MP-NLRI (code= 14), and GRE tunnel & VxLAN tunnel listed under the Tunnel Attribute (code = 23).

When R1 receives the UPDATE from R2, R1 can assume that packets to D1, D2, D3, D4 can use either VxLAN or GRE. Is it correct?

So if R2 needs to specifically indicate GRE for D1, VxLAN for D2, D3, and IPinIP for D4, then R2 needs to send 3 separate UPDATE messages. Is it correct?

Thank you very much.

From: Srihari Sangli <[email-masked]>
Sent: Thursday, October 17, 2019 3:08 AM
To: Robert Raszuk <[email-masked]>; Srihari Sangli <ssangli=[email-masked]>
Cc: Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

Hi Robert,

Hope this helps. Thanks.

srihari…

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Oct 2019 22:15:09 -0400

Hi Linda,

Yes your interpretation is correct.

Thx
R.

On Tue, Oct 22, 2019, 16:25 Linda Dunbar <[email-masked]> wrote:

> Your explanation indicates that the tunnel information described in Tunnel
> Path Attributes are applicable to all the NLRI listed in the MP-NLRI Path
> Attributes, correct?
>
> For example, D1/D2/D3/D4 all have R2 as Next Hop, and R2 supports GRE and
> VxLAN.  The Update from R2 will have D1, D2, D3, D4 listed in the MP-NLRI
> (code= 14), and GRE tunnel & VxLAN tunnel listed under the Tunnel Attribute
> (code = 23).
>
>
>
> When R1 receives the UPDATE from R2, R1 can assume that packets to D1, D2,
> D3, D4 can use either VxLAN or GRE. Is it correct?
>
>
>
> So if R2 needs to specifically indicate GRE for D1, VxLAN for D2, D3, and
> IPinIP for D4, then R2 needs to send 3 separate UPDATE messages. Is it
> correct?
>
>
>
> Thank you very much.
>
>
>
>
>
>
>
> *From:* Srihari Sangli <[email-masked]>
> *Sent:* Thursday, October 17, 2019 3:08 AM
> *To:* Robert Raszuk <[email-masked]>; Srihari Sangli <ssangli=
> [email-masked]>
> *Cc:* Linda Dunbar <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [Idr] Can one Destination Address appear in both Tunnel