[EXTERNAL] Re: Yet another BGP hijacking towards AS16509

Tue Aug 23 17:18:42 UTC 2022

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
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?  In order to get around this vulnerability, all of the Internet would have to only perform BGPsec which doesn't seem realistic.  Security solutions where everyone has to implement the control before it works effectively are rarely adopted.

-Rich

On 8/23/22, 2:49 AM, "NANOG on behalf of Job Snijders via NANOG" <nanog-bounces+rich.compton=charter.com at nanog.org on behalf of nanog at nanog.org> wrote:

    CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.

    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

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.