Re: Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

Robert,

comments inlined #Keyur

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

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 protected]<mailto:[email protected]>> 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..).

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 protected]<mailto:[email protected]>> on behalf of "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Date: Thursday, October 17, 2019 at 6:32 AM
To: Ondrej Zajicek <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Linda Dunbar <[email protected]<mailto:[email protected]>>, Srihari Sangli <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]>> wrote:
On Thu, Oct 17, 2019 at 10:25:13AM +0200, Robert Raszuk wrote:
> 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 ?

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 protected]<mailto:[email protected]>)

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr