[Sidrops] Different path validation options

[Iljitsch van Beijnum <[e-mail]>]

There are now four drafts about AS path validation to remedy routing leaks that I'm aware of:

LDM:	draft-ietf-grow-route-leak-detection-mitigation
ASPA:	draft-ietf-sidrops-aspa-verification
ASCones:	draft-ietf-grow-rpki-as-cones
PathRPKI:	draft-van-beijnum-sidrops-pathrpki

The TL;DR on the four:

LDM

Add in-band information to BGP that signals that a peer-peer hop has been traversed to avoid having two peer-peer hops. The idea is to do this without new code, at first at least. As the checks must thus be implemented with existing policy options, those will probably be easy to implement in code on the routers later.

ASPA

Register customer-to-provider (C2P) relationships with extensions to RPKI. Based on this, check the upstream and downstream parts of the AS path, making sure there are no valleyfreeness violations and that if the customer in the relationship between two ASes has registered a set of provider ASes, the upstream AS is indeed one of the registered providers. If not, then the path is considered invalid.

The hop between the upstream and downstream parts of the path may be an unregistered hop; peer relationships are not registered and in this part of the path any relationship is a valid one anyway. If there are additional unregistered relationships in the path, validation is not possible and the path is considered valid.

ASCones

Register provider-to-customer (P2C) relationships with extensions to RPKI. Recursively collect this information to resolve all ASes that may be visible behind a given AS. Then do a reverse lookup in the ROA database to obtain all the prefixes that are authorized to be advertised by these ASes and generate a prefix filter that can be applied to a BGP neighbor.

Unclear what happens to prefixes that aren't included in the filter because of a missing AS-Cone (P2C record) or ROA.

PathRPKI

The RPKI ROA format is extended to include a set of authorized transit ASes in the upstream part of the path. Authorized ASes in the downstream part of the path are known through local configuration. For each prefix, the two halves of the path are combined into a list of ASes that may appear in the AS path.

These paths are sent to routers using an extended version of the RPKI to router protocol. Routers mark a prefix as invalid if the origin AS doesn't match as usual, and if an extended list of ASes is present, if there are ASes in the BGP AS path that are not in the filter list (or appear in the wrong order).

So let's compare.

In-band vs out-of-band

LDM is the only mechanism that works in-band. In-band is inherently less effective because the same issues that create a route leak in the first place may also send incorrect in-band information.

Deployment

LDM: although it was supposed to be easy to deploy, discussion has been going on for four years, and in my opinion, as per my earlier email about the draft, deployment issues haven't been solved at this time.

ASPA, ASCone and PathRPKI all require changes in the RIR RPKI front- and backends and the RPKI relying party software implementations.

ASPA: requires unspecified changes to the RPKI to router protocol to convey C2P records, and for routers to implement the validation logic. (Maybe this is not necessary, but this is my best guess at this time.) If so, that may take considerable time and subsequent updates to the filtering logic will be difficult because of the slow update cycle in routers. Lack of an "unknown" validation state with partial deployment may be problematic.

ASCone: generating router filters to be included in configurations is easy to deploy, but very clumsy. Not clear how reusing the RPKI to router protocol would work. Unclear what partial deployment would look like.

PathRPKI: changes to RPKI to router protocol necessary. However, the scope of these changes is small. Good partial deployment as each combination of origin AS and destination AS is immediately protected agains route leaks even if ASes in the middle don't implement PathRPKI.

Who is involved

LDM: transit ASes. Leaf ASes that don't peer have no actions.

ASPA: All ASes. Origin ASes and transit ASes that have transit ASes of their own register C2P records. All other ASes filter based on this, most notably ASes that peer.

ASCone: Transit ASes register P2C records, ASes that peer filter based on this. Leaf ASes that don't peer have no actions.

PathRPKI: origin AS registers authorized transit ASes. No specific actions for transit ASes. ASes in the downstream part of the path filter based on this.

Security

LDM: relatively low, as a malicious AS could modify the in-band information.

ASCone: middle, as ASes can incorrectly claim a P2C relationship with no obvious recourse for the AS that is incorrectly labeled as a customer.

ASPA: high, as only customers claim the customer-provider relationship.

PathRPKI: a little higher, as the upstream part of the path is solely determined by the origin AS (however, at the cost of flexibility as transit relationship changes further upstream now require work by all the ASes downstream of the change)

What now?

There are some good ideas here, but it sure looks like we haven't figured out the best way to attack this problem. Publish four RFCs, throw them to the wall, see what sticks? Hopefully we can come up with a better process than that.

Iljitsch