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

["Roque Gagliano (rogaglia)" <[e-mail]>]

Hi Wes,

Thanks for your message, I think it is always great to have a fresh view when we are looking at new problems.

I have some comments inline.

Cheers!
Roque

On Aug 5, 2014, at 5:51 PM, "George, Wes" <[e-mail]<mailto:[e-mail]>> wrote:


On 8/4/14, 5:47 PM, "Sandra Murphy" <[e-mail]<mailto:[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?

(Roque)
The answer resides in the definitions of VRPs-Validated ROA payloads which is the information received by the BGP speakers. As its name states, the validator server only sends VRPs that correspond to valid ROAs. So, you are right that in the transition from ROAs to VRPs, the router has not knowledge that there were some signed objects (not just ROAs) that failed the validation process. This behaviour is document on RFC 6811:

"The BGP speaker loads validated objects from the cache into local

   storage.  The objects loaded have the content (IP address, prefix
   length, maximum length, origin AS number).  We refer to such a
   locally stored object as a "Validated ROA Payload" or "VRP"."

Terry's point is that as VRPs always correspond to valid ROAs, the problem under discussion will, in the worse case, take you to a "not-found" state.


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?

(Roque) There is the case of AS 0 (section 7.1.6<http://tools.ietf.org/html/rfc6907#section-7.1.6> in RFC6907 and also in RFC 6483 BUT  both Informational documents).

AS0 was thought as a solution to bogon prefixes or networks that are not meant to be public (military, banks, etc.)

Do we ever
see a need to treat an invalid ROA as a revoke?

(Roque) I believe the current process of allowing to take the union of valid ROAs for a given prefix is the right strategy. It is consistent with the "make before break" principle.
Some examples are:
- changing network ASes
- networks with multiple origin ASes
- ROA's EE certification roll-overs

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?

(Roque) You only send VRPs to the routers, which correspond to valid ROAs. You notify the router of changes, including removals

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.

(Roque) VRPs are always referring to valid ROAs. There is not "matching" with invalid ROAs. The problem under discussion, IMO, is that in some specific "corner cases" where ROAs may be invalidated due to some issues up in the allocation hierarchy.


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.

(Roque) Agree to add to the document a "before" and "after" process for transfer as example.


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.
_______________________________________________
sidr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sidr