[150477] in North American Network Operators' Group
Re: do not filter your customers
daemon@ATHENA.MIT.EDU (Nick Hilliard)
Fri Feb 24 18:18:54 2012
X-Envelope-To: nanog@nanog.org
Date: Fri, 24 Feb 2012 23:16:06 +0000
From: Nick Hilliard <nick@foobar.org>
To: Shane Amante <shane@castlepoint.net>
In-Reply-To: <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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?
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.
Nick
