Re: [sidr] Key learning procedures in BGPsec?

["Murphy, Sandra" <[e-mail]>]

Speaking as regular ol' member



On  Tuesday, January 31, 2012, Ross.Anderson said:



>If you want to authenticate a large number of messages from Alice to Bob that

>all arrive in order then hash chains are great.

That is not what we are looking for in the sidr work.



Authenticating the stream of messages between two adjacent routers is not

the sidr focus.  Furthermore, there are solutions in hand (TCP AO, IPSEC,

pt-pt physical protections, etc.).



The sidr work is creating protections for the path - the AS_PATH attribute

that is modified by each AS in the path of propagation of the BGP update.



A sends an update to B, who adds itsself to the AS_PATH and sends to C,

who adds itself and send the update to D, who....



The protections ensure that a recipient can look at an AS_PATH that shows

A, B, C, D, ... and know that the update did in fact pass through those systems.



And "in order" becomes a more complex idea as well.



-Sandy, speaking as regular ol' member



________________________________
From: [e-mail] [[e-mail]]
Sent: Tuesday, January 31, 2012 3:05 AM
To: [e-mail] list
Cc: Murphy, Sandra; Brian Dickson
Subject: Re: [sidr] Key learning procedures in BGPsec?

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<http://www.ross-anderson.com>


On 30 January 2012 23:57, Brian Dickson <[e-mail]<mailto:[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.