Re: [sidr] [Idr] Route Leaks and solutions

["Sriram, Kotikalapudi" <[e-mail]>]

>If the RLP bit is dependent upon ops folks getting the right
>config-bit set for each customer we would want that to be as much
>automated as possible so there would be the least chance for 'forgot
>to set the bit' or 'set bit incorrectly'.

Some sort of mapping of a prefix-route to eBGP neighbors to who it will be sent to, 
namely, customers, peers, providers, isn’t that done already in a routers currently?

>I'm worried that I can't tell reliably what the bit was 2 as-hops
>away, did they mean 'customer' ? or was that a mistake? Did someone
>change it mid-path to me? Did the implementation of their vendor gear
>change/set the wrong attribute value?

Initially, only the big ISPs have to get it right (setting the RLP bits). 
That itself would help reap the benefit substantially.
Basically, then one big ISP’s prefix-routes sent to its customer cannot make  
a U-turn (route leak) somewhere in its customer cone and be accepted by another big ISP,
even if the ASes in between are not doing it (or they make mistakes with their 
RLP bits) as long as they do not change any preceding ASs' RLP fields.    

>There seem to be a bunch of uncertainties with this, in my mind. I
>guess that with bgpsec signing this attribute at least 'joe really
>meant that jim was his customer', and you can't change the value on a
>bgpsec path.
>
>If we want that, I think having the attribute where it can get changed
>(not-bgpsec secured paths) is a real problem, or opens up some pretty
>large problems...

Like I said in my talk in GROW yesterday, without bgpsec (RLP bits secured), 
the 99% accidental leaks are detected/mitigated but not the 1% malicious.  
With bgpsec (RLP bits secured), the 1% malicious are also detected/mitigated.  
See slide 5:
https://www.ietf.org/proceedings/93/slides/slides-93-grow-4.pdf 

Prior to bgpsec protection, there are two types of attacks that
are possible on unprotected RLP bits:

1. Upgrade attack (RLP = 01 is altered to RLP = 00) to avoid route-leak detection. 
That falls in the 1% malicious category (undetected) but no other 
more egregious damage occurs as a result of this upgrade attack.
See more discussion of this in Section 5.1. of the draft:
https://www.ietf.org/id/draft-sriram-idr-route-leak-detection-mitigation-01.txt 

2. Downgrade attack: (RLP = 00 is altered to RLP = 01) 
This does not matter in the 'down' direction because RLP =01 
always allows propagation of the prefix-route in 'down' direction.
So this attack (RLP = 00 --> RLP = 01) matters only when update propagates 
in the up or lateral peer direction.
That would only mean that an alternate update that is not labeled a route leak 
would be preferred by the (provider or peer) over this one.
And if there is no alternate update, then for reachability,
the only prefix-route that seems like a leak might still be accepted.
But this is left up to operator policy.       

Sriram