[Sidrops] Re: Mitigation policy for ASPA Downstream Invalid / draft-ietf-sidrops-aspa-verification-25

[Maria Matejka <[e-mail]>]

On Tue, Jun 16, 2026 at 03:35:26PM +0000, Job Snijders wrote:

> On Tue, Jun 16, 2026 at 04:57:17PM +0200, Maria Matejka wrote:
>
> > I'd like to suggest updating Sec. 5.6 of current draft-ietf-sidrops-aspa-verification-25
> > by adding a new paragraph:
> > 
> >     Note: When receiving all routes from geographically close Providers,
> >     none of which has deployed ASPA verification yet, it may happen that
> >     all received routes for a specific prefix are a result of the same
> >     route leak or misconfiguration farther from the recipient. That may,
> >     in turn, result into rendering all routes Downstream Invalid, even
> >     though there may be an acceptable path, which has been hidden by the
> >     best route selection algorithms at the providers. There is no clear
> >     recommendation what to do in such situations, as dropping the route
> >     may lead to unnecessary unreachability in case of misconfiguration,
> >     or to allowing a hijack in case of an attempted hijack.
> 
> To me the above text is not an improvement and I think it should not be
> added to the ASPA verification draft. It can be summarized as "List all
> your providers in your ASPA". In fact, this already is part of the ASPA
> specifications, I quote from draft-aspa-profile, section 1:
> 
> 	"When the Customer AS makes use of multiple providers,
> 	 all Provider ASes are to be listed in the ASPA object"

This is irrelevant.

The scenario is simple. Pick some prefix which is far enough so that it
is not available from your customers or peers. The only routes you get
for this prefix are from your providers. All these routes are working
but they are also ASPA Downstream Invalid.

Here is also a picture for better understanding:

              /----------- transit T (depreferenced)
             /             /                      \
            /-----------) / (--------\              \
       provider A    provider B --- leaker L --- provider P
            |        /                               |
    affected network N                           originator O
    (the only ASPA-verifying)

Providers A and B have routes L-P-O and T-P-O available. Transit is
paid, they prefer L-P-O based on local pref. Affected network N gets
A-L-P-O and B-L-P-O. The route works because the leaker forwards traffic
on the data plane. There is no ASPA misconfiguration. There is a leak.

By dropping the routes for that prefix (all invalid), you are actively
degrading your connectivity. The users and the sales department are not
impressed by you shooting your own leg by ASPA and blaming somebody
far away on the path.

That is the whole point of my proposal, which would probably deserve
even a stronger wording, like this:

    If none of the Providers of a network have deployed ASPA
    verification yet, a route leak or misconfiguration may render all
    available routes for a specific prefix Downstream Invalid, even
    though the traffic is forwarded. It is RECOMMENDED to consider such
    routes eligible for route selection as a last resort, with a very
    low value of the LOCAL_PREF BGP attribute.

That would fix the problem, and as soon as any of the providers deploys
ASPA, they start sending down valid routes, and the depreferenced routes
get disused anyway, even if the operators don't notice right away.

> >     Informative reference: https://ripe92.ripe.net/programme/meeting-plan/sessions/109/ZT9NYU/
> 
> This reference is not informative and demonstrates an unfortunate
> misunderstanding of what transpired. The presenter does not correctly
> attribute where the problem resided: the problem was a misconfigured
> ASPA.

This is, first of all, irrelevant, see above.

Also it is wrong. You may check in the public records that the leaker
is yet again not included neither in the AS holder's ASPA Provider list,
nor in their RPSL records.

> The confirmation that a misconfigured ASPA was the root cause was
> confirmed by the publicly visible solution: a new ASPA was issued that
> this time around listed all the AS holder's providers.

A new ASPA was obviously a temporary hotfix of the connectivity, because
it was the easiest way in this very specific case.

> (If the problem
> had been a 'leak', obviously the AS holder would've shut down the EBGP
> sessions with the leaker.

This is a wrong assumption of what is a suitable temporary hotfix
for traffic restoration in that exact case.

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.