...
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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
