الخلاصة

  • تتكون هوية التاريخ القابل لإعادة التشغيل من موقع الإشعار والأصل والجلسة والرقم التسلسلي والهاش. إذا تغيّر الهاش لرقم سبق أن شاهدته جهة الاعتماد، فلا يعود المسار التزايدي صالحاً للاستمرار.
  • العلاج المحدود هو التحذير والانتقال إلى أحدث snapshot ثم إعادة فحص manifests والشهادات وقوائم الإبطال والكائنات الموقعة. نجاح هذه العملية لا يأمر الراوتر بحذف مسار؛ فالقرار يبقى لسياسة الشبكة المحلية بعد مقارنة الـpayloads وقياس الأثر.

لنتخيل موزّعاً يخدم موقعين من edge مختلفين. حصل المدقق الأول على دلتا رقم 1774 واحتفظ بهاش A. وبعد مدة قرأ المدقق الثاني إشعاراً ينسب إلى الجلسة والرقم نفسيهما هاش B. كل ملف طابق الإشعار الذي كان ظاهراً عند تنزيله، وكلا المدققين وصل في النهاية إلى الرقم الحالي ذاته. مع ذلك قد تكون قاعدة الكائنات المحلية، ثم قائمة الـValidated Payloads، مختلفة.

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

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

الدليل ينتقل بين ثلاثة أمناء

يصف RFC 8182 إشعاراً ثابت الموقع يعلن session_id والرقم الحالي وموقع snapshot وسلسلة من الدلتا. يحتوي snapshot على الحالة الكاملة المنشورة، بينما تحمل كل دلتا عمليات publish وreplace وwithdraw لانتقال واحد.

يستطيع العميل متابعة الدلتا إذا تطابقت الجلسة، وكانت الأرقام المفقودة متصلة ومرتبة، وطابقت بايتات كل ملف الهاش المعلن. أما البداية الجديدة أو أي كسر في الشروط فيقود إلى snapshot.

لا تمثل session_id هوية عالمية للمستودع. ينص RFC 8182 على ربطها بموقع الإشعار لأن خادماً آخر يمكنه إعادة استخدام UUID. الموقع يحدد النطاق، والجلسة تحدد دورة التهيئة، والرقم يرتب الانتقالات، والهاش يربط الانتقال ببايتات بعينها.

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

يشير RFC 6811 إلى أن صورة RPKI العالمية متسقة بصورة رخوة بسبب اختلاف أوقات الجلب والتحديث. التأخر العادي يعني أن مراقبين يقفان عند نقطتين مختلفتين في تاريخ واحد. أما تبديل الهاش عند النقطة نفسها فيعني وجود تاريخين، وهو فشل مختلف في النوع لا الدرجة.

الثبات هو الشرط الذي يسمح للوسيط بالتوسع

تستفيد RRDP من HTTP وCDN لأن snapshot والدلتا لا يتغيران بعد النشر. يستطيع cache الاحتفاظ بالملف وتسليمه لعدد كبير من جهات الاعتماد، ويستطيع كل متلقٍ التأكد من أن البايتات تطابق الهاش المعلن.

إذا استبدل الملف تحت عنوانه التاريخي، فقد يحتفظ edge بالنسخة الأولى ويأخذ آخر النسخة الثانية. لا يلزم أن يكون أي نقل تالفاً. الانقسام ناتج عن ادعاء نسختين أنهما الدليل نفسه.

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

لذلك يجب أن يسجل التنبيه موقع الإشعار والجلسة والرقم والهاش القديم والجديد وتوقيتي الجلب. عبارة عامة مثل «فشلت المزامنة» تمحو الفرق بين دلتا مفقودة، وملف لا يطابق الهاش، وجلسة جديدة سليمة، وإعادة كتابة لما سبق تسليمه.

إعادة البناء لا تمنح عفواً للكائنات

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

وقد يكون reset واسع النطاق مكلفاً. آلاف العملاء الذين يتحولون من دلتا صغيرة إلى snapshots كاملة يضغطون على الأصل وCDN والشبكات والمدققات. إعادة المحاولة بلا حدود تحول الإصلاح إلى تضخيم للعطل. يلزم backoff وتدرج وسعة ومراقبة.

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

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

صحة النقل ليست صحة السلطة

يضع RFC 6480 المستودعات داخل بنية RPKI الموزعة. وظيفتها إتاحة المواد العامة، لا منحها سلطة تشفيرية بمجرد الاستضافة.

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

يوضح RFC 6481 بنية نقاط النشر والحاجة إلى تجنب الحالات الوسيطة التي لا يتطابق فيها manifest مع الملفات. النقل المتماسك لا يستطيع إصلاح حالة جُمعت بصورة غير متماسكة قبل التوزيع.

ثم يأتي RFC 6488 بفحوص البنية CMS والشهادة المضمنة ونوع المحتوى والـdigest والتوقيع، إلى جانب قواعد كل منتج. التوقيع الصحيح يكشف التعديل غير المصرح به، لكنه لا يثبت أن الملف هو الأحدث أو أن ملفات أخرى لم تُحجب.

لهذا يحدد RFC 9286 manifest موقع النشر وقائمة الملفات وهاشاتها. عدم توفر ملف مذكور لا يسمح باعتبار المجموعة الجزئية كاملة. ويحدّث RFC 9981 التعامل مع رقم manifest وإعادة التشغيل المرتبطة بالـreplay.

رقم manifest ليس الرقم التسلسلي لـRRDP. كما أن جلسة وserial بروتوكول RPKI-to-Router تخصان تسليم الـpayloads. خلط الأرقام في خانة واحدة باسم «نسخة RPKI» يزيل حدود السلطة بين ثلاث آلات حالات.

يجمع RFC 8897 مسؤوليات جهة الاعتماد. يمكن فصل الجلب عن التحقق في البرامج، لكن يلزم مسار إثبات يربط البايتات بالـmanifest والشهادة وCRL والكائن المقبول والـpayload الناتج.

عند الراوتر تنتهي سلطة المدقق

بعد إعادة البناء قد تضاف ارتباطات prefix-origin أو تزال. يطلب RFC 6811 إعادة فحص المسارات المتأثرة ويتيح لسياسة التوجيه المحلية استخدام حالات Valid وInvalid وNotFound. ولا يفرض استجابة واحدة.

قد ترفض الشبكة Invalid أو تخفض أفضليته أو تراقبه أو تستثنيه وفق شروط محددة. RPKI تتحقق من تفويض الأصل، لا من كامل AS_PATH ولا من نجاح forwarding. لذلك لا تمنح طفرة هاش RRDP وحدها تفويضاً لحذف المسارات.

يستمر الإثبات عبر فرق الـpayload، واكتمال RPKI-to-Router، والقاعدة التي اختارتها السياسة، وLoc-RIB وFIB وقياسات الحزم. إصلاح المستودع بداية التحقيق التشغيلي، لا نهايته.

المصادر