Re: [GROW] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help

[Danny McPherson <[e-mail]>]

On 2014-05-12 15:42, George, Wes wrote:
> I see a thread dated 2013 Nov in GROW, in which substantive 
> discussion and
> comments were provided after -03 was published, in which the authors
> mainly just expressed why they were frustrated with SIDR and the IETF 
> in
> general for in their minds, ignoring this problem because it was 
> hard,
> rather than addressing the concerns raised within the WG. -04 is a
> keepalive to reset the expiration date with no substantive updates. 
> Why
> are we now talking about WGLC?

Because we'd like this memorialized in an Informational RFC, that's the 
purpose, methinks.

> Chris, you were one of the ones who said that your comments hadn’t 
> been
> addressed yet.
> 
> (https://mailarchive.ietf.org/arch/msg/grow/0ho_RU3e15TCvp4p8ScCeObk42Y)

Eric owns comments follow-up, I'll defer to him on responding to that 
bit....

> Substantive comments:
> This document provides one example of a route leak causing a problem 
> that
> BGPSec does not protect against, but still does not do much to 
> provide
> guidance on how such a leak would be systematically identified,

Nor does it have to in any programmatic way, IMO.  It's easy for an 
entry level routing person to understand what the problem is here, hell, 
they have to deal with them every day.  It doesn't have to expand to 
every possible reason or define detection mechanisms.  We hope folks 
that read such things will be as clever as the SIDR folks and solve this 
solution :-)

However, if you can be more specific about examples not covered or send 
text then we'd be happy to incorporate it.

> It does
> note that there are data supporting the assertion that this is a real
> problem, and imply that perhaps additional analysis of that data 
> would
> reveal more information. I don’t think that anyone would dispute that 
> this
> is a valid attack. However:
>         "This document is meant to provide input into routing 
> protocol design
> choices being
>         considered within the IETF, and to foster discussion of the 
> practical
>         implications of "policy" and "intent" in operational routing 
> system
>         security."
>
> This document provides no actionable guidance beyond articulating the
> basics of the attack, certainly no meaningful discussion of policy vs
> intent other than to note that discerning intent is difficult, and as 
> such
> the draft is absolutely not ready for publication if the above is its
> goal.

We didn't say we'd proclaim all is accomplished, we said we'd like to 
foster discussions of policy v. intent.  This very discussion makes me 
think it works, and given that even you don't think anyone would dispute 
that this is a valid attack, I claim success and request publication -- 
although perhaps we should update with more recent leak references and 
we can certainly encourage more folks to do research, with a stable 
reference, which was precisely the intent.

> We’re not hiding behind SIDR’s carefully crafted requirements and
> charter here, so let’s actually have the discussion about policy and
> intent and see if we can come to some consensus on how to use that 
> info to
> define a route leak such that we can first systematically find, and 
> then
> protect against it.

I'm glad you agree it was carefully crafted.  This draft is only meant 
to document the issue above, which you seem to agree that no one would 
dispute.  It doesn't need to be the kitchen sink for attack vectors.

> I absolutely want to see a solution to this problem,
> but one example/existence proof isn’t enough to get us moving in that
> direction.

I don't think that's a surprise Wes.  We should document what some 
believe the problems are before we begin designing solutions, else we'll 
end up with more complicated solutions that don't address what me 
operators believe to be the key issues.


-danny