Re: [sidr] BGPSEC Threat Model ID

[Brian Dickson <[e-mail]>]

On Fri, Nov 4, 2011 at 5:07 PM, Christopher Morrow
<[e-mail]> wrote:
> On Fri, Nov 4, 2011 at 3:05 PM, Eric Osterweil <[e-mail]> wrote:
> I'm not randy, but I was talking about this very thing in the office
> today with a co-worker... I'm not clear on how anything can stop an
> instance like:
> src      time                                        prefix
> puck    2011-11-04 16:15:49.157742      8.10.160.0/23
>   path
>   2914 2828 12989 12189 3356 19181 19181 19181
>  Contact   score  blame_asn
>   2828 3       12989
>
> As I read this, 12989 (highwind) is 'accidentally' announcing
> reachability for 8.10.160.0/23 (CWIE? AS19181). Looking at one popular
> source of routing data:
>  <http://www.robtex.com/as/as19181.html>
>
> it actually seems that the 2 people may be peers :( the route that we
> see is merely an artifact of their connectivity and 'poor route
> selection' inside their networks :(

I suspect that it is a case of "accidental back-up transit via a peer".
(I have seen this personally, where it was "malicious" instead of "accidental".)

Generally, the problem with prefix-only filtering is it ignores the as-path.
If you build your upstream filter based on who your customers are (nominally)
instead of based on where that route was learned, this can happen.

> Point being that in cases like this (or really all route leak cases)
> the only thing that stops this is filtering routes between bgp peers.
> (transits, customers, SFP peers) There isn't anything in the protocol
> itself (which is Stephen's, Russ's, Randy's comment through out) that
> tells you/me/them that 12989 should not be permitted to announce this
> route. (looking at available data, it seems that they SHOULD, perhaps
> not with this ASPath, but...)

It's actually tricky to do in reality. You have to build prefix filters AND
as-path filters AND ensure that BOTH filters are applied to everything.
And that doesn't necessarily always work either. Communities are a big
help...

> How would you go about telling, from the data on the wire in bgp, that
> a route is a hijack?
> How would you propose changing the data on the wire in bgp today to do
> this tomorrow?

I would propose adding a mandatory "bit" signaling "customer" or "non-customer".

In the BGPSEC context, the bit would need to be signed and kept AS-hop-by-hop,
added in a way that unambiguously shows exactly where in the AS-path
it is applied,
and where the bit requires both sides of the peering agree on it. No
unilateral bit-setting.

The status from the last AS-hop, however is all that is really needed.
Local announcements start with the bit set.
Going "upstream", the customer bit gets kept. Upstream is only allowed
if the bit is set.
Downstream is always allowed, and the bit is always cleared.
Sending to peers is only allowed if the bit is set, and in the process
the bit is cleared.

(Mutual transit means the bits are kept and all routes are sent.)

Once a route crosses a peer connection or goes "downhill", it can no
longer go "uphill"
or cross another peering link.

Uphill N times, one peering link (optional), downhill M times. No exceptions.

Of course, filtering or marking to restrict individual prefixes can be
added to this,
without violating the restrictions. (More restrictive, good. Less
restrictive, very bad.)

In fact, I'd add it to the negotiated capabilities (being
offered/requested) so it gets configured
on each "neighbor" statement: Transit-Offered; Transit-Accepted; or in
the oddball case, both.
Only if there is match between one side offering transit and the other
accepting it, is the status
set.

In a left-to-right representation of an AS path, there would be four
possibilities:
XXX <t> YYY (Y provides transit to X)
XXX <c> YYY (X provides transit to Y, i.e. Y is a customer of X)
XXX <p> YYY (X and Y are peers)
XXX <tc> YYY (X and Y are mutual transit buddies)

An example representation of AS-path-plus-bit might look like:

2914 <c> 2828 <c> 12989 <t> 12189 <t> 3356 <c> 19181 19181 19181

In the above case, the sequence "<c> .* <t>" shows where the problem was.
Having the protocol enforce the restrictions would have stopped the leak.

> Would having data you could mechanically verify about the routes and
> origins and relationships (say connectivity only?) between bgp peers
> help solve this problem?

Yes, and I believe the relationship info, even on the most recent AS-hop,
would be sufficient. While the protocol enforcing it would fix things, there
is the issue of trusting the implementation/implementors, so I think there
would still be a requirement to sign at each leg, and validate all signatures
and hops.

The sender signing her interpretation of the status, with the receiver
authenticating
and having the ability to reject if either the signature is bad, OR if
the signed
status of the relationship does not agree with the receiver's idea of
the status,
ensures local bad actors are caught right away. Non-local bad actors is what
further requires all signatures be built with the peering-type. Enforcing the
restriction on the peering-type-path stops the leaks.

> In my view I don't see a change to the BGP wire format helping, I do
> see existence of data to mechanically verify ownership (and perhaps
> connectivity information?) helping.

Yep - and without requiring extrinsic information (i.e. does not
require the information
be in an IRR-type database, can be marked locally in the path, as long as the
peering type is mutually negotiated at each hop.)

Brian