ยานเดกซ์ใช้ RPKI

สวัสดี ฉันชื่ออเล็กซานเดอร์ อาซิมอฟ ที่ 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 จะเพิ่มขึ้นเช่นกัน แต่ความผิดปกติส่วนใหญ่ยังคงเกิดจากข้อบกพร่อง ตัวอย่างปีนี้ก็คือ ข้อผิดพลาดของตัวดำเนินการขนาดเล็ก ในเบลารุสซึ่งทำให้ผู้ใช้ MegaFon ไม่สามารถเข้าถึงอินเทอร์เน็ตส่วนสำคัญได้เป็นเวลาครึ่งชั่วโมง ตัวอย่างอื่น - เครื่องมือเพิ่มประสิทธิภาพ BGP ที่บ้าคลั่ง ทำลายเครือข่าย CDN ที่ใหญ่ที่สุดในโลกแห่งหนึ่ง

ข้าว. 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 และ ROA ไม่เพียงแต่สามารถแทนที่ AS-SET ที่ “รั่ว” เท่านั้น แต่ยังปิดปัญหาการโจมตี MiTM โดยใช้ BGP อีกด้วย

ฉันจะพูดรายละเอียดเกี่ยวกับ ASPA ในอีกหนึ่งเดือนที่การประชุม Next Hop เพื่อนร่วมงานจาก Netflix, Facebook, Dropbox, Juniper, Mellanox และ Yandex ก็จะพูดคุยที่นั่นด้วย หากคุณสนใจ Network Stack และการพัฒนาในอนาคต มาได้เลย เปิดลงทะเบียนแล้ว.

ที่มา: will.com