Sorry, have to call B.S. on this one. Make-before-break is fully possible with exclusivity.
Exclusivity enforced at the CA level still allows for multiple ROAs (and thus multiple announcing AS). Changing (or adding, in case of anycast) ASNs requires new_ROA, new BGP announcement, and (optionally) deletion of old ROA (or update ROA to exclude moved INR). (These would be two or more ROAs under control of the same party, to which the INR had been assigned.) If an INR needs to be moved from one party to another (e.g. transfer, such as sale of INR), that kind of doesn't correspond to "live transfer", does it? And even if it does, the two-phase changes would be, new_ROA (signed by old CA) with new_ASN, and new_new_ROA (signed by new CA) also with new_ASN. When the parent (or parent^n) moves the INR delegation, a new validation path replaces the old one. The fact that both new_ROA and new_new_ROA provide validation paths for new_ASN origination of the INR, means either way, validation continues to work. BGP is stateful, so there isn't any substantial risk of problems. At worst, a BGP flap during the move and/or sync issues across delegation boundaries (from RP perspective) suggests that live transfers should occur during maintenance windows. This also suggests that "punting" on the requirements towards publication points creates operational issues. These risks could be eliminated by a requirement for atomic state-change associated with changes to published data (e.g. *nix-style "mv" which is atomic at the filesystem level, is well-known and widely implemented.) IMHO, but with facts + math to back this up. Zorn's Lemma, Axiom of Choice, anyone? FTW. Brian On Tue, Sep 4, 2012 at 10:39 AM, Stephen Kent <[email protected]> wrote: > Exclusivity cannot be enforced via RP processing of the RPKI, because of > INR transfers, > and a "make before break" INR transfer policy. RFC 6480 alludes to "make > before break" > in its discussion of ROAs, though not in the context of INR transfers. > > Steve > >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
