اختطاف BGP لا يزال يعطل الإنترنت — و RPKI هو الحل الذي لم تنشره معظم مزودات الخدمة بعد

في أبريل 2010، لحوالي 18 دقيقة، أعيد توجيه نحو 15% من حركة الإنترنت العالمية عبر شبكة China Telecom. شمل ذلك حركة من وزارة الدفاع الأميركية، ووكالات حكومية، وشركات كبرى. لم تخترق China Telecom شيئًا؛ فقط أعلنت أن لديها مسارات أفضل لتلك الوجهات، وصدّقها باقي الإنترنت — لأن Border Gateway Protocol، النظام الذي يوجّه كل حركة الإنترنت، لا يملك وسيلة للتحقق من شرعية إعلان التوجيه.

كان ذلك قبل 16 سنة. المشكلة الأساسية لم تُحل بعد.

البروتوكول الذي يعتمد على الثقة

يعود BGP لعام 1989. صُمم عندما كان الإنترنت شبكة صغيرة من جامعات ووكالات حكومية تعرف بعضها البعض. يعمل البروتوكول على مبدأ أنه إذا أعلنت شبكة (تُسمى نظام ذاتي أو AS) أنها تستطيع الوصول إلى كتلة معينة من عناوين IP، فإن الإعلان صحيح. لا يوجد تحقق تشفيري، ولا توثيق، ولا طريقة لإثبات أن لديك الحق في إعلان مسار. فقط تعلنه، ويوجّه الإنترنت حركة المرور إليك.

هذا مهم لأن BGP هو الوسيلة التي تجد بها كل حزمة على الإنترنت وجهتها. عندما تحمّل صفحة ويب، يستشير جهاز التوجيه التابع لمزود الخدمة جداول BGP ليعرف المسار إلى الخادم. إذا قام أحد بحقن مسار مزيف، تذهب حركة المرور إلى مكان آخر — إلى شبكة يمكنها قراءتها، تعديلها، أو ببساطة إسقاطها.

عمليات اختطاف BGP تحدث بانتظام. في 2008، أوقفت Pakistan Telecom يوتيوب لمدة ساعتين بإعلانها بطريق الخطأ أن لديها مسارًا أفضل. في 2020، اعترضت Rostelecom في روسيا حركة مرور من Amazon و Google و Akamai و 200 مزود آخر. في 2021، اختطف مزود خدمة بيلاروسي نطاق Cloudflare. معظم الحوادث ناتجة عن أخطاء تكوين، لكن جهات حكومية أظهرت قدرة على فعلها عمدًا.

ما يفترض أن يصلحه RPKI

Resource Public Key Infrastructure — RPKI — هو إطار تشفيري يسمح لحاملي عناوين IP بتوقيع سجلات تُسمى Route Origin Authorizations (ROAs). يقول ROA بلغة تشفيرية: "AS 64500 مخوّل بالإعلان عن البادئة 198.51.100.0/24". إذا أعلن شخص آخر نفس البادئة، يمكن للشبكات التي فعّلت تحقق RPKI أن ترى أن الإعلان لا يتطابق مع أي ROA صالح وترفضه.

جميع سجلات الإنترنت الإقليمية الخمسة — ARIN (أمريكا الشمالية)، RIPE NCC (أوروبا/الشرق الأوسط)، APNIC (آسيا-المحيط الهادئ)، LACNIC (أمريكا اللاتينية)، AFRINIC (أفريقيا) — تقدم خدمات RPKI. إنشاء ROAs مجاني. البنية التحتية التشفيرية جاهزة بالفعل.

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

أين يقف التبني فعليًا

مع بداية 2026، حوالي 50–55% من بادئات IPv4 الموجهة عالميًا لديها ROAs صالحة — أي أن حامليها وقعوا عليها باستخدام RPKI. هذا ارتفاع من حوالي 20% في 2020، وهو تقدم حقيقي. لكن إنشاء ROAs هو نصف المعادلة فقط.

تحقق المصدر — التصفية التي ترفض المسارات السيئة فعليًا — منشور على عدد أقل بكثير من الشبكات. تقدر NIST أن حوالي 30–35% من شبكات Tier-1 و Tier-2 تفرض RPKI-ROV حاليًا. كبار الناقلين في الولايات المتحدة (AT&T, Verizon, Lumen/CenturyLink) كانوا بطيئين. الناقلون الأوروبيون، خاصة المتصلون بـ RIPE NCC، لديهم معدلات تبني أعلى. بعض شبكات توصيل المحتوى الكبرى مثل Cloudflare و Fastly يفرضونه. معظم مزودي الخدمة الإقليميين وشبكات المؤسسات لا يفعلون ذلك.

ما يعنيه هذا: حتى لو قال ROA الخاص بك إنك تملك بادئة، جزء كبير من البنية التحتية للإنترنت سيقبل إعلانًا مختطفًا لتلك البادئة من شخص آخر. الحماية جزئية، وليست عالمية.

لماذا يستغرق الأمر وقتًا طويلاً

أسباب التبني البطيء معظمها تشغيلية واقتصادية، وليست تقنية. تكوين RPKI-ROV على أجهزة توجيه الناقل يتطلب تعديل سياسة التوجيه عبر كل نقطة اتصال وكل جهاز توجيه حدودي. ROA تم تكوينه بشكل خاطئ يمكن أن يجعل شبكة شرعية غير قابلة للوصول — يصبح العلاج هو سبب الانقطاع. مزودو الخدمة الكبار الذين يديرون مئات الآلاف من المسارات قلقون بشكل مفهوم من تفعيل تصفية قد تسقط حركة مرور صالحة عن غير قصد.

هناك أيضًا فجوة في الحوافز. تكاليف اختطاف BGP تقع على الشبكة الضحية. عمل نشر RPKI-ROV يقع على كل شبكة أخرى. بالنسبة لأي مزود خدمة فردي، كانت المعادلة تاريخيًا: الجهد عليّ، والفائدة منتشرة. هذه مشكلة تنسيق كلاسيكية.

الجهات التنظيمية بدأت تضغط. وكالة الأمن السيبراني وأمن البنية التحتية الأميركية (CISA) وهيئة الاتصالات الفيدرالية (FCC) نشرتا إرشادات تشجع نشر RPKI بين الناقلين الأميركيين، ومبادئ CISA "الآمنة بالتصميم" تذكر أمان BGP صراحة. توجيه NIS2 للاتحاد الأوروبي، الذي دخل حيز التنفيذ في 2024، يطلب من مشغلي الخدمات الأساسية تنفيذ إجراءات أمان BGP — رغم أن التنفيذ لا يزال متفاوتًا بين الدول الأعضاء.

ما وراء RPKI: ما هو مطلوب لتأمين التوجيه فعليًا

RPKI-ROV يتحقق فقط من مصدر المسار — أول AS يعلنه. لا يتحقق من المسار الكامل الذي يسلكه إعلان التوجيه. حل أكثر اكتمالاً يُسمى BGPsec يضيف تواقيع تشفيرية لكل خطوة من المسار، لكنه يتطلب دعم كل AS على طول المسار وله آثار كبيرة على أداء أجهزة التوجيه. النشر صفر تقريبًا.

وسط حل يُسمى ASPA (Autonomous System Provider Authorization) تم توحيده من قبل IETF في 2024. يسمح ASPA للشبكات بتوقيع سجلات تحدد أي AS هي مزوداتها العليا. هذا يجعل من الممكن كشف ورفض فئة من تسريبات المسار التي يفوتها RPKI-ROV — خاصة الحالات التي تعلن فيها شبكة عن مسارات عملائها لمزوداتها الأخرى. ASPA يحظى باهتمام لكنه في مراحل نشر مبكرة جدًا.

الحقيقة الأساسية هي أن أمان توجيه الإنترنت هو مشكلة عمل جماعي. تتطلب من أغلبية الشبكات المهمة تغيير ممارساتها التشغيلية في وقت واحد لتكون فعالة بالكامل. RPKI أحرز تقدمًا حقيقيًا في السنوات الخمس الماضية — المسار إيجابي — لكن بالمعدل الحالي، لا يزال جهة حكومية مصممة أو جهاز توجيه Tier-1 خاطئ يمكنه إعادة توجيه حركة الإنترنت العالمية. الحل التقني موجود. فجوة النشر هي المشكلة.