>> 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".
it is compressing prepends that is the optimization. transparent route servers are not an optimization, they're a hack. >> 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. prepending is supported in the current spec. the problem is that there is one signature per prepend, expensive. >> o a bgpsec-speaking 'transparent' route server signs over a zero >> prepend count. > > 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 ? maintaining bgpsec. if A hands announcement to RS and RS hands to B and C truely transparently, to whom does A forward sign the announcement, B or C? #faceplant > 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 ? so, A has to know all the ASs to which RS will hand route, forward sign announcements to each of them and hand all those to RS, and RS then stores them all and forwards as appropriate. that'll scale really well. omg! on reread it seems you are giving A's private key to RS. not a fracking chance in hell. you just blew the trust model to hell. >> o bgpsec speakers calculate as path length by summing prepend >> counts. > > Are you suggesting placing the prepend count in the AS Path itself ? see slide 29 of https://archive.psg.com/110614.nanog-bgpsec.pdf randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
