mailing list archives
Re: do not filter your customers
From: Shane Amante <shane () castlepoint net>
Date: Fri, 24 Feb 2012 23:07:04 -0700
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
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
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, 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. 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
 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.
 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. :-)