RPKI and BGP Route Origin Validation

1. لماذا لا يوجد لدى BGP التحقق من صحة الأصل الأصلي

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

الحوادث البارزة التي أدت إلى تسريع اعتماد RPKI:

• 2008 – شركة الاتصالات الباكستانية:أعلنت شركة PTCL عن طريق الخطأ عن بادئة أكثر تحديدًا لمساحة عنوان YouTube (208.65.153.0/24)، مما أدى إلى حجب YouTube عالميًا لمدة ساعتين تقريبًا قبل أن يسحب مقدمو الخدمات الأولية المسار.
• 2010 – تشاينا تيليكوم:أنشأت شركة China Telecom حوالي 50000 بادئة تابعة للشبكات العسكرية والحكومية والتجارية الأمريكية لمدة 18 دقيقة تقريبًا. لم يتم تأكيد ما إذا كان عرضيًا أو متعمدًا.
• 2018 - اختطاف نظام أسماء النطاقات Amazon Route 53:استخدم أحد المهاجمين BGP لاختطاف 205.251.196.0/24 (Amazon DNS)، وإعادة توجيه حركة مرور محفظة العملة المشفرة لسرقة الأموال. استخدم الهجوم تحديث BGP من eNet (AS10297).
• 2019 - إعادة توجيه حركة المرور الأوروبية عبر شركة China Telecom:تمت إعادة توجيه حركة مرور الهاتف المحمول الأوروبية (بما في ذلك Vodafone وSwisscom السويسرية) عبر شركة China Telecom لمدة ساعتين تقريبًا بسبب تسرب مسار BGP.

2. التسلسل الهرمي لثقة RPKI

RPKI (آر إف سي 6480) ينشئ تسلسلًا هرميًا لشهادات X.509 يعكس كيفية تفويض مساحة عنوان IP:

1. IANAيحمل مرساة الثقة الجذرية. وتقوم بإصدار شهادات الموارد إلى مكاتب RIR الخمسة (ARIN، وRIPE NCC، وAPNIC، وLACNIC، وAFRINIC)، والتي تغطي كل منها مساحة العناوين الخاصة بها.
2. سجلات الإنترنت الإقليميةإصدار شهادات لأعضائها (مزودي خدمات الإنترنت والمؤسسات) لمساحة العناوين التي يحتفظ بها هؤلاء الأعضاء.
3. أعضاءإصدار شهادات الكيان النهائي (EE) والتوقيع عليهاتفويضات أصل الطريق(ROAs) - شهادات موقعة تسمح لـ ASN محدد بإنشاء بادئات محددة.

يقوم القائمون على التحقق بتنزيل هذا التسلسل الهرمي للكائن الموقع من خمسة مستودعات RIR (بالإضافة إلى أي مستودعات مفوضة)، والتحقق من صحة سلسلة الشهادات، وإنشاء جدول حمولة ROA (VRP) تم التحقق منه. تقوم أجهزة التوجيه بعد ذلك بالاستعلام عن ذاكرة التخزين المؤقت RPKI المحلية عبر ملفبروتوكول آر تي آر (آر إف سي 8210) للحصول على هذا الجدول وإجراء التحقق من صحة الأصل على تحديثات BGP الواردة.

3. تفويضات أصل الطريق (ROAs)

العائد على الأصول (آر إف سي 6482) هو كائن موقّع يحتوي على ثلاثة حقول:

• ASN: النظام الذاتي المخول بإنشاء البادئة.
• بادئة: تم اعتماد بادئة IP (IPv4 أو IPv6).
• أقصى طول: الحد الأقصى لطول البادئة الذي يحق لـ ASN الإعلان عنه. إذا لم يتم تحديدها، فسيتم اعتماد البادئة المحددة فقط. إذا تم التعيين، على سبيل المثال، على 24 للبادئة /20، فقد يعلن ASN أيضًا عن أي تحديد أكثر بين /20 و/24.

يمكن أن يأذن ROA واحد ببادئات متعددة لنفس ASN، لكن لا يمكن أن يأذن ROA واحد بعدة أرقام ASN لبادئة واحدة. للسماح لـ ASN ثانوي (على سبيل المثال، موفر النقل أو CDN) بإنشاء البادئة الخاصة بك، قم بإنشاء ROA منفصل لـ ASN هذا.

4. حالات التحقق

عندما يتلقى جهاز التوجيه تحديث BGP، فإنه يقوم بالتحقق من صحة الأصل (آر إف سي 6811) مقابل جدول VRP المحلي الخاص به:

البصيرة الرئيسية:غير صالحهو دليل أقوى على وجود مشكلة منغير موجود. يعني NotFound ببساطة أن مالك البادئة لم يقم بإنشاء ROA بعد. غير صالح يعني أن ROA موجود ويوضح أن ASN موجودلامعتمد - إشارة قوية إما إلى وجود خطأ في التكوين أو الاختطاف.

5. بروتوكول RTR

لا تقوم أجهزة التوجيه بالتحقق من صحة سلاسل شهادات X.509 بنفسها - وهذا قد يكون مكلفًا من الناحية الحسابية ويتطلب الاحتفاظ بذاكرة تخزين مؤقت كاملة لـ RPKI. بدلا من ذلك، مخصصمدقق RPKI(Routinator، OctoRPKI، Fort، rpki-client) يقوم بتنزيل مستودع RPKI الكامل والتحقق من صحته ويصدر فقط حمولات ROA التي تم التحقق منها (VRPs) إلى أجهزة التوجيه عبر بروتوكول RTR (آر إف سي 8210).

يستخدم RTR TCP (المنفذ 323 المخصص لـ IANA؛ أدوات التحقق مثل Routinator الافتراضية للمنفذ 3323 لتجنب طلب امتيازات الجذر) مع آلية مزامنة تزايدية: يرسل جهاز التحقق الأرقام التسلسلية، وتطلب أجهزة التوجيه دلتا فقط منذ آخر مزامنة لها. يؤدي هذا إلى إبقاء النطاق الترددي منخفضًا حتى بالنسبة لجداول VRP الكبيرة (حاليًا ما يقرب من 400000+ إدخالات IPv4 على مستوى العالم).

6. النشر والإحصائيات

اعتبارًا من أوائل عام 2026، وصل نشر RPKI إلى نطاق واسع:

• أكثر من 50% من بادئات IPv4 الموجهة عالميًا تحتوي على عائد وصول (ROA) واحد على الأقل (ارتفاعًا من 10% تقريبًا في عام 2019).
• يقوم الآن غالبية مزودي خدمات الإنترنت من المستوى 1 والمستوى 2 بإجراء التحقق من صحة أصل المسار وإسقاط المسارات غير الصالحة أو إلغاء أولوياتها.
• تتطلب MANRS (القواعد المتفق عليها بشكل متبادل لأمان التوجيه) إنشاء RPKI ROA كشرط أساسي للعضوية وتنشر لوحة معلومات مطابقة لكل AS.

إحصائيات حية:مراقب NIST RPKI, روف++, إحصائيات APNIC RPKI.

7. ما وراء ROV: ASPA وBGPsec

التحقق من صحة أصل طريق RPKI يتحقق فقط من أنأصل ASNمخول للإعلان عن البادئة. إنه لا يتحقق من صحة AS_PATH — لا يزال بإمكان المهاجم إنشاء AS_PATH زائفًا بأصل شرعي AS في النهاية. يتناول معياران من معايير IETF هذا الأمر:

• BGPsec (آر إف سي 8205): يقوم كل AS في المسار بتوقيع التحديث بشكل مشفر، مما يؤدي إلى إنشاء سلسلة رعاية غير قابلة للكسر. يتطلب من جميع ASES العبور دعم BGPsec - وهو عائق نشر كبير. نادرًا ما يتم نشرها اعتبارًا من عام 2026.
• ASPA(ترخيص موفر النظام المستقل،مسودة-ietf-sidrops-aspa-profile): يقوم AS بتوقيع كائن يدرج موفريه المعتمدين. يمكن لوحدات التحقق اكتشاف المسارات الخالية من الوادي غير الصالحة (على سبيل المثال، إعلان العميل عن المسارات كما لو كان مزودًا). أسهل في النشر من BGPsec وتكتسب قوة جذب اعتبارًا من 2025-2026.

مراجع

• آر إف سي 6480— بنية أساسية لدعم توجيه الإنترنت الآمن (نظرة عامة على RPKI)
• آر إف سي 6482- ملف تعريف لتفويضات أصل الطريق (ROAs)
• آر إف سي 6811- التحقق من أصل بادئة BGP
• آر إف سي 8210- RPKI لبروتوكول جهاز التوجيه، الإصدار 1 (RTR)
• آر إف سي 8416- إدارة مبسطة لموارد أرقام الإنترنت المحلية باستخدام RPKI (SLURM - التجاوزات المحلية)
• آر إف سي 9286- البيانات الخاصة بالبنية التحتية للمفتاح العام للموارد (RPKI)
• آر إف سي 8205- مواصفات بروتوكول BGPsec
• مانرس- المعايير المتفق عليها بشكل متبادل لأمن التوجيه
• بوابة كلاودفلير RPKI- البحث المباشر عن ROA