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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
