Subject: [sidr] comment on draft-ietf-sidr-origin-ops

From: "George, Wes E [NTK]" <[email-masked]>
Date: Wed, 19 Jan 2011 14:23:43 +0000

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Jan 2011 16:56:54 +0900

intereting.  how about

      When using a metric which is also influenced by other local
      policy, the operator should be careful not to create privilege
      upgrade vulnerabilities.  E.g. if Local Pref is set depending on
      validity state, be careful that peer community signaling can not
      upgrade an invalid announcement to valid or better.

randy

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Thu, 20 Jan 2011 18:13:38 +0000

Sounds ok to me. Would that go in the security considerations section, or in
the main body? If in the main body, you might want at least a reference
calling it out in the security considerations.

Wes

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, January 20, 2011 2:57 AM
> To: George, Wes E [NTK]
> Cc: [email-masked]
> Subject: Re: comment on draft-ietf-sidr-origin-ops
> 
> intereting.  how about
>