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

[Jakob Heitz <[e-mail]>]

I think you mean "paths with valleys are all instances of unintended routing".

Surely, that can be fixed:
A provider can reject valleyed routes from a customer BY DEFAULT,
but allow some through if so configured.

The point is that such a valley attribute can provide good information to prevent
the majority of route leaks without leaking customer relationship information.

--Jakob.

-----Original Message-----
From: Geoff Huston [mailto:[e-mail]] 
Sent: Friday, November 22, 2013 3:21 PM
To: Jakob Heitz
Cc: Christopher Morrow; [e-mail] [e-mail]
Subject: Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

If you are referring to the proposal that "valley free paths are all instances of unintended routing", then as I recall there is a line of argument that says that some paths that contain valleys are intentional.

 
On 23 Nov 2013, at 7:03 am, Jakob Heitz <[e-mail]> wrote:

> Wasn't there once a proposal along the lines of:
> 
> The originator adds a signed attribute that says "this update is going up the chain".
> Each AS signs it before passing it on.
> When an AS sends the update down the chain, it removes the attribute.
> When an AS receives an update clearly "from below", it checks for the presence of the attribute.
> 
> What were the objections to this?
> 
> --Jakob.
> 
> -----Original Message-----
> From: GROW [mailto:[e-mail]] On Behalf Of Geoff Huston
> Sent: Friday, November 22, 2013 11:44 AM
> To: Christopher Morrow
> Cc: [e-mail] [e-mail]
> Subject: Re: [GROW] I-D Action: 
> draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt
> 
> 
> 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?
> 
>> 
>>> 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.
> 
> 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.
> 
> 
>>> 
>>>> 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.
> 
>> 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.
> 
> 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."
> 
> 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."
> 
> 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?
> 
> 
> 
>> 
>>> 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?
> 
> 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? :-)
> 
> 
>>> [...]
>>> 
>>> 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
> 
> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow