Re: [sidr] Key learning procedures in BGPsec?

["[e-mail]" <[e-mail]>]

Brian

(delurk) As a recovering cryptographer I can think of nits to pick but it's
certainly possible to build a robust system using hash chains and hash
trees rather than conventional signatures.

Declaration of interest: I started this field of study 15 years ago with a
paper on the Guy Fawkes protocol. This was then taken up by Adrian Perrig
and others and turned into systems (TESLA etc) for authenticating digital
streams using hash chains. If you want to authenticate a large number of
messages from Alice to Bob that all arrive in order then hash chains are
great.

Here's how it might work. You have a conventional mechanism for initial key
setup between routers (maybe a route reflector doing public-key crypto,
maybe DNSSEC). Then each router sets up a hash chain with each peer and
uses hashes to authenticate routine updates.

Steve Kent will point out that routers do in effect have key material, in
the sense of not-yet-published hash preimages, and this is almost
equivalent to using symmetric keys for MACs (not quite, as you can get some
nonrepudiation from hash chains). But having local symmetric keys (or
short-lived signature keys) managed by per-AS route reflectors, perhaps
with HSMs for the bigger players, is in any case a good strategy to get
resilience in the face of occasional compromise.

So it might well be worth trying to explore the design options in more
detail. The authentication mechanisms had better be cheap and resilient if
we want this thing deployed

Ross Anderson
www.ross-anderson.com


On 30 January 2012 23:57, Brian Dickson <[e-mail]>wrote:

>
> > Do you have any designs in mind that will NOT use cryptography?
>
> There are two things to consider here.
>
> (1) If I can come up with an example design that does not rely on
> private keys being kept (let alone exposed) on routers, would that be
> sufficient to justify exploring more options than just my example? I'm
> fine with someone else coming up with something better than this, and
> am not married to the particulars of this. However, it can be
> considered an "existence proof".
>
> (2) Do you accept that an example of such a design is intended to
> prompt the merits of looking for better designs, rather than the
> example being fodder for dissection/discussion/bashing? I mean for
> this to be an "okay, fine, clearly there are alternatives, and we
> should discuss the high-level pros/cons of on-router crypto and key
> management".
>
>
>
> Having said that, here's a simple example (with "simple" being in the
> eye of the beholder, obviously).
>
> Each AS maintains a (for lack of a better term) "database" of its BGP
> neighbors, and known prefixes.
>
> Each AS also maintains a single, global "nonce", which it may
> periodically change.
>
> From these sets of data and the single nonce, each AS publishes a set
> of SHA-256 hashes (or other SHA hash, as appropriate), over (prefix +
> neighbor_ASN + nonce) tuples.
>
>