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 6:40 PM, Jakob Heitz <[e-mail]> wrote:
> 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.

is this a default-on property? or do I configure bgp-peer-A as 'i am a
customer' and peer-b as 'I am a transit'? what is the default expected
value? how do I verify that the value is correct? or do I just trust
the 3-as-hops away path I see? how is this better than today's:
"filter your routes" situation?

> -----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
>