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

[Danny McPherson <[e-mail]>]

On 2014-05-14 07:58, Jeffrey Haas wrote:

> This to a large extent identifies the problem: BGP *as a protocol* 
> has no
> idea what these boundaries are.  Thus, "intent" is up to the 
> perception of
> the involved parties.

Ans therefore, the solve need not necessarily be IN BGP itself.

> This thread has looped a few iterations with "this is a problem!" and 
> SIDR
> basically saying "there's nothing in BGP here to secure".  Both 
> things are
> still true.

Heh, perhaps.

> I think documenting route-leaks and their potential negative (or 
> malicious)
> consequences is worth GROW doing.

Concur, especially since it's a global routing operations related issue 
that happens all the time, and persists whether BGPSEC is deployed fully 
or not.

> I think this issue exists even without bgpsec being involved.  While 
> it's
> correct that bgpsec doesn't add anything here, until the underlying 
> base
> protocol has some idea of what we can do, picking on bgpsec doesn't 
> help.
> If anything, I'd probably take the route-leak document and say 
> "here's the
> problem" with a one or two sentence note that bgpsec doesn't do much.

I don't agree, and I don't believe this problem needs to be solved IN 
BGP.  And I do believe it's extremely important to provide a stable 
reference to these attacks in order for folks to realize it doesn't 
solve this very basic problem.

> In it's current form, I don't think the document is ready to 
> progress.

What specifically would you change in the document, given that it's 
intent is to highlight how BGPSEC does not address the route leak issue, 
and that it's a real operational issue that at least the authors are 
concerned with?

> I'd even suggest it needs to be rescoped.

If folks are interested in doing work more broadly than this then 
they're certainly welcome to.  If they're not interested in doing the 
work then it's disingenuous to suggest it be rescoped as such, 
particularly at this stage.

> The interesting work is resurrecting the thread on injecting routing 
> policy
> intent into some system we can secure. :-)

I suppose degrees of "interesting" is a matter of perspective, and the 
notion of strict linear thinking that suggests "injecting" it into the 
active routing system is the only way to solve the problem is perhaps 
why we keep dancing around this (and other adjacent topics such as 
anti-spoofing in the datapath).  Quite frankly, I prefer inter-domain 
static routing or SDN over what I see BGPSEC-enabled RPKI bringing to 
the table - and I seriously mean that --  and they might well beat 
BGPSEC off the launchpad :-)

-danny