الخلاصة

  • يتيح RFC 8360 للطرف المعتمد المتوافق أن يحسب «مجموعة الموارد المتحققة» VRS وأن يواصل التحقق بالجزء الذي تثبته السلسلة عندما تبالغ شهادة سلطة تصديق في مواردها، ولكن فقط مع سياسة وإضافات الإصدار الثاني ذات معرّفات OID الجديدة.
  • لا يصبح المورد الزائد صالحاً أبداً: يجب أن تقع جميع بادئات ROA داخل VRS-IP وجميع أرقام ASN في شهادة موجّه BGPsec داخل VRS-AS، أما الشهادات ذات السياسة القديمة فتظل خاضعة للرفض الكامل.

كيف تحوّل اختلاف إداري إلى أثر هرمي

تربط شهادات الموارد في RPKI مفاتيح عامة بكتل عناوين IP وأرقام الأنظمة المستقلة. لا تستمد الشهادة معناها من توقيعها وحده؛ فما تطالب به السلطة الابنة يجب أن يندرج ضمن ما تملكه الجهة المصدرة بصورة صحيحة، ويستمر هذا الشرط صعوداً حتى مرساة الثقة. حدّد RFC 3779 إضافات الموارد، ثم وضع RFC 6487 ملف الشهادات وإجراء التحقق في RPKI.

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

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

يحمل RFC 8360 أسماء Geoff Huston وGeorge Michaelson وCarlos Martinez وTim Bruijnzeels وAndrew Newton وDonald Shaw. وحلهم الجماعي هو خوارزمية بديلة تتمحور حول Verified Resource Set، أو VRS. بدلاً من مساواة ما هو مكتوب في الشهادة بما يمكن استخدامه، يحتفظ المدقق بتقاطع الموارد التي يدعمها كل مستوى في المسار المتحقق.

مجموعتان منفصلتان وحد سلطة واحد

يحسب المعيار VRS-IP لموارد العناوين وVRS-AS لأرقام الأنظمة المستقلة كلّاً على حدة. عند غياب المبالغة، تكون النتيجة هي نفسها في RFC 6487. وعند وجودها، يصبح الفرق بين المجموعة المعلنة والتقاطع المتحقق هو الجزء المستبعد.

هذا السلوك لا يُفرض خفية على الشهادات القديمة. عرّف RFC 8360 سياسة شهادات من الإصدار الثاني ومعرّفات OID جديدة لإضافات الموارد. إذا استخدمت الشهادة ذلك الملف وفهمه الطرف المعتمد، يسجل المدقق تحذيراً يعدد الموارد الزائدة ثم يكمل باستخدام VRS. وإذا استخدمت سياسة RFC 6487 القديمة، فلا تزال المبالغة تفرض الرفض. يحمل OID هنا معنى تشغيلياً وحداً للتوافق.

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

يوضح مثال الوثيقة الحد بدقة. تطالب سلطة ابنة بالبادئة 192.0.2.0/24 التي يدعمها المسار، وتضيف 198.51.100.0/24 التي لا يدعمها. تبقى الأولى في VRS وتُستبعد الثانية. يمكن أن تصح ROA للأولى، ولا يمكن أن تصح ROA للثانية. استمرار الفرع المشروع لا يمرر المورد غير المملوك.

نجاة شهادة السلطة ليست موافقة جماعية

تخضع الكائنات الموقعة لفحصها الخاص. يعرّف RFC 6482 كائن ROA، ويشترط RFC 8360 أن تقع كل بادئة فيه داخل VRS-IP لشهادة الكيان النهائي. فإذا جُمعت بادئة صحيحة وأخرى مستبعدة في ROA واحدة، يفشل الكائن حتى لو بقيت شهادة السلطة الأعلى في المسار.

ومن هنا تأتي فائدة الفصل التشغيلي. قد يصدر حامل الموارد كائنات ROA منفصلة للبادئات المستقلة، فلا يؤدي فقدان واحدة إلى إبطال تفويضات منشأ تخص غيرها. وينطبق المنطق نفسه على شهادات موجّهات BGPsec: يجب أن تشمل VRS-AS كل ASN معلن، ويمكن لشهادة منفصلة لكل ASN أن تقلص الأثر الجانبي.

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

يبدأ الانتقال عند من يتحقق

تنشئ معرّفات OID الجديدة حاجز توافق. أداة قديمة لا تعرف الملف البديل سترفض الشهادة الجديدة. لذلك يضع RFC 8360 تحديث أدوات الأطراف المعتمدة قبل بدء سلطات التصديق استخدام معرّفات الإصدار الثاني. قدرة المصدر على إنشاء الشهادة لا تثبت أن المستهلكين قادرون على فهمها.

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

يقدم RFC 8488 لقطة تنفيذية تاريخية من عام 2018. فقد وصف RIPE NCC Validator بخيار «تحقق صارم» يختاره المشغل، وباستخدام السلوك البديل خارج ذلك الخيار وفق الإعداد. هذه شهادة على تصميم منتج واحد آنذاك، وليست ضماناً لوضعه الحالي ولا بديلاً عن دلالة OID المعيارية في RFC 8360.

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

المصادر