Analisis anomali BGP yang terjadi di Venezuela

 (blog.cloudflare.com)
1 poin oleh GN⁺ 2026-01-09 | 1 komentar | Bagikan ke WhatsApp
  • Beberapa kali terjadi kebocoran rute BGP (route leak) di jaringan CANTV (AS8048) di Venezuela, sehingga sebagian jalur jaringan tersebar secara tidak normal
  • Menurut data Cloudflare Radar, sejak Desember telah terkonfirmasi 11 kejadian kebocoran, dan ini sangat mungkin merupakan kesalahan teknis akibat kebijakan routing yang tidak memadai
  • Insiden ini berbentuk AS8048 meneruskan kembali rute yang diterima dari penyedia hulu AS6762 (Sparkle) ke penyedia lain AS52320 (V.tal GlobeNet), sebuah struktur khas Type 1 hairpin leak
  • Validasi asal rute berbasis RPKI (ROV) tidak efektif untuk kasus ini, dan standar baru seperti ASPA (Autonomous System Provider Authorization) serta RFC9234 diperlukan untuk mencegah kebocoran semacam ini
  • Karena struktur BGP berbasis kepercayaan, insiden seperti ini umum terjadi, dan penerapan teknologi seperti ASPA, Peerlock, dan RFC9234 menjadi kunci pengoperasian Internet yang aman

Konsep kebocoran rute BGP

  • BGP (Route Gateway Protocol) adalah protokol untuk bertukar rute antar autonomous system (AS) di Internet
    • Relasi antarjaringan dibentuk dalam pola customer-provider atau peer-peer
  • Kebocoran rute (route leak) didefinisikan dalam RFC7908 sebagai “penyebaran informasi routing melampaui cakupan yang dimaksudkan”
    • Contoh: pelanggan menyebarkan kembali ke penyedia lain rute yang diterimanya dari penyedia
  • Kebocoran seperti ini merupakan pelanggaran terhadap aturan valley-free routing, sehingga trafik bergerak melalui jalur yang tidak normal
    • Akibatnya dapat muncul masalah seperti kemacetan jaringan, latensi, dan kehilangan trafik

Kasus kebocoran rute AS8048 (CANTV)

  • Cloudflare Radar mengonfirmasi bahwa AS8048 (CANTV) meneruskan kembali rute yang diterima dari AS6762 (Sparkle) ke AS52320 (V.tal GlobeNet)
    • Ini merupakan bentuk route leak yang jelas
  • Asal rute yang bocor adalah AS21980 (Dayco Telecom), yaitu jaringan pelanggan dari AS8048
    • Relasi antara kedua AS tersebut dikonfirmasi sebagai relasi provider-customer melalui data Cloudflare Radar dan bgp.tools
  • Pada jalur tersebut, AS8048 diprepend berkali-kali (multiple prepend)
    • Prepend adalah teknik untuk membuat suatu jalur kurang menarik agar trafik diarahkan ke jalur lain
    • Karena itu, kemungkinan MITM (serangan man-in-the-middle) yang disengaja rendah
  • Kebocoran terjadi beberapa kali antara 2 Januari 2026 pukul 15:30 hingga 17:45 UTC, dan kemungkinan merupakan akibat kesalahan kebijakan jaringan atau masalah konvergensi
  • Menurut catatan Cloudflare Radar, sejak Desember telah berulang 11 kebocoran serupa, sehingga dinilai sebagai kekurangan kebijakan yang berkelanjutan

Penyebab teknis dan masalah kebijakan

  • Ada kemungkinan AS8048 mengatur kebijakan export routing secara longgar terhadap provider AS52320
    • Jika hanya menggunakan prefix list berbasis IRR alih-alih tag komunitas BGP pelanggan, retransmisi rute yang keliru bisa terjadi
  • Kesalahan kebijakan seperti ini dapat dicegah melalui atribut Only-to-Customer (OTC) dari RFC9234
    • OTC secara eksplisit mendefinisikan peran BGP (pelanggan, penyedia, peer) untuk memblokir penyebaran rute yang keliru

Peran RPKI dan ASPA

  • Sparkle (AS6762) belum sepenuhnya mengimplementasikan RPKI Route Origin Validation (ROV),
    • namun insiden ini adalah anomali jalur (path) sehingga tidak dapat dicegah dengan ROV
  • ASPA (Autonomous System Provider Authorization) menyediakan validasi berbasis jalur
    • Setiap AS menyatakan daftar provider hulu yang diotorisasi, sehingga jalur abnormal dapat diblokir secara otomatis
    • Contoh: jika AS6762 menyatakan “tidak ada provider hulu”, jaringan lain dapat menolak jalur keliru yang memuat AS6762
  • ASPA bekerja berbasis RPKI dan memiliki efektivitas langsung dalam mencegah route leak

Usulan untuk membangun BGP yang aman

  • BGP pada dasarnya adalah protokol berbasis kepercayaan, sehingga kebocoran akibat kesalahan kebijakan atau kekeliruan operasional sering terjadi
  • Jika teknologi seperti ASPA, RFC9234, dan Peerlock/Peerlock-lite diterapkan secara bersamaan, maka
    • validasi jalur dapat diperkuat
    • penyebaran rute yang salah dapat diblokir
    • stabilitas jaringan dapat ditingkatkan
  • RIPE sudah mendukung pembuatan objek ASPA, dan
    • operator perlu menyampaikan permintaan implementasi RFC9234 kepada vendor perangkat jaringan
  • Penerapan standar kolaboratif seperti ini merupakan sarana utama untuk mencegah insiden BGP seperti kasus Venezuela

Bacaan terkait

1 komentar

 
GN⁺ 2026-01-09
Opini Hacker News

  • Alur komentar di sini agak tak terduga. Semua orang membicarakan ketakutan terhadap perusahaan Amerika, tetapi tampaknya tidak terlalu terkait dengan isi artikelnya
    Tulisan Cloudflare hanya menjelaskan cara kerja BGP dan menyoroti bahwa route leak dari ISP Venezuela sering terjadi
    Tentu saja Cloudflare bisa saja salah atau menyembunyikan sesuatu, tetapi tidak ada bagian mana pun di artikel yang mengatakan mereka terlibat langsung. Saya penasaran dasar keyakinan orang-orang itu apa

    • Menurut saya tidak ada bukti yang layak ditakuti di artikel ini
      Namun, melihat kasus Stuxnet dan Dual EC DRBG, kita tidak boleh meremehkan kemampuan pemerintah dalam memanfaatkan 0-day
      Teman saya pernah bekerja di perusahaan FANG, dan katanya ia melihat perusahaan memberikan stream data secara langsung ke pemerintah. Backdoor ISP juga nyata (Room 641A)
      Jika Cloudflare memang bekerja sama berdasarkan surat perintah, apakah mereka secara hukum bisa menulis artikel yang menyangkalnya?
      Karena itu saya rasa muncul skeptisisme dasar dari orang-orang. Kesimpulan Cloudflare bahwa “ini masalah lama jadi bukan hal besar” terasa agak lemah
    • Saya juga punya pertanyaan yang sama. Saya tidak paham bagaimana artikel ini bisa langsung dikaitkan dengan campur tangan pemerintah AS
      Saya juga penasaran apakah dalam struktur BGP memang ada alasan yang membuat AS lebih mudah melakukan hal seperti ini dibanding negara lain
    • Mungkin kebanyakan orang hanya menilai dari judul. Selain itu, ada latar belakang historis bahwa AS memang pernah melakukan hal-hal seperti ini di masa lalu
      Opini publik terhadap pemerintah AS belakangan sangat sinis, jadi insiden kecil pun mudah dicurigai
      Atau mungkin itu cuma akun sosial Rusia atau China, siapa yang tahu
    • Beberapa hari lalu juga ada tulisan serupa — postingan loworbitsecurity yang menghubungkan teori invasi Venezuela dengan anomali BGP
      Lalu ada juga artikel CNN yang menyebut Trump membahas kemungkinan aksi militer bahkan terhadap sekutu
      Dengan pemerintahan yang sekarang, rasanya mereka malah akan membanggakan serangan semacam ini secara terbuka. Jadi saya cenderung percaya ini sekadar “kesalahan konfigurasi”
      Meski begitu, wajar kalau ketidakpercayaan publik membesar karena setiap kali AS muncul di berita belakangan ini isinya ancaman, penarikan diri, atau sanksi

  • Meski sedang mengantuk, saya merasa artikel ini menarik. Analisis AS path prepending sangat mendukung teori “kecelakaan”
    Jika negara memang ingin mencegat trafik, tidak ada alasan untuk sengaja membuat jalurnya lebih panjang
    Kemungkinan besar ini hanya kesalahan konfigurasi routing biasa. BGP masih merupakan sistem berbasis kepercayaan, jadi satu typo kecil saja bisa berdampak global
    Filter ekspor yang terlewat terasa sebagai penjelasan yang lebih masuk akal daripada niat jahat

    • Ada juga bantahan bahwa “aktor negara pun bisa saja sengaja menambahkan padding path yang salah”
      Memang ada juga aktor non-negara yang mencoba memanipulasi trafik iklan
      Tapi dari sudut pandang operator jaringan, kesalahan seperti ini umum terjadi, dan skrip penyesuaian trafik otomatis kadang memperbesar masalah
      Pada akhirnya, masalahnya adalah kerentanan struktural BGP. Keamanan dan BGP masih terasa seperti dua kata yang tidak cocok disandingkan

  • Salah satu dokumen Snowden, NSA Network Shaping 101, layak dijadikan referensi
    Dokumen itu ditulis pada 2007 dan menjelaskan ASIN serta kontrol trafik layer 3

    • Namun “layer 3 shaping” di dokumen ini tampaknya tidak terlalu berkaitan dengan anomali BGP
      Isinya lebih sekadar menjelaskan struktur di mana trafik ke IP tertentu akan melewati link tersebut
    • Lucunya, bahkan NSA pun salah memakai konsep ASN. Rasanya seperti bilang “tetangga saya tinggal di string ‘123 Main Street’”

  • Setelah membaca artikelnya, saya kembali merinding melihat betapa dalamnya keterikatan perusahaan Amerika dengan pemerintah
    Ini memang sudah lama saya tahu, tetapi kali ini rasanya kepercayaan benar-benar runtuh. Seperti titik balik zaman

    • Dulu saya punya teman yang bercerita soal penyadapan legal, dan saya ingat ekspresinya langsung mengeras saat membahasnya
      Infrastruktur pengawasan seperti ini sudah ada sejak lama, dan Jepang pun melakukan pemantauan trafik real-time pada 2003
      Sekarang teknologi DPI terlalu mudah untuk diimplementasikan
    • Siklus ketidakpercayaan seperti ini rasanya berulang tiap 10 tahun
      Orang-orang baru di industri memulai dengan polos, tetapi akhirnya menyadari kedekatan pemerintah dan korporasi lalu kehilangan kepercayaan
      Setelah waktu berlalu, generasi baru kembali mengulangi proses yang sama
    • Menganggap Cloudflare sedang menutupi operasi pemerintah AS terasa seperti tafsir yang berlebihan
      Inti tulisan itu adalah pisau cukur Hanlon: curigai kesalahan sebelum menganggap ada niat jahat
      Tentu saja jika Cloudflare memelintir fakta, mereka patut dikritik, tetapi belum ada buktinya
    • Bahwa “perusahaan terikat dengan pemerintah” itu sama saja di negara mana pun. Bukan hal baru

  • Kalau melihat infrastruktur Venezuela yang sudah tua, rasanya apakah perlu sampai serangan siber canggih?
    Kenyataannya justru kontraktor korup mengirimkan sistem asal-asalan

    • Sebenarnya di negara seperti itu, dengan beberapa puluh ribu dolar saja sudah bisa membeli orang yang akan memanipulasi switch secara langsung
      Dibanding serangan siber, struktur korupsi jauh lebih besar masalahnya
    • Saya sendiri pernah memakai CANTV, dan pemasangan saluran telepon butuh 9 tahun setengah
      Pada akhirnya saya menyelesaikannya dengan membayar teknisi yang bekerja di jalan, dan nomor itu ternyata nomor perusahaan taksi
      Dalam lingkungan seperti ini, membahas serangan BGP terasa agak hampa
    • Serangan terhadap jaringan listrik yang benar-benar pernah terjadi sebenarnya tidak ada hubungannya dengan BGP. Ini tampak seperti kesalahan jaringan biasa

  • Tulisan ini merupakan ulasan BGP yang bagus
    Saat dulu bekerja sebagai network engineer, saya sering memakai BGP community magic,
    dan kadang saya berpikir mungkin BGP akan jauh lebih sederhana kalau hanya mengekspresikan tiga jenis: provider, customer, dan peer

    • Benar, itu akan jauh lebih sederhana, tetapi sederhana tidak selalu lebih baik
      Ini seperti menghapus data lalu lintas dan lampu merah dari Google Maps: perhitungannya jadi mudah, tetapi hasilnya berantakan

  • Dulu Google Maps pernah mengarahkan saya dari jalan tol ke parkiran Walmart lalu ke jalan tol lain
    Saat itu saya menganggapnya sebagai bug algoritme biasa, tetapi kalau diarahkan ke drive-thru McDonald’s mungkin saya akan curiga ada konspirasi
    Kejadian kali ini juga terasa mirip; melihatnya sebagai kesalahan sederhana lebih meyakinkan

    • Alasan BGP route leak tidak lebih sering terjadi adalah berkat filtering dari ISP lain. Kesalahan ternyata jauh lebih mudah terjadi daripada yang dibayangkan

  • Agak menakutkan bahwa infrastruktur inti internet dioperasikan dengan berpusat pada perusahaan Amerika
    Sekarang negara lain juga perlu membangun struktur yang mandiri

    • Namun internet itu sendiri pada dasarnya dibangun oleh militer, universitas, dan perusahaan Amerika, jadi sebenarnya tidak terlalu mengejutkan
      Jadi saya penasaran, siapa yang seharusnya mengelolanya sebagai pengganti
    • Eropa sebenarnya juga bisa membangun perusahaan seperti Cloudflare, tetapi masalahnya ada pada brain drain dan kurangnya investasi
    • Internet pada dasarnya terdesentralisasi. Tidak ada yang namanya router BGP sentral

  • Saya sudah lama mengamati insiden BGP, dan selalu merasa sulit membedakan antara perubahan yang disengaja, kesalahan, dan gangguan struktural
    Karena itu saya biasanya mengajukan tiga pertanyaan lebih dulu: apakah cakupan dampaknya makin meluas, apakah path berubah secara simetris, dan apakah pemulihannya rapi
    Lalu saya melihat perubahan AS-path prepending lebih dulu, dan membandingkan visibilitas per wilayah
    Terakhir, saya menelusuri “siapa yang diuntungkan”. Saya penasaran metrik apa yang dipakai orang lain untuk mendeteksi masalah seperti ini

  • Cakupan global Cloudflare memang sangat mengesankan

    • Tapi justru itu terasa sebagai konsentrasi yang berbahaya bagi dunia. Perusahaan non-AS sekarang harus mulai mandiri
    • Jika memakai jaringan anycast, BGP bisa diamati dari banyak titik, jadi ini bukan kemampuan eksklusif Cloudflare
      Hanya saja mereka memang organisasi yang berfokus pada engineering, jadi mereka pandai memublikasikan analisis seperti ini
    • Sebenarnya siapa pun bisa melakukan analisis serupa lewat RIPE RIS
    • Cloudflare punya banyak sumber daya, dan sejujurnya memang perusahaan yang hebat