Yet another BGP hijacking towards AS16509

Tue Aug 23 18:03:31 UTC 2022

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 at 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-comments-20220510-201259363-pdf.pdf
>
> Kind regards,
>
> Job
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220823/8b7789b7/attachment.html>