>> Actually I think the "lower preference" thing still makes some sense. >> I still see the case where you receive the routes from different >> peerings, for which you either check or do not check the received >> prefix against the ROA. I can give the below example:
> you have a sick mind.:) yes, this is possible. so perhaps qualify the > recommendation. > in a configuration when some announcements may be checked and others > not, it is possible that a prefix may be marked both notfound, > because of not being checked, and [in]valid, because it is checked. > in this configuration, we recommend that the operator prefer valid > over notfound. The situation of having in(valid) and notfound routes simultaneous for a prefix also arises when a router is not doing its own origin-AS check but is relying on neighboring IBGP speakers (all within the same AS): https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 One IBGP peer may signal "Valid" (or "Invalid") and another may signal "NotFound" for the same prefix. Also, it is possible one IBGP peer may signal "Valid" and another may signal "Invalid" even when the origin AS is the same in the two updates. Two IBGP peers apparently not in sync w.r.t. their RPKI state. The sidr-origin-validation-signaling I-D and RFC 7115 have not gone into discussing these situations. There are some subtleties involved. For example, it is possible the IBGP peer signaling "Invalid" is actually correct and another IBGP peer signaling "NotFound" is actually wrong (relative to true global RPKI state). Sriram _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
