Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

["George, Wes" <[e-mail]>]

On 8/4/14, 5:47 PM, "Sandra Murphy" <[e-mail]> wrote:

>An invalid ROA does not necessarily mean an invalid route.
>
>If there is no other covering ROA, then a BGP route for that prefix
>becomes unknown, as Terry pointed out.
>
>If there is another ROA which covers the same prefix, then a route may be
>invalid -- if no covering ROA authorizes the ASN that the invalidated ROA
>mentions.

WG] I'm once again bitten by an incomplete understanding of the way that
the PKI interacts with the routing side. Sigh. That makes more sense, but
since I have often volunteered to be "new guy who's not an RPKI expert"
thus serving as the canary in the coal mine for finding the hidden gotchas
like this, we have a very important detail here that may or may not be
properly covered in our existing documents.

I went poking through 6907, and it contains a useful definition for a
covering ROA that seems to imply that an invalid ROA could technically
still be considered a covering ROA, but for this:
"For all of the use cases in this document, it is assumed that RPKI
   objects (e.g., resource certificates, ROAs) validate in accordance
   with [RFC6487] and [RFC6480].  In other words, we assume that
   corrupted RPKI objects, if any, have been detected and eliminated."

So that text explicitly declares this case of invalid ROA and how to
handle it out of scope for the scenarios discussed.

Restating the combination of this text and your answer above, is it
accurate to say that invalid ROAs are removed before the RP ever gets to
the step where it checks to see if they are covering or matching, thus it
is impossible for an invalid ROA to invalidate a route? Is that required
by the standard, or simply an implementation convention that some or all
of the existing RP software follows?

I think that begs some further questions: Is there ever a case where we
*want* an invalid ROA to translate to an invalid route, or do we *always*
want to simply punt those from the system so that the routes they would
have covered are tested only against any remaining valid ROAs? Do we ever
see a need to treat an invalid ROA as a revoke? Is the behavior any
different if the ROA was previously valid and unexpired, and suddenly
becomes invalid vs if it was previously unknown and the first ROA that
shows up is invalid? I'm quite sure that diving into this will also
generate a bunch of unpleasant questions about tiebreaker behavior when
both valid and invalid ROAs match or cover prefixes, so it may be simpler
to just make it clear that this is the intended behavior, but I figured
I'd pose the questions since that's what we seem to be having a
fundamental misunderstanding about.

I think that there are probably still cases during a transfer where if you
get the order of operations wrong, in addition to the invalid ROA, you
will have a second valid covering ROA that might not match what's being
announced and thus a potentially invalid route. That's probably what needs
to be enumerated in the validation-reconsidered draft as the problem with
the biggest potential impact, even if it's secondary to the main failure
mode where a bunch of routes just go to unknown status and temporarily
lose the protection that origin validation is supposed to provide.

Thanks
Wes George


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.