> 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
