do not filter your customers

Sat Feb 25 06:07:04 UTC 2012

Nick,

On Feb 24, 2012, at 4:16 PM, Nick Hilliard wrote:
> On 24/02/2012 20:04, Shane Amante wrote:
>> Solving for route leaks is /the/ "killer app" for BGPSEC.  I can't
>> understand why people keep ignoring this.
> 
> I'd be interested to hear your opinions on exactly how rpki in its current
> implementation would have prevented the optus/telstra problem.  Could you
> elaborate?

I apologize if I mislead you, but I did not claim that the RPKI, in its current ROA implementation, *would* have prevented this specific route leak related to Optus/Telstra.  OTOH, I would completely agree with Geoff's comment that the policy language of RPSL has the ability to express routing _policy_, a.k.a. "intent", recursively across multiple ASN's ... (please note that I'm specifically talking about the technical capability of the policy language of RPSL, not the actual _data_ contained in the IRR).

Or, to put it a different way, the reachability information carried in BGP is the end-result/output of policy.  One needs to understand the *input*, a.k.a.: the policy/intent, if they are to validate the output, namely the reachability information carried in BGP.  Unfortunately, denying this reality is not going to make it "go away".

> Here's a quote from draft-ietf-sidr-origin-ops:
> 
>>   As the BGP origin AS of an update is not signed, origin validation is
>>   open to malicious spoofing.  Therefore, RPKI-based origin validation
>>   is designed to deal only with inadvertent mis-advertisement.
>> 
>>   Origin validation does not address the problem of AS-Path validation.
>>   Therefore paths are open to manipulation, either malicious or
>>   accidental.
> 
> An optus/telstra style problem might have been mitigated by an rpki based
> full path validation mechanism, but we don't have path validation.  Right
> now, we only have a draft of a list of must-have features -
> draft-ietf-sidr-bgpsec-reqs.  This is only the first step towards designing
> a functional protocol, not to mind having running code.

As one example, those "must-have features" have not, yet[1], accounted for the various "kinky" things we all do to manipulate the AS_PATH in the wild, for lots of very important business reasons, namely: ASN consolidation through knobs like "local-as alias" in JUNOS-land and "local-as no-prepend replace-as" in IOS-land, which have existed in shipping code for several years and are in active, widespread use and will continue to remain so[2].  Furthermore, given the current design proposal on the table of a BGPSEC transmitter forward-signing the "Target AS", as learned from a receiver in the BGP OPEN message, this could make it impossible to do ASN consolidation in the future, (unless I'm misunderstanding something).

-shane

[1] I have asked at the the last SIDR WG meeting in Taipei specifically for this to be accounted for, but I don't see this in the current rev of the draft you cite. Perhaps others should chime in on the SIDR WG mailing list if they are aware of the use of ASN-consolidation knobs and consider them a critical factor to consider during the design process, particularly so they are looked at during the earliest stages of the design.
[2] I haven't heard of any vendors stating that they are intending to EOL or not support those features any more, but it would be amusing to see the reaction they would get if they tried.  :-)