Just reviewed the -02 version, and something occurred to me. I think it makes sense to include in this draft since it's basically an operational consideration, but it could also fit in the sidr-pfx-validate draft.
Since we're recommending LocalPref as one of the ways to influence routing decisions using the RPKI validation data, we probably need something pointing out that care must be taken to avoid (or at least understand the significance of) LocalPref race conditions. That is, other route policies already in effect that change the LocalPref value on one or more routes may be in conflict with the values being set by the RPKI route policy. For example, if a provider listens to communities that allow eBGP peers to raise or lower the LocalPref on routes that they announce to that ASN, and if LocalPref values for RPKI validation are set improperly, it could have the side effect that someone could inject an invalid route tagged with the community to raise LocalPref to a level that it is still considered along with the rest of the valid routes, which would make the RPKI largely ineffective on that ASN. Or if LP is lowered by policy for certain ASNs because those routes are less preferable, only to have them raised again by RPKI validation, that may have undesired consequences in traffic flow across the network. Ultimately, the decision of what value to set in LocalPref for each policy (valid, invalid, unknown, plus any additional policies) and which "wins" in any race condition is up to the provider. During the rollout, it may even be desired behavior to allow customers to compensate for LocalPref changes being brought on by RPKI that suddenly redirect traffic to a different route on certain networks because of inconsistent participation in the RPKI, but we probably need to make it clear that this should be a temporary measure, or else it defeats the purpose of RPKI. It may be that those who use community-tag policies like this will need to make them more complex (integrate the RPKI policy into them) so that different LocalPref values are set based on the community being set PLUS the RPKI validity state, rather than two separate policies that can potentially fight each other. I don't know if we want to explicitly recommend that here or not, but it might be worth suggesting. Either way, I think we do need to cover this, both from the potential security angle and from the traffic engineering angle. Thanks, Wes George
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
