Bug Pemrosesan BGP Menyebabkan Ketidakstabilan Routing Internet

 (blog.benjojo.co.uk)
1 poin oleh GN⁺ 2025-05-29 | 1 komentar | Bagikan ke WhatsApp
  • Pada 20 Mei 2025 pukul 07:00 UTC, sebuah pesan BGP yang rusak yang menyebar memicu perilaku tak terduga pada dua implementasi utama, menyebabkan banyak sesi BGP yang terhubung ke internet direset dan pada beberapa jaringan terjadi ketidakstabilan routing atau kehilangan koneksi singkat
  • Update bermasalah tersebut membawa BGP Prefix-SID Attribute yang umumnya tidak diharapkan muncul dalam update BGP internet, dan berada dalam kondisi rusak dengan seluruh data internal bernilai 0x00
  • IOS-XR/Nokia SR-OS yang menerapkan toleransi error berbasis RFC7606 memfilternya, tetapi JunOS meneruskannya dan Arista EOS mereset sesi, sehingga berpotensi memengaruhi pengguna Arista yang terhubung ke transit carrier berbasis JunOS
  • Dalam pengamatan bgp.tools, AS9304, AS135338, AS151326, dan AS138077 muncul berulang kali, dan pihak yang menambahkan atribut cacat kemungkinan besar adalah Starcloud AS135338 atau Hutchison AS9304
  • Selama insiden, rata-rata 10 detik laju pesan route collector bgp.tools melonjak dari kondisi normal 20.000–30.000 per detik menjadi lebih dari 150.000/s, menunjukkan bahwa perbedaan penanganan error BGP dapat mengguncang stabilitas rute internet nyata

Insiden Update BGP 20 Mei 2025

  • Pada Selasa, 20 Mei 2025 pukul 07:00 UTC, sebuah pesan BGP yang menyebar memicu perilaku tak terduga pada dua implementasi BGP utama yang sering digunakan untuk meneruskan trafik internet
  • Dampaknya meluas ketika banyak sesi BGP yang terhubung ke internet otomatis ditutup
    • Pada beberapa jaringan terkonfirmasi adanya ketidakstabilan routing
    • Dalam skenario terburuk, kemungkinan terjadi kehilangan koneksi singkat

Pesan BGP yang Bermasalah

  • Update yang terlihat pada sesi yang memasok data ke bgp.tools adalah BGP Update yang relatif biasa untuk /16, tetapi menyertakan BGP Prefix-SID Attribute yang bermasalah
  • Atribut tersebut berbahaya karena dua alasan
    • Ini adalah atribut yang tidak diharapkan terlihat dalam update BGP tabel internet
    • Ini adalah atribut yang rusak dengan seluruh data internal bernilai 0x00
  • Sebagian besar implementasi seperti IOS-XR/Nokia SR-OS, ketika “BGP error tolerance” berbasis RFC7606 diaktifkan, memfilternya dengan benar sehingga tidak menimbulkan masalah
  • Pada kombinasi JunOS dan Arista EOS, hasilnya berbeda
    • JunOS meneruskan pesan yang rusak
    • Perangkat Arista EOS mereset sesi ketika menerima pesan tersebut yang tampaknya datang dari perangkat JunOS
  • Karena banyak internet transit carrier memakai hardware Juniper yang menjalankan JunOS, jaringan yang mengoperasikan Arista EOS dan terhubung ke router transit upstream berbasis JunOS kemungkinan sempat kehilangan akses internet untuk beberapa waktu
    • Durasinya diperkirakan maksimal sekitar 10 menit

Kandidat AS yang Menambahkan Atribut Cacat

  • Hasil pemfilteran arsip bgp.tools pada periode tersebut menunjukkan beberapa origin AS tampaknya terlibat dalam insiden ini
  • Ini mengindikasikan bahwa atribut tersebut kemungkinan ditambahkan oleh carrier perantara menuju internet yang lebih luas, bukan oleh jaringan yang menjadi origin prefix
  • Empat kandidat yang muncul berulang kali di seluruh pesan bermasalah adalah sebagai berikut
    • AS9304 — Hutchison Global Communications Limited
    • AS135338 — Starcloud Information Limited
    • AS151326 — DCConnect Communication Pte. Ltd.
    • AS138077 — PT Abhinawa Sumberdaya Asia
  • bgp.tools mengamati impacted prefix pada jalur […] 151326 138077 […] tanpa atribut BGP yang cacat
    • Karena itu, pihak yang menambahkan atribut cacat kemungkinan besar adalah Starcloud AS135338 atau Hutchison AS9304
  • Beberapa prefix yang diamati dalam update yang menyertakan atribut tersebut adalah sebagai berikut
    • 156.230.0.0/16
    • 138.113.116.0/24
    • 163.171.102.0/24
    • 163.171.103.0/24
    • 163.171.104.0/24

Jalur yang Menyebar ke Internet Exchange

  • Insiden ini membesar karena Hutchison/AS9304 terhubung ke banyak internet exchange
  • Pesan bermasalah dikirim ke IX route server, dan route server ini biasanya menjalankan bird
  • Karena Bird tidak mendukung BGP SID, ia tidak dapat memfilter pesan tersebut dan mendistribusikannya apa adanya ke berbagai internet exchange multi-terabit
  • Akibatnya, kekacauan menyebar melampaui sesi internet transit ke cakupan yang lebih luas

Sifat BGP Prefix-SID

  • BGP Prefix-SID Attribute umumnya hanya seharusnya terlihat pada sesi BGP internal
  • Tujuan yang didefinisikan dalam RFC8669 adalah membantu menentukan jalur yang akan ditempuh trafik menuju tujuan di dalam satu jaringan
  • Alasan atribut ini bocor ke tabel routing global mungkin karena sesi BGP eksternal dikonfigurasi seperti sesi internal

Jaringan yang Terdampak dan Metrik Pengamatan

  • Sulit memastikan secara tepat siapa saja yang terdampak, tetapi berdasarkan lokasi dengan churn yang sangat besar relatif terhadap ukuran jaringan tepat setelah pesan BGP bermasalah pertama, diperkirakan sekitar 100 jaringan mengalami masalah
  • Contoh dengan tingkat keyakinan tinggi adalah sebagai berikut
  • Dalam kondisi normal, route collector bgp.tools mengumpulkan sekitar 20.000–30.000 pesan per detik
  • Selama insiden ini, rata-rata 10 detik laju pesan jauh melampaui 150.000/s
    • Ini menunjukkan adanya gangguan signifikan pada banyak rute internet

Perbedaan Penanganan Error antar Vendor

  • Walaupun akar penyebab atau pihak pemicu sebenarnya belum sepenuhnya jelas, fakta bahwa pesan cacat menyebar pada skala internet menunjukkan risiko penanganan error BGP
  • Vendor lain mendeteksi atribut cacat dan menahan pengumuman rute, tetapi Juniper meneruskannya ke peer
  • Setelah pesan tersebut mencapai perangkat Arista, ketiadaan atau cacat pada kode BGP error tolerance menyebabkan reset sesi
  • Dokumentasi BGP error tolerance JunOS dari Juniper menyatakan bahwa JunOS tidak memeriksa semua bagian pesan
  • Perilaku ini membuat JunOS sendiri menghindari reset sesi yang dipicu dari jarak jauh, tetapi meneruskan pesan yang sama ke peer lain atau ke sisi pelanggan

Implikasi Operasional

  • Outage kali ini berlangsung singkat, tetapi bisa saja berdampak lebih besar
  • Seiring makin banyak layanan berpindah ke basis IP, cakupan gangguan internet dapat melampaui kegagalan akses email
    • Kegagalan siaran TV
    • Gangguan panggilan layanan darurat
  • Bug seperti ini meningkatkan kemungkinan menyebabkan atau memperburuk korban jiwa di dunia nyata
  • Operator jaringan yang memiliki tabel routing penuh dapat menyediakan feed data ke bgp.tools untuk membantu debugging insiden di masa depan

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-29
Komentar Hacker News

  • Pendekatan standar adalah bersikap longgar saat menerima dan ketat saat mengirim
    Pilihannya adalah memfilter pesan yang rusak, membuangnya, mengabaikan atribut yang rusak tetapi tetap meneruskannya, atau menjadi rusak karena atribut yang rusak; menurut saya yang benar-benar sulit diterima hanya nomor 4, yaitu perilaku ala Arista. Nomor 3, perilaku ala Juniper, memang tidak ideal tetapi tidak fatal
    Setelah saya baca ulang, Arista tampaknya lebih dekat ke nomor 2 daripada nomor 4; sepertinya bukan crash total, melainkan menganggapnya sebagai koneksi yang salah lalu menutupnya. Dari sudut pandang pengguna ini tidak bagus, tetapi dalam perdebatan masih termasuk dapat diterima

    • Sudah ada RFC 7606 (Revised Error Handling for BGP UPDATE Messages), yang menetapkan secara terperinci bagaimana pesan BGP yang rusak harus ditangani
      Cara paling umum adalah treat-as-withdraw, yaitu memperlakukan pembaruan pengumuman rute seperti penarikan rute yang sebelumnya diumumkan. Jika pesan yang rusak begitu saja dibuang, status lama yang tidak lagi valid akan terus dipertahankan, jadi itu tidak boleh dilakukan
    • Yang diparafrasakan di sini adalah apa yang disebut prinsip ketangguhan, yakni Hukum Postel
      Ini adalah gagasan dari sejarah kuno internet pada 1980-an dan 1990-an, dan saat ini secara luas dipahami sebagai ide keliru yang menyebabkan ossification protokol dan banyak masalah keamanan
    • Masalahnya adalah orang-orang memanfaatkan di seluruh jaringan perilaku BGP yang meneruskan atribut yang tidak dikenal sekalipun perangkat lokal tidak memahaminya
      Kini banyak sistem bergantung pada perilaku itu, dan kita sedang merasakan sisi buruk dari “fitur” tersebut
    • Dalam tulisan terkait, penulis juga menyoroti poin yang sama
      Sepintas, “fitur” ini tampak seperti ide yang sangat buruk karena membuat informasi yang tidak dikenal menyebar secara membabi buta melalui sistem yang tidak memahami dampak informasi yang diteruskannya. Namun berkat fitur ini, hal-hal seperti Large Communities bisa diterapkan lebih cepat dan lebih luas, dan bisa juga dikatakan bahwa penerapan fitur BGP baru itu sendiri menjadi mungkin
    • Saya tidak setuju dengan pendekatan ini. Menurut saya lebih baik sangat ketat saat menerima maupun saat mengirim

  • Saya masih ingat harus berlarian seperti orang gila untuk memperbaiki CVE-2023-4481 di seluruh jaringan
    Bug semacam ini pasti benar-benar mimpi buruk untuk ditangani, dan karena cara BGP dirancang serta diimplementasikan, memperbaiki perilaku seperti ini akan memakan waktu sangat lama

  • Memang sudah puluhan tahun lalu, tetapi saya pernah mengembangkan fitur BGP di sebuah vendor perangkat telekomunikasi
    Saya masih berpikir BGP terlalu rumit, orang-orang terus menambahkan fitur baru, dan para vendor terus mengimplementasikannya berdasarkan standar RFC atau draf
    Sepertinya BGP tidak akan dipensiunkan, jadi bug seperti ini tampaknya akan terus ditemukan berulang kali ke depannya

    • Pernah ada masa ketika AT&T bersama Juniper dan Cisco jelas-jelas mendorong BGP sepenuhnya ke wilayah yang rumit melalui fitur terkait MPLS dan VPN
      Secara pribadi, itu rumit sampai menakutkan, tetapi bagi sebagian pihak cukup menguntungkan

  • HGC Global Communications Limited adalah perusahaan yang sebelumnya dikenal sebagai Hutchison Global Communications Limited, penyedia layanan internet di Hong Kong
    https://en.wikipedia.org/wiki/HGC_Global_Communications

  • Sasis IOS XR kami juga menerima sebagian paket seperti ini, dan waktunya bertepatan dengan iklan rute BGP yang tinggi. Terus terang saya tidak tahu perangkat apa yang dipakai upstream
    Saya jadi penasaran apakah protokol BGP benar-benar sedang di-fuzzing dengan layak. Mungkin ini bidang yang terlalu penting sehingga semua orang takut mencoba merusaknya
    Menulis fuzzer BGP mungkin mudah, tetapi mendiagnosis penyebab crash tampaknya akan sangat sulit

  • Saya rasa saya tidak pernah mempelajari BGP sampai mendengar bahwa ia menimbulkan masalah. Meski sama pentingnya bagi internet seperti TCP/IP, TCP/IP dipelajari di kampus, ditemui sepanjang karier, dan banyak dibahas di buku, sedangkan BGP hampir tidak pernah saya temui di kampus, kantor, maupun buku
    TCP/IP bisa dipelajari dengan “bermain-main” lewat proyek mainan di rumah, tetapi saya tidak tahu harus mulai dari mana untuk BGP. Bagaimana cara belajar BGP di rumah?

    • Beli router yang memiliki implementasi BGP. Ada perangkat murah seperti Mikrotik, dan ada juga implementasi open source
      Artikel ini menyebut bird, dan ada juga implementasi yang sangat populer bernama FRR (free range routing). Menjalankan dua kontainer Docker, membuat sesi BGP di antara keduanya, lalu misalnya menyebarkan rute statis yang dikonfigurasi secara internal itu sangat mudah
      Jika suka tutorial berpemandu, https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/ cukup bagus dan berkembang hingga topik yang sedikit lebih lanjut. Semua yang dibutuhkan untuk mengikutinya adalah perangkat lunak bebas
    • DN42[1] menyediakan tempat bermain untuk bereksperimen dengan teknologi routing. Jika tidak berniat meluangkan banyak waktu, saya tidak menyarankan untuk mendalaminya. Bahkan bagi orang yang cukup terbiasa dengan networking, routing WAN tetap membingungkan
      Cara termudah untuk mendapatkan pengalaman langsung dengan teknologi networking apa pun mungkin adalah GNS3
      [1]: https://wiki.dn42.us/home
    • BGP itu seperti pelayaran internasional. Ia mutlak diperlukan agar dunia berjalan, tetapi kebanyakan orang tidak perlu berinteraksi langsung dengannya
      Salah satu cara untuk bereksperimen adalah ini: https://www.eve-ng.net/
      Cara lain adalah membuat beberapa mesin virtual dengan beberapa antarmuka jaringan, menyusun jaringan di antara mereka, lalu memakai daemon routing BGP
      https://bird.network.cz/
      https://www.nongnu.org/quagga/
      dan sejenisnya
    • Di kelas networking S1, BGP tidak dibahas; di kelas networking pascasarjana, BGP dibahas
      Kami memakai paket Python untuk mensimulasikan beberapa AS, tetapi saya tidak ingat paket yang mana
    • Di kelas jaringan S1, BGP memang dibahas sedikit, tetapi hanya lewat penjelasan di papan tulis
      Untuk bereksperimen dengan BGP, Anda bisa memakai simulator jaringan seperti penulis artikel ini. Di kelas, kami memakai gini[1], yang sepertinya dibuat oleh mahasiswa pascasarjana dosen kami, dan penulis tampaknya memakai gns3, yang terlihat seperti versi ns3 khusus Cisco. Saya pernah mencoba ns3 sekali, dan kurva belajarnya curam. Simulator gini memiliki antarmuka pengguna yang lebih mendasar, tetapi mungkin fiturnya juga kurang kuat
      [1] https://citelab.github.io/gini5/
      [2] https://docs.gns3.com/docs/

  • Sepertinya BGP akan jauh lebih stabil jika berbagai vendor perangkat keras sepakat pada cara standar untuk menangani hal semacam ini
    Apakah masalah sebenarnya adalah tiap vendor menginginkan efek lock-in sehingga tidak melakukan standardisasi?
    Namun, pemahaman saya tentang BGP dangkal dan terbatas, dan saya bukan ahli

  • Melihat dampak bug semacam ini, mengejutkan bahwa tidak ada konsorsium yang memiliki suite pengujian interoperabilitas
    Mungkin saja ada, tetapi masalah khusus ini tidak ada di suite pengujian tersebut. Kalau begitu, mengejutkan juga bahwa mereka tidak membuat kasus uji dengan menelusuri semua kemungkinan kesalahan paket menggunakan fuzzer atau metode yang dihasilkan mesin. Tidak masalah jika menjalankan suite itu memakan waktu berjam-jam atau berhari-hari
    Penulis artikel ini membuat fuzzer dengan tingkat cakupan tertentu, dan tampaknya pernah menemui masalah serupa sebelumnya. Mengejutkan bahwa para vendor tidak secara aktif mengadopsi pekerjaan ini

  • Beberapa vendor pernah mengalami bug ini di masa lalu: https://www.kb.cert.org/vuls/id/347067
    Ada CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd), CVE-2023-40457 (EXOS)
    Saat itu Arista tidak terdampak

  • Saya bertanya-tanya apakah ada hal lain yang sebesar pipa internet dan memiliki kompleksitas tak disengaja yang begitu rumit ala Bizantium