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

[Jeffrey Haas <[e-mail]>]

On Wed, May 14, 2014 at 10:13:13AM -0600, Danny McPherson wrote:
> >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.

Fine, let me amend that:
Unless there is something that documents/formalizes the scoping of
advertisements for a given prefix, and that informatoin can be distributed
for use of validation of right to propagate, then there's nothing to be
secured.  Whether this is in BGP or bgpsec or something new isn't the
important bit.

FWIW, I did a rough proof of concept that such scoping could be modeled in
RPSL a number of years ago when I was doing a lot of IRR related stuff.  It
*can* be modeled, but not really in a tractable fashion.  The addition of
some recursive elements (my customer as-set includes the following as-sets
I've received from this upstream) in the language helped, but it was still
ugly.

What was a particularly ugly observation from that was that one person's
mechanism for preventing route leaking was another person's mechanism to
lock a customer into a relationship tighter than a set of mutual parties
were willing to be contractually bound by.  (The best part of policies are
the exceptions, as someone once said to me.)

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

It's worth noting that I've had a TODO in my IETF list to review this
document for over a year.  WGLC is what finally made me check that off. :-)
So yes, mea culpa, I'm just as bad as many other IETFers.

My point was that you want to illustrate route-leaks are bad, and that
bgpsec won't help.  By framing this strictly in the terms of a
man-in-the-middle attack, I think you're going contrary to what bgpsec
claims it is doing: validating that an announcement has traversed a set of
ASes.  bgpsec doesn't claim to stop this.  (I am further behind in my SIDR
reading than in grow, so if they do, I'll stand corrected.)

If you stop claiming that bgpsec is there to prevent this and reframe the
document as "bgpsec can't stop route leaks", I'm fine with that.

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

Note I didn't say the routing system. :-)

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

I think you'll find that particular bit of state and rate of state
scaling... fun.  Bar conversation.

-- Jeff