On 8/4/14, 5:47 PM, "Sandra Murphy" <[email protected]> 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. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
