BGP işleme hatası nedeniyle internet yönlendirmesinde kararsızlık yaşandı

 (blog.benjojo.co.uk)
1 puan yazan GN⁺ 2025-05-29 | 1 yorum | WhatsApp'ta paylaş
  • BGP mesaj işleme hatası nedeniyle 20 Mayıs 2025'te büyük ölçekli yönlendirme kararsızlığı ve bazı ağlarda internet bağlantısının kesilmesi yaşandı
  • Sorunun kaynağı hatalı bir BGP Prefix-SID Attribute idi ve başlıca BGP uygulamalarında, özellikle JunOS ve Arista EOS'ta, istisnai davranışlara yol açtı
  • Hutchison ve Starcloud dahil bazı transit taşıyıcılar kaynak mesajı aktararak etkinin yayılmasına neden oldu
  • Olay nedeniyle 100'den fazla ağda çok sayıda BGP oturumu sıfırlanması ve kararsızlık görüldü
  • Bu olay, üreticilere göre BGP hata toleransı işleme mekanizmalarındaki açıkları ve iyileştirme ihtiyacını öne çıkardı

27 Mayıs 2025

BGP işleme hatası nedeniyle dünya genelinde internet yönlendirmesinde kararsızlık

20 Mayıs 2025 Salı günü saat 07:00'de (UTC) bir BGP mesajı yayılırken, internet trafiğini işlemek için yaygın olarak kullanılan iki önemli BGP uygulamasında beklenmedik davranışlar ortaya çıktı

Bunun sonucunda çok sayıda “internet bağlantısı BGP oturumu” otomatik olarak sonlandı; en hafif durumda yönlendirme kararsızlığı, en kötü durumda ise bazı ağlarda geçici bağlantı kesintileri yaşandı

Sorunlu BGP mesajı

  • bgp.tools'tan toplanan oturumların analizi, bu olaya neden olan BGP Update mesajının normal göründüğünü ancak iç verisi 0x00 ile doldurulmuş bozuk bir BGP Prefix-SID Attribute içerdiğini gösteriyor
  • BGP uygulamalarının çoğu (IOS-XR, Nokia SR-OS) RFC7606 (BGP hata toleransı) uyarınca bunu doğru şekilde filtreliyor, ancak JunOS ile Arista EOS arasındaki etkileşimde sorun ortaya çıkıyor
    • JunOS bozuk mesajı koruyup iletirken, Arista EOS bu mesajı aldığında BGP oturumunu sıfırlıyor
  • Juniper donanımının (JunOS) yaygın kullanıldığı ortamlarda, Arista EOS ile bağlantı varsa yaklaşık 10 dakikaya kadar internet erişim kesintisi yaşanma ihtimali bulunuyor

Sorunlu mesajın göndericisi

  • İlgili dönemde bgp.tools arşivinin analizi, birden fazla AS origin'in olaya dahil olduğunu gösteriyor

  • Bu, Prefix'i oluşturan ağın değil, yol üzerindeki bir transit taşıyıcının hatalı Attribute'u eklediğine işaret ediyor

  • Sorunla ilişkili başlıca AS'ler şunlar:

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

  • bgp.tools verilerine göre Attribute'u fiilen ekleyen tarafın Starcloud (AS135338) veya Hutchison (AS9304) olma ihtimali yüksek

  • Bu Attribute'un yayıldığı öne çıkan Prefix'ler arasında 156.230.0.0/16 ve 138.113.116.0/24 yer alıyor

  • Hutchison/AS9304, birçok internet exchange'e (IX) bağlı olduğu için mesaj bird'ün kullandığı route server'lara da yayıldı

  • Bird, BGP SID desteği sunmadığından filtreleme yapmadan mesajı çok sayıda IX'e iletti ve ağ çapındaki kargaşayı büyüttü

BGP Prefix-SID nedir?

  • BGP Prefix-SID Attribute normalde yalnızca dahili BGP oturumlarında kullanılmalı ve tek bir ağ içinde hedefe giden yolu tanımlamak için kullanılır (RFC8669)
  • Bu Attribute'un küresel yönlendirme tablosuna sızmasının nedeni, harici BGP oturumlarının dahili oturum gibi yapılandırılmış olması olabilir

Etkilenenler

  • Etkilenenleri tam olarak belirlemek zor olsa da, ilk BGP mesajının ardından olağanüstü değişim (churn) gösteren yaklaşık 100 ağda sorun tespit edildi
  • bgp.tools'un route collector'ları normalde saniyede 20-30 bin mesaj toplarken, olay anında 10 saniyelik ortalamada 150 binin üzerinde kayıt görüldü
  • Bu rakam, geniş çaplı internet yollarında ciddi bir arıza yaşandığının işareti

Üreticilerin sorumluluğu ve çıkarımlar

  • Kök neden kesin olarak bilinmese de, hatalı mesajın internet ölçeğinde yayılması mevcut BGP hata işleme sorunlarının gerçek bir risk olduğunu kanıtlıyor
  • Diğer üreticiler sorunlu Attribute'u filtrelerken, Juniper bunu dolaylı olarak geçirdi ve Arista cihazlarına iletti; BGP hata toleransı kodundaki eksiklik de oturum sıfırlanmasına yol açtı
  • JunOS'un resmi belgelerinde de “mesajın tamamını denetlemediği” açıkça belirtiliyor
  • Bu tasarım sayesinde JunOS, uzaktan oturum sıfırlama riskini önlese de sorunlu mesajları başka peer'lara veya müşterilere iletme olasılığı taşıyor

Sonuç

  • Bu olay kısa süreli olsa da, ölçek büyüdüğünde daha ciddi hale gelebileceğini gösteriyor

  • Hizmetler giderek daha fazla IP merkezli hale geldikçe, internet kesintilerinin etkisi sadece tüketicilerin e-postaya erişememesiyle sınırlı kalmayıp TV yayınlarının başarısız olması ve acil servis çağrılarının ulaştırılamaması gibi sonuçlara da yayılabilir

  • Bu nedenle, gerçekçi biçimde can kaybına kadar varabilecek riskler söz konusu olduğundan, üreticilerin sağlam BGP hata toleransı uygulamaları geliştirmesi gerektiği vurgulanıyor

  • bgp.tools veri analizine katkı sunmak isteyen ağ operatörlerinin katılımına açık olduğu belirtiliyor (bağlantı verilmiş)

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-29
Hacker News görüşleri

  • Genel olarak "alırken esnek, gönderirken katı ol" ilkesi standart yaklaşım olarak bilinen bir şey

    • Bozuk mesajları elemek (drop, filtrelemek), yalnızca özniteliği yok sayıp iletmek (break) ya da bağlantının kendisini kesmek (Arista gibi) gibi seçenekler var

    • Bence dördüncü seçenek (Arista yaklaşımı) gerçekten kabul etmesi çok zor bir davranış

    • Üçüncü seçenek (Juniper) de arzu edilir değil ama ölümcül bir sorun sayılmaz diye düşünüyorum

    • Düzenleme: Metni tekrar okuyunca Arista'nın dördüncü değil ikinci seçenek olduğu, yani bağlantıyı sonlandırdığı anlaşılıyor

    • Bağlantıyı tamamen geçersiz sayıp kapatmışlar; bu kullanıcı deneyimi açısından pek iyi bir karar değil ama kabul edilebilir sınırlar içinde gibi görünüyor

    • Zaten RFC 7606 (BGP UPDATE mesajları için geliştirilmiş hata işleme) mevcut ve burada bozuk mesajların nasıl ele alınacağı açıkça belirtilmiş durumda

      • En yaygın yöntem treat-as-withdraw (sanki rota withdraw edilmiş gibi ele almak)
      • Bozuk mesajı tamamen yok sayarsanız önceki durum gerçekte artık geçerli olmasa bile korunmuş oluyor

    • "Alırken esnek, gönderirken katı ol" ilkesi tam da "robustness principle" ya da "Postel yasası" denilen şey

      • Bu ilke, internetin 1980'ler ve 90'lardaki ilk dönemlerinden gelen bir kavram
      • Ama bugün bunun hatalı bir düşünme biçimi olduğu sektörde geniş ölçüde kabul ediliyor
      • Bu ilke, protokol katılaşmasına ve sayısız güvenlik sorununa yol açtı

    • BGP'nin çalışma özellikleri istismar edilerek, yerel cihazın bilmediği öznitelikleri olduğu gibi iletebilmesinden kaynaklanan çeşitli sorunlar ağ genelinde yaşandı

      • Artık bu tür bir "özelliğin" dezavantajlarının ortaya çıktığı bir dönemden geçiyoruz

    • Yazı sahibi de ilgili yazısında buna dikkat çekiyor

      • Bu "özellik", sistemin anlamadığı veriyi sorgulamadan iletmesine neden olduğu için şaşırtıcı derecede kötü bir fikir gibi görünüyor
      • Ancak bu özellik sayesinde Large Communities gibi yeni yetenekler hızla yayılabildi ve yeni BGP özelliklerinin devreye alınması mümkün oldu

    • Ben bu yaklaşıma katılmıyorum

      • Hem neyin kabul edileceği hem neyin gönderileceği konusunda katı ve açık olmak çok daha iyi diye düşünüyorum

  • CVE-2023-4481 hatasını ağ genelinde yamamak için delicesine koşturduğum günleri hâlâ hatırlıyorum

    • Bu tür hatalar gelecekte de başa çıkması tam bir kâbus olmaya devam edecek
    • BGP'nin tasarımı ve uygulanış biçimi nedeniyle, bu davranışları düzeltmenin oldukça uzun süreceğinden endişeliyim

  • Geçmişte bir telekom ekipmanı üreticisinde BGP özellikleri geliştirmiştim (oldukça eski bir hikâye)

    • Hâlâ BGP'nin fazla karmaşık olduğunu düşünüyorum

    • İnsanlar sürekli yeni özellikler ekliyor, üreticiler de standartlara ya da draft'lara göre tekrar tekrar uygulama geliştiriyor

    • BGP'nin sanki hiç ortadan kalkmayacak doğası yüzünden bu tür hataların sürekli yeniden ortaya çıkacağı hissine kapılıyorum

      • Eskiden AT&T gibi operatörler ile Juniper, Cisco gibi üreticiler MPLS ve VPN ile ilgili özelliklerde BGP'yi zorlayarak sistemi derin bir karmaşıklığın içine itmişti
        • Aşırı derecede karmaşıktı ama bazıları bundan çok para kazandı

  • HGC Global Communications Limited (eski adı Hutchison Global Communications Limited, kısaca HGC), Hong Kong merkezli bir internet servis sağlayıcısıdır

  • Donanım üreticilerinin BGP konusunda bu tür meselelerde standartları gerçekten hizalaması durumunda her şey çok daha kararlı olurmuş gibi geliyor

    • Asıl sorunun, her üreticinin müşteriyi kendine kilitlemek için standartlaşmadan kaçınması olup olmadığını merak ediyorum
    • Bu arada BGP konusundaki bilgimin yüzeysel olduğunu da belirteyim

  • Sadece bana mı öyle geliyor bilmiyorum ama BGP diye bir şeyin varlığını, sorun çıkardığına dair bir şey duyana kadar hiç bilmiyordum

    • İnternet için TCP/IP kadar temel bir protokol ama TCP/IP'yi okulda, kariyerimde, kitaplarda sıkça gördüm; BGP ise hiç karşıma çıkmadı
    • Evde TCP/IP ile pratik yapıp öğrenebilirsiniz ama BGP ile evde nasıl "oynanır" hiç fikrim yok

      • Evde BGP pratiği yapmak için bir yöntem varsa duymak isterim

      • BGP desteği olan gerçek bir router (ucuz örneklerden biri Mikrotik gibi cihazlar) ya da bir açık kaynak uygulama edinip deneyebilirsiniz

        • Yazıda geçen bird ve çok popüler FRR (Free Range Routing) gibi seçenekler var
        • İki Docker container'ı ayağa kaldırıp bir BGP oturumu kurabilir ve static route gibi şeyleri yayabilirsiniz
        • Bir eğitim istiyorsanız bu bağlantıdaki rehber, ücretsiz yazılım tabanlı olarak takip edilebilecek şekilde güzel hazırlanmış

      • DN42, yönlendirme teknolojilerini pratik etmek için bir oyun alanı

        • Ancak zaman yatırımı şart, o yüzden öyle hafifçe girilecek bir şey değil
        • Ben de ağ işlerine oldukça aşinayım ama WAN routing hâlâ kafamı karıştırıyor
        • GNS3, hangi ağ teknolojisi olursa olsun doğrudan pratik yapmak için en kolay araç
        • DN42 wiki

      • Lisans ağ dersimde BGP işlenmemişti ama yüksek lisans dersinde BGP gördüm

        • Birden fazla AS simüle edebilen bir Python paketi kullanmıştık ama tam adını hatırlamıyorum

      • Benim aldığım lisans ağ dersinde BGP sadece tahtada kısaca anılmıştı

        • BGP pratiği için, yazının yazarının kullandığı gibi ağ simülatörlerinden yararlanabilirsiniz
        • Bizim derste gini adlı bir simülatör kullanılmıştı; hocanın bir yüksek lisans öğrencisinin yaptığı bir programdı
        • Yazarın kullandığı gns3, Cisco odaklı bir ns3 hissi veriyor
        • ns3, öğrenilecek çok şey olduğu için zor gelmişti
        • gini daha kolay bir arayüze sahip ama performansı daha düşük
        • gini proje sayfası
        • gns3 resmi dokümanları

      • İnsana, BGP'yi gerçekten "pratik etmek" için gerçek internet trafiğine bağlı büyük ölçekli bir ağı yönetmek gerekiyormuş gibi geliyor

        • Evde kurcalayabileceğiniz şey esasen ağ simülatörleriyle sınırlı

  • Geçmişte başka üreticilerde de bu yazıdakine benzer hatalar vardı

    • İlgili güvenlik açığı bilgileri
    • CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd), CVE-2023-40457 (EXOS) vb.
    • Arista ise o dönemde etkilenmeyen üreticilerden biriydi

  • Bizim IOS XR chassis cihazlarımızda da buna benzer paketler almıştık

    • Aynı anda çok sayıda BGP rota ilanı da vardı

    • Upstream tarafta hangi cihazın olduğunu tam bilmiyorum

    • BGP protokolünün gerçekten fuzz edilerek test edilip edilmediğini merak ettim

    • O kadar kritik bir protokol ki, belki de insanlar kasıtlı olarak arıza üretmeye cesaret edemiyordur diye düşündüm

    • BGP için bir fuzzer yazmak kolay olurdu ama çökme teşhisi fazla zor olabilir

      • (yazı sahibi)
        • Evet, tam olarak bunu ben de gönderide gerçekten yaptım
        • İlgili yazı

  • İnternet omurgası kadar geniş ve tesadüfi karmaşıklık biriktirmiş başka bir sistem olmuş mudur diye düşündürüyor

  • Bu tür hataların etkisi düşünülünce, birlikte çalışabilirlik için test paketleri işleten bir konsorsiyum vardır sanıyordum; olmayışı şaşırtıcı

    • Ya da gerçekten vardır ama bu sorun test kapsamı dışında kalmıştır
    • Olası tüm paket hatalarını otomatik üretip kapsamı artırmak için fuzzer'lar ya da makinelerle çok çeşitli test vakaları oluşturmak gayet doğal görünüyor
    • Çalışma süresinin günler sürmesi bile sorun olmaz
    • Yazının yazarı gerçekten bir fuzzer yapıp kullanmış ve benzer sorunlarla birkaç kez karşılaşmış
    • Üreticilerin bu kadar önemli araştırmalara aktif ilgi göstermemesi bana ilginç geliyor