On 30 Apr 2015, at 19:48, Matthew Lepinski <[email protected]> wrote:
> For path validation (as opposed to origin validation), the path validation > algorithm returns one of two states. That is, either an update has a valid > signed path or it doesn't. (We discussed previously in SIDR whether there was > a useful third case for path validation, and the working group wasn't able to > come up with one.) I think expired certificates qualifies. And a case can be made for strong crypto algo vs weak crypto algo is a fourth one. > This means that there are six possible states that come from SIDR validation > (assuming you are using both origin validation and path validation). That is, > three possible origin validation states and two possible path validation > states yields six possible joint states. Actually nine, assuming < 100% BGPsec deployment: 1. BGPsec=valid, RPKI=valid 2. BGPsec=valid, RPKI=unknown 3. BGPsec=valid, RPKI=invalid 4. no BGPsec, RPKI=valid 5. no BGPsec, RPKI=unknown 6. no BGPsecd, RPKI=invalid 7. BGPsec=notvalid, RPKI=valid 8. BGPsec=notvalid, RPKI=unknown 9. BGPsec=notvalid, RPKI=invalid Only with type 1 can we be sure that the prefix is advertised legitimately. Type 5 indicates no BGPsec or RPKI deployment and may or may not be legitimate. These should have a lower local_pref than type 1. Type 2 is strange, but can probably be treated the same as type 5, or perhaps a loc_pref higher than 5 but lower than 1. Types 3, 6 and 9 are bad news, as they may be unauthorized more specifics, so it's important to filter these. Type 4 can happen because BGPsec hasn't been fully deployed yet (remember that the whole path must support it while RPKI can be deployed by just the "end" AS) but once that's no longer common it will be the attack vector of choice because it's easy to fake the origin AS if there's no BGPsec, so at some point, these need to be filtered, too. That leaves 7 and 8, which SHOULD be filtered if they're legitimate BGPsec validation failures and not incidental mistakes such as expired certificates. > it is perfectly fine for different operators to handle such cases > differently.) Famous last words. Obviously we don't want to be overly prescriptive, but I don't think there's as much room for creativity as you suggest. > However, personally, for path validation, I would not recommend throwing out > all route advertisements where path validation returns invalid. That is, if > the only route you know of to get to a particular block of address space has > a signature that doesn't valid (or lack signatures because someone in the > middle doesn't have BGPsec turned on), I think it is probably a good idea to > use that route despite the lack of valid signature chain. Actually I don't think that case can happen. Consider the following path: 6 5 4 3 2 1 If AS 4 doesn't support BGPsec but the others do, then AS 3 will convert the BGPsec_Path to an AS_PATH, removing all the signatures. ASes 5 and 6 are not in the position to repair this, so as far as they're concerned, the path is completely unprotected. However, what you say here is problematic: > That is, if the only route you know of to get to a particular block of > address space has a signature that doesn't valid (or lack signatures because > someone in the middle doesn't have BGPsec turned on), I think it is probably > a good idea to use that route despite the lack of valid signature chain. Considering whether a route is "the only route you know" is explicitly forbidden by RFC 4271: "The function that calculates the degree of preference for a given route SHALL NOT use any of the following as its inputs: the existence of other routes, the non-existence of other routes, or the path attributes of other routes." However, you can get the same result by simply giving the invalid path a low local preference. However 2, the real problem with allowing prefixes that don't RPKI/BGPsec validate is that these invalid prefixes could be more specifics of legitimate prefixes, and no matter how high the local_pref of the valid prefixes and low the local_pref of the invalid more specifics, the packets will be forwarded as per the invalid more specifics. Therefore, the only workable approach is to completely filter out prefixes that don't validate. However, the downside of such a strict policy is that if the certificates used for BGPsec signatures expire, the path will become notvalid and the associated prefixes disappear from the internet. That's why we need the ability to treat paths that don't validate because of expired certificates differently from paths that don't validate for other reasons. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
