On 11 Jul 2019, at 19:58, Brian Dickson <[email protected]> wrote:
> One thing to be cautious about: > AS Cones still allow customer vs customer leaks, while ASPA would prevent > those. Yes, the AS Cones draft mentions "building a prefix list". So even though the validation procedure has access to all the ASes in the AS paths, this information is lost in that final step, presumably because AS Cones wants to build a filter that works on today's routers, and there is no scalable way to make a filter thatonly allows a certain AS path for a certain prefix. But that is of course the advantage of coming up with something new: then we don't have to be limited in this way. So if AS Cones were to make use of the proposed RPKI-Router extensions, it should probably use the IPvX Path mechanism rather than the Allow IPvX mechanism. So the Allow IPvX mechanism may be less useful than I thought it would be. > Depending on how PathRPKI works (including the RPKI-RTR piece), it might be > better to only support the ASPA-like functionality (i.e. does performance of > path validation scale independent of how valid paths themselves are > calculated? ). Well, basically, if we gloss over some details like the issue above, ASPA, AS Cones and PathRPKI do much the same thing, with the main difference in how they validate the path on the relying party software cache: - ASPA uses customer-to-provider (C2P) records to recursively build the full path - AS Cones uses provider-to-customer (P2C) records to recursively build the full path - PathRPKI uses origin-to-provider (O2P) records for the upstream part of the path and local configuration for the downstream part of the path to build the full path AS Cones requires the least actions to deploy because only the providers have to register P2C records and there's fewer providers than customers. However, this is less secure because now a provider can incorrectly claim that some AS is its customer and then leak those routes, with the "customer" AS having no way to stop this. PathRPKI has a deployment advantage over ASPA because only the origin ASes need to register information, and then the path between two ASes that implement PathRPI is immediately protected against leaks, even if the ASes in the middle haven't implemented PathRPKI. On the other hand, PathRPKI has the downside that if a provider switches providers, now all the customers downstream have to change their O2P registrations, making changes harder and riskier. Perhaps the right way forward is to integrate the three approaches. If we allow C2P records to contain not just the immediate upstream providers, but optionally, also providers of providers, then basically C2P does everything O2P does so ASPA would gain the advantages of PathRPKI. We can also support both P2C and C2P records, where C2P records overrule P2C records. (I.e., if AS4 says AS1 is its customer and AS1 has no C2P record, we believe this. But if AS1 says AS2 and AS3 are its providers, then the AS4 claim that AS1 is its customer is ignored.) This way, we have the best possible deployment scenario, because, apart from the need for the origin to at least have ROAs, for each customer/provider pair, only one side needs to register the relationship to allow us to validate paths, so a single AS in the middle not bothering to participate won't be a showstopper. Iljitsch _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
