الخلاصة

  • يرتّب رقم بيان RPKI محليًا قوائم الملفات الموقّعة الصادرة عن CA واحدة. ليس ساعة عالمية ولا وصفًا لما تمرره الشبكة. وللحقل حد أقصى، لذلك قد يجعل خلل في الإصدار كل بيان لاحق أصغر من القيمة التي قُبلت بالفعل.
  • يعدّ RFC 9981 اسمًا مختلفًا لملف البيان بداية حقبة مقارنة جديدة. يجب على relying party تنبيه المشغّل، ولا ينبغي للجهة المصدرة أن تجعل تغيير الاسم ممارسة اعتيادية.
  • الذي يبدأ من جديد هو مرجع الرقم المحفوظ وحده. تبقى سلسلة التوقيع، وthisUpdate الأحدث، وقائمة الملفات والهاشات، والتطابق الدقيق بين URI الموقّع وموقع RRDP أو rsync شروطًا قائمة.

بيان أحدث لا يستطيع أن يكون أكبر

لنتصور أن سلطة تصديق تستعد لإصدار البيان رقم 7914. يكتب خلل حسابي بدلًا منه 2^159 - 1، وهي أكبر قيمة يسمح بها الحقل. يوقّع المفتاح الصحيح الكائن، وتكون الأزمنة صحيحة، وتطابق أسماء الملفات وبصماتها نقطة النشر. تقبل عدة relying parties البيان وتحفظ الرقم.

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

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

يختار RFC 9981 أصغر قطيعة يمكن للطرفين ملاحظتها: اسم ملف مختلف. لا يمنح الجهة المصدرة سلطة عامة لمحو تاريخ مزعج. الاسم يفتتح حقبة جديدة لمقارنة الأرقام، بينما تعبر بقية الأدلة الحد من دون تغيير.

ما الذي يشهد عليه البيان فعلًا

بيان RPKI هو قائمة موقّعة بالملفات التي تنوي CA نشرها في نقطة نشر واحدة. يرتبط كل اسم ملف ببصمة، وبذلك يمكن اكتشاف الملف المفقود أو المستبدل أو الصورة غير المكتملة للمستودع.

البيان نفسه كائن RPKI موقّع، ويحمله EE certificate مخصص للاستخدام مرة واحدة. يتضمن manifestNumber وthisUpdate وnextUpdate وخوارزمية الهاش وأزواج اسم الملف والبصمة. ويشير CA certificate إليه عبر SIA من نوع id-ad-rpkiManifest.

نطاق هذا الدليل محدود عن قصد. إدراج ملف ROA لا يثبت أن المسار ظاهر في BGP. إدراج CRL لا يثبت أن كل مدقّق حصل عليها. إنتاج VRP لا يعني أن الموجّه استهلكه. يتحدث البيان عن طبقة النشر؛ أما التحقق وقرار التمرير ففي طبقات لاحقة.

يحمي هذا الفصل عملية التعافي من التوسع غير الضروري. لم تنهَر «الثقة في RPKI كلها». الذي أصبح غير قابل للاستمرار هو التاريخ الرقمي لجهة واحدة تحت اسم واحد. ويمكن أن يبقى الإصلاح محليًا بالقدر نفسه.

حقل هائل لكنه محدود

يفرض RFC 9286 زيادة رقم البيان بمقدار واحد مع كل إصدار جديد. يتوقع relying party قيمة أعلى من آخر قيمة مقبولة. قد تكشف القفزة حالة مفقودة، وقد يكشف التراجع كائنًا قديمًا أو معاد العرض.

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

يوضح RFC 9981 الحد: INTEGER موجب لا يتجاوز 20 ثمانية، أي بحد أقصى 2^159 - 1. لو صدر بيان كل ثانية، لاحتاج الاستنفاد الطبيعي إلى نحو 23,171,956,451,847,141,650,870 كوينتليون سنة. ليست المشكلة سعة الحقل.

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

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

اسم الملف بوصفه حدًا صريحًا للحقبة

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

هذا الاسم ليس ملصقًا حرًا في شاشة إدارة. إنه الجزء الأخير من مسار URI في id-ad-rpkiManifest SIA داخل CA certificate. يجب على السلطة تسمية الموقع الجديد في الشهادة، ونشر الكائن فيه، وإبقاء التوافق مع URI الخاص بالـsigned-object في EE certificate.

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

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

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

ما الذي لا يُعاد ضبطه

لا تعني القاعدة «اسم جديد، إذن اقبل». يحدد الاسم فقط أي manifestNumber محفوظ سيُستخدم أساسًا للمقارنة.

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

تبقى الحداثة أيضًا. يجب أن يكون thisUpdate في البيان الجديد أحدث من نظيره في آخر بيان مقبول. لا يصبح جرد قديم موقّع حديثًا بمجرد نسخه إلى مسار آخر. ويستمر nextUpdate في تحديد النافذة التي يعلنها المصدر.

ويبقى الموقع دليلًا. يجب أن يطابق URI الخاص بالـsigned-object داخل EE certificate تمامًا publish URI في RRDP أو مسار rsync الذي جُلب منه الكائن. نسخ البايتات تحت اسم مختلف من دون مواءمة المراجع الموقّعة لا ينشئ حقبة RFC 9981.

ولا يغيّر البيان الكائنات التي يسردها. يمكنه جعل قائمة جديدة مؤهلة للتحقق، لكنه لا يغيّر موارد شهادة أو بادئات ROA أو حالة CRL أو مدخلات الموجّه.

فخ تعدد SIA

قد يحمل CA certificate أكثر من وصف SIA للبيان. وقد تختار relying parties مواقع مختلفة. إذا أزال البديل اسمًا قديمًا وأبقى اسمًا قديمًا آخر، ترى مجموعة حقبة جديدة بينما تعتقد مجموعة أخرى أن الحقبة السابقة مستمرة.

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

لهذا يفرض RFC 9981 ألا يبقى أي اسم بيان سابق في الشهادة الجديدة عندما يعتمد التعافي على تغيير الاسم. يجب جرد جميع قيم SIA والمسارات وقواعد اختيار المدققين. تغيير الموقع الذي يوصف بأنه «الأساسي» وحده غير كافٍ.

RRDP وrsync وسيلتا نقل، لا حقيقتان بديلتان. يجب أن تتقارب snapshot وdelta وصورة rsync على كائنات تتطابق بايتاتها وURIs الموقّعة. نجاح HTTP يثبت التسليم، لا التفويض التشفيري للموقع.

لماذا تكون عقدة الثقة أصعب

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

أما trust anchor فلا تملك CA أعلى. يصل مفتاحها ومواقع شهادتها إلى relying party عادة عبر TAL. ويصطدم تغيير المفتاح أو توزيع TAL جديد باختلاف مواعيد التحديث، وبقاء تثبيتات قديمة، وخطر فقدان الشجرة كلها عند المدققين الذين يحتفظون بالمادة السابقة.

يحسن RFC 9691 الانتقالات المخططة عبر كائنات TAK. تستطيع عقدة الثقة الحالية الإعلان عن مفتاح خلف ومواقعه، ويتحقق المدققون من العلاقات المتبادلة ثم ينتظرون مدة قبول قبل الانتقال.

لكن TAK ليست بابًا سحريًا حول نقطة نشر تالفة. يبدأ relying party من المفتاح الموثوق حاليًا، ويجلب الشهادة، ويتحقق من البيان وCRL، ثم يعالج TAK. يجب إعداد الاستمرار قبل الطوارئ، والتدرب عليه منفصلًا عن تغيير اسم RFC 9981.

التعافي يُثبت بالتقارب

لا تنتهي العملية عندما توقّع CA ملفًا جديدًا. يثبت التعافي حين تحصل تطبيقات مستقلة على الكائن نفسه، وتعترف بحقبة RFC 9981، وتتحقق من القائمة، وتتقارب مخرجاتها المتوقعة.

يستخدم الاختبار الآمن مواد ملتقطة أو اصطناعية، ولا يقرّب عدّاد الإنتاج من الحد الأقصى. ويشمل تسلسلًا طبيعيًا، وقفزة، والحد الأقصى، ورقمًا صغيرًا تحت الاسم نفسه، ورقمًا صغيرًا تحت اسم جديد، وthisUpdate أقدم، وURI موقّعًا مخالفًا، وشهادة تبقي SIA قديمة.

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

في الإنتاج تُحفظ الشهادة والبيان السابقان، وكل URIs والأرقام والأزمنة وبصمات المخرجات. ويسجل السبب والموافقون وSIA الجديدة والأثر المتوقع. ثم تُقارن RRDP snapshot وdelta وrsync والمدققات ومدخلات الموجهات قبل إزالة المادة القديمة.

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

المصادر