Ketidakstabilan routing internet terjadi akibat bug pemrosesan BGP

 (blog.benjojo.co.uk)
1 poin oleh GN⁺ 2025-05-29 | 1 komentar | Bagikan ke WhatsApp
  • Bug pemrosesan pesan BGP menyebabkan ketidakstabilan routing skala besar dan putusnya konektivitas internet pada sebagian jaringan pada 20 Mei 2025
  • Penyebab masalah adalah BGP Prefix-SID Attribute yang rusak, yang memicu respons tidak lazim pada implementasi BGP utama, khususnya JunOS dan Arista EOS
  • Sejumlah carrier transit termasuk Hutchison dan Starcloud meneruskan pesan penyebab tersebut sehingga dampaknya meluas
  • Insiden ini menyebabkan reset massal sesi BGP dan ketidakstabilan pada lebih dari sekitar 100 jaringan
  • Peristiwa ini menyoroti celah dalam penanganan toleransi kesalahan BGP antar-vendor dan perlunya perbaikan

27 Mei 2025

Ketidakstabilan routing internet global akibat bug pemrosesan BGP

Pada Selasa, 20 Mei 2025 pukul 07.00 (UTC), sebuah pesan BGP tersebar dan memicu perilaku tak terduga pada dua implementasi BGP utama yang sering digunakan untuk menangani lalu lintas internet

Akibatnya, banyak ‘sesi BGP konektivitas internet’ berakhir otomatis, sehingga menimbulkan mulai dari ketidakstabilan routing minimal hingga, dalam kasus terburuk, terputusnya konektivitas sementara pada sebagian jaringan

Pesan BGP yang bermasalah

  • Analisis terhadap sesi yang dikumpulkan di bgp.tools menunjukkan bahwa pesan BGP Update yang menyebabkan fenomena ini tampak biasa, tetapi mengandung BGP Prefix-SID Attribute yang rusak dengan data internal yang diisi 0x00
  • Sebagian besar implementasi BGP (IOS-XR, Nokia SR-OS) memfilter ini dengan benar sesuai RFC7606 (BGP error handling), tetapi masalah muncul dalam interaksi antara JunOS dan Arista EOS
    • JunOS mempertahankan dan meneruskan pesan yang rusak tersebut, sementara Arista EOS mereset sesi BGP saat menerima pesan itu
  • Di lingkungan yang banyak menggunakan perangkat Juniper (JunOS), jika terhubung dengan Arista EOS, ada kemungkinan terjadi putus akses internet hingga sekitar 10 menit

Pengirim pesan bermasalah

  • Analisis arsip bgp.tools untuk periode tersebut menunjukkan bahwa beberapa origin AS terlibat

  • Ini mengindikasikan bahwa bukan jaringan pembuat Prefix yang menambahkan Attribute tersebut, melainkan carrier transit di tengah jalur propagasi

  • AS utama yang terkait dengan insiden ini adalah sebagai berikut

    • AS9304 (Hutchison Global Communications Limited)
    • AS135338 (Starcloud Information Limited)
    • AS151326 (DCConnect Communication Pte. Ltd.)
    • AS138077 (PT Abhinawa Sumberdaya Asia)

  • Berdasarkan data bgp.tools, pihak yang kemungkinan besar benar-benar menambahkan Attribute itu adalah Starcloud (AS135338) atau Hutchison (AS9304)

  • Prefix representatif yang menyebarkan Attribute tersebut antara lain 156.230.0.0/16 dan 138.113.116.0/24

  • Hutchison/AS9304 terhubung ke banyak internet exchange (IX), dan pesan tersebut juga tersebar ke route server yang menggunakan bird

  • Bird tidak mendukung BGP SID, sehingga mengirimkan pesan itu ke banyak IX tanpa pemfilteran, yang memperparah kekacauan pada skala jaringan

Apa itu BGP Prefix-SID?

  • BGP Prefix-SID Attribute pada umumnya seharusnya hanya digunakan pada sesi BGP internal, dan dipakai untuk mendefinisikan jalur menuju tujuan di dalam satu jaringan (RFC8669)
  • Kebocoran Attribute ini ke global routing table mungkin terjadi ketika sesi BGP eksternal dikonfigurasi seolah-olah merupakan sesi internal

Pihak yang terdampak

  • Sulit mengidentifikasi korban secara tepat, tetapi masalah terkonfirmasi pada sekitar 100 jaringan yang menunjukkan churn sangat besar setelah pesan BGP awal
  • Dalam kondisi normal, route collector bgp.tools mengumpulkan 20–30 ribu pesan per detik, tetapi pada saat insiden angkanya tercatat lebih dari 150 ribu per rata-rata 10 detik
  • Angka ini menjadi sinyal bahwa telah terjadi gangguan serius pada rute internet yang luas

Tanggung jawab vendor dan implikasinya

  • Walaupun penyebab akar yang pasti belum jelas, fakta bahwa pesan yang salah dapat menyebar pada skala internet membuktikan bahwa masalah lama dalam penanganan error BGP adalah risiko nyata
  • Vendor lain memfilter Attribute bermasalah tersebut, tetapi Juniper secara tidak langsung mengizinkannya lewat dan meneruskannya ke perangkat Arista, yang kemudian memicu reset sesi akibat kurang matangnya kode toleransi kesalahan BGP
  • Dokumentasi resmi JunOS juga menyatakan bahwa “seluruh pesan tidak diperiksa sepenuhnya”
  • Dengan desain seperti ini, JunOS memang mencegah risiko reset sesi jarak jauh pada dirinya sendiri, tetapi tetap berpotensi meneruskan pesan bermasalah ke peer lain atau pelanggan

Kesimpulan

  • Insiden ini memang berlangsung singkat, tetapi menunjukkan bahwa dampaknya bisa menjadi jauh lebih serius jika skalanya membesar

  • Seiring layanan makin berpusat pada IP, dampak gangguan internet dapat meluas melampaui sekadar tidak bisa mengakses email konsumen, hingga kegagalan siaran TV dan panggilan layanan darurat yang tidak tersambung

  • Karena itu, kebutuhan akan implementasi toleransi kesalahan BGP yang andal pada tiap vendor kembali ditekankan, mengingat ada kemungkinan realistis terjadinya korban jiwa nyata

  • Disampaikan pula kemungkinan partisipasi operator jaringan yang ingin membantu analisis data bgp.tools (tautan tersedia)

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-29
Opini Hacker News

  • Secara umum, prinsip "bersikap longgar saat menerima, spesifik saat mengirim" dikenal sebagai pendekatan standar

    • Ada beberapa pilihan, seperti membuang pesan yang rusak (drop, filter), mengabaikan hanya atributnya lalu tetap meneruskan (break), atau memutus koneksi itu sendiri (seperti Arista)

    • Saya menganggap opsi keempat (cara Arista) benar-benar perilaku yang sulit diterima

    • Opsi ketiga (Juniper) juga tidak ideal, tetapi menurut saya tidak bisa dibilang masalah yang fatal

    • Edit: setelah membaca ulang, ternyata Arista bukan yang keempat melainkan yang kedua (mengakhiri koneksi)

    • Mereka hanya menganggap koneksinya tidak valid lalu menutupnya, dan meski ini bukan keputusan yang bagus dari sisi pengalaman pengguna, kesannya masih bisa diterima

    • RFC 7606 (enhanced error handling for BGP UPDATE messages) sebenarnya sudah ada, dan secara spesifik menjelaskan bagaimana menangani pesan yang rusak

      • Metode yang paling umum adalah treat-as-withdraw (menangani seolah rute tersebut telah di-withdraw)
      • Jika pesan yang rusak begitu saja diabaikan, state sebelumnya bisa tetap dipertahankan padahal sebenarnya sudah tidak valid

    • Prinsip "terima secara longgar dan kirim secara spesifik" itulah yang biasa disebut sebagai "robustness principle" atau "Postel's law"

      • Prinsip ini berasal dari masa awal internet pada era 1980-an hingga 1990-an
      • Namun sekarang industri secara luas menyadari bahwa ini adalah cara berpikir yang keliru
      • Prinsip tersebut menyebabkan protocol ossification dan tak terhitung banyaknya masalah keamanan

    • Dengan memanfaatkan karakteristik cara kerja BGP, pernah muncul berbagai masalah di seluruh jaringan karena perangkat lokal dapat meneruskan atribut yang tidak dikenalnya begitu saja

      • Kini kita sedang mengalami realitas ketika sisi buruk dari "fitur" semacam ini mulai terlihat

    • Penulis juga menyinggung hal ini dalam tulisan terkait

      • "Fitur" ini tampak seperti ide yang sangat buruk karena membuat sistem meneruskan data yang tidak dipahaminya tanpa kritik
      • Namun berkat fitur ini, kemampuan baru seperti Large Communities bisa menyebar dengan cepat, dan ada sisi yang memungkinkan adopsi fitur-fitur BGP baru

    • Saya tidak setuju dengan pendekatan ini

      • Menurut saya jauh lebih baik jika kita bersikap ketat dan spesifik, baik untuk apa yang diterima maupun yang dikirim

  • Saya masih ingat betapa gilanya kesibukan saat harus menambal bug CVE-2023-4481 di seluruh jaringan

    • Bug jenis ini akan tetap jadi mimpi buruk untuk ditangani ke depannya
    • Mengingat sifat desain dan implementasi BGP, saya khawatir butuh waktu sangat lama untuk memperbaiki perilaku seperti ini

  • Saya pernah mengembangkan fitur BGP di vendor perangkat telekomunikasi pada masa lalu (ini cerita yang sudah cukup lama)

    • Sampai sekarang saya masih merasa BGP terlalu kompleks

    • Orang-orang terus menambahkan fitur baru, dan vendor berulang kali mengimplementasikannya agar sesuai standar atau draft

    • Karena rasanya BGP tidak akan pernah pensiun, bug seperti ini juga terasa akan terus berulang

      • Dulu operator seperti AT&T dan vendor seperti Juniper, Cisco, dan lainnya juga mendorong penggunaan BGP untuk fitur MPLS dan VPN, sehingga sistem tenggelam dalam kompleksitas yang mendalam
        • Terlalu kompleks, tetapi sebagian orang menghasilkan banyak uang dari situ

  • HGC Global Communications Limited (berganti nama dari Hutchison Global Communications Limited, disingkat HGC) adalah penyedia layanan internet di Hong Kong

  • Rasanya BGP akan jauh lebih stabil untuk isu-isu seperti ini jika berbagai vendor hardware menyelaraskan standar mereka

    • Saya jadi penasaran apakah masalah sebenarnya adalah tiap vendor enggan melakukan standardisasi demi mengunci pelanggan ke ekosistem mereka sendiri
    • Sebagai catatan, pemahaman saya tentang BGP masih dangkal

  • Entah cuma saya atau tidak, tapi saya bahkan belum pernah mendengar BGP sampai ada kabar bahwa ia menyebabkan masalah

    • Ini adalah protokol yang penting bagi internet seperti TCP/IP, tetapi sementara TCP/IP banyak dipelajari di sekolah, karier, dan buku, saya tidak pernah sekali pun benar-benar membahas BGP
    • Saya bisa belajar dan bereksperimen dengan TCP/IP di rumah, tetapi saya sama sekali tidak tahu bagaimana "main-main di rumah" dengan BGP

      • Kalau ada cara untuk berlatih BGP di rumah, saya penasaran seperti apa

      • Anda bisa membeli router nyata yang memiliki implementasi BGP (yang murah misalnya perangkat Mikrotik), atau memakai implementasi open source

        • Ada bird yang disebut di artikel, dan FRR (Free Range Routing) yang sangat populer
        • Anda bisa menjalankan dua container Docker dan membentuk sesi BGP lalu menyebarkan static route dan sebagainya
        • Jika ingin tutorial, panduan di tautan ini tersusun rapi dan bisa diikuti dengan software gratis

      • DN42 adalah taman bermain untuk berlatih teknologi routing

        • Namun ini butuh investasi waktu, jadi bukan sesuatu yang bisa dicoba secara santai
        • Saya sendiri cukup sering menangani networking, tetapi routing WAN masih membingungkan bagi saya
        • GNS3 adalah cara termudah untuk langsung berlatih teknologi networking apa pun
        • Wiki DN42

      • Di mata kuliah jaringan saat sarjana saya tidak belajar BGP, tetapi saya mempelajarinya di kelas pascasarjana

        • Kami menggunakan paket Python yang bisa mensimulasikan beberapa AS, tetapi saya tidak ingat nama paketnya secara tepat

      • Di kelas jaringan sarjana yang saya ambil, BGP hanya disebut singkat di papan tulis

        • Untuk praktik BGP, Anda bisa memakai simulator jaringan seperti yang digunakan penulis
        • Di kelas kami, kami memakai simulator bernama gini, program buatan mahasiswa pascasarjana dosen kami
        • gns3 yang dipakai penulis terasa seperti ns3 yang berfokus pada Cisco
        • ns3 terasa sulit karena banyak yang harus dipelajari
        • gini punya antarmuka yang lebih mudah, tetapi performanya cenderung lebih rendah
        • Info proyek gini
        • Dokumentasi resmi gns3

      • Rasanya Anda baru benar-benar bisa "berlatih" BGP jika mengelola jaringan besar yang terhubung ke lalu lintas internet nyata

        • Yang bisa dicoba di rumah pada dasarnya hanya menggunakan simulator jaringan

  • Dulu beberapa vendor juga pernah mengalami bug serupa dengan yang ada di artikel utama

    • Info kerentanan keamanan terkait
    • CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd), CVE-2023-40457 (EXOS), dan lain-lain
    • Arista adalah vendor yang saat itu tidak terdampak

  • Kami juga pernah menerima paket serupa pada chassis IOS XR kami

    • Pada saat yang sama, kami juga mengalami banyak iklan rute BGP

    • Saya tidak tahu pasti perangkat upstream-nya apa

    • Saya jadi penasaran apakah protokol BGP benar-benar diuji dengan fuzzing secara memadai

    • Mungkin karena ini protokol yang sangat penting, orang jadi tidak berani sengaja memicu gangguan

    • Menulis fuzzer untuk BGP mungkin mudah, tetapi diagnosis crash-nya bisa sangat sulit

      • (penulis artikel)
        • Ya, justru itulah yang benar-benar saya lakukan dalam postingan saya
        • Posting terkait

  • Ini membuat saya bertanya-tanya apakah pernah ada sistem lain yang sebesar backbone internet dan menumpuk begitu banyak kompleksitas tak disengaja

  • Mengingat besarnya dampak bug seperti ini, saya kira pasti ada konsorsium yang menjalankan semacam interoperability test suite, jadi ini cukup mengejutkan

    • Atau mungkin itu memang ada, hanya saja masalah ini luput dari cakupan pengujian
    • Rasanya sudah sewajarnya menggunakan fuzzer atau mesin untuk menghasilkan berbagai test case dari semua kemungkinan error paket agar cakupan pengujian lebih tinggi
    • Tidak masalah meskipun waktu eksekusinya sampai berhari-hari
    • Penulis artikel memang benar-benar membuat dan menggunakan fuzzer, dan beberapa kali menemukan masalah serupa
    • Agak aneh rasanya bahwa vendor tidak menunjukkan minat yang lebih aktif terhadap riset penting seperti ini