Re: [EXTERNAL] Re: Yet another BGP hijacking towards AS16509

[Job Snijders via NANOG <nanog () nanog org>]

On Tue, Aug 23, 2022 at 05:18:42PM +0000, Compton, Rich A wrote:
> I was under the impression that ASPA could prevent route leaks as well
> as path spoofing.  This "BGP Route Security Cycling to the Future!"
> presentation from NANOG seems to indicate this is the case:
> https://youtu.be/0Fi2ghCnXi0?t=1093 

I'm not sure how ASPA can prevent AS Path spoofing. Perhaps something
got lost in translation?

ASPA records are published in the RPKI, from there a RPKI RP transforms
the ASN.1/X.509/crypto stuff into something 'plain text'. This 'plain
text' data is loaded into EBGP routers via RTR, which then compare the
*plain text* AS_PATH attribute to the table of plain-text ASPA records,
to determine if it came via an authorized upstream provider or not.

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.

> Also, can't the path spoofing protection that BGPsec provides be
> defeated by an attacker advertising a hijacked prefix with a forged
> AS_PATH without BGPsec?

An attacker certainly can try to announce hijacked prefixes with a
forged AS_PATH (knowing that BGPsec-protected paths also exist). But the
attacker has no influence on the local routing policy of other networks.
I imagine that in a 'partial BGPsec' deployment future some operators
might opt to assign a higher LOCAL_PREF to BGPSec secured paths; or
apply a form of 'peerlock' ("I only accept routes with so-and-so ASN if
seen via BGPsec secured paths); this is an area of future study.

> In order to get around this vulnerability, all of the Internet would
> have to only perform BGPsec which doesn't seem realistic.

The vulnerability is "if the operator configures their routers to use
non-signed paths, the operator choose to use a non-signed path" (I hope
this makes sense).

> Security solutions where everyone has to implement the control before
> it works effectively are rarely adopted.

Fully agreed. Fortunately, I see a number of scenarios in which a partial
deployment of BGPsec benefits those who deployed it. Ultimately BGPsec
deployment is a 'selfish' act, as in that the benefits are immediate to
the two adjacent networks using BGPsec to protect the paths between
then.

Perhaps I should prepare a NANOG presentation to outline why BGPsec does
not require 100% deployment to be beneficial?

Kind regards,

Job