Home page logo
/

nanog logo nanog mailing list archives

Re: do not filter your customers
From: Shane Amante <shane () castlepoint net>
Date: Fri, 24 Feb 2012 23:07:04 -0700

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.  :-)

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]