Re: [sidr] Key learning procedures in BGPsec?

[Brian Dickson <[e-mail]>]

On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent <[e-mail]> wrote:
> At 1:43 PM -0500 1/24/12, Eric Osterweil wrote:
>>>  The focus of BGPSEC is improving inter-AS routing security. The operator
>>> of any AS may not do a great job of securing the keys associated with some
>>> or all of its routers. Other ASes will not, in general, be able to evaluate
>>> the operational security of an AS. BGPSEC tries to limit the extent to which
>>> an AS  can lie about routes that it propagates. Local (within an AS)
>>> security errors or poor practices do not undermine this security feature.
> A major goal of BGPSEC is to limit the extent to which errors/misbehavior by
> an AS operator, or a successful attack against an AS operator, can adversely
> affect other ASes (re routing). The RPKI limits the (verifiable) assertions
> that an AS operator can make about the AS that its routers represent, and
> the prefixes it can originate.

> The BGPSEC per-AS-hop sigs limit the
> assertions the AS can make re what routes have been advertised to it.

This is a stated goal, but how this achieved or achievable relates
greatly to key management.
See below for why I think there are issues with the current protocol
design vs key management.

> These
> guarantees still apply whether the operator does a good or poor job of
> router key management.

I disagree with this assertion.

Let's consider off-axis risks.

Originator O, Relying party R, Weak-operator W, and Bad Actor B.

If poor key management on W makes it possible for the private keys of
a single router in W's network to be learned by B, then all bets are
off for anything advertised via W.

Here's why:

Presume all the good stuff you want about O, and the RPKI system.
Route X, originated by O, is fully validated and legitimate.

Topologically, let's say the following BGPSEC sessions and links exist:

O--?--W--?--R--?--B--?

(All the "?" mean there could be intermediate parties, but none are
required for this example to still be applicable.)

In order to spoof announcements, B need two things: The private key of
a single router (such as the key for a W router), and the data that
would be signed by that router (for X).

However, since anyone receiving route X which was sent from O via W
_must_ contain that data, it is trivial for B to generate false routes
for O.

The process would be:
B sets up a router F ( which claims to be the W router for which the
key was compromised).
The (W_fake) router F is configured with ASN == W.
B sets up a BGPSEC session between F and B, and signs the results.

Voila, BGPSEC signed routes received by R, that appear to be:

O--?--W--B--?--R

and this BGPSEC-signed path is fully origin-validatable and fully
BGPSEC path-validatable.

An error by W, allows B to "pwn" O, without O or R doing anything wrong at all.

There is no (trivial) way for R (or O) to detect or prevent this kind of attack.

This shows why one or more of the following things needs to be changed
in the BGPSEC design:
(1) key management requirements (not part of the design)
(2) availability of unencrypted signature-input data to off-axis parties
(3) ability for a single signature to subvert the validation process
(4) absolute trust model for signature chains (all/nothing)
(5) ???

Brian