الخلاصة

  • يبدأ مقترح RIPE 2026-02 الإجراءات بعد ظهور عنوان IP على قائمة بنية تحتية معتمدة مدة تراكمية تبلغ 14 يوماً ضمن أي فترة متحركة من 30 يوماً. ويمنح صاحب المورد سبعة أيام عمل للمعالجة، ثم يتطلب رفع القيود خلال يوم عمل من التحقق.
  • يقبل البند 3.4 عزل البادئات المتأثرة بعد التحقق منه. أما البند 3.6 فلا يذكر هذا الخيار؛ بل يشترط الخروج من القائمة أو حذف ROA المعني عند ارتباط الحالة بـRPKI. حذف ROA يغيّر سجل التحقق من منشأ المسار؛ وسحب إعلان BGP وعزل البادئة إجراءان شبكيان منفصلان.

ثلاثة مواعيد واختباران

يحوّل مقترح RIPE NCC رقم 2026-02 الإجراء إلى جدول واضح. يجب أن يظهر عنوان IP مدة تراكمية قدرها 14 يوماً على قائمة بنية تحتية معتمدة خلال أي نافذة متحركة من 30 يوماً. ويقدّم مشغّل شبكة متأثر أو National CERT إخطاراً موثقاً عبر تذكرة RIPE NCC Support، مع بيانات قياس آلية وطوابع زمنية أو توقيعات رقمية. ثم ترسل RIPE NCC إخطار معالجة يمكن تتبع تأكيد استلامه إلى جهات الاتصال القانونية والإدارية والمالية التي يلتزم صاحب المورد بإبقائها. تبدأ بعدها مهلة سبعة أيام عمل. وبعد التحقق من الامتثال، يجب رفع القيود خلال يوم عمل.

من السهل وضع التسلسل كله في شريحة واحدة. أما السؤال الصعب فيظهر عند الخانة الأخيرة: ما الدليل الذي يعيد لصاحب المورد القدرة المعتادة على التعامل مع السجل؟

العزل مقبول عند المعالجة ويختفي عند الاستعادة

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

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

وحذف ROA يطرح سؤالاً آخر. يعرّف RFC 9582 هذا الكائن الموقّع بوصفه تفويضاً لـAutonomous System كي ينشئ مسارات إلى بادئات محددة. ويعطي RFC 6811 المسار حالة NotFound عندما لا يغطي بادئته أي VRP صالح. تصف الحالة سجل التحقق. يتطلب سحب إعلان BGP وعزل البادئة إجراءين شبكيين منفصلين؛ وتحدد سياسة الموجّه ما إذا كانت حالة التحقق ستغيّر اختيار المسار أو تمرير الحزم.

يسهّل الاختبار الثنائي في البند 3.6 العمل الإداري. لكنه قد يصل إلى نتيجة مختلفة عن الإصلاح الذي أجازه البند 3.4.

القائمة جزء من أداة الإنفاذ

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

ويجعل البند 3.5 القيود الوسيطة رهناً ببنية السجل لدى صاحب المورد. ستقلل هذه القيود قدرته على إجراء عمليات السجل، وستظهر حالة عامة باسم “non-compliant abuse status” في RIPE Database، مع محاولة إبقاء تخصيص الموارد سليماً وحماية الشبكات اللاحقة من الفصل الفوري. وتعترف مبررات المقترح بأن القيود نفسها تحتاج إلى اتفاق ووصف مفصل في وثيقة RIPE منفصلة حتى لا تنتج إجراءات ملتبسة أو غير قابلة للتطبيق. هذه هي آلية السلطة، لا هامشها.

ما زال المقترح في مرحلة النقاش. حدد تحديث RIPE NCC لشهر أكتوبر 11 نوفمبر موعداً نهائياً للتعليقات، ويضع برنامج RIPE 93 النقاش في Security Working Group يوم 27 أكتوبر. تستطيع النسخة التالية توحيد اختبار الخروج قبل تشغيل الساعة.

المصادر