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

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

I was thinking a little about this case... I'm almost certain that this case cited by Siyuan would have been avoided if there was a cross-check between the items contained in the AS-SET objects (and others such as the Route-Set), and the "member-of" attributes of the referred objects. I participated in a small exchange of ideas about this, and there were questions about whether this crosscheck should be done by the consumer of the IRR data, or if it should be validated at the time of insertion in the base through NRTM. Em ter., 23 de ago. de 2022 às 05:50, Job Snijders via NANOG < nanog@nanog.org> escreveu:

Dear Siyuan, others,

Thank you for the elaborate write-up and the log snippets. You contributed a comprehensive overview of what transpired from a publicly-visible perspective, what steps led up to the strike.

I want to jump in on one small point which I often see as a point of confusion in our industry:

On Tue, Aug 23, 2022 at 01:54:50AM +0200, Siyuan Miao wrote:

...

Nowadays hijacking a service by forging AS path is pretty easy and RPKI won't be able to solve this (as it validates origin AS and prefixes only) :-(

I do think RPKI can help solve this! The "RPKI" is a cryptographically secured distributed database of authorizations for Internet Resource Numbers (IP addresses & AS numbers). (((yikes, that's a mouthful :-)))

Another way of looking at the RPKI is as a "general purpose framework", a framework on top of which the Internet community can build multiple "applications". These applications include:

A) Route Origin Validation (aka "BGP Prefix Origin Validation", RFC 6811) B) BGPSec (AS Path validation, RFC 8205) C) ASPA (draft-ietf-sidrops-aspa-{profile,verification}, combating routeleaks by publishing what ASNs are your upstreams) D) .. and others: https://datatracker.ietf.org/wg/sidrops/documents/

Nowadays Item A ("BGP Origin Validation") is widely deployed: all major IP Transit carriers & major IX Route Server operators use RPKI ROAs to filter out BGP announcements which have the wrong BGP Origin AS in the AS_PATH. This is fantastic (and relatively recent) news!

Item B ("BGPsec") and C ("ASPA") are "work in progress": people are building software, running experiments, studying what it would take to get those technologies deployed in the wild (the 'production Internet').

BGPSec and ASPA are complementary solutions, each has its challenges and opportunities. BGPsec prevents path spoofing, while ASPA can prevent route leaks. These are similar but not identical threats that are often conflated. ASPA and BGPsec should not be thought of as mutually exclusive or incompatible; both of these technologies will support routing security in the long term.

I recently co-authored an elaboration to the FCC on where the industry stands and how some technologies relate to each other, this might be of interest to some folks:

https://sobornost.net/~job/fastly-fcc-noi-secure-internet-routing-reply-comm...

Kind regards,

Job

-- Douglas Fernando Fischer Engº de Controle e Automação