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

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

(Cc'ing sidr list also since there is interest there too in this topic.)

>> If A's customer C does not want A to propagate, then C has a choice not to send
>> the prefix-route to A in the first place.
>> Given that choice, why would C instead choose to poison or downgrade by altering RLP bits?

>Q: why do people poison routes by jamming in to the aspath ASN which
>they want to ignore their prefix/announcement?
>A: because knob.

Section 5.1 in the route leaks solution draft already discusses possible abuse 
of the knob (without security / bgpsec).
Randy and I were trying to come up with more examples (besides what is in Sec. 5.1).
I will include Randy's additional example (that we have discussed here) also in Section 5.1. 
But, IMHO, so far none of these abuses seems egregious.
So the benefit seems to outweigh the 'new attack vector' disadvantage. Explained further below.

Even with ROA origin validation, there is the fake-origin-AS attack vector (without bgpsec),
but we recognize that ROA origin validation stops all accidental mis-originations. So it is worth it.  
The determined attacker may still use fake-origin-AS attack; 
but that would be mitigated by bgpsec (when it is deployed). 
 
Likewise, the evolution path for route leaks solution could be as follows:

Current BGP (without route leak solution; assuming prefix /AS path filters aren’t doing job adequately)

--- Vulnerable to accidental and malicious route leaks

--- Let us say 99% are accidental and 1% malicious (you can substitute your numbers)
  
  |
  |
  \/

BGP with proposed route leak solution (without bgpsec)

--- Detects/mitigates the 99% but not the 1%

  |
  |
  \/
  
Proposed route leak solution with bgpsec
       
--- Detects/mitigates the 99% as well as the 1%

Sriram