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" <wesley.geo...@twcable.com<mailto:wesley.geo...@twcable.com>> wrote: On 8/4/14, 5:47 PM, "Sandra Murphy" <sa...@tislabs.com<mailto:sa...@tislabs.com>> 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 sidr@ietf.org<mailto:sidr@ietf.org> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
