Randy Bush wrote (on 08-Jul-2011 at 14:51 +0100): > Chris Hall wrote: > > ... 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 A signs it's announcements to RS in the usual way, with the RS ASN as the next AS hop. When announcing A's routes to B, the RS *rewrites* the signature it received, using the key it has for A, as if A had announced the route directly to B. Clearly the RS would be required to preserve the Expire Time on any routes originated by A. Similarly, announcing A's routes to any other AS. Unless that is somehow impossible... .... > 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. ...yes, I'm suggesting that A delegates a unique signing key to the RS. It is still A's key, so in terms of the trust model, it is covered by A's CA. This is what "6.6 Proxy Signing" in draft-sriram-bgpsec-design-choices suggests, is it not ? Or does that blow the trust model to hell, also ? Chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
