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

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

Randy Bush wrote (on Fri 08-Jul-2011 at 11:52 +0100):
> i have a design that covers you.  it is based on an 'optimization'
> and we have agreed to let optimizations sit for a bit.

OK.  But I quibble with the notion that support for Route Servers
should be treated as an "optimisation".

> the hack is as follows <hold nose>:
> 
>   o an early optimization will be that each bgpspeaking AS adds
>     a one byte prepend count, over which it signs.  this saves
>     signing 92 prepends.  the count is normally one.

OK.  That clears up a confusion I had... I wasn't sure whether there
was supposed to be one signature per ASN in the path, or one per
*distinct* ASN in the path.  For my money, prepending is common enough
to merit covering as a "feature.

>   o a bgpsec-speaking 'transparent' route server signs over a zero
>     prepend count.

You're right: <HOLD NOSE> indeed.
 
That would be, as you suggest, less 'transparent' than it used to be.
I don't know if "revealing" the use of the route server is a serious
issue.  But I'm not sure how much is gained by inserting the route
server ASN ?

It seems reasonable to me to treat the route server as an extension of
its clients' networks -- that's pretty much what it is.  So, if the
route server uses a different key for each client's routes, and the
*client* is responsible for issuing the certificate (as if the route
server were one of its routers), then that about covers it -- unless I
am missing something ?

I suppose that if the route server went off the reservation it could
sign all kinds of rubbish as being announced by its clients, but the
owners of the certificates could revoke them ?

BTW (and sorry if this is a stupid question) where should I be looking
for a discussion of the key/certificate management for AS Path signing
keys ?  This is intended to be added into the RPKI, yes ?

>   o bgpsec speakers calculate as path length by summing prepend
>     counts.

Are you suggesting placing the prepend count in the AS Path itself ?
Say, an AS_SEQUENCE_N, which is like an AS_SEQUENCE, but has a 1 byte
repeat count for the first ASN in the sequence ?  That would pay for
itself (bytes-wise) and mean that where there is no prepending, there
is no overhead -- except for the inclusion of the count (implied or
explicit) in the signed data.

>   o a bgpsec speaker passing a signed announcement to a non-speaker
>     expands all prepends.  of course, the expansion of a zero
>     prepend is rather small.
> 
> <release nose>

<collapse of stout party>

Chris