BGP प्रोसेसिंग बग से इंटरनेट रूटिंग में अस्थिरता हुई

 (blog.benjojo.co.uk)
1 पॉइंट द्वारा GN⁺ 2025-05-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 20 मई 2025 को 07:00 UTC पर फैले एक corrupted BGP message ने दो प्रमुख implementations में अप्रत्याशित व्यवहार पैदा किया, जिससे इंटरनेट से जुड़ी कई BGP sessions reset हुईं और कुछ networks में routing instability या थोड़े समय के लिए connection loss हुआ
  • समस्या वाले update में एक BGP Prefix-SID Attribute जुड़ा था, जिसकी आम तौर पर इंटरनेट BGP updates में उम्मीद नहीं की जाती, और उसकी internal data पूरी तरह 0x00 वाली corrupted स्थिति में थी
  • RFC7606-आधारित error tolerance लागू करने वाले IOS-XR/Nokia SR-OS ने इसे filter कर दिया, लेकिन JunOS ने इसे forward किया और Arista EOS ने session reset किया, जिससे JunOS-आधारित transit carrier से जुड़े Arista users प्रभावित हो सकते थे
  • bgp.tools observations में AS9304, AS135338, AS151326, AS138077 बार-बार दिखे, और defect वाला attribute जोड़ने वाली इकाई संभवतः Starcloud AS135338 या Hutchison AS9304 थी
  • incident के दौरान bgp.tools route collector की 10-second average message rate सामान्य 20,000~30,000 प्रति सेकंड से बढ़कर 150,000/s से अधिक हो गई, जिससे दिखा कि BGP error handling में फर्क वास्तविक internet route stability को हिला सकता है

20 मई 2025 का BGP update incident

  • मंगलवार, 20 मई 2025 को 07:00 UTC पर फैले BGP message ने internet traffic delivery में अक्सर इस्तेमाल होने वाली दो प्रमुख BGP implementations में अप्रत्याशित व्यवहार पैदा किया
  • कई internet-connected BGP sessions अपने-आप terminate होने से impact फैल गया
    • कुछ networks में routing instability देखी गई
    • सबसे खराब स्थिति में थोड़े समय का connection loss हुआ हो सकता है

समस्या वाला BGP message

  • bgp.tools को feed की जाने वाली sessions में देखा गया update /16 के लिए अपेक्षाकृत सामान्य BGP Update था, लेकिन इसमें समस्या वाला BGP Prefix-SID Attribute शामिल था
  • यह attribute दो कारणों से जोखिम भरा था
    • यह ऐसा attribute है जिसके internet table BGP updates में दिखने की उम्मीद नहीं होती
    • इसकी internal data पूरी तरह 0x00 वाली corrupted attribute थी
  • IOS-XR/Nokia SR-OS जैसी अधिकांश implementations, RFC7606 आधारित “BGP error tolerance” configured होने पर, इसे सही तरह filter करके समस्या नहीं होने देतीं
  • JunOS और Arista EOS combination में अलग नतीजा दिखा
    • JunOS ने corrupted message forward किया
    • Arista EOS devices ने JunOS device से आया हुआ दिखने वाला यह message मिलने पर session reset कर दिया
  • क्योंकि कई internet transit carriers JunOS चलाने वाला Juniper hardware इस्तेमाल करते हैं, Arista EOS चलाने और JunOS-आधारित upstream transit carrier router से जुड़े networks की internet access कुछ समय के लिए कट गई हो सकती है
    • duration अधिकतम लगभग 10 मिनट अनुमानित है

defect attribute जोड़ने वाले candidate AS

  • उस period के bgp.tools archive को filter करने पर दिखता है कि कई origin AS incident में शामिल थे
  • यह संकेत देता है कि attribute शायद prefix originate करने वाले network ने नहीं, बल्कि wider internet की ओर जाने वाले किसी intermediate carrier ने add किया
  • problem messages में बार-बार दिखे candidates ये 4 हैं
    • AS9304 — Hutchison Global Communications Limited
    • AS135338 — Starcloud Information Limited
    • AS151326 — DCConnect Communication Pte. Ltd.
    • AS138077 — PT Abhinawa Sumberdaya Asia
  • bgp.tools ने […] 151326 138077 […] route में defective BGP attribute के बिना impacted prefix observe किया
    • इसलिए defect attribute जोड़ने वाली इकाई संभवतः Starcloud AS135338 या Hutchison AS9304 है
  • attribute शामिल करने वाले updates में observe किए गए कुछ prefixes ये हैं
    • 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

internet exchanges तक फैलने का रास्ता

  • incident इसलिए और बड़ा हुआ क्योंकि Hutchison/AS9304 कई internet exchanges से जुड़ा था
  • problem message IX route servers को भेजा गया, और ये route servers आम तौर पर bird चलाते हैं
  • Bird BGP SID को support नहीं करता, इसलिए message filter नहीं कर सका, और उसे कई multi-terabit internet exchanges में ज्यों का त्यों distribute कर दिया
  • नतीजतन disruption internet transit sessions से आगे, और व्यापक दायरे में फैल गया

BGP Prefix-SID की प्रकृति

  • BGP Prefix-SID Attribute आम तौर पर सिर्फ internal BGP sessions में दिखना चाहिए
  • RFC8669 में परिभाषित उद्देश्य एक single network के भीतर destination तक traffic कौन सा path लेगा, यह तय करने में मदद करना है
  • यह attribute global routing table में leak होने की वजह यह हो सकती है कि external BGP session को internal session की तरह configure किया गया था

प्रभावित networks और observed metrics

  • ठीक-ठीक किस पर impact पड़ा, यह तय करना कठिन है, लेकिन पहले problem BGP message के तुरंत बाद network size की तुलना में बहुत अधिक churn वाले networks के आधार पर लगभग 100 networks ने समस्या झेली मानी गई
  • high-confidence examples ये हैं
  • सामान्य समय में bgp.tools route collector प्रति सेकंड लगभग 20,000~30,000 messages collect करता है
  • इस incident के दौरान 10-second average message rate 150,000/s से काफी ऊपर चला गया
    • यह दर्शाता है कि कई internet routes में significant disruption था

vendors के error handling में अंतर

  • root cause या वास्तविक trigger करने वाली इकाई पूरी तरह clear नहीं है, लेकिन defective message का internet scale पर फैलना BGP error handling के risks दिखाता है
  • अन्य vendors ने defective attribute detect करके route announcements दबा दिए, लेकिन Juniper ने इसे peers तक propagate किया
  • जब यह message Arista devices तक पहुंचा, तो BGP error tolerance code नहीं था या उसमें defect था, जिससे session reset हुआ
  • Juniper की JunOS BGP error tolerance documentation बताती है कि JunOS message के सभी हिस्सों को inspect नहीं करता
  • इस behavior का नतीजा यह हुआ कि JunOS खुद remote-triggered session reset से बचा रहा, लेकिन वही message दूसरे peers या customers की ओर forward कर दिया

operations के लिए implications

  • यह outage छोटा था, लेकिन इसका impact ज्यादा बड़ा हो सकता था
  • जैसे-जैसे अधिक services IP-based होती जा रही हैं, internet outages का दायरा email access failure से आगे जा सकता है
    • TV broadcast failure
    • emergency service calls में disruption
  • ऐसे bugs real world में जान-माल के नुकसान को पैदा करने या बढ़ाने की संभावना बढ़ाते हैं
  • full routing table रखने वाले network operators bgp.tools को data feed देकर future incidents debug करने में मदद कर सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-29
Hacker News टिप्पणियां

  • मानक तरीका यह है कि स्वीकार करते समय उदार और भेजते समय सख्त होना चाहिए
    विकल्प हैं: टूटे हुए संदेशों को फ़िल्टर करना, उन्हें छोड़ देना, टूटे हुए attributes को नज़रअंदाज़ करके आगे भेजना, या टूटे हुए attributes की वजह से खुद बिगड़ जाना। मुझे लगता है कि सच में अस्वीकार्य केवल चौथा, Arista-स्टाइल व्यवहार, है। तीसरा, Juniper-स्टाइल व्यवहार, अच्छा नहीं है, लेकिन घातक भी नहीं
    दोबारा पढ़ने पर लगता है कि Arista चौथा नहीं बल्कि दूसरे के करीब था; वह पूरी तरह क्रैश नहीं हुआ, बल्कि शायद इसे गलत connection मानकर बंद कर दिया। यूज़र के नज़रिए से यह अच्छा नहीं है, लेकिन बहस के लिहाज़ से स्वीकार्य माना जा सकता है

    • पहले से ही RFC 7606 (Revised Error Handling for BGP UPDATE Messages) मौजूद है, जिसमें टूटे हुए BGP संदेशों को कैसे संभालना चाहिए, यह विस्तार से तय किया गया है
      सबसे आम तरीका treat-as-withdraw है, जिसमें route announcement update को पहले से announce किए गए route की वापसी की तरह संभाला जाता है। टूटे हुए संदेश को बस छोड़ देना ठीक नहीं, क्योंकि इससे आप ऐसी पुरानी state बनाए रखते हैं जो अब valid नहीं है
    • यहां जिसे दूसरे शब्दों में कहा गया है, वह तथाकथित robustness principle, यानी Postel's law है
      यह 1980 और 90 के दशक के इंटरनेट के प्राचीन इतिहास से निकला विचार है, लेकिन आज इसे व्यापक रूप से एक गलत idea माना जाता है, जिसने protocol ossification और कई security समस्याएं पैदा कीं
    • समस्या यह है कि BGP का वह व्यवहार, जिसमें स्थानीय उपकरणों को समझ न आने वाले unknown attributes भी आगे भेजे जाते हैं, लोगों ने पूरे नेटवर्क में तरह-तरह के उपयोगों के लिए अपना लिया
      अब कई systems उस व्यवहार पर निर्भर हैं, और हम उस “feature” के नुकसान झेल रहे हैं
    • संबंधित लेख में लेखक ने भी यही बात उठाई है
      ऊपर से देखने पर यह “feature” बहुत खराब idea लगता है, क्योंकि इससे unknown information ऐसे systems के जरिए अंधाधुंध फैलती है जो उस जानकारी के असर को समझते ही नहीं। लेकिन इसी feature की वजह से Large Communities जैसी चीजें ज्यादा तेजी से और व्यापक रूप से deploy हो सकीं, और कहा जा सकता है कि नई BGP features का deployment इसी से संभव हुआ
    • मैं इस approach से सहमत नहीं हूं। मुझे लगता है कि स्वीकार करने में भी बहुत सख्त और भेजने में भी बहुत सख्त होना बेहतर है

  • मुझे अब भी याद है कि पूरे network में CVE-2023-4481 को ठीक करने के लिए किस तरह पागलों की तरह भागदौड़ करनी पड़ी थी
    इस तरह के bugs को संभालना सचमुच nightmare होगा, और BGP जिस तरह design और implement किया गया है, उसकी वजह से ऐसे behavior को ठीक करने में बहुत लंबा समय लगेगा

  • कई दशक पहले की बात है, लेकिन मैंने एक telecom equipment vendor में BGP features develop किए थे
    मुझे अब भी लगता है कि BGP बहुत ज्यादा complex है, और लोग लगातार नए features जोड़ते रहते हैं, जबकि vendors RFC standards या drafts के आधार पर implementations करते रहते हैं
    BGP के खत्म होने की संभावना भी नहीं दिखती, इसलिए ऐसे bugs आगे भी बार-बार मिलते रहेंगे

    • एक समय ऐसा ज़रूर था जब AT&T, Juniper और Cisco के साथ मिलकर MPLS और VPN से जुड़ी features के जरिए BGP को पूरी तरह complex क्षेत्र में धकेल रहा था
      निजी तौर पर यह डराने की हद तक complex था, लेकिन किसी के लिए यह काफी profitable था

  • HGC Global Communications Limited पहले Hutchison Global Communications Limited के नाम से जानी जाती थी, और यह Hong Kong की internet service provider है
    https://en.wikipedia.org/wiki/HGC_Global_Communications

  • हमारे IOS XR chassis को भी ऐसे कुछ packets मिले, और समय high BGP route advertisements के साथ मेल खाता था। सच कहूं तो मुझे नहीं पता upstream कौन-सा equipment इस्तेमाल कर रहा है
    सोच रहा हूं कि क्या BGP protocol की ठीक से fuzzing हो रही है। शायद यह इतना critical क्षेत्र है कि हर कोई इसे तोड़कर देखने से डरता है
    BGP fuzzer लिखना आसान हो सकता है, लेकिन crash की वजह diagnose करना बहुत मुश्किल लगता है

  • लगता है मैंने BGP के बारे में तब तक कभी नहीं सीखा था, जब तक यह नहीं सुना कि यह समस्याएँ पैदा करता है। TCP/IP की तरह यह भी इंटरनेट के लिए अनिवार्य है, फिर भी TCP/IP तो यूनिवर्सिटी में भी पढ़ा, करियर के दौरान भी मिला, और उस पर काफी किताबें भी पढ़ीं, लेकिन BGP से यूनिवर्सिटी, काम या किताबों—कहीं भी लगभग सामना नहीं हुआ
    TCP/IP को घर पर toy projects के साथ “खेलते” हुए सीखा जा सकता है, लेकिन BGP के साथ क्या करना चाहिए, समझ नहीं आता। घर पर BGP सीखना हो तो कैसे करें?

    • BGP implementation वाला router खरीद लें। Mikrotik जैसे सस्ते डिवाइस भी हैं, और open source implementations भी हैं
      लेख में bird का जिक्र है, और एक बहुत लोकप्रिय implementation FRR (free range routing) भी है। दो Docker containers चलाकर उनके बीच BGP session बनाना, और उदाहरण के लिए अंदर configured static routes को propagate करना बहुत आसान है
      अगर guided tutorials पसंद हैं, तो https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/ काफी अच्छा है और थोड़ा advanced topics तक भी जाता है। इसे follow करने के लिए जो कुछ चाहिए, वह सब free software है
    • DN42[1] routing technologies के साथ प्रयोग करने के लिए एक playground देता है। अगर आप बहुत समय नहीं देना चाहते, तो इसमें बहुत गहराई तक जाने की सलाह नहीं दूँगा। networking में काफी comfortable होने के बावजूद WAN routing अब भी उलझाऊ लगती है
      किसी भी networking technology का hands-on अनुभव लेने का सबसे आसान तरीका शायद GNS3 होगा
      [1]: https://wiki.dn42.us/home
    • BGP international shipping जैसा है। दुनिया चलाने के लिए यह जरूरी है, लेकिन ज्यादातर लोगों को इससे सीधे interact करने की जरूरत नहीं पड़ती
      इसे experiment करने का एक तरीका यह है: https://www.eve-ng.net/
      दूसरा तरीका है कुछ network interfaces वाली दो-तीन virtual machines बनाना, उनके बीच network configure करना, और BGP routing daemon इस्तेमाल करना
      https://bird.network.cz/
      https://www.nongnu.org/quagga/
      जैसी चीजें हैं
    • undergraduate networking class में BGP cover नहीं किया गया था, और graduate networking class में किया गया था
      हमने कई AS simulate करने वाला एक Python package इस्तेमाल किया था, लेकिन कौन सा package था, याद नहीं
    • undergraduate network class में BGP थोड़ा cover हुआ था, लेकिन सिर्फ blackboard explanation तक
      BGP के साथ experiment करने के लिए इस लेख के लेखक की तरह network simulator इस्तेमाल किया जा सकता है। class में हमने gini[1] इस्तेमाल किया था, जो शायद professor के graduate student ने बनाया था, और लगता है लेखक ने gns3 इस्तेमाल किया, जो Cisco-specific ns3 version जैसा दिखता है। ns3 मैंने एक बार इस्तेमाल किया था और उसका learning curve steep था। gini simulator का user interface ज्यादा basic है, लेकिन शायद वह कम powerful होगा
      [1] https://citelab.github.io/gini5/
      [2] https://docs.gns3.com/docs/

  • अगर कई hardware vendors इस तरह की चीजों को handle करने के लिए किसी standard way पर सहमत हो जाते, तो लगता है BGP कहीं ज्यादा stable होता
    क्या असली समस्या यह है कि हर vendor lock-in effect चाहता है, इसलिए standardize नहीं करता?
    हालांकि BGP की मेरी समझ सतही और कमजोर है; मैं expert नहीं हूँ

  • ऐसे bug के impact को देखते हुए यह हैरानी की बात है कि कोई interoperability test suite वाला consortium नहीं है
    शायद है, लेकिन यह खास issue उस test suite में नहीं है। अगर ऐसा है, तो यह हैरानी की बात है कि fuzzer या machine-generated तरीके से सभी संभावित packet errors explore करके test cases नहीं बनाए जाते। suite चलाने में कुछ घंटे या दिन भी लगें तो ठीक ही होगा
    इस लेख के लेखक ने कुछ coverage वाला fuzzer बनाया है, और लगता है पहले भी इसी तरह की समस्या से गुजरे हैं। vendors का इस काम को सक्रिय रूप से न अपनाना हैरान करता है

  • कई vendors पहले इस bug से गुजर चुके हैं: https://www.kb.cert.org/vuls/id/347067
    CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd), CVE-2023-40457 (EXOS) थे
    उस समय Arista प्रभावित नहीं था

  • इंटरनेट की plumbing जितनी विशाल और accidental complexity में Byzantine तरीके से उलझी हुई कोई और चीज रही है क्या, सोचता हूँ