Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

[Christopher Morrow <[e-mail]>]

On Fri, Nov 22, 2013 at 2:43 PM, Geoff Huston <[e-mail]> wrote:
>
> On 23 Nov 2013, at 2:57 am, Christopher Morrow <[e-mail]> wrote:
>
>> On Fri, Nov 22, 2013 at 4:47 AM, Geoff Huston <[e-mail]> wrote:
>>>
>>> On 22 Nov 2013, at 3:43 pm, Christopher Morrow <[e-mail]> wrote:
>>>
>>>> On Thu, Nov 21, 2013 at 5:48 PM, Geoff Huston <[e-mail]> wrote:
>>>>> but in our haste to comply with the timelines dictated by DHS's project
>>>>> funding
>>>>> I guess we've got what DHS were prepared to pay for, and not what we
>>>>> actually
>>>>> wanted or need. And for many its an unsatisfactory outcome.
>>>>
>>>> just asking about one part here... so DHS aside, because i'm not sure
>>>> that who the funder is is relevant to the work, exactly...  what
>>>> options are there for securing more than the aspath?
>>>
>>>
>>> As I understand the draft correctly, the draft is saying even if you secure ASPATH
>>> along the lines proposed in secure BGP, there are still ways in which an attacker can
>>> inject a path that was not intended by the originator.
>>
>> inject a path... hrm, I'm not parsing that properly I bet.
>>
>> Did you mean prepend on random asns? (no, don't think so, not and stay
>> validated)
>> Did you mean pull a route down a customer link and pass it back up the
>> hill to the other transit? (sure, but that's known, right?)
>
>
> Chris, you have READ the draft I assume?

yes, describes a transit->customer->transit path, AS7007 like situation.

I was asking for clarification of what ways (aside from 'leak the
internet from one transit to another') one could inject a path.

>>
>>> So the question that the draft raises in my head is is it possible to communicate
>>> routing policies in a secure manner?
>>
>> so far this keeps coming up and keeps ending in a deathspiral of:
>>  "People don't want to share their byzantine routing policy stuff 'publicly'"
>>
>> or:
>>  "sure, you could make a global registry of routing policy... isn't
>> rpsl that? and it's working out how well so far?"
>>
>
> I hear different responses in other parts of the network, where communities have invested
> significant levels of effort in publishing routing policies and attempting to
> compute across them.
>

sure, but in aspac, emea, us, lacnic ... pretty much everywhere we
still see forms of not-valley-free networking by mistake happening. I
reckon we'll keep seeing that until there's a better way to
incentivize filtering and validation of the paths seen.

> It seems to me that ensuring that the protocol operates correctly does not provide
> sufficient levels of assurance that a BGP speaker can reliably distinguish between
> routing information that is in some sense "genuine" and routing information that
> is intended to corrupt the speaker's forwarding state.

right, so... fix bgp in some way? you seem to have jumped to step3
below, which is fine, but we are supposed to agree on 1 and 2 first.

>>>
>>>> Additionally, the draft in question here still doesn't say how you'd
>>>> know 'thats a route leak' more than 1 as-hop away form the 'leak'. (it
>>>> also doesn't take into account any of the comments I provided to the
>>>> authors :(  which is another matter entirely)
>>>
>>> so we get back to RPSL.
>>
>> maybe? though I'm not sure that it's any more helpful than just IRR
>> based filtering with prefixes only and no policy-foo.
>
> I'm not sure its worth repeating the arguments that lead to the work in RPSL.
>
> Apparently, folk at the time who worked on RPSL held the belief that it was more helpful.
>

ok, it's not working across the board, so... ok.

>> People have to
>> be willing to be pretty damned specific in their policy language
>> there.. Is 702 going to publish that they are a transit of NTT in
>> Japan?
>
>
> good question - the folk in Japan seem to have been one of the communities that invested
> heavily in populating a local route registry with current information. But its tue that in
> many communities a local route policy registry is variously populated with current and
> lapsed information, as well as large gaps.
>

and there's not a way (today) to say: "Oh, that route for ConEdison
that NTT's customer put in 18 months ago shouldn't be in their
prefix-list AS-SET anymore"

L3 and plenty of other folks have had this problem as well, all folk
that filter strictly on their customer peerings.

> I think that the draft that triggered this interchange is spot on when it observes:
>
>   "This document describes an attack on an RPKI-enabled BGPSEC and is
>    meant to inform the IETF community that this vulnerability exists as
>    a result of route-leaks and attacks that conform to this type of
>    behavior, and that operators should not assume that that work items
>    and designs address these operational security issues."

So, one of my comments on the draft was that really a route 'leak' (a
valley where there ought not be one) isn't in itself a 'security'
problem. What you do after the valley is there COULD BE a problem for
someone's security, sure... but just the fact of traffic taking an
unintended path isn't a security problem.

It's not worth fighting that battle elsewhere, but it IS worth saying
that the unintended valley is an operational problem (latency issues,
congestion, customer problems, loss of revenue, etc) and it'd be nice
to find a solution for that. Ratholing on 'is security or not' is not
as critical as: "Crap, we defined a route leak and we agree on that
definition" and "Crap! we decided this is operationally relevant and
can someone please fix this."

> The next sentence was what motivated me to respond:
>
>   "The authors believe the capability to prevent route-leaks and leak-
>    attacks should be a primary engineering objective in any secure
>    routing architecture."
>

sure, I want a pony too, but ... so far I'm not sure I've seen any
credible way out of the problem. I still can't identify a route-leak
from more  than 1 as-hop away... which I'd want to do so I don't
install paths with known unintended valleys.

> i.e. the concepts of a "secure routing architecture", as envisaged by SIDR,
> are inadequate.
>
>
>>> But I am still wondering:...
>>>
>>> Why are we using GROW to host this discussion?
>>
>> So.. I think part of this is:
>>  1) no one has published a good definition of 'route leak' (that
>> 'people' agree upon)
>>  2) without the definition (which might not be 'required', debate
>> later pls) 'operations people' can't say (or haven't said): "Hey, this
>> route leak thing is a problem, could you ietf-smarty-pants figure out
>> how to fix it for us?"
>>  3) IDR can chew on this requirement and spit out 'Yes, you should do
>> XXX' or 'OH HAI! we changed the bgp protocol to add this widget you
>> can use to signal intent!' (or something)
>>  4) SIDR can then whack that with authentication/etc bits
>>
>> in essence the 4 steps there are what was agreed upon by the
>> routing-ads, idr/sidr folks + grow folks... it looks like things that
>> smell rolling downhill a bit :) but, welp there you have it.
>
>
> As I read your thoughts I am left with the impression that you hold the
> view that IDR that inherited the "requirements  for securing the routing
> system" task. Have I got this right?
>

Your sentence didn't parse for me, one or more words are incorrect,
somewhere around:
  "view that IDR that inherited"

I believe the path set forth by routing and ops ADs was the 3-4 step
program above... is that your question?

>>
>>> What are GROW's intended objectives in considering this draft?
>>
>> I hope:
>>  1) define in a useful fashion route leak
>>  2) get grow folks to agree (or not) that 'route leaks' (as defined)
>> are some form of operational problem that needs ietf assistance in
>> solving.
>>
>> If we don't agree that they are a problem then ... nothing happens, I suppose.
>>
>
>
> If one is allowed to assume that "leaks" redirect traffic, then isn't one
> AS operator's "route leak" indistinguishable from another AS operator's
> attack via the inter-domain routing system, as the draft itself clearly
> points out? Or is your use of the term "leak" in this context intended
> to distinguish between the two forms of corruption of the inter-domain
> routing system based on the assumed purity of motives of the perpetrator?

I don't know that motives are important? whether a path drops into a
valley is what's important, right? Speculating on motivations isn't
going to be useful, I feel.

> Or do we currently have a collective belief that if we assign the same problem
> space to enough working groups one of them will eventually have a bright
> idea? :-)

OPS ADs have traditionally tried to keep the spew level down. I don't
think anyone here is trying to move the problem around, there's a
fairly clear 3-4 step process to be followed, one might view the draft
in question as step1 of that process.

-chris

>>> And if we are ready to reopen this consideration of requirements for securing the operation
>>> of BGP, just how much of this are we willing to re-consider? Is it all the way back to
>>> RPSL and RPSS?
>>
>> not sure... :)
>
> neither am I - which is why I asked the question.
>
>     Geoff
>