[EXTERNAL] Re: Yet another BGP hijacking towards AS16509

Wed Aug 24 10:55:26 UTC 2022

Heya,

On Wed, Aug 24, 2022 at 09:17:03AM +0200, Claudio Jeker wrote:
> On Tue, Aug 23, 2022 at 08:07:29PM +0200, Job Snijders via NANOG wrote:
> > In this sense, ASPA (just by itself) suffers the same challenge as
> > RPKI ROA-based Origin Validation: the input (the BGP AS_PATH) is
> > unsigned and unsecured; thus spoofable.
> 
> ASPA enforces that the neighbor AS appears as first element in the
> ASPATH. It also disallows empty ASPATHs from eBGP sessions. 

Yup, this is a helpful property of ASPA. ASPA also nukes routes which
have an AS_SET segment anywhere in the AS_PATH (which helps the
community to get a move on with https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set)
The addition of type of constraints helps keep the global Internet
routing tables clean.

> Because of this spoofing becomes harder. The problem is that this only
> works for paths that are validated by ASPA (all AS hops have been
> verified). An ASPA-unknown path can still be spoofed.

We might be talking about different types of 'spoofing'. ASPA doesn't
help verify the *authenticity* of the neighbor (or the ASes behind the
neighbor). Does the AS number transmitted in the BGP OPEN message really
belong to the entity that controls the router on the other side of the
link? Is the neighbor on the other side of the IX Route Server really
who they claim they are? ASPA doesn't solve that type of question.

Publication of ASPA records & verification of BGP UPDATES against the
published ASPA records will impose additional constraints on the global
routing table "so and so ASN should only appear behind AS X". This is
helpful, and I'm sure it'll knock down some fake paths generated by BGP
optimizers. :-)

> Spoofing will become much harder once a critical mass of infrastructure
> deployed ASPA.

I'd phrase it as "fat fingering will become even harder". :-)

Route Origin Validation based on RPKI ROAs reduced the number of BGP
routing incidents; but cynical critics could argue "silly you, you
published the exact list of Origin ASNs we need to spoof to bypass
ROV!". Similarly, publication of ASPA records tells the world what
exactly the fabricated AS_PATH should look like to bypass ASPA validation.
This is OK, it just means that ROV + ASPA is not a complete solution.

I think in-band signatures (BGPsec) are also needed to complete the
puzzle.

Kind regards,

Job