Re: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server

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

Sandra Murphy wrote (on Fri 08-Jul-2011 at 20:30):
...
> Section 6.6 rightly notes that if an AS decided to share its
> private key with another AS, no one outside the agreement
> could tell the difference.

As it stands, this is how a transparent route server could be
implemented.

I don't see a requirement to support transparent route servers in
draft-ietf-sidr-bgpsec-reqs :-(

Mind you, placing the RS ASN in the path might be said to violate:

  3.15 A BGPsec design MUST NOT require operators to reveal
       more than is currently revealed...

Though there's no shame in using an RS... except, perhaps, that your
larger ASes will tend not to, and may turn their noses up at those
that do.

Using an RS, IXP customers can peer with each other for the cost of
one BGP Session (or one with each local RS instance).  At some IXPs
there are several hundred RS clients.  The cost doesn't go away, but
falls on the RS, which scales as (N * N * R) -- number of clients 'N'
and average number of routes each 'R' -- that is: it scales horribly.

It would make life easier for the RS if the clients' routers were able
to do more of the work -- noting that it is vital that this does NOT
require any additional administrative effort beyond the initial
configuration, and that new RS clients are automatically connected to
all others (by default, at least).  But any change at the client end
requires some change to BGP and/or to administrative features of BGP
implementations... so good luck with that, as they say :-(

One such approach would use something like draft-walton-bgp-add-paths
(currently expired), so that the RS no longer has to make any best
path selection, but can pass all routes it has for each prefix, and
let the clients decide.  (This also solves the problem of how to allow
clients to tune the selection process in the RS.)

For BGPSEC it might be nice to push the signing out to the client:
suppose BGPSEC were extended, so that each route given to the RS
contained a list of AS Path signatures, one for each possible
destination.  This would also require a means for the RS to signal all
possible destination ASes, so that there is no need for administrators
to fiddle with their configurations.  This solves the private key
issue and has the happy property of moving work to the client --
except that they may not be quite ready to generate and send several
hundred path signatures per route !

More exotic would be to arrange for the RS to talk to a box in each
client which would provide the required signatures (inside the minimum
advertisement interval).  If that were a function of the local RPKI
Cache, then setting up a BGPSEC connection to the RS would be a little
more complicated, but once done would require no further work.  (The
request for a new signature could pass the current signatures, AS Path
and NLRI etc, so that the signing box can verify that the RS is not
asking for something it shouldn't.)

Chris