[email protected] wrote: > Adding [email protected] for reality check. We live in a post-truth world.
On a more serious note, this draft is the wrong way around and this probably means it's not operationally useful in most cases. Let's say there's a route server R with clients A, B and C. Clients A and B announce a prefix, the intention being that the route server will propagate this to C. The route server will inject both prefixes into client C's Loc-RIB, and will then run the routing decision engine on that Loc-RIB. The best path will be computed and the result will be sent to C. If this draft is implemented the way it's stated, and client A injects a prefix which is has a valid rpki signature, and client B illegitimately injects the same prefix with an attribute set which ensures that it's the preferred prefix (doesn't matter whether it's signed or not), then the RDE will run and will unilaterally prefer the prefix from client B, ignoring the signed prefix from client A. Client C will receive the hijacked prefix. Not good. Or assume that client A injects a prefix which has an invalid rpki signature, and client B legitimately injects the same prefix with an attribute set which ensures that it's not the preferred prefix (again, it doesn't matter whether it's signed or not), the prefix from client A will be preferred in client C's Loc-RIB. If client C drops invalid prefixes, then the route server R has contributed to path hiding (see rfc7947). In both these cases, and some other easily identifiable situations, the draft as stated contributes to topologically surprising results which wouldn't necessarily be what any of clients A, B or particularly C might expect or want. There are two ways to fix this: 1. either this draft should mandate that add-path must be used for tx from the point of view of the route server. This is not operationally very useful because most clients and many route servers don't support ebgp add path, either due to policy or technical limitations. 2. by far the easiest and best way to solve this particular problem would be for the IXP operator to allow the IXP participants to specify how to handle rpki-signed prefixes for their route server configs. You would need two binary tickboxes in the IXP's provisioning system: drop or don't drop notfound, and drop or don't drop invalid. I would assume that there's no requirement for the same sort of tickbox for valid prefixes. If the IXP operator implemented this, then the Adj-RIB-In to Loc-RIB-out prefix filter would be able to make a decision about whether to accept or drop the RPKI notfound/invalid prefixes on a per client basis, which is what IXP route server client operators would want and expect. Obviously, this is a local IXP provisioning system issue, and it would be up to the IXP as to how to implement it, i.e. allow the customer to modify this themselves using a portal, or raise a ticket with the IXP support desk. Consequently, as this is not an problem which would be best solved by the IETF, I'd suggest it would be better for this draft not to progress further. Nick _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
