Re: [sidr] Key learning procedures in BGPsec?

[Stephen Kent <[e-mail]>]

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

To put this into perspective you need to say how the secruity problem 
created by poor key management by W for this router is substantively 
different from B successfully attacking W's network management system 
or compromising the router in question to achieve the same goal.

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

You're example is a bit underspecified, so I'll try to fill in the blanks.

	- B's goal is to send a route to R, for address space 
legitimately originated by O, which will attract traffic to B rather 
than to W, right?

	- B needs to acquire an update for the target (O), that 
passed through W, otherwise the forward sig on the BGPSEC update will 
fail, making the attack fail.

	- in your example, B will get the BGPSEC update for O, from 
R, after it has passed through W, which satisfies the criteria above.


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

In many cases, ASes have external info about neighbors to which they 
are directly connected, e.g., they executed a contract, paid for a 
link, etc. So, if B tries to claim it's W, based only on having a key 
from one of W's routers, that often may not work. (It might work if B 
and R are peers at an IXP and the VLAN at the IXP is not too strong.)

I would expect the attack to be:

	- upon receiopt of the signed update, B strips the sigs 
applied by W, and by any ASes between W and R, and any ASes between R 
and B.

	- using the compromised router key from W, B generates an update
that shows O-?-W-B. it signs the update using its (B's) key, and 
sends it to R, possibly via an intermediate AS ("?"). this way B does 
not have to pretend to be W. It only asserts that it (B) has a link 
to W, and that it has the same path to O as W had, plus itself.

If there are one or more ASes between W and R, legitimately, then the 
bogus route is shorter and probably preferable. So, the presence of 
one or more "?" ASes between W and R is critical, contrary to your 
assertion. If W is directly connected to R, the bogus route is longer 
and may not be preferred.

You go on to observe that W's poor key management practices allow B 
to cause O's traffic to be routed through it, even though O and R did 
nothing wrong. That's true. But it also would be true if B 
compromised a router or network management computer in W and caused 
the AS/router to forward traffic destined for O (from R) to B. Or, W 
may be evil and takes $ from B to send it a copy of traffic from R to 
O. All of these are ways that the targeted traffic ca be misrouted, 
due to some bad behavior by W. This is an inherent limitation, in 
your example; R is dependent on W's secruity, realtive to traffic 
beign sent to O, because W is between O and R.

I don't agree with any of your proposed changes for the design.

#1 calls for a level of micromanagement that is not common in IETF standards

#2 is not relevant; my detailed attack example did not need to 
acquire the updates by wiretapping "off axis."

#3 suggests multiple sigs per something (AS?, router?) are more 
secure than a single sig. Absent a lot of unspecified context 
details, this assertion is not valid.

#4, viewed in the context of Eric's message, seems to suggest that if 
every AS were required to publish self-assertions about key 
management, then this info would be used as a "trust" value inputs to 
local routing policy by other ASes. Really?

Steve