Hi Randy, thanks for you quick reply.
I actually might be mixing this up with some discussion about DNSsec a while ago, where the problem was that once enable others will remember that it was supported and will not accept non secured requests anymore. But as we are talking about this, could there be a similar case here, where a router is known to support BGPsec and others would ignore/drop non-signed announcements? (Sorry if that’s all discussed in the protocol doc; in this case just ignore my questions ;-); didn’t review the protocol spec yet but it’s the next doc on my list; probably should have read that one first…) Mirja > Am 02.01.2017 um 14:45 schrieb Randy Bush <[email protected]>: > >> Quick question: I'm by far not an expert here, but I remember that >> there used to be some concerns that it is practical not possible to >> disable BGPsec once enabled. If that's (still) true, should this be >> mentioned here? > > i am not sure what you mean, so let me guess. > > an established bgp session has negotiated simplex or duplex bgpsec via > bgp capability exchange. one can not change the agreement without > tearing down and restarting the session. > > a router which is bgpsec enabled, receives a signed path from the left, > but on the right it had a non-sec session, strips the bgpsec info from > the path. > > these are discussed in the bgpsec protocol document. section 6, > appended to save dumster diving, shows some of the operational uses of > this. do you have suggestions for other examples worth enumerating? > > randy > > 6. Considerations for Edge Sites > > An edge site which does not provide transit and trusts its > upstream(s) SHOULD only originate a signed prefix announcement and > need not validate received announcements. > > An Operator might need to use hardware with limited resources. In > such cases, BGPsec protocol capability negotiation allows for a > resource constrained edge router to hold only its own signing key(s) > and sign its announcements, but not receive signed announcements. > Therefore, the router would not have to deal with the majority of the > RPKI, potentially saving the need for additional hardware. > > As the vast majority (84%) of ASs are stubs, and they announce the > majority of prefixes, this allows for simpler and less expensive > incremental deployment. It may also mean that edge sites concerned > with routing security will be attracted to upstreams which support > BGPsec. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
