BGP يبلغ 35 عامًا ولا يزال يحمل الإنترنت معًا — وهذا هو سبب المشكلة

في عام 1989، رسم مهندسان في اجتماع بروتوكول توجيه على مناديل. البروتوكول — بروتوكول البوابة الحدودية (BGP) — كان حلاً سريعًا لمشكلة متزايدة حول كيفية إخبار الشبكات المستقلة بعضها البعض بمكان إرسال حركة المرور. كان عمليًا ووظيفيًا وخاليًا تقريبًا من الأمان. أصبح الآن أساس الإنترنت العالمي لمدة 35 عامًا.

BGP ليس برنامجًا يتفاعل معه معظم الناس. إنه البروتوكول الذي يعمل بين أجهزة التوجيه على حواف كل شبكة رئيسية — كل مزود خدمة إنترنت، كل مزود سحابي، كل شركة لديها مساحة عنوان IP خاصة بها. عند تحميل صفحة ويب، يضمن BGP أن طلبك يمر عبر التسلسل الصحيح للشبكات للوصول إلى الخادم المناسب. بدونه، الإنترنت عبارة عن مجموعة من الجزر المنعزلة. معه، هو مساحة عنوان واحدة قابلة للوصول تضم حوالي 4.3 مليار عنوان IPv4.

كيف يعمل BGP بالفعل

الإنترنت منظم إلى أنظمة مستقلة (ASes) — شبكات مستقلة تديرها منظمة واحدة. مزود خدمة الإنترنت الخاص بك هو AS. Amazon Web Services هو AS. جامعة ذات بنية تحتية شبكية خاصة بها هي AS. كل AS لديه رقم (ASN، يتم تعيينه بواسطة سجلات الإنترنت الإقليمية) ومجموعة من بادئات IP — نطاقات العناوين التي يتحكم فيها.

BGP هو البروتوكول الذي تستخدمه ASes للإعلان عن بادئاتها لجيرانها وتعلم مسارات بعضهم البعض. عندما تريد AS-A الوصول إلى بادئة مملوكة لـ AS-Z، تعتمد على سلسلة من إعلانات BGP: يعرف جهاز التوجيه الخاص بـ AS-A أن AS-B لديه مسار إلى AS-Z، وAS-B يعرف أن AS-C لديه، وهكذا. البروتوكول مبني على الثقة: عندما تعلن AS عن "لدي مسار إلى عناوين IP هذه"، تقبل ASes المجاورة هذا الإعلان وتنشره أكثر. لا يوجد تحقق تشفيري. لا توجد سلطة مركزية. إذا أعلنت AS عن بادئة لا تملكها، ينتشر الإعلان عالميًا.

هذا هو اختطاف BGP. ويحدث بانتظام.

الإخفاقات الشهيرة

في عام 2010، أعلنت China Telecom حوالي 15% من مسارات الإنترنت العالمية عبر شبكتها لمدة 18 دقيقة تقريبًا. تم توجيه حركة المرور المتجهة إلى المواقع العسكرية الأمريكية وDell وIBM ومئات المنظمات الأخرى عبر البنية التحتية الصينية لفترة وجيزة. كان الحادث على الأرجح عرضيًا — سوء تكوين بدلاً من اعتراض متعمد — لكنه أظهر حجم التعرض.

في عام 2019، أعلن مزود خدمة إنترنت صغير في ولاية بنسلفانيا عن 20,000 مسار لا يملكها، مما تسبب في توجيه حركة المرور لـ Amazon وCloudflare وFacebook وغيرها عبر شبكة ذات سعة غير كافية. النتيجة: تباطؤ وانقطاع واسع النطاق أثر على ملايين المستخدمين لعدة ساعات.

في عام 2021، تسبب خطأ تكوين BGP لـ Facebook — مع فشل DNS — في خروج جميع خدمات Facebook (Facebook وInstagram وWhatsApp) تمامًا عن العمل لمدة ست ساعات. يعني سحب بادئات BGP الخاصة بـ Facebook أنه حتى لو كان DNS يعمل، لم يكن بإمكان حركة المرور الوصول إلى بنيتها التحتية. تطلبت استعادة الخدمة وصول المهندسين فعليًا إلى أجهزة مركز البيانات لأن أدوات الإدارة عن بُعد العادية لم تستطع الاتصال أيضًا.

النمط عبر هذه الحوادث متسق: نموذج الثقة في BGP يعني أن الأخطاء والإعلانات الخبيثة تنتشر بسرعة الإنترنت، وتستغرق التصحيحات وقتًا للتصفية عبر مئات الأنظمة المستقلة.

RPKI: الإصلاح الذي استغرق عقودًا لنشره

البنية التحتية للمفتاح العام للموارد (RPKI) هي الإطار التشفيري المصمم لحل مشكلة الثقة في BGP. يسمح RPKI لحاملي عناوين IP بإنشاء شهادات موقعة رقميًا — تفويضات أصل المسار (ROA) — التي تؤكد تشفيريًا أي ASes مخول بإصدار أي بادئات. يمكن لجهاز التوجيه الذي يقوم بالتحقق من RPKI رفض الإعلانات التي ليس لديها ROA صالح، مما يغلق الباب أمام معظم سيناريوهات الاختطاف.

كان RPKI متاحًا تقنيًا منذ أوائل عام 2010. كان التبني بطيئًا لأسباب هيكلية: كل شبكة تحتاج إلى القيام بأمرين — توقيع بادئاتها الخاصة (التحقق من الأصل)، والتحقق من إعلانات النظراء (التحقق من أصل المسار). الخطوة الثانية توفر حماية تتناسب مع عدد الشبكات التي تقوم بالأولى. إنها مشكلة تنسيق على نطاق الإنترنت.

تسارع التقدم. اعتبارًا من عام 2026، حوالي 40% من جدول التوجيه العالمي مغطى بـ ROAs صالحة. الشبكات الكبيرة — Cloudflare (التي كانت المدافعة الأكثر صوتًا عن RPKI)، وAT&T، وComcast، وDeutsche Telekom، ومعظم موفري الخدمات السحابية الكبرى — تقوم الآن بفرض التحقق من RPKI على وصلات النظراء الخاصة بها. MANRS (المعايير المتفق عليها بشكل متبادل لأمن التوجيه) تتبع الامتثال، وقد زادت نسبة الشبكات الممتثلة لـ MANRS بشكل كبير منذ عام 2022.

النسبة المتبقية 60% من جدول التوجيه هي ذيل طويل عنيد. غالبًا ما تفتقر مزودو خدمات الإنترنت الصغار والشبكات الإقليمية إلى الموارد الهندسية لتنفيذ RPKI، أو لديهم معدات قديمة لا تدعمه. البعض لديه أسباب تجارية لتجنب تصفية المسار (يمكن أن تؤثر التصفية على إيرادات النظراء). تتركز المشكلة في المناطق النامية حيث يكون تحديث مزودي خدمات الإنترنت أبطأ.

ما وراء RPKI: BGPsec والتحقق من المسار

يحل RPKI التحقق من الأصل — تأكيد أن AS المعلنة لبادئة مخولة للقيام بذلك. لا يحل التحقق من المسار — تأكيد أن مسار AS في إعلان BGP يعكس بدقة المسار الفعلي الذي ستتخذه حركة المرور. يمكن لهجوم أكثر تطوراً (أو سوء تكوين) إدخال معلومات مسار AS خاطئة حتى مع وجود RPKI.

BGPsec هو الحل المقترح: توقيع تشفيري كامل لمسار AS بأكمله لكل إعلان مسار. سيوفر ضمانات أمنية أقوى بكثير. سيتطلب أيضًا أن تدعم كل موجه في المسار وتقوم بالتحقق من BGPsec، ويخلق عبء حسابي أكبر بكثير، ويتطلب ترقية منسقة عالميًا للبنية التحتية للتوجيه. الإجماع بين مهندسي الشبكات هو أن BGPsec مكلف جدًا لنشره على نطاق الإنترنت في المدى القريب.

الخريطة العملية هي: إنهاء نشر RPKI للتحقق من الأصل (السنوات الخمس القادمة)، ثم تقييم أمان المسار تدريجيًا باستخدام مزيج من سياسات تصفية المسار وRPKI والبنية التحتية للمراقبة. تنشر منظمات مثل RIPE NCC وARIN لوحات مراقبة BGP في الوقت الفعلي تسمح للمشغلين باكتشاف عمليات الاختطاف في غضون دقائق بدلاً من الساعات التي كانت تستغرقها سابقًا.

ماذا يعني هذا للموثوقية

هشاشة BGP هيكلية وليست عرضية. صُمم البروتوكول لإنترنت مختلف — إنترنت به عدد صغير من المشاركين الموثوق بهم يربطون الجامعات والمؤسسات البحثية. قرار تمديده إلى بنية تحتية تجارية عالمية تضم مئات الآلاف من المشاركين، كثير منهم لديهم دوافع عدائية، لم يكن خيار تصميم متعمد أبدًا. حدث ذلك افتراضيًا، لأنه لم يكن هناك بديل جاهز عندما احتاج الإنترنت إلى التوسع.

عاش الإنترنت مع هذه المقايضة لمدة 35 عامًا. يمثل النشر البطيء لـ RPKI أول جهد منهجي لإضافة خصائص أمان إلى بروتوكول لم يُصمم أبدًا لامتلاكها. إنه يعمل — حوادث اختطاف BGP التي تتصدر العناوين اليوم أصبحت نادرة وأقصر عمرًا مما كانت عليه في 2015 أو 2019، لأن المزيد من الشبكات ترفض الآن إعلانات المسار غير الصالحة تلقائيًا. لكن "أقل تواترًا" و"نادر" ليسا مثل "مُحل"، وبالنسبة لبنية تحتية تحمل التجارة العالمية والسجلات الصحية والاتصالات، لا تزال الفجوة بين هاتين الحالتين مهمة.