Re: [Sidrops] [GROW] Different path validation options

[Brian Dickson <[e-mail]>]

Minor clarifications/comments inline about LDM.

On Tue, Jul 9, 2019 at 8:15 AM Iljitsch van Beijnum <iljitsch=
[e-mail]> wrote:

> 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.
>

LDM marks prefixes in-band, on peer-to-peer AND on transit-to-customer
(assuming at least one party is doing LDM.)
LDM checks prefixes in-band upon receipt, on peer-to-peer AND on
customer-to-transit (assuming recipient is doing LDM.)

This prevents all of the major leak paths:
transit-customer-peer
transit-customer-transit
peer-peer-transit
peer-peer-peer

The marking is propagated if large communities are being sent, so even if
intermediate networks involved don't mark or check, the leakage is still
detectable under many scenarios.


>
> 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.
>

"send incorrect in-band information" is limited (in the latest draft) to
only "fails to send in-band information".
The only incorrect in-band information that would have any effect is if the
peer-peer marking uses the wrong ASN, at which point the recipient will
block the incoming announcements. I.e. it will treat that error as a leak.
Failure to mark, or failure to check, looks exactly the same as not
participating, and is no worse.


>
> 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.
>

The finalized versions are being discussed among the authors and will be
discussed at the Montreal meeting. Modulo uptake by providers, I believe we
are crossing the threshold to actual deployment, at which point this is
entirely in the hands of the operators.
We can lead them to water, but cannot make them drink.


>
> 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.
>

Mostly correct; we are potentially adding the ability of Leaf ASes to mark
prefixes on ingress (identical to the marking that their transit ISPs would
have marked), allowing (but not requiring) leaf ASes to allow upstreams to
detect leaks that these same leaf ASes might have caused.


>
> 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.
>

A malicious AS modifying the in-band information can only remove leak
marking, or add leak marking.
If they add leak marking, the only impact would be to block announcements
that would otherwise be accepted.

Removing leak marking would allow the malicious AS to leak, but potentially
be visible to third parties that are able to see the modification
(differentiate based on the ASN in the leak marking received on other
connections, vs AS path and absence of marking).
The latter would at least allow for non-repudiation (it would be
theoretically possible to identify the specific ASN).

Lack of protection on the AS-path is equally problematic WRT malicious ASes.

Brian


>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow
>