كيف تعمل البنية التحتية للمفاتيح العامة لموارد الإنترنت

يتطلب التحقق أدلة تُصان باستمرار: يجب أن تظل الشهادات والتفويضات وأنظمة النشر متسقة مع تغيّر الشبكات.

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

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

1. تحديد من يملك صلاحية التفويض باستخدام العناوين

تُسمّى مجموعة عناوين IP بادئة. وتعرّف الشبكة التي تعلن عن تلك البادئة نفسها برقم نظام مستقل، أو ASN. وتستخدم البنية التحتية للمفاتيح العامة لموارد الإنترنت، RPKI، الشهادات لإثبات من يملك صلاحية إصدار تفويضات لنطاقات محددة من العناوين.

تشكّل هذه الشهادات سلسلة تنتهي عند جذر موثوق. ويتبع هذا التسلسل الهرمي توزيع موارد أرقام الإنترنت، على النحو الموضح في RFC 6480. وهو يقدّم أدلة بشأن الموارد داخل ذلك النظام؛ لكنه لا يمنح جهة إصدار الشهادات تفويضاً سياسياً على مستخدمي الإنترنت.

2. نشر تفويض موقّع

ينشر حائز العناوين تفويض منشأ المسار، أو ROA. ورسالته محددة: يجوز لرقم ASN هذا أن يكون منشأ الإعلان عن هذه البادئة. ويعني المنشأ الشبكة الواقعة في بداية المسار المُعلَن، لا كل شبكة تنقل حركة البيانات بعد ذلك.

يمكن لتفويض ROA أيضاً أن يحدد طولاً أقصى للبادئة، أي الحد الذي يجوز عنده تقسيم نطاق العناوين إلى نطاقات أصغر يُعلَن عنها. ومن دون هذا الإعداد الاختياري، لا يُسمح إلا بطول البادئة المحدد. وهذا يمنع «التفويض لهذا النطاق» من التحول ضمنياً إلى تفويض لكل تقسيم فرعي ممكن. وتعرّف الوثيقة RFC 9582 هذا السجل الموقّع.

3. تحويل السجلات المنشورة إلى بيانات متحقق منها

تُتاح السجلات الموقّعة في مستودعات النشر. وتجمعها برمجيات التحقق وتفحص سلسلة الشهادات والتوقيعات ومعلومات انتهاء الصلاحية والإلغاء، إلى جانب قوائم الجرد التي تصف العناصر المنشورة. فلا يكفي أن يكون الملف قابلاً للقراءة؛ بل يجب أن تجتاز الأدلة التي تسنده عملية التحقق أيضاً.

ينتج برنامج التحقق بيانات تفويض قابلة للاستخدام، تُسمّى غالباً حمولات ROA المتحقق منها، أو VRPs. وتتضمن البادئة ورقم ASN المسموح له بأن يكون المنشأ والطول الأقصى. وتتلقى الموجّهات النتائج من ذاكرة تخزين مؤقت موثوقة عبر بروتوكول RPKI-to-Router الموضح في RFC 8210. وهي لا تطلب إذناً من أحد السجلات كلما فتح زائر صفحة.

4. مقارنة المسار بالتفويض

BGP هو البروتوكول الذي تعلن الشبكات من خلاله عن المسارات. ويقارن الموجّه المتلقي بادئة المسار ورقم ASN لمنشئه بالتفويضات المتحقق منها لديه. وتُسمّى هذه العملية التحقق من منشأ المسار، أو ROV.

صالح (Valid): يوجد تفويض يغطي البادئة ويسمح بالمنشأ وبطول البادئة معاً. غير صالح (Invalid): توجد تفويضات تغطي البادئة، لكن أياً منها لا يسمح بهذا الجمع بين المنشأ والطول. غير موجود (NotFound): لا يوجد تفويض يغطي البادئة. هذه نتائج مقارنة، وليست أحكاماً على نوايا أحد. ويقرر المشغّل كيف يستخدمها في سياسة التوجيه. انظر RFC 6811.

لنعد إلى نقل الخدمة. إذا ظل رقم ASN القديم مفوّضاً ولم يكن الرقم الجديد مفوّضاً، فقد يُصنَّف الإعلان الجديد بأنه غير صالح. وقد ترفضه الشبكات التي ترشّح المسارات غير الصالحة. والحل هو تنسيق تغيير التفويض مع عملية النقل، بما يشمل أي فترة تحتاج فيها الشبكتان إلى التفويض، بدلاً من افتراض أن سلامة الخوادم تضمن إمكانية الوصول. وتتناول RFC 7115 الاحتياطات التشغيلية.

5. إبقاء السلسلة بأكملها عاملة

يساعد التحقق من المنشأ على رفض الادعاءات الزائفة بشأن منشأ المسار. لكنه لا يتحقق من كل قفزة، ولا يشفّر حركة البيانات، ولا يكشف كل تسرّب للمسارات. فقد يحتفظ التسرّب بمنشأ مفوّض. ولذلك تظل وسائل حماية التوجيه الأخرى ضرورية.

وتحتاج الأدلة أيضاً إلى صيانة. فالشهادات تنتهي صلاحيتها، والتفويضات وبيانات النشر تتغير. ولا تؤدي إزالة تفويض ROA بالضرورة إلى انقطاع فوري: إذ تتوقف نتيجة التحقق النهائية على السجلات الأخرى المتاحة، ويتوقف الأثر في التوجيه على السياسة المحلية. وتبحث RFC 8211 كيف يمكن لأخطاء جهات إصدار الشهادات ومشغّلي المستودعات أو إجراءاتهم الضارة أن تؤثر في النظام.

مقترح لو هينغ: صون الخدمة واستبدال القائم على إدارتها

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

ويجعل البديل الذي يقترحه الاستمرارية خاصية في النظام نفسه: سجلات قابلة للتدقيق المستقل، وعملية تسليم مختبَرة إلى جهة خلف مؤهلة، ووسيلة لنقل الإدارة من دون إجبار الشبكات على تغيير عناوينها. وهو يقرّ صراحة بأن نقل RPKI لا يتم بمجرد نسخ دليل ملفات. إذ يجب أن تظل المفاتيح والشهادات والنشر والثقة متسقة طوال الانتقال.

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

لماذا نبني هذه القدرة قبل وقوع أزمة؟

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

تتمثل حجة لو هينغ في إرساء الاستمرارية والحق في المغادرة مسبقاً، مع منع النزاعات الإدارية من التحول إلى سلاح ضد الشبكات العاملة. تابع الحجة كاملة في المذكرة 70: احموا السجل، لا حارس البوابة.