الخلاصة

  • شارك Job Snijders وTies de Kock من RIPE NCC في تأليف RFC 9697، المنشور عن IETF في ديسمبر 2024.
  • يقارن المدقق الأرقام التسلسلية وبصمات الملفات التي رآها سابقاً؛ وعند تغير بصمة قديمة يصدر تنبيهاً ويعيد المزامنة من أحدث نسخة كاملة.

الدرج رقم 1774 لم يبق كما كان

في مثال RFC 9697، ينتقل إشعار التحديث من الرقم 1774 إلى 1775. يحدث ذلك كل يوم. الغريب أن بصمة الملف المرتبط بالرقم القديم 1774 تغيرت، فيما بقيت بصمة 1773 كما هي. بطاقة الدرج ثابتة، والمحتوى تبدّل. هذه أرقام توضيحية في المعيار، وليست تقريراً عن حادثة إنتاجية محددة. أخذ Job Snijders وزميله Ties de Kock هذا التناقض وصاغا له فحصاً عملياً.

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

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

عرف Snijders مشكلات التوزيع من قبل. ففي سرده التقني عام 2021 عن rpki-client وصف خوادم خلف موزع حمل لا تتحرك بالإيقاع نفسه: خادم يعلن ملف دلتا لم يصل بعد إلى خادم آخر. ذلك سباق بين خوادم؛ أما RFC 9697 فيتناول تغير ملف قديم تحت رقمه السابق. لكل مشكلة آليتها، وكلتاهما تكشفان أن التوقيع وحده لا ينقل الملف إلى المدقق.

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