نشرت Cloudflare تحليلاً لمدى انتشار معيار RFC 9234 المستخدم للحد من تسربات التوجيه في بروتوكول BGP، مستندة إلى بيانات جلسات التبادل مع شبكاتها وتجارب أعلنت خلالها مسارات اختبارية عبر الإنترنت. ووجدت الشركة أن 67 شبكة كانت تضيف سمة Only to Customer أو OTC إلى المسارات التي ترسلها مباشرة، لكنها اكتشفت أيضاً أن عدداً من الشبكات يزيل هذه السمة أثناء تمرير المسارات، ما يضعف قدرة الشبكات المتوافقة على اكتشاف التسربات ورفضها.
تحدث تسربات BGP عندما تعلن شبكة مساراً تعلمته من مزود أو نظير إلى مزود أو نظير آخر، خلافاً للعلاقات التجارية والمنطق الهرمي المفترض لمسارات الإنترنت. وقد يؤدي ذلك إلى دفع حركة البيانات عبر شبكة لم تكن مهيأة لاستيعابها أو غير مخولة أصلاً بتمريرها، مع احتمال ارتفاع زمن الوصول أو فقدان الحزم أو وقوع أعطال أوسع.
نقل قواعد منع التسرب إلى البروتوكول
تفرض آليات الحماية التقليدية على كل مشغل إعداد سياسات يدوية، مثل مرشحات البادئات والسياسات المستخرجة من سجلات IRR، بما يتطلب تعريف علاقة كل جلسة BGP بدقة. ويقترح RFC 9234 نقل جزء من هذا العبء إلى البروتوكول نفسه من خلال مكوّنين: BGP Roles وسمة OTC.
تحدد أدوار BGP طبيعة العلاقة بين الجارين في جلسة eBGP، مثل Provider وCustomer وPeer، إضافة إلى RS وRS-Client المرتبطين بخوادم المسارات في نقاط تبادل الإنترنت. وعند إرسال الطرفين لدورين غير متوافقين، تُرفض الجلسة بإشعار Role Mismatch بدلاً من استمرارها إلى أن يظهر الخطأ لاحقاً كتسرب فعلي. أما في حالات التبني الجزئي، فيمكن للجلسة أن تعمل إذا أرسل طرف واحد الدور، ما لم يُفعّل المشغل الوضع الصارم الذي يرفض الجلسات التي لا يعلن فيها الطرف المقابل أي دور.
تسجل سمة OTC رقم النظام المستقل الذي أضافها أول مرة عندما يتوقف المسار عن التحرك صعوداً عبر الهرمية ويبدأ الانتقال إلى العملاء. وبمجرد وجودها، لا ينبغي للمسار أن ينتقل إلى مزود أو نظير أو خادم مسارات، كما يمكن للموجه المتوافق رفض مسار يحمل OTC إذا وصل من علاقة لا تسمح بذلك. وبذلك تصبح الوقاية تلقائية بعد ضبط الأدوار، بدلاً من الاعتماد حصراً على سياسة يكتبها المشغل لكل جلسة.
ماذا قاست Cloudflare فعلياً؟
استخدمت Cloudflare بيانات BMP من موجهاتها، وراقبت قيمة OTC الواردة من الجيران المباشرين خلال ثلاثة أشهر. واعتبرت الشبكة مرشحة للامتثال عندما تساوت قيمة السمة مع رقم نظام الجار، وهي طريقة تقلل الالتباس الذي يظهر عند تحليل المسارات التي مرت عبر عدة شبكات. أظهرت هذه القياسات 67 نظاماً مستقلاً يضيف OTC، مع ملاحظة أن خوادم المسارات قد تتبنى الميزات الجديدة بسرعة أكبر، وأن بعض الشبكات التي يديرها أفراد ظهرت بنسبة ملحوظة ضمن النتائج.
أما تحليل بيانات RIB العامة من RouteViews وRIPE RIS فأعطى نتائج أكثر تحفظاً. فبعد محاولة التمييز بين الشبكات التي تضيف OTC عند الإرسال وتلك التي تملأ قيمة مفقودة عند الاستقبال، حددت Cloudflare 18 شبكة يُحتمل أن تضيف السمة و20 شبكة يُحتمل أن تملأها، ومع دمج نتائج الجيران المباشرين توصلت إلى 36 شبكة يُحتمل توافقها مع RFC 9234. وتؤكد الشركة أن المنهجية قد تفوّت شبكات ذات عدد محدود من المسارات أو الجيران.
الشبكات التي أزالت OTC
اختبرت Cloudflare انتشار OTC عبر إعلان بادئة IPv4 وأخرى IPv6 تحملان القيمة 13335 من مواقع التبادل التابعة لها، ثم حللت رسائل BGP أثناء الإعلان والسحب باستخدام بيانات RIPE RIS وRouteViews وبيانات BMP المحلية. في المرحلة الأولى، حددت ستة أنظمة مستقلة تزيل السمة، من بينها شبكتا المستوى الأول GTT، AS3257 وArelion، AS1299. وأدت مواصلة تحليل المسارات الأطول إلى تحديد تسع شبكات إضافية تزيل OTC.
كانت السمة غائبة عن 33.1% من مسارات AS_PATH الخاصة بـIPv4 و17% من مسارات IPv6 في التجربة. وظهرت GTT أو Arelion أو كلتاهما في 96.6% من مسارات IPv4 التي فقدت OTC و92.9% من مسارات IPv6، مع استحواذ Arelion على معظم الحالات. وعند فحص المسارات التي كان قفزتها التالية إحدى الشبكتين، وجدت Cloudflare أن GTT كانت تزيل السمة باستمرار، بينما أزالتها Arelion في 71.4% من مسارات IPv4 و40.7% من مسارات IPv6 في العينة المعنية.
قالت Cloudflare إن الشبكتين أكدتا أن إزالة OTC كانت جزءاً من ممارسات دفاعية نشأت بعد حوادث مرتبطة بمعالجة أخطاء BGP. ووفق النتائج المنشورة، ظلت إعدادات GTT تزيل السمة، بينما بدأت Arelion في الحفاظ عليها بعد التواصل مع Cloudflare، وهو ما تحقق منه تحليل لاحق لمسارات الاختبار.
ما الذي يتغير عملياً لمشغلي الشبكات؟
توضح النتائج أن تبني RFC 9234 لا يعتمد فقط على دعم الموجهات للميزة، بل أيضاً على استمرار الشبكات الوسيطة في تمرير السمة العابرة اختيارياً. إزالة OTC في شبكة ذات موقع مركزي قد تمنع شبكة متوافقة تقع بعدها بعدة قفزات من اكتشاف تسرب كان يمكن منعه.
تذكر Cloudflare أن Junos OS وJunos OS Evolved يدعمان RFC 9234، وأن دعم Cisco IOS XR كان مقرراً في الإصدار 26.4.1، بينما أدرجت تطبيقات أخرى في جدولها من دون تحديد حالة دعم مكتملة، ومنها Arista EOS وNokia SR OS وHuawei وExtreme SLX-OS وRouterOS وBIRD وOpenBGPD وFRR وArcOS وGoBGP وExaBGP. وتوصي الشركة المشغلين الذين تتوفر لديهم الميزة بضبط أدوار BGP تدريجياً خلال نوافذ الصيانة، لأن تطبيقها يتطلب إعادة ضبط جلسات BGP. كما بدأت Cloudflare نشر الإعدادات تدريجياً عبر أسطولها العالمي، وتخطط لإتاحة بيانات التبني في قسم التوجيه ضمن Cloudflare Radar.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.