Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

>On the basis that detection-mitigation adds an attribute to 
>every route (potentially per AS hop), whereas bgp-open 
>keeps it to the neighbor relationship.  
>One attribute per route * 600k routes * N hops seems like a lot 
>if I can do the same thing with an open message.  

Perhaps you have realized by now (based on the discussion on the list) 
that the bgp-open draft also adds one OTC flag per route (or prefix).
(Yep, on the wire there is one flag per route in the bgp-open draft also.)

The SIDR, IDR, and GROW WGs have been working on it for 
the past four years or so. See this post from 2012:
https://www.ietf.org/mail-archive/web/sidr/current/msg04263.html  
which summarized some of the requirements/design principles that were 
discussed at the time in the WG meetings. Note that in particular it says:
"the relationship has to be per prefix not per link, as prefixes with
    different business models are often sent over the same link."

Several people in this thread also have tried to convey the above 
design principle (i.e. RLP flag per route). Also see the discussion 
in Section 5.3 of [route-leak-detection-mitigation].   

>I'm also concerned about how much I should trust the RLP bit 
>from an AS a few hops away.  Getting it from my directly connected 
>neighbor is one thing, but if I can trust the source to do the right thing 
>with the RLP bit, why can't I just assume they won't leak 
>YouTube-ish things to begin with?

It is not the source, but the AS that is two hops from you
-- it is important to know what they asserted in the update.
(Keyur also highlighted this earlier in this thread.)
Let us say AS X is a multi-homed customer of AS A and AS B:
AS A ---> AS X ---> AS B   (path of the update propagation)
(assume that RLP flag per AS-hop is in use)
AS X receives a route from its provider AS A, 
and accidentally leaks it to provider AS B.
AS X is not participating in RLP (does not set its own RLP flag),
but it passes on the RLP flag set by of AS A to AS B because
the RLP attribute is transitive. Then AS B is able to detect the leak...
because AS B knows that the AS two hops away (AS A) asserted that
it is sending the update to a customer (or a lateral peer) by
setting its (i.e. AS A's) own RLP = 1.

So there is need to know the RLP flag value set by the ASes 
before your immediate neighbor. Your immediate neighbor (AS X) is 
the leaker (the offender) -- in this instance. 
So you do not want to rely on their RLP flag as much 
(for detection of route leaks). 
Also, you have knowledge about your peering relationship with them.  

Down the road, the intention is to secure the RLP attribute so that
no AS can change the RLP flag set by another AS in the path.
In the above example, if AS X were maliciously trying to leak the
route by changing the RLP flag of AS A, then it (AS X) would be prevented
from doing so if there is cryptographic protection of the RLP attribute
(e.g. by using the BGPsec protocol path signatures; see Section 3.1.2). 

The end goal of this effort has been to provide 
*secure* route leak protection (progressing via IDR-->SIDR).
(I.e. provide a solution for both accidental and malicious route leaks.)
Then it becomes necessary that each AS must set its RLP attribute 
individually (RLP per AS-hop) and be secured.

>I didn't see a discussion of scale anywhere in detection-mitigation.  
>This seems like such an obvious scale difference to me that I worry that 
>"hard to say that one proposal is more heavy weight than 
>the other in principle" means I'm missing something.  
>Feel free to enlighten me as needed.

The BGP RLP attribute is sown in Section 3.1.1 of 
[route-leak-detection-mitigation]. It consists of {ASN, RLP flag} tuples. 
The parsing/processing load associated with the BGP RLP attribute 
is not much different from processing the AS_PATH attribute.
May be it is simpler than the AS_PATH processing where you have to 
take into account the prepends, AS_SETs, CONFED_SETs, loop detection etc.
If you want to consider another per-AS-hop thing to compare with ....
We have done and reported elsewhere about BGPsec validation processing 
which involves verifying one path signature per prefix and per AS-hop. 
That has been implemented and does not seem daunting.
Just some preliminary thoughts trying to address your concerns.

Sriram