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

 (blog.benjojo.co.uk)
1 คะแนน โดย GN⁺ 2025-05-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อวันที่ 20 พฤษภาคม 2025 เวลา 07:00 UTC ข้อความ BGP ที่เสียหาย ซึ่งถูกเผยแพร่ออกไปทำให้ implementation หลัก 2 รายเกิดพฤติกรรมที่ไม่คาดคิด ส่งผลให้ BGP session ที่เชื่อมต่ออินเทอร์เน็ตจำนวนมากถูกรีเซ็ต และทำให้บางเครือข่ายเกิดความไม่เสถียรในการกำหนดเส้นทางหรือการเชื่อมต่อขาดช่วงสั้น ๆ
  • update ที่เป็นปัญหามี BGP Prefix-SID Attribute แนบมาด้วย ซึ่งปกติไม่คาดว่าจะพบใน BGP update บนอินเทอร์เน็ต และอยู่ในสภาพเสียหายโดยข้อมูลภายในทั้งหมดเป็น 0x00
  • IOS-XR/Nokia SR-OS ที่ใช้การยอมรับข้อผิดพลาดตาม RFC7606 สามารถกรองออกได้ แต่ JunOS ส่งต่อ และ Arista EOS รีเซ็ต session ซึ่งอาจส่งผลต่อผู้ใช้ Arista ที่เชื่อมต่อกับ transit carrier ที่ใช้ JunOS
  • จากการสังเกตของ bgp.tools พบ AS9304, AS135338, AS151326, AS138077 ปรากฏซ้ำ ๆ และผู้ที่เพิ่ม attribute ที่มีข้อบกพร่องน่าจะเป็น Starcloud AS135338 หรือ Hutchison AS9304
  • ระหว่างเหตุการณ์ อัตราข้อความเฉลี่ย 10 วินาทีของ route collector ของ bgp.tools พุ่งจากระดับปกติ 20,000–30,000 ข้อความต่อวินาที เป็น มากกว่า 150,000/s แสดงให้เห็นว่าความแตกต่างในการจัดการข้อผิดพลาดของ BGP สามารถสั่นคลอนเสถียรภาพของเส้นทางอินเทอร์เน็ตจริงได้

เหตุการณ์ BGP update วันที่ 20 พฤษภาคม 2025

  • เมื่อวันอังคารที่ 20 พฤษภาคม 2025 เวลา 07:00 UTC ข้อความ BGP ที่ถูกเผยแพร่ออกไปก่อให้เกิดพฤติกรรมที่ไม่คาดคิดใน implementation หลัก 2 รายของ BGP ที่มักใช้ในการส่งต่อทราฟฟิกอินเทอร์เน็ต
  • ผลกระทบลุกลามเมื่อ BGP session ที่เชื่อมต่ออินเทอร์เน็ตจำนวนมากถูกปิดโดยอัตโนมัติ
    • มีการยืนยันว่าในบางเครือข่ายเกิด ความไม่เสถียรของการกำหนดเส้นทาง
    • ในกรณีเลวร้ายที่สุด อาจเกิดการเชื่อมต่อขาดช่วงสั้น ๆ

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

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

AS ที่อาจเป็นผู้เพิ่ม attribute ที่มีข้อบกพร่อง

  • จากการกรอง archive ของ bgp.tools ในช่วงเวลาดังกล่าว พบว่า origin AS หลายแห่งดูเหมือนเกี่ยวข้องกับเหตุการณ์
  • สิ่งนี้ชี้ว่า attribute อาจไม่ได้ถูกเพิ่มโดยเครือข่ายที่เป็น origin ของ prefix แต่ถูกเพิ่มโดย carrier ระหว่างทางไปยังอินเทอร์เน็ตวงกว้าง
  • ผู้ต้องสงสัยที่ปรากฏซ้ำในข้อความที่เป็นปัญหาทั้งหมดมี 4 รายดังนี้
    • AS9304 — Hutchison Global Communications Limited
    • AS135338 — Starcloud Information Limited
    • AS151326 — DCConnect Communication Pte. Ltd.
    • AS138077 — PT Abhinawa Sumberdaya Asia
  • bgp.tools สังเกตเห็น impacted prefix บนเส้นทาง […] 151326 138077 […] โดยไม่มี attribute BGP ที่มีข้อบกพร่อง
    • ดังนั้นผู้ที่เพิ่ม attribute ที่มีข้อบกพร่องน่าจะเป็น Starcloud AS135338 หรือ Hutchison AS9304
  • prefix บางส่วนที่พบใน update ที่มี attribute มีดังนี้
    • 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 Exchange

  • เหตุการณ์ขยายวงมากขึ้นเพราะ Hutchison/AS9304 เชื่อมต่ออยู่กับ Internet Exchange จำนวนมาก
  • ข้อความที่เป็นปัญหาถูกส่งไปยัง IX route server และ route server เหล่านี้โดยทั่วไปจะรัน bird
  • Bird ไม่รองรับ BGP SID จึงไม่สามารถกรองข้อความได้ และเผยแพร่ต่อไปยัง Internet Exchange ระดับหลาย terabit หลายแห่งโดยตรง
  • ผลคือความปั่นป่วนแพร่กระจายไกลเกินกว่า internet transit session ไปสู่ขอบเขตที่กว้างขึ้น

ลักษณะของ BGP Prefix-SID

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

เครือข่ายที่ได้รับผลกระทบและตัวชี้วัดที่สังเกตได้

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

ความแตกต่างในการจัดการข้อผิดพลาดของแต่ละ vendor

  • แม้สาเหตุรากหรือผู้ก่อให้เกิดจริงจะยังไม่ชัดเจนทั้งหมด แต่การที่ข้อความมีข้อบกพร่องถูกเผยแพร่ในระดับอินเทอร์เน็ตแสดงให้เห็นความเสี่ยงของการจัดการข้อผิดพลาดใน BGP
  • vendor รายอื่นตรวจพบ attribute ที่มีข้อบกพร่องและระงับการประกาศ route แต่ Juniper ส่งต่อไปยัง peer
  • หลังจากข้อความดังกล่าวไปถึงอุปกรณ์ Arista แล้ว ดูเหมือนว่าโค้ด BGP error tolerance จะไม่มีอยู่หรือมีข้อบกพร่อง จนนำไปสู่การรีเซ็ต session
  • เอกสาร BGP error tolerance ของ JunOS จาก Juniper ระบุว่า JunOS ไม่ได้ตรวจสอบทุกส่วนของข้อความ
  • พฤติกรรมนี้ทำให้ JunOS เองหลีกเลี่ยงการถูกรีเซ็ต session จากระยะไกล แต่กลับส่งต่อข้อความเดียวกันไปยัง peer อื่นหรือลูกค้า

นัยเชิงปฏิบัติการ

  • outage ครั้งนี้เกิดขึ้นไม่นาน แต่ก็อาจก่อผลกระทบที่ใหญ่กว่านี้ได้
  • เมื่อบริการจำนวนมากขึ้นย้ายมาอยู่บนฐาน IP ขอบเขตของอินเทอร์เน็ตขัดข้องอาจเกินกว่าการเข้าอีเมลไม่ได้
    • การออกอากาศทีวีล้มเหลว
    • การโทรหาบริการฉุกเฉินขัดข้อง
  • บั๊กเช่นนี้เพิ่มความเป็นไปได้ที่จะก่อให้เกิดหรือซ้ำเติมความเสียหายต่อชีวิตมนุษย์ในโลกจริง
  • ผู้ให้บริการเครือข่ายที่มี routing table แบบเต็มสามารถส่ง data feed ให้ bgp.tools เพื่อช่วย debug เหตุการณ์ในอนาคตได้

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

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

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

  • แนวทางมาตรฐานคือควรใจกว้างตอนรับเข้า และเข้มงวดตอนส่งออก
    ทางเลือกมีทั้งกรองข้อความที่เสียทิ้ง, โยนทิ้ง, เพิกเฉยต่อ attribute ที่เสียแต่ยังส่งต่อ, หรือพังเพราะ attribute ที่เสีย ซึ่งผมมองว่าสิ่งที่ยอมรับได้ยากจริง ๆ มีแค่ข้อ 4 คือ พฤติกรรมแบบ Arista เท่านั้น ข้อ 3 ซึ่งเป็นพฤติกรรมแบบ Juniper แม้ไม่พึงประสงค์ แต่ก็ไม่ถึงขั้นร้ายแรง
    พอกลับมาอ่านใหม่ ดูเหมือน Arista จะใกล้เคียงข้อ 2 มากกว่าข้อ 4 และไม่ได้ crash ทั้งหมด แต่ดูเหมือนมองว่าเป็นการเชื่อมต่อที่ไม่ถูกต้องแล้วปิดไป ในมุมผู้ใช้ก็ไม่ดี แต่ในเชิงถกเถียงถือว่ายอมรับได้อยู่

    • มี RFC 7606 (Revised Error Handling for BGP UPDATE Messages) อยู่แล้ว ซึ่งกำหนดไว้อย่างละเอียดว่าควรจัดการข้อความ BGP ที่เสียอย่างไร
      วิธีที่พบบ่อยที่สุดคือ treat-as-withdraw คือปฏิบัติต่อ update การประกาศเส้นทางเหมือนเป็นการถอนเส้นทางที่เคยประกาศไว้ ถ้าแค่โยนข้อความที่เสียทิ้งไป จะทำให้ยังคงสถานะเก่าที่ไม่ถูกต้องอีกต่อไปไว้เรื่อย ๆ ดังนั้นจึงไม่ควรทำแบบนั้น
    • สิ่งที่พูดอีกแบบในที่นี้คือสิ่งที่เรียกว่า หลักความทนทาน หรือกฎของ Postel
      เป็นแนวคิดจากประวัติศาสตร์ยุคโบราณของอินเทอร์เน็ตในทศวรรษ 1980 และ 1990 แต่ทุกวันนี้เป็นที่เข้าใจกันกว้างขวางว่าเป็นไอเดียที่ผิดพลาด ซึ่งก่อให้เกิด protocol ossification และปัญหาความปลอดภัยจำนวนมาก
    • ปัญหาคือผู้คนเอาพฤติกรรมของ BGP ที่ส่งต่อ attribute ที่ไม่รู้จัก แม้อุปกรณ์ใน local จะไม่เข้าใจ ไปใช้สารพัดอย่างทั่วทั้งเครือข่าย
      ตอนนี้ระบบจำนวนมากพึ่งพาพฤติกรรมนั้นอยู่ และกำลังเจอข้อเสียของ “ฟีเจอร์” นี้
    • ในบทความที่เกี่ยวข้อง ผู้เขียนก็ชี้จุดเดียวกัน
      ดูเผิน ๆ แล้ว “ฟีเจอร์” นี้ดูเหมือนเป็นไอเดียที่แย่มาก เพราะทำให้ข้อมูลที่ไม่รู้จักถูกแพร่กระจายแบบไม่ลืมหูลืมตาผ่านระบบที่ไม่เข้าใจผลกระทบของข้อมูลที่ส่งต่ออยู่ แต่ในอีกมุมหนึ่ง ด้วยฟีเจอร์นี้ สิ่งอย่าง Large Communities จึงสามารถถูก deploy อย่างแพร่หลายได้เร็วขึ้น และอาจพูดได้ว่ามันทำให้การ deploy ฟีเจอร์ใหม่ ๆ ของ BGP เป็นไปได้ด้วย
    • ไม่เห็นด้วยกับแนวทางนี้ ผมคิดว่าควรเข้มงวดมากทั้งตอนรับเข้าและตอนส่งออกจะดีกว่า

  • ยังจำได้อยู่เลยว่าต้องวิ่งวุ่นเหมือนบ้าเพื่อแก้ CVE-2023-4481 ทั่วทั้งเครือข่าย
    บั๊กประเภทนี้คงเป็นฝันร้ายมากในการจัดการ และด้วยวิธีที่ BGP ถูกออกแบบและ implement มา การแก้พฤติกรรมแบบนี้คงใช้เวลา นานมาก

  • แม้จะหลายสิบปีก่อนแล้ว แต่เคยพัฒนา ฟีเจอร์ BGP ที่บริษัทผู้ผลิตอุปกรณ์สื่อสาร
    ถึงตอนนี้ก็ยังคิดว่า BGP ซับซ้อนเกินไป และผู้คนก็ยังเพิ่มฟีเจอร์ใหม่ ๆ กันต่อไป ขณะที่ผู้ผลิตก็ implement ตามมาตรฐาน RFC หรือ draft กันเรื่อย ๆ
    BGP ก็ดูไม่น่าจะถูกเลิกใช้ ดังนั้นบั๊กแบบนี้ก็คงจะถูกพบซ้ำแล้วซ้ำเล่าต่อไป

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

  • HGC Global Communications Limited เป็นบริษัทที่เคยรู้จักกันในชื่อ Hutchison Global Communications Limited เป็นผู้ให้บริการอินเทอร์เน็ตในฮ่องกง
    https://en.wikipedia.org/wiki/HGC_Global_Communications

  • แชสซี IOS XR ของเราก็ได้รับ packet แบบนี้บางส่วน และเวลาตรงกับการโฆษณาเส้นทาง BGP ปริมาณสูงด้วย บอกตามตรงว่าไม่รู้ว่า upstream ใช้อุปกรณ์อะไร
    เลยสงสัยว่าโปรโตคอล BGP ถูก fuzz อย่างเหมาะสมอยู่หรือเปล่า อาจเป็นพื้นที่ที่สำคัญเกินไปจนทุกคนกลัวที่จะลองทำให้มันพังก็ได้
    การเขียน BGP fuzzer อาจง่าย แต่การวินิจฉัยสาเหตุของ crash น่าจะยากมาก

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

    • ซื้อเราเตอร์ที่มีการใช้งาน BGP ก็ได้ มีอุปกรณ์ราคาถูกอย่าง Mikrotik และก็มี implementation แบบโอเพนซอร์สด้วย
      ในบทความพูดถึง bird และยังมี implementation ที่นิยมมากอย่าง FRR (free range routing) ด้วย การรัน Docker container สองตัวแล้วสร้าง BGP session ระหว่างกัน จากนั้นเช่นประกาศ static route ที่ตั้งไว้ภายในนั้น ทำได้ง่ายมาก
      ถ้าชอบ tutorial แบบมีคำแนะนำ https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/ ค่อนข้างดี และขยายไปถึงหัวข้อที่สูงขึ้นอีกเล็กน้อยได้ด้วย สิ่งที่ต้องใช้ในการทำตามทั้งหมดเป็นซอฟต์แวร์เสรี
    • DN42[1] มีสนามทดลองให้ลองเทคโนโลยี routing ได้ ถ้าไม่ได้ตั้งใจจะทุ่มเวลาเยอะ ก็ไม่แนะนำให้ขุดลึกมาก แม้ในฐานะคนที่ค่อนข้างคุ้นกับ networking แล้ว WAN routing ก็ยังชวนสับสนอยู่ดี
      วิธีที่ง่ายที่สุดในการได้ลองเทคโนโลยี networking ใด ๆ ด้วยตัวเองน่าจะเป็น GNS3
      [1]: https://wiki.dn42.us/home
    • BGP ก็เหมือนการขนส่งสินค้าทางเรือระหว่างประเทศ จำเป็นต้องมีเพื่อให้โลกเดินต่อไปได้ แต่คนส่วนใหญ่ไม่จำเป็นต้องมีปฏิสัมพันธ์กับมันโดยตรง
      วิธีหนึ่งในการทดลองคือแบบนี้: https://www.eve-ng.net/
      อีกวิธีคือสร้าง virtual machine สักสองสามตัวที่มี network interface หลายอัน แล้วตั้งค่าเครือข่ายระหว่างกัน จากนั้นใช้ BGP routing daemon
      https://bird.network.cz/
      https://www.nongnu.org/quagga/
      มีของประมาณนี้อยู่
    • ในวิชา networking ระดับปริญญาตรีไม่ได้สอน BGP แต่ในวิชา networking ระดับบัณฑิตศึกษามีสอน
      ตอนนั้นใช้แพ็กเกจ Python สำหรับจำลอง AS หลายตัว แต่จำไม่ได้ว่าเป็นแพ็กเกจไหน
    • ในวิชา network ระดับปริญญาตรีก็แตะ BGP นิดหน่อย แต่เป็นแค่อธิบายบนกระดาน
      ถ้าจะทดลอง BGP ก็ใช้ network simulator ได้เหมือนผู้เขียนบทความนี้ ในวิชาใช้ gini[1] ซึ่งเหมือนจะเป็นสิ่งที่นักศึกษาบัณฑิตศึกษาของอาจารย์ทำไว้ ส่วนผู้เขียนดูเหมือนใช้ gns3 ซึ่งคล้าย ns3 เวอร์ชันเฉพาะทางของ Cisco ผมเคยลองใช้ ns3 ครั้งหนึ่งและพบว่า learning curve ชันมาก ส่วน gini simulator มี user interface พื้นฐานกว่า แต่ก็คงมีความสามารถน้อยกว่าด้วย
      [1] https://citelab.github.io/gini5/
      [2] https://docs.gns3.com/docs/

  • ดูเหมือนว่า BGP น่าจะเสถียรกว่านี้มาก หากผู้ผลิตฮาร์ดแวร์หลายรายตกลงกันได้ถึง วิธีมาตรฐาน ในการจัดการเรื่องลักษณะนี้
    ปัญหาจริง ๆ อยู่ที่แต่ละรายไม่ยอมทำให้เป็นมาตรฐานเพราะต้องการ lock-in effect หรือเปล่า?
    ทั้งนี้ ความเข้าใจของผมเกี่ยวกับ BGP ยังตื้นและจำกัดมาก และผมไม่ใช่ผู้เชี่ยวชาญ

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

  • ผู้ผลิตหลายรายเคยเจอบั๊กนี้มาก่อน: 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 ไม่ได้รับผลกระทบ

  • คงหาอะไรที่มีขนาดใหญ่และมี ความซับซ้อนโดยไม่จำเป็น พัวพันแบบไบแซนไทน์ได้เท่ากับท่อประปาของอินเทอร์เน็ตได้ยาก