On Thu, Feb 2, 2012 at 3:11 PM, Murphy, Sandra <[email protected]> wrote:
>>(Contrast this with the risk of exposed on-router private keys, where
>>literally _any_ AS-path could be forged via the AS of that router,
>>off-axis.)
>
> I believe you are wrong here.
>
> The holder of the private key for an AS can not produce the signatures for 
> the ASs that precede it in the AS_PATH, nor the signatures for the ASs that 
> follow it in the AS_PATH.
>
> By example:  consider an AS_PATH A-B-C-D-E
>
> The holder of the private key for C cannot produce the signature attributes 
> produced by A, B, D, or E.
>
> It can produce an update and a new signature for A-B-C, but *only* if it has 
> a valid bgpsec update that
> A sent to B and B sent to C.  It can not produce the signatures that D and E 
> would add.

I think I used too many pronouns and left too much detail to the
reader to infer.

The fault is entirely mine.

What I am saying is, any AS_PATH which can be observed anywhere, which
goes through C, can be made to appear via X, if the legitimate holder
of keys to X, happens to gain access to the keys to C.

Access to any open routing table (route-server, router, etc.) is
sufficient, presuming BGPSEC attributes are included in the data.

And the ability to forge routes is basically unlimited, even if there
is no relationship between C and X.

Given a set of sets of prefixes, {P1, P2, P3}, where P1 = {A.B.C.0/24,
A.D.E.0/22, etc.}, P2 = {...}, P3 = {...},
and given a set of AS_PATHs for each set of prefixes, A1, A2, A3,
which correspond to the announcements of P1, P2, and P3 respectively.

And suppose further that all of the AS_PATHs end in "C".

Then X, who holds keys to X, and has learned keys to C, can construct
announcements P1 A1-X, P2 A2-X, and P3 A3-X, etc...

And by "construct" I mean BGPSEC secured announcements which satisfy
origin validation and path validation.

The restriction over "any" means, "any existing AS-path can be forged
via paths that end in stolen-key and key-thief ASNs in sequence."

If the stolen key corresponds to someone with the full set of routes
for IPv4, e.g. anyone running BGPSEC, and their routes are visible
somewhere, like a route-server, then every prefix can have forged
routes (maybe with long AS_PATH) announced securely.

If the thief is a customer of enough ISPs who do local-pref of
customers, the thief can hijack a significant proportion of global
traffic. This is why the importance of _universal_ key security cannot
be overstated here, at the earliest point in development of BGPSEC.

Again, there is no topological proximity required (to the AS from who
the keys are stolen) , and the value depends entirely on the ability
to have the forged paths preferred.

Brian
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to