ความไม่เสถียรของการกำหนดเส้นทางอินเทอร์เน็ตเกิดขึ้นจากบั๊กในการประมวลผล BGP

 (blog.benjojo.co.uk)
1 คะแนน โดย GN⁺ 2025-05-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เกิด ความไม่เสถียรของการกำหนดเส้นทางครั้งใหญ่ และการเชื่อมต่ออินเทอร์เน็ตของบางเครือข่ายขาดหายไปบางส่วนเมื่อวันที่ 20 พฤษภาคม 2025 จาก บั๊กในการประมวลผลข้อความ BGP
  • สาเหตุของปัญหาคือ BGP Prefix-SID Attribute ที่ผิดรูปแบบ ซึ่งทำให้ BGP implementation หลักบางตัวเกิดการตอบสนองผิดปกติ โดยเฉพาะ JunOS และ Arista EOS
  • ผู้ให้บริการทรานซิตบางรายรวมถึง Hutchison และ Starcloud ทำหน้าที่ส่งต่อข้อความต้นเหตุ ทำให้ผลกระทบลุกลาม
  • เหตุการณ์นี้ทำให้เกิด การรีเซ็ต BGP session จำนวนมากและความไม่เสถียร ใน เครือข่ายมากกว่าประมาณ 100 แห่ง
  • เหตุการณ์นี้ตอกย้ำถึง ช่องโหว่ของการจัดการความทนทานต่อข้อผิดพลาดของ BGP ในแต่ละผู้ผลิต และความจำเป็นในการปรับปรุง

27 พฤษภาคม 2025

ความไม่เสถียรของการกำหนดเส้นทางอินเทอร์เน็ตทั่วโลกจากบั๊กในการประมวลผล BGP

เมื่อเวลา 07:00 น. UTC ของวันอังคารที่ 20 พฤษภาคม 2025 มีการแพร่กระจายของ ข้อความ BGP ซึ่งทำให้เกิดพฤติกรรมที่ไม่คาดคิดใน BGP implementation หลักสองตัวที่มักใช้สำหรับจัดการทราฟฟิกอินเทอร์เน็ต

ผลคือ ‘BGP session สำหรับการเชื่อมต่ออินเทอร์เน็ต’ จำนวนมากถูกปิดโดยอัตโนมัติ ก่อให้เกิดตั้งแต่ ความไม่เสถียรของการกำหนดเส้นทาง ในระดับเล็กน้อย ไปจนถึง การตัดขาดการเชื่อมต่อ ของบางเครือข่ายชั่วคราวในกรณีร้ายแรงที่สุด

ข้อความ BGP ที่เป็นปัญหา

  • จากการวิเคราะห์ session ที่เก็บโดย bgp.tools พบว่า ข้อความ BGP Update ที่ทำให้เกิดเหตุการณ์นี้ดูเหมือนปกติภายนอก แต่ภายในมี BGP Prefix-SID Attribute ที่เสียหาย ซึ่งข้อมูลภายในถูกเติมด้วยค่า 0x00
  • BGP implementation ส่วนใหญ่ เช่น IOS-XR และ Nokia SR-OS กรองสิ่งนี้ได้อย่างถูกต้องตาม RFC7606 (BGP error tolerance) แต่เกิดปัญหาในการทำงานร่วมกันระหว่าง JunOS และ Arista EOS
    • JunOS คงข้อความที่เสียหายไว้และส่งต่อ ขณะที่ Arista EOS เมื่อได้รับข้อความดังกล่าวจะรีเซ็ต BGP session
  • ในสภาพแวดล้อมที่ใช้อุปกรณ์ Juniper (JunOS) อย่างแพร่หลายและเชื่อมต่อกับ Arista EOS อาจเกิด การเข้าใช้อินเทอร์เน็ตไม่ได้ยาวนานสูงสุดราว 10 นาที

ผู้ส่งข้อความที่เป็นปัญหา

  • เมื่อวิเคราะห์ archive ของ bgp.tools ในช่วงเวลาดังกล่าว พบว่ามีหลาย AS origin ที่เกี่ยวข้อง

  • สิ่งนี้บ่งชี้ว่าไม่ใช่เครือข่ายที่สร้าง Prefix แต่เป็น ผู้ให้บริการทรานซิต ระหว่างทางที่เพิ่ม Attribute ที่ผิดพลาดเข้าไป

  • AS หลักที่เกี่ยวข้องกับการเกิดปัญหามีดังนี้

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

  • จากข้อมูลของ bgp.tools มีความเป็นไปได้สูงว่าฝั่งที่เพิ่ม Attribute นี้จริงคือ Starcloud (AS135338) หรือ Hutchison (AS9304)

  • Prefix ตัวอย่างที่มีการแพร่กระจาย Attribute นี้ ได้แก่ 156.230.0.0/16 และ 138.113.116.0/24

  • เนื่องจาก Hutchison/AS9304 เชื่อมต่อกับ internet exchange (IX) หลายแห่ง ข้อความดังกล่าวจึงถูกส่งต่อไปยัง route server ที่ใช้ bird ด้วย

  • Bird ไม่รองรับ BGP SID จึงส่งข้อความนี้ต่อไปยัง IX จำนวนมากโดยไม่มีการกรอง ทำให้ความปั่นป่วนในระดับเครือข่ายยิ่งรุนแรงขึ้น

BGP Prefix-SID คืออะไร?

  • BGP Prefix-SID Attribute โดยทั่วไปควรถูกใช้เฉพาะใน internal BGP session เท่านั้น และใช้เพื่อกำหนดเส้นทางไปยังปลายทางภายในเครือข่ายเดียวกัน (RFC8669)
  • สาเหตุที่ Attribute นี้รั่วออกไปยัง global routing table อาจเป็นเพราะ external BGP session ถูกตั้งค่าเหมือน internal session

ผู้ที่ได้รับผลกระทบ

  • แม้จะระบุผู้เสียหายได้อย่างแม่นยำยาก แต่พบปัญหาใน เครือข่ายราว 100 แห่งที่มีการเปลี่ยนแปลงอย่างรุนแรง (churn) หลังข้อความ BGP ชุดแรก
  • โดยปกติ route collector ของ bgp.tools จะเก็บข้อความได้ราว 20,000–30,000 รายการต่อวินาที แต่ในช่วงเกิดเหตุมีการบันทึกมากกว่า 150,000 รายการต่อค่าเฉลี่ย 10 วินาที
  • ตัวเลขนี้เป็นสัญญาณว่าเกิด ความขัดข้องร้ายแรง ในเส้นทางอินเทอร์เน็ตอย่างกว้างขวาง

ความรับผิดชอบของผู้ผลิตและข้อสรุปเชิงนัย

  • แม้สาเหตุรากยังไม่ชัดเจนแน่นอน แต่การที่ข้อความผิดพลาดแพร่กระจายในระดับอินเทอร์เน็ตพิสูจน์ว่า ปัญหาเดิมของการจัดการข้อผิดพลาดใน BGP เป็นความเสี่ยงที่เกิดขึ้นได้จริง
  • ผู้ผลิตรายอื่นกรอง Attribute ที่เป็นปัญหาออก แต่ Juniper อนุญาตให้ผ่านไปได้ทางอ้อม แล้วส่งต่อไปยังอุปกรณ์ Arista ซึ่งนำไปสู่การรีเซ็ต session จากความไม่สมบูรณ์ของโค้ดด้านความทนทานต่อข้อผิดพลาดของ BGP
  • เอกสารทางการของ JunOS ก็ระบุไว้อย่างชัดเจนว่า “ไม่ได้ตรวจสอบทั้งข้อความทั้งหมด”
  • จากการออกแบบเช่นนี้ JunOS แม้จะป้องกันความเสี่ยงจากการรีเซ็ต remote session ได้ แต่ก็ยังมีโอกาส ส่งต่อข้อความที่มีปัญหาไปยัง peer หรือ ลูกค้าอื่น

บทสรุป

  • เหตุการณ์ครั้งนี้แม้จะเกิดขึ้นช่วงสั้น ๆ แต่ชี้ให้เห็นว่าหากขยายวงกว้างกว่านี้ ผลกระทบอาจรุนแรงยิ่งกว่าเดิม

  • เมื่อบริการต่าง ๆ ย้ายไปสู่ระบบที่พึ่งพา IP มากขึ้น ผลกระทบของการขัดข้องของอินเทอร์เน็ตอาจไม่ได้หยุดอยู่แค่ผู้บริโภคเข้าอีเมลไม่ได้ แต่เสี่ยงลุกลามไปถึง การออกอากาศทีวีล้มเหลว และ การโทรหาบริการฉุกเฉินไม่ติด

  • ด้วยเหตุนี้ จึงตอกย้ำความจำเป็นที่ผู้ผลิตแต่ละรายต้องมีการทำ BGP error tolerance ที่เชื่อถือได้ เพราะในทางปฏิบัติอาจนำไปสู่ ความสูญเสียต่อชีวิตจริง ได้

  • มีการเปิดโอกาสให้ผู้ดูแลเครือข่ายที่ต้องการร่วมวิเคราะห์ข้อมูลจาก bgp.tools เข้าร่วมได้ (มีลิงก์ให้)

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-29
ความคิดเห็นจาก Hacker News

  • โดยทั่วไป หลักการ "เข้มงวดตอนส่งออก แต่ยืดหยุ่นตอนรับเข้า" เป็นแนวทางมาตรฐานที่คนรู้จักกันดี

    • มีทางเลือกทั้งการทิ้งข้อความที่เสียหายไปเลย (drop, filter), เพิกเฉพาะแอตทริบิวต์แล้วส่งต่อ (break), หรือถึงขั้นตัดการเชื่อมต่อทั้งหมด (แบบ Arista)

    • ผมคิดว่าทางเลือกที่สี่ (แบบ Arista) เป็นพฤติกรรมที่ยอมรับได้ยากจริงๆ

    • แบบที่สาม (Juniper) ก็ไม่นับว่าน่าปรารถนา แต่ผมก็ไม่คิดว่าเป็นปัญหาร้ายแรงถึงขั้นวิกฤต

    • แก้ไข: อ่านเนื้อหาอีกทีแล้วพบว่า Arista ไม่ใช่แบบที่สี่ แต่เป็นแบบที่สอง (ยุติการเชื่อมต่อ)

    • มันแค่ถือว่าการเชื่อมต่อนั้นใช้ไม่ได้แล้วปิดทิ้งไป ซึ่งถ้ามองในแง่ประสบการณ์ผู้ใช้ก็ไม่ใช่การตัดสินใจที่ดีนัก แต่ก็ยังพอรับได้

    • มี RFC 7606 อยู่แล้ว (Improved Error Handling for BGP UPDATE Messages) ซึ่งระบุไว้อย่างชัดเจนว่าจะจัดการข้อความที่เสียหายอย่างไร

      • วิธีที่พบบ่อยที่สุดคือ treat-as-withdraw (ปฏิบัติเสมือนมีการ withdraw เส้นทางนั้น)
      • ถ้าเพิกเฉยต่อข้อความที่เสียหายไปเลย จะเกิดปัญหาที่สถานะก่อนหน้าถูกคงไว้ทั้งที่ในความเป็นจริงมันอาจไม่ถูกต้องแล้ว

    • หลักการ "ยืดหยุ่นตอนรับเข้า และเข้มงวดตอนส่งออก" ก็คือสิ่งที่เรียกว่า "robustness principle" หรือ "Postel's law"

      • หลักการนี้มาจากยุคแรกเริ่มของอินเทอร์เน็ตในช่วงทศวรรษ 1980–90
      • แต่ตอนนี้วงการตระหนักกันอย่างกว้างขวางแล้วว่านี่เป็นวิธีคิดที่ผิด
      • หลักการนี้ทำให้เกิด protocol ossification และปัญหาด้านความปลอดภัยนับไม่ถ้วน

    • มีปัญหาหลายอย่างทั่วทั้งเครือข่ายที่เกิดจากการอาศัยลักษณะการทำงานของ BGP ซึ่งอนุญาตให้อุปกรณ์ฝั่ง local ส่งต่อแอตทริบิวต์ที่ตัวเองไม่รู้จักได้ตามเดิม

      • ตอนนี้เรากำลังได้เห็นความจริงว่าข้อเสียของ "ฟีเจอร์" แบบนี้มีอะไรบ้าง

    • ผู้เขียนก็ชี้ประเด็นนี้ไว้ในบทความที่เกี่ยวข้องเช่นกัน

      • "ฟีเจอร์" นี้ดูเหมือนเป็นความคิดที่แย่มากอย่างน่าประหลาด เพราะมันทำให้ระบบส่งต่อข้อมูลที่ตัวเองไม่เข้าใจแบบไม่วิพากษ์วิจารณ์
      • แต่ในอีกด้านหนึ่ง ฟีเจอร์นี้ก็ช่วยให้ความสามารถใหม่อย่าง Large Communities แพร่หลายได้อย่างรวดเร็ว และทำให้การนำฟีเจอร์ BGP ใหม่ๆ มาใช้เป็นไปได้

    • ผมไม่เห็นด้วยกับแนวทางนี้

      • ผมคิดว่าการเข้มงวดและระบุให้ชัดเจนทั้งสิ่งที่จะรับและสิ่งที่จะส่งออกนั้นดีกว่ามาก

  • ผมยังจำได้ดีว่าตอนต้องวิ่งวุ่นอย่างบ้าคลั่งเพื่อแพตช์บั๊ก CVE-2023-4481 ให้ทั่วทั้งเครือข่าย

    • บั๊กประเภทนี้จะยังคงเป็นฝันร้ายในการรับมือต่อไป
    • ด้วยธรรมชาติของการออกแบบและการอิมพลีเมนต์ BGP ผมกังวลว่าจะต้องใช้เวลานานมากกว่าจะแก้พฤติกรรมลักษณะนี้ได้จริง

  • ผมเคยพัฒนาฟังก์ชัน BGP ให้กับผู้ผลิตอุปกรณ์โทรคมนาคมรายหนึ่งมาก่อน (นานมากแล้ว)

    • จนถึงตอนนี้ก็ยังคิดว่า BGP ซับซ้อนเกินไป

    • ผู้คนยังคงเพิ่มฟีเจอร์ใหม่เข้าไป และฝั่ง vendor ก็อิมพลีเมนต์ตามมาตรฐานหรือ draft กันต่อเนื่อง

    • ด้วยธรรมชาติของ BGP ที่ดูเหมือนจะไม่มีวันถูกปลดระวาง จึงรู้สึกว่าบั๊กแบบนี้จะกลับมาเกิดซ้ำไม่รู้จบ

      • เมื่อก่อนผู้ให้บริการอย่าง AT&T และ vendor อย่าง Juniper, Cisco ฯลฯ เคยผลัก BGP เข้าไปใช้กับฟีเจอร์ด้าน MPLS และ VPN จนระบบจมลงสู่ความซับซ้อนอย่างลึก
        • มันซับซ้อนเกินเหตุ แต่บางส่วนก็ทำเงินได้มากจากสิ่งนั้น

  • HGC Global Communications Limited (เปลี่ยนชื่อมาจาก Hutchison Global Communications Limited, ย่อว่า HGC) เป็นผู้ให้บริการอินเทอร์เน็ตในฮ่องกง

  • รู้สึกว่าถ้า BGP มีการทำมาตรฐานให้ตรงกันในประเด็นพวกนี้ระหว่างผู้ผลิตฮาร์ดแวร์หลายราย ก็น่าจะมีเสถียรภาพมากกว่านี้

    • เลยสงสัยว่าปัญหาที่แท้จริงคือผู้ผลิตแต่ละรายไม่อยากทำมาตรฐาน เพราะต้องการ lock-in ลูกค้าไว้กับตัวเองหรือเปล่า
    • ขอบอกไว้ก่อนว่าความเข้าใจ BGP ของผมยังอยู่ในระดับตื้นๆ

  • ไม่รู้ว่ามีแค่ผมหรือเปล่า แต่ผมไม่เคยได้ยินเรื่อง BGP มาก่อนเลย จนกระทั่งได้ยินว่ามันไปก่อปัญหาอะไรสักอย่าง

    • มันเป็นโปรโตคอลสำคัญของอินเทอร์เน็ตพอๆ กับ TCP/IP แต่ TCP/IP กลับถูกสอนเยอะมากทั้งในโรงเรียน ในงาน ในหนังสือ ฯลฯ ขณะที่ BGP ผมไม่เคยได้แตะเลย
    • ที่บ้านเรายังทดลองและเรียนรู้ TCP/IP ได้ แต่ผมไม่รู้เลยว่าจะ "ลองเล่นที่บ้าน" กับ BGP ได้อย่างไร

      • ถ้ามีวิธีฝึก BGP ที่บ้านได้ก็อยากรู้

      • คุณสามารถซื้อเราเตอร์จริงที่มี BGP implementation อยู่ในตัวได้ (ของไม่แพงก็อย่างอุปกรณ์ Mikrotik) หรือใช้ implementation แบบโอเพนซอร์สก็ได้

        • มีทั้ง bird และ FRR (Free Range Routing) ที่ได้รับความนิยมมาก
        • คุณสามารถรัน Docker container สองตัวแล้วตั้ง BGP session ระหว่างกันเพื่อกระจาย static route ฯลฯ ได้
        • ถ้าต้องการ tutorial ก็มีคู่มือในลิงก์นี้ ที่เรียบเรียงไว้ดีและทำตามได้ด้วยซอฟต์แวร์ฟรี

      • DN42 เป็นสนามเด็กเล่นสำหรับฝึกเทคโนโลยี routing

        • แต่ต้องลงทุนเวลาอย่างจริงจัง จึงไม่ใช่อะไรที่ลองแบบชิลๆ ได้
        • ถึงผมจะทำงานด้านเน็ตเวิร์กพอสมควร แต่ WAN routing ก็ยังทำให้งงอยู่ดี
        • GNS3 เป็นวิธีที่ง่ายที่สุดในการลงมือฝึกเทคโนโลยีเครือข่ายแทบทุกแบบ
        • วิกิ DN42

      • ในวิชาเครือข่ายระดับปริญญาตรีของผมไม่ได้สอน BGP แต่ในระดับบัณฑิตศึกษามีสอน

        • ตอนนั้นเราใช้แพ็กเกจ Python ตัวหนึ่งที่จำลองหลาย AS ได้ แต่จำชื่อที่แน่ชัดไม่ได้แล้ว

      • วิชาเครือข่ายระดับปริญญาตรีที่ผมเคยเรียนพูดถึง BGP แค่คร่าวๆ บนกระดาน

        • ถ้าจะฝึก BGP ก็ใช้ network simulator แบบที่ผู้เขียนใช้ได้
        • ตอนเรียนเราใช้ simulator ชื่อ gini ซึ่งเป็นโปรแกรมที่นักศึกษาปริญญาโทของอาจารย์ทำขึ้น
        • gns3 ที่ผู้เขียนใช้ให้ความรู้สึกเหมือน ns3 เวอร์ชันที่เน้น Cisco
        • ns3 มีอะไรให้เรียนเยอะมากจนรู้สึกยาก
        • gini มีอินเทอร์เฟซที่ง่ายกว่า แต่ประสิทธิภาพก็ดรอปกว่า
        • ข้อมูลโครงการ gini
        • เอกสารทางการของ gns3

      • ให้ความรู้สึกว่าการจะ "ฝึก" BGP อย่างแท้จริงได้ ต้องถึงขั้นดูแลเครือข่ายขนาดใหญ่ที่เชื่อมกับทราฟฟิกอินเทอร์เน็ตจริง

        • สิ่งที่ทำที่บ้านได้ก็คือใช้ network simulator เท่านั้น

  • ในอดีตก็มี vendor หลายรายที่มีบั๊กลักษณะคล้ายกับในบทความ

  • เราเคยได้รับแพ็กเก็ตลักษณะคล้ายกันบนอุปกรณ์ chassis ที่ใช้ IOS XR ของเราด้วย

    • และในเวลาเดียวกันก็มีการประกาศ BGP route จำนวนมาก

    • ผมไม่แน่ใจว่าอุปกรณ์ upstream คืออะไรแน่

    • เลยสงสัยว่าโปรโตคอล BGP ถูก fuzz test อย่างเหมาะสมหรือไม่

    • มันเป็นโปรโตคอลที่สำคัญมากจนบางทีอาจไม่มีใครกล้าทำให้ล่มโดยตั้งใจก็ได้

    • การเขียน fuzzer สำหรับ BGP น่าจะง่าย แต่การวิเคราะห์สาเหตุการ crash อาจยากมาก

  • ทำให้นึกสงสัยว่ามีระบบไหนอีกไหมที่ทั้งมหึมาและเต็มไปด้วย accidental complexity สะสมเท่ากับอินเทอร์เน็ตแบ็กโบน

  • เมื่อดูจากผลกระทบของบั๊กประเภทนี้แล้ว ก็น่าแปลกใจที่ไม่มี consortium ที่ดูแลสิ่งอย่าง interoperability test suite

    • หรือไม่ก็อาจมีอยู่จริง เพียงแต่ปัญหานี้หลุดจากขอบเขตการทดสอบไป
    • ดูเป็นเรื่องธรรมดาว่าควรให้ fuzzer หรือเครื่องมือสร้าง test case สร้างแพ็กเก็ตผิดพลาดทุกรูปแบบโดยอัตโนมัติเพื่อเพิ่ม coverage
    • ต่อให้ใช้เวลารันหลายวันก็ยังคุ้ม
    • ผู้เขียนบทความได้สร้าง fuzzer ขึ้นมาใช้จริง และเจอปัญหาแบบคล้ายกันหลายครั้ง
    • จึงรู้สึกแปลกที่ vendor ไม่ได้ให้ความสนใจอย่างจริงจังกับงานวิจัยสำคัญแบบนี้