|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Shane Amante <shane@castlepoint.net> In-Reply-To: <4F481A36.8090701@foobar.org> Date: Fri, 24 Feb 2012 23:07:04 -0700 To: Nick Hilliard <nick@foobar.org> Cc: North American Network Operators' Group <nanog@nanog.org> Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org 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. >=20 > 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: >=20 >> 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. >>=20 >> Origin validation does not address the problem of AS-Path = validation. >> Therefore paths are open to manipulation, either malicious or >> accidental. >=20 > 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. :-)=
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |