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
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
