Re: [sidr] Route Leaks and BGP Security

[Russ White <[e-mail]>]

> yup... no-export/advertise were taken as 'advisory' communities that
> networks MAY heed, but certainly weren't bound to do so.

>From what's been said on the list in the last several days, however,
isn't it true that even the signatures are "advisory?" There is an
insistence that local policy overrules the signatures --so all the
entire SIDR effort is doing is providing more information on which to act.

Why wouldn't signing communities be providing more information on which
to act, as well? How can we say that providing more information on which
to at is legitimate in the one case (that the receiver isn't bound by
the information provided, but it is good information to have), and yet
in the second case argue that because no-one is bound to act on the
information, we shouldn't provide it?

> I suppose documenting: "One leak scenario is <see id name>" is a fine
> thing, does it help to actually fix the problem though? I think what I
> heard in the meeting and on the thread(s) here was: "Sure leaks are
> important, there's not a way devised so far that distinguishes a
> 'leak' route from a 'normal' route, more than 1 as-hop from the
> 'source' of the leak.
> 
> In the id/draft:
> 
>    isp1   isp2 - me
>        \     /
>         AS1
> 
> I can't tell at 'me' that the route I see is a 'leak', just that I see
> an as-path that is isp1-as1-isp2.

There is a way to tell --you simply have to have ISP1 and ISP2 advertise
through some mechanism that AS1 is not a transit peer. You can either
add this information into BGP itself, through a community or some other
attribute --but note that BGP wasn't designed to do this, and you're
trusting AS1 to pass along the information that's it's not a transit
peer when trying to act as a transit peer (a bit pathological, IMHO), or
you must do so out of band.

There are out of band solutions available, but the insistence that
no-one ever advertise their intent has blocked all such out of band options.

Not everyone might object to advertising their intent --and building a
system that doesn't allow the advertisement of policy to appease the few
that do object appears to be backwards from the way business should be
done. Operators should be given the ability to trade off between
additional security and "privacy."

:-)

Russ