สวัสดี ฉันชื่ออเล็กซานเดอร์ อาซิมอฟ ที่ Yandex ฉันพัฒนาระบบตรวจสอบต่างๆ รวมถึงสถาปัตยกรรมเครือข่ายการขนส่ง แต่วันนี้เราจะมาพูดถึงโปรโตคอล BGP
เมื่อสัปดาห์ที่แล้ว Yandex เปิดใช้งาน ROV (การตรวจสอบความถูกต้องของเส้นทาง) ที่อินเทอร์เฟซกับพันธมิตรแบบเพียร์ทั้งหมด รวมถึงจุดแลกเปลี่ยนการรับส่งข้อมูล อ่านด้านล่างว่าเหตุใดจึงทำเช่นนี้ และจะส่งผลต่อปฏิสัมพันธ์กับผู้ให้บริการโทรคมนาคมอย่างไร
BGP และเกิดอะไรขึ้นกับมัน
คุณคงรู้ว่า BGP ได้รับการออกแบบให้เป็นโปรโตคอลการกำหนดเส้นทางระหว่างโดเมน อย่างไรก็ตาม ในระหว่างนี้ จำนวนกรณีการใช้งานสามารถเพิ่มขึ้นได้: ในปัจจุบัน BGP ต้องขอบคุณส่วนขยายจำนวนมาก ที่ได้กลายเป็นบัสข้อความ ครอบคลุมงานตั้งแต่ VPN ของผู้ให้บริการไปจนถึง SD-WAN ที่ทันสมัยในขณะนี้ และยังพบแอปพลิเคชันอีกด้วย การขนส่งสำหรับคอนโทรลเลอร์ที่มีลักษณะคล้าย SDN โดยเปลี่ยนเวกเตอร์ระยะทาง BGP ให้เป็นสิ่งที่คล้ายกับโปรโตคอล sat ของลิงก์
มะเดื่อ 1 บีจีพี ซาฟี
เหตุใด BGP จึงได้รับ (และยังคงได้รับ) การใช้งานมากมาย? มีสองเหตุผลหลัก:
- BGP เป็นโปรโตคอลเดียวที่ทำงานระหว่างระบบอัตโนมัติ (AS)
- BGP รองรับแอตทริบิวต์ในรูปแบบ TLV (type-length-value) ใช่ โปรโตคอลไม่ได้อยู่คนเดียวในเรื่องนี้ แต่เนื่องจากไม่มีอะไรจะมาแทนที่ที่ทางแยกระหว่างผู้ให้บริการโทรคมนาคม การแนบองค์ประกอบการทำงานอื่นเข้ากับมันมักจะทำกำไรได้มากกว่าการรองรับโปรโตคอลการกำหนดเส้นทางเพิ่มเติม
เกิดอะไรขึ้นกับเขา? กล่าวโดยสรุป โปรโตคอลไม่มีกลไกในตัวสำหรับตรวจสอบความถูกต้องของข้อมูลที่ได้รับ นั่นคือ BGP เป็นโปรโตคอลความเชื่อถือแบบนิรนัย: หากคุณต้องการบอกให้โลกรู้ว่าตอนนี้คุณเป็นเจ้าของเครือข่าย Rostelecom, MTS หรือ Yandex ได้โปรด!
ตัวกรองที่ใช้ IRRDB - ดีที่สุดจากแย่ที่สุด
คำถามเกิดขึ้น: เหตุใดอินเทอร์เน็ตจึงยังทำงานในสถานการณ์เช่นนี้ได้ ใช่ มันใช้งานได้เกือบตลอดเวลา แต่ในขณะเดียวกันก็ระเบิดเป็นระยะ ทำให้ไม่สามารถเข้าถึงกลุ่มระดับชาติทั้งหมดได้ แม้ว่ากิจกรรมของแฮ็กเกอร์ใน BGP จะเพิ่มขึ้นเช่นกัน แต่ความผิดปกติส่วนใหญ่ยังคงเกิดจากข้อบกพร่อง ตัวอย่างปีนี้ก็คือ
ข้าว. 2. การสกัดกั้นการรับส่งข้อมูล Cloudflare
แต่ทำไมความผิดปกติดังกล่าวถึงเกิดขึ้นทุกๆ หกเดือน ไม่ใช่ทุกวัน? เนื่องจากผู้ให้บริการใช้ฐานข้อมูลภายนอกของข้อมูลเส้นทางเพื่อตรวจสอบสิ่งที่พวกเขาได้รับจากเพื่อนบ้าน BGP มีฐานข้อมูลดังกล่าวมากมาย บางส่วนได้รับการจัดการโดยผู้รับจดทะเบียน (RIPE, APNIC, ARIN, AFRINIC) บางส่วนเป็นผู้เล่นอิสระ (ที่มีชื่อเสียงที่สุดคือ RADB) และยังมีผู้รับจดทะเบียนทั้งชุดที่เป็นเจ้าของโดยบริษัทขนาดใหญ่ (ระดับ 3) , NTT ฯลฯ) ต้องขอบคุณฐานข้อมูลเหล่านี้ที่การกำหนดเส้นทางระหว่างโดเมนรักษาความเสถียรของการทำงาน
อย่างไรก็ตามมีความแตกต่าง ข้อมูลเส้นทางจะถูกตรวจสอบตามวัตถุ ROUTE-OBJECTS และ AS-SET และหากครั้งแรกบ่งบอกถึงการอนุญาตสำหรับส่วนหนึ่งของ IRRDB ดังนั้นสำหรับคลาสที่สองจะไม่มีการอนุญาตในฐานะคลาส นั่นคือใครๆ ก็สามารถเพิ่มใครก็ได้ในชุดของตนได้ และด้วยเหตุนี้จึงข้ามตัวกรองของผู้ให้บริการอัปสตรีมได้ ยิ่งไปกว่านั้น ไม่รับประกันความเป็นเอกลักษณ์ของการตั้งชื่อ AS-SET ระหว่างฐาน IRR ที่แตกต่างกัน ซึ่งอาจนำไปสู่ผลกระทบที่น่าประหลาดใจด้วยการสูญเสียการเชื่อมต่ออย่างกะทันหันสำหรับผู้ให้บริการโทรคมนาคม ซึ่งในส่วนของเขาไม่ได้เปลี่ยนแปลงอะไรเลย
ความท้าทายเพิ่มเติมคือรูปแบบการใช้งานของ AS-SET มีสองจุดที่นี่:
- เมื่อผู้ปฏิบัติงานได้รับไคลเอนต์ใหม่ มันจะเพิ่มเข้าไปใน AS-SET แต่แทบไม่เคยลบมันออกไปเลย
- ตัวกรองนั้นได้รับการกำหนดค่าเฉพาะที่อินเทอร์เฟซกับไคลเอนต์เท่านั้น
ด้วยเหตุนี้ รูปแบบใหม่ของตัวกรอง BGP จึงประกอบด้วยตัวกรองที่ค่อยๆ ลดระดับลงที่อินเทอร์เฟซกับไคลเอ็นต์ และความเชื่อถือเบื้องต้นในสิ่งที่มาจากพันธมิตรที่เทียบเคียงกันและผู้ให้บริการขนส่ง IP
การแทนที่ตัวกรองคำนำหน้าตาม AS-SET คืออะไร สิ่งที่น่าสนใจที่สุดคือในระยะสั้นไม่มีอะไรเลย แต่กลไกเพิ่มเติมกำลังเกิดขึ้นซึ่งช่วยเสริมการทำงานของตัวกรองที่ใช้ IRRDB และประการแรกคือ RPKI
อาร์พีเค
ในลักษณะที่เรียบง่าย สถาปัตยกรรม RPKI ถือได้ว่าเป็นฐานข้อมูลแบบกระจายที่สามารถตรวจสอบบันทึกด้วยการเข้ารหัสได้ ในกรณีของ ROA (การอนุญาตวัตถุเส้นทาง) ผู้ลงนามคือเจ้าของพื้นที่ที่อยู่ และบันทึกนั้นเป็นสามเท่า (คำนำหน้า, asn, max_length) โดยพื้นฐานแล้ว รายการนี้ตั้งสมมติฐานดังต่อไปนี้: เจ้าของพื้นที่ที่อยู่ $prefix ได้อนุญาตให้หมายเลข AS $asn โฆษณาคำนำหน้าที่มีความยาวไม่เกิน $max_length และเราเตอร์ที่ใช้แคช RPKI สามารถตรวจสอบคู่ความสอดคล้องได้ คำนำหน้า - ผู้พูดคนแรกระหว่างทาง.
รูปที่ 3 สถาปัตยกรรม RPKI
ออบเจ็กต์ ROA ได้รับการกำหนดมาตรฐานมาเป็นเวลานาน แต่จนกระทั่งเมื่อไม่นานมานี้ จริงๆ แล้วออบเจ็กต์เหล่านี้ยังคงอยู่บนกระดาษในวารสาร IETF เท่านั้น ในความคิดของฉัน เหตุผลนี้ฟังดูน่ากลัว - การตลาดที่ไม่ดี หลังจากการกำหนดมาตรฐานเสร็จสิ้น สิ่งจูงใจก็คือให้ ROA ป้องกันการไฮแจ็ก BGP ซึ่งไม่เป็นความจริง ผู้โจมตีสามารถเลี่ยงตัวกรองที่ใช้ ROA ได้อย่างง่ายดายโดยการใส่หมายเลข AC ที่ถูกต้องที่จุดเริ่มต้นของเส้นทาง และทันทีที่การตระหนักรู้นี้เกิดขึ้น ขั้นตอนต่อไปคือการละทิ้งการใช้ ROA และจริงๆ แล้วทำไมเราถึงต้องการเทคโนโลยีถ้ามันใช้งานไม่ได้?
เหตุใดจึงถึงเวลาเปลี่ยนใจ? เพราะนี่ไม่ใช่ความจริงทั้งหมด ROA ไม่ได้ป้องกันกิจกรรมของแฮ็กเกอร์ใน BGP แต่ ป้องกันการจี้รถโดยไม่ได้ตั้งใจเช่นจากการรั่วไหลแบบคงที่ใน BGP ซึ่งกำลังเกิดขึ้นบ่อยมากขึ้น นอกจากนี้ ไม่เหมือนกับตัวกรองที่ใช้ IRR ตรงที่ ROV สามารถใช้ได้ไม่เพียงแต่กับอินเทอร์เฟซกับไคลเอนต์เท่านั้น แต่ยังสามารถใช้กับอินเทอร์เฟซกับเพื่อนและผู้ให้บริการต้นน้ำได้ด้วย นั่นคือ ควบคู่ไปกับการเปิดตัว RPKI ความไว้วางใจแบบนิรนัยก็ค่อยๆ หายไปจาก BGP
ขณะนี้ การตรวจสอบเส้นทางตาม ROA กำลังค่อยๆ ถูกนำมาใช้โดยผู้เล่นหลัก: European IX ที่ใหญ่ที่สุดได้ละทิ้งเส้นทางที่ไม่ถูกต้องแล้ว ในบรรดาผู้ให้บริการระดับ Tier-1 ถือว่าคุ้มค่าที่จะเน้นย้ำ AT&T ซึ่งได้เปิดใช้งานตัวกรองที่อินเทอร์เฟซกับพันธมิตรที่มีการเชื่อมต่อแบบเพียร์ ผู้ให้บริการเนื้อหารายใหญ่ที่สุดก็กำลังเข้าใกล้โครงการนี้เช่นกัน และผู้ประกอบการขนส่งขนาดกลางหลายสิบรายก็ได้ดำเนินการอย่างเงียบๆ โดยไม่บอกใครเกี่ยวกับเรื่องนี้ เหตุใดตัวดำเนินการเหล่านี้จึงใช้ RPKI คำตอบนั้นง่ายมาก: เพื่อปกป้องการรับส่งข้อมูลขาออกของคุณจากความผิดพลาดของผู้อื่น นั่นคือเหตุผลที่ยานเดกซ์เป็นหนึ่งในบริษัทแรกๆ ในสหพันธรัฐรัสเซียที่รวม ROV ไว้ที่ขอบของเครือข่าย
จะเกิดอะไรขึ้นต่อไป?
ขณะนี้เราได้เปิดใช้งานการตรวจสอบข้อมูลเส้นทางที่อินเทอร์เฟซที่มีจุดแลกเปลี่ยนการรับส่งข้อมูลและการเพียร์ส่วนตัว ในอนาคตอันใกล้นี้ จะมีการเปิดใช้งานการยืนยันกับผู้ให้บริการการรับส่งข้อมูลต้นทางด้วย
สิ่งนี้สร้างความแตกต่างให้กับคุณอย่างไร? หากคุณต้องการเพิ่มความปลอดภัยในการกำหนดเส้นทางการรับส่งข้อมูลระหว่างเครือข่ายของคุณกับ Yandex เราขอแนะนำ:
- ลงนามในพื้นที่ที่อยู่ของคุณ
ในพอร์ทัล RIPE - ง่าย ๆ ใช้เวลาโดยเฉลี่ย 5-10 นาที วิธีนี้จะช่วยปกป้องการเชื่อมต่อของเราในกรณีที่มีคนขโมยพื้นที่ที่อยู่ของคุณโดยไม่รู้ตัว (และสิ่งนี้จะเกิดขึ้นไม่ช้าก็เร็วอย่างแน่นอน) - ติดตั้งหนึ่งในแคช RPKI โอเพ่นซอร์ส (
เครื่องมือตรวจสอบสุกงอม ,ผู้ประจำการ ) และเปิดใช้งานการตรวจสอบเส้นทางที่ชายแดนเครือข่าย - การดำเนินการนี้อาจใช้เวลานานขึ้น แต่จะไม่ทำให้เกิดปัญหาทางเทคนิคใดๆ อีกครั้ง
ยานเดกซ์ยังสนับสนุนการพัฒนาระบบกรองตามวัตถุ RPKI ใหม่ -
ฉันจะพูดรายละเอียดเกี่ยวกับ ASPA ในอีกหนึ่งเดือนที่การประชุม Next Hop เพื่อนร่วมงานจาก Netflix, Facebook, Dropbox, Juniper, Mellanox และ Yandex ก็จะพูดคุยที่นั่นด้วย หากคุณสนใจ Network Stack และการพัฒนาในอนาคต มาได้เลย
ที่มา: will.com