Network Fundamental › ออกสู่โลกกว้าง

BGP — อินเทอร์เน็ตเดินได้เพราะทุกคนเชื่อสิ่งที่เพื่อนบ้านบอก

บทการเลือกเส้นทางจบด้วยประโยคว่าไม่มีอะไรพิสูจน์ว่าเพื่อนบ้านพูดจริง บทนี้แสดงว่าเอกสารมาตรฐานของ BGP เองก็เขียนไว้แบบนั้น

2026-09-14 · หมวด 8 · ออกสู่โลกกว้าง · 9 นาที

บทความ การเลือกเส้นทาง จบด้วยประโยคที่ ค้างไว้

"คนที่รู้เส้นทางนั้นรู้เพราะมีคนอื่นบอก และไม่มีอะไรพิสูจน์ว่าคนที่บอกพูดความจริง"

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

ถ้ายังไม่เคยดู เริ่มตรงนี้

ข้อมูลเส้นทางของอินเทอร์เน็ตเปิดให้ทุกคนดูได้ RIPE เก็บสิ่งที่เราเตอร์จริงทั่วโลก มองเห็นไว้ และเปิด API ให้เรียก

$ curl "https://stat.ripe.net/data/routing-status/\
data.json?resource=8.8.8.0/24"

ตอบกลับมาว่าใครเป็นเจ้าของเส้นทางนั้น และมีผู้สังเกตกี่รายที่เห็นมัน

หน่วยของ BGP ไม่ใช่เราเตอร์ แต่เป็นองค์กร

RFC 4271 นิยามตัวเองไว้ในประโยคเดียว

"The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol."

Autonomous System คือองค์กรที่ตัดสินใจเรื่องเส้นทางเองได้ ผู้ให้บริการหนึ่งราย คือหนึ่ง AS มหาวิทยาลัยใหญ่ก็เป็นได้ และมีเลขประจำตัวของตัวเอง

ข้างในองค์กรจะมีเราเตอร์กี่ตัวก็เรื่องของเขา BGP ไม่สนใจ มันมองเห็นแค่ว่า องค์กรไหนต่อกับองค์กรไหน ซึ่งเป็นเหตุผลที่มันขยายไปทั้งโลกได้ — จำนวนองค์กร น้อยกว่าจำนวนเราเตอร์มหาศาล

และหน้าที่ของมันคือ

"The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems."

กันลูปด้วยการจดชื่อทุกคนที่ผ่าน

บทความ STP แก้ลูปด้วยการปิดพอร์ต บทความ IP กันลูปด้วย TTL ที่ลดลงทุกฮอป BGP ใช้วิธีที่สามที่ต่างจากทั้งคู่

ทุกครั้งที่เส้นทางผ่าน AS หนึ่ง AS นั้นเติมเลขตัวเองลงไปในรายการที่เดินทางมากับ เส้นทางนั้น RFC 4271 อธิบายการตรวจไว้ว่า

"AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path."

เห็นเลขตัวเองในรายการเมื่อไหร่ แปลว่าเส้นทางนี้วนกลับมาหาเราแล้ว จึงทิ้ง

ข้อดีที่ตามมาโดยไม่ต้องออกแบบเพิ่ม คือรายการนั้นบอกด้วยว่าเส้นทางเดินผ่านใครมาบ้าง ซึ่งเป็นข้อมูลที่ TTL ไม่มีทางให้ได้

วัดจากของจริง สามร้อยเจ็ดสิบห้าจุด

ผมดึงสิ่งที่ผู้สังเกตของ RIPE มองเห็นสำหรับ 8.8.8.0/24 ณ วันที่ 2 กันยายน 2026

  AS_PATH length   จุดสังเกต
       2 AS            279
       3 AS             82
       4 AS             12
       5 AS              2
                       ---
                       375

เส้นทางที่สั้นที่สุดกับยาวที่สุดที่เก็บได้

  328977 15169
  328840 327727 174 6453 15169

สังเกตตัวสุดท้ายของทั้งสองเส้น มันคือเลขเดียวกัน และเมื่อไล่ดูทั้ง 375 เส้น

  observers            375 จุด
  path lengths           4 แบบ
  origin AS numbers      1 ค่า

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

เลือกด้วยนโยบาย ไม่ใช่ระยะทาง

นี่คือจุดที่คนมาจากโลกของ OSPF หรือ RIP เข้าใจผิดมากที่สุด

RFC 4271 บอกว่าข้อมูลที่ BGP แลกกันเพียงพอสำหรับ

"constructing a graph of AS connectivity, from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced."

คำว่า policy อยู่ในประโยคนิยาม ส่วนคำว่าเร็วที่สุดหรือใกล้ที่สุดไม่มี

เส้นทางที่ผ่าน 2 AS อาจถูกทิ้งเพื่อไปใช้เส้นที่ผ่าน 4 AS ได้ ถ้าเส้นแรกต้องจ่ายเงิน และเส้นหลังไม่ต้อง และนั่นไม่ใช่ความผิดพลาด มันคือสิ่งที่โพรโทคอลออกแบบมาให้ทำได้

ส่วนความปลอดภัยของ RFC 4271 ปกป้องท่อ ไม่ใช่คำพูด

ผมอ่านหัวข้อ Security Considerations ของ RFC 4271 ทั้งหัวข้อ ยาวราวสี่พันตัวอักษร และมันพูดถึงเรื่องเดียวคือกุญแจ MD5 ที่ใช้ป้องกันการเชื่อมต่อ TCP ระหว่างเราเตอร์ สองตัวที่คุยกัน

  word in that section   จำนวนครั้ง
  authorization                   0
  hijack                          0
  entitled                        0

ไม่มีสักคำเรื่องว่าเส้นทางที่ประกาศมานั้นเป็นของผู้ประกาศจริงหรือเปล่า และ หัวข้อนี้จบด้วยประโยคเดียวที่ชี้ไปที่อื่น

"BGP vulnerabilities analysis is discussed in [RFC4272]."

RFC 4272 พูดสิ่งที่ RFC 4271 ไม่ได้พูด

เอกสารฉบับนั้นเขียนไว้ตรง ๆ สามประโยค

"BGP has no internal mechanism that provides strong protection of the integrity, freshness, and peer entity authenticity of the messages in peer-peer BGP communications."

"no mechanism has been specified within BGP to validate the authority of an AS to announce NLRI information."

"no mechanism has been specified within BGP to ensure the authenticity of the path attributes announced by an AS."

ประโยคที่สองแปลว่า ไม่มีอะไรตรวจว่าคุณมีสิทธิ์ประกาศเลขไอพีชุดนั้น ประโยคที่สามแปลว่า ไม่มีอะไรตรวจว่าเส้นทางที่คุณอ้างว่าผ่านมานั้นเป็นเรื่องจริง

นี่คือประโยคที่บทการเลือกเส้นทางทิ้งท้ายไว้ เขียนโดย IETF เอง

ทำไมการแย่งเส้นทางถึงได้ผล

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

  announcement   addresses   result against /24
  /24 genuine          256   genuine wins
  /25 forged           128   forged wins
  /26 forged            64   forged wins

ผู้แย่งไม่ต้องเจาะอะไรเลย แค่ประกาศ prefix ที่ยาวกว่า แล้วเราเตอร์ทุกตัว ที่รับข่าวนั้นจะเลือกตัวปลอม เพราะทำตามกฎอย่างถูกต้อง

จำนวนทางเลือกที่ผู้แย่งมี ถ้าเป้าหมายเป็น /24 หนึ่งอัน

  /25    2 อัน
  /32  256 อัน

RPKI ปิดครึ่งหนึ่งของช่องนั้น

RFC 6811 เพิ่มการตรวจว่าเลข AS ที่อ้างเป็นต้นทาง ได้รับอนุญาตจากเจ้าของ prefix จริงหรือไม่ ผลออกมาสามสถานะ

"NotFound: No VRP Covers the Route Prefix."

"Valid: At least one VRP Matches the Route Prefix."

"Invalid: At least one VRP Covers the Route Prefix, but no VRP Matches"

ผมตรวจของจริงกับ 8.8.8.0/24 และ AS15169

  status       valid
  ROA prefix   8.8.8.0/24
  ROA origin   15169
  maxLength    24

maxLength เท่ากับ 24 คือสิ่งที่ปิดช่องข้างบน เพราะการประกาศ /25 ของ prefix นี้ จะถูกตัดสินเป็น Invalid ทันที แม้ผู้ประกาศจะใส่เลข 15169 มาเองก็ตาม

แต่ปิดได้แค่ครึ่งเดียวจริง ๆ

RFC 6811 บอกขอบเขตของตัวเองไว้ชัดกว่าเอกสารส่วนใหญ่

"does not protect against 'AS-in-the-middle attacks' or provide any path validation."

"Note that the complete path attestation against the AS_PATH attribute of a route is outside the scope of this document."

มันตรวจว่าใครเป็นต้นทาง ไม่ได้ตรวจว่าเส้นทางที่อ้างว่าเดินผ่านมานั้นจริงไหม ซึ่งตรงกับประโยคที่สามของ RFC 4272 พอดี — ประโยคนั้นยังไม่มีคำตอบ

เมื่อมันโกหก

"BGP เลือกเส้นทางที่สั้นที่สุด" เอกสารนิยามใช้คำว่า policy ไม่ได้ใช้คำว่าสั้น เส้นที่ยาวกว่าอาจถูกเลือกเพราะถูกกว่า

"เส้นทางที่ผ่าน AS น้อยกว่าคือเส้นที่เร็วกว่า" จำนวน AS ไม่ใช่ระยะทาง หนึ่ง AS อาจครอบทั้งทวีป

"มี RPKI แล้วปลอดภัย" RFC 6811 เขียนเองว่าไม่ได้ตรวจเส้นทาง ตรวจแค่ต้นทาง

"การแย่งเส้นทางคือการเจาะระบบ" ไม่ใช่ มันคือการประกาศข้อมูลเท็จแล้วให้ทุกคน ทำตามกฎ ซึ่งเป็นสิ่งที่เกิดจากความผิดพลาดในการตั้งค่าได้พอ ๆ กับเจตนา

"เราตรวจสอบได้เองว่าเส้นทางถูกต้อง" จากเครื่องปลายทาง คุณเห็นแค่เส้นทางที่ ถูกเลือกแล้ว ไม่ได้เห็นเส้นทางที่ถูกทิ้ง และไม่เห็นเหตุผลที่ทิ้ง

ตัวอย่างจริงจากงานจริง

กรณีที่ 1 — ตรวจว่าเลขไอพีของเราถูกประกาศจากที่ที่ควร

สถานการณ์ อยากรู้ว่าเลขไอพีขององค์กรถูกใครประกาศบ้าง

คำสั่ง

$ curl "https://stat.ripe.net/data/routing-status/\
data.json?resource=<prefix>"

อ่านอย่างไร ดูรายการ origins ถ้ามีเลข AS ที่ไม่ใช่ของคุณหรือของผู้ให้บริการ ที่คุณมอบหมายไว้ นั่นคือสัญญาณที่ต้องตามต่อ และดู ris_peers_seeing ว่ามีผู้สังเกต กี่รายที่เห็น ถ้าน้อยผิดปกติแปลว่าเส้นทางกระจายไม่ทั่ว

สิ่งที่ยังไม่ได้พิสูจน์ ผู้สังเกตของ RIPE คือชุดหนึ่งของมุมมองบนโลก ไม่ใช่ ทุกมุมมอง การที่พวกเขาไม่เห็นความผิดปกติ ไม่ได้แปลว่าไม่มีที่ไหนเห็น

กรณีที่ 2 — ทราฟฟิกออกเส้นที่แพงกว่าโดยไม่มีใครสั่ง

สถานการณ์ มีผู้ให้บริการสองราย ทราฟฟิกไปกองอยู่รายที่คิดเงินแพงกว่า

อ่านอย่างไร ตรวจสามอย่างตามลำดับ

  1  local preference   ค่าที่เราตั้งเอง มาก่อนทุกอย่าง
  2  AS_PATH length     สั้นกว่าชนะ ถ้าข้อ 1 เท่ากัน
  3  prefix length      ยาวกว่าชนะ ก่อนทั้งสองข้อข้างบน

ข้อสามมาก่อนเสมอ เพราะการเลือกเส้นทางเกิดที่ระดับ prefix ไม่ใช่ระดับปลายทาง ถ้าอีกฝั่งประกาศ prefix ที่ละเอียดกว่า ค่าที่เราตั้งไว้ในข้อหนึ่งไม่มีผลเลย

สิ่งที่ยังไม่ได้พิสูจน์ เกณฑ์รองหลังจากสามข้อนี้ต่างกันไปตามผู้ผลิต และเอกสาร มาตรฐานไม่ได้กำหนดทั้งหมด ต้องดูคู่มือของอุปกรณ์ที่ใช้จริง

กรณีที่ 3 — ประเมินว่าควรทำ ROA ไหม

สถานการณ์ มีเลขไอพีเป็นของตัวเอง และต้องตัดสินใจว่าจะลงทุนทำ RPKI ไหม

อ่านอย่างไร ถามสองข้อ

  1  prefix ที่ยาวที่สุดที่เราจะประกาศจริง คือเท่าไหร่
  2  ถ้ามีคนประกาศ prefix ที่ยาวกว่านั้น เราอยากให้ผลเป็นอย่างไร

ข้อแรกคือค่า maxLength ที่ควรตั้ง และการตั้งให้กว้างเกินจำเป็น คือการเปิดช่อง ที่ ROA มีไว้ปิดพอดี

สิ่งที่ยังไม่ได้พิสูจน์ ROA มีผลก็ต่อเมื่อผู้รับเส้นทางเลือกเอาไปใช้ตัดสิน การมี ROA ที่ถูกต้องไม่ได้แปลว่าทุกเราเตอร์บนโลกจะปฏิเสธของปลอมให้

สิ่งที่ทั้งซีรีส์เดินมาถึง

ARP เชื่อคำตอบว่าใครถือที่อยู่นั้น DHCP เชื่อเครื่องที่ตอบมาก่อน STP เชื่อค่าที่เพื่อนบ้านประกาศ และ BGP เชื่อว่าเส้นทางที่ได้รับมาเป็นเรื่องจริง

ทั้งสี่ทำงานได้เพราะเชื่อ และทั้งสี่ถูกหลอกได้ด้วยวิธีเดียวกัน คือพูดให้ดัง และพูดก่อน

ต่างกันที่ขนาดของผลลัพธ์ ARP หลอกได้แค่ในวงเดียว ส่วน BGP หลอกได้ทั้งอินเทอร์เน็ต

และคำตอบที่มนุษย์หามาได้จนถึงตอนนี้ ไม่ใช่การเลิกเชื่อ แต่คือการทำให้การโกหก ตรวจจับได้ทีหลัง ซึ่ง RPKI ทำได้ครึ่งหนึ่ง และอีกครึ่งยังเปิดอยู่

อ้างอิง

เอกสารมาตรฐาน

• RFC 4271 มกราคม 2006 A Border Gateway Protocol 4 — ประโยคนิยาม การตรวจลูปด้วย AS_PATH และหัวข้อ Security Considerations ที่พูดถึงแต่กุญแจ TCP
• RFC 4272 มกราคม 2006 BGP Security Vulnerabilities Analysis — สามประโยคที่ยกมาอ้างในบทนี้
• RFC 6811 มกราคม 2013 BGP Prefix Origin Validation — สามสถานะ และขอบเขตที่เอกสารระบุเอง

วัดจากข้อมูลสาธารณะ

• RIPEstat API ข้อมูลของ 8.8.8.0/24 ณ 2 กันยายน 2026 — ต้นทาง AS15169 ผู้สังเกตเห็น 99 จาก 99 ราย เส้นทาง 375 เส้นจากจุดสังเกตทั่วโลก และผลตรวจ RPKI เป็น valid โดย ROA กำหนด maxLength เท่ากับ 24
• ข้อมูลชุดนี้มาจากเราเตอร์จริงที่ RIPE เก็บไว้ ไม่ใช่จากเครื่องที่ใช้เขียน

คำนวณเอง

• ตารางจำนวนที่อยู่ต่อ prefix และจำนวน prefix ย่อยที่ซอยได้ คำนวณจากความยาว prefix โดยตรง

ความเชื่อใจวัดจากเครื่องจริงคำนวณเอง

อ่านหน้านี้เป็นภาษาอังกฤษ