الخلاصة

  • تقترح مسودة DOA المنشورة في 20 أغسطس ربط البادئات وأطوالها ورقم AS المنشئ والأقران الاختياريين ومجتمعات BGP بتوقيع من صاحب المورد داخل RPKI.
  • تظل نتيجة DOA منفصلة عن ROV ولا تفرض إسقاطاً افتراضياً؛ فالمسودة فردية وغير معتمدة، كما أن الأمن والتشغيل ونقل RPKI-RTR لم تكتمل بعد.

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

تقدم draft-spaghetti-grow-rpki-doa-00 المنشورة في 20 أغسطس اعتماداً منفصلاً لهذه الحالة. سيكون Discard Origin Authorization كائناً موقّعاً في RPKI يحدد رقم AS المسموح له بإنشاء الطلب، والعناوين ومدى أطوال البادئات، ومجتمعات BGP الكلاسيكية أو الكبيرة، وأرقام AS للأقران الذين يمكنهم تمرير الطلب عند الحاجة.

لا يجوز توسيع وصف الحدث إلى قرار معياري. يصنف Datatracker الوثيقة Internet-Draft فردية ويؤكد أنها غير مؤيدة من IETF ولا تتمتع بوضع رسمي في مسار المعايير. وقد نقل المؤلفان مقترحاً يعود إلى 2022 من اسم يستهدف SIDROPS إلى اسم يستهدف GROW، لكن ذلك لا يثبت أن مجموعة العمل تبنته.

مع ذلك، حُسم سؤال كان مفتوحاً في النص القديم. فقد كانت نسخة 2022 تسأل هل تُقيَّم عدة مجتمعات بمنطق «و» أم «أو». النسخة الحالية تختار «أو»: يكفي وجود مجتمع واحد من القائمة على المسار لتلبية هذا الشرط. ويمكن لأداة التوقيع أن تضيف مجتمع BLACKHOLE المعروف في RFC 7999 افتراضياً عندما لا يحدد المُصدر مجتمعاً آخر.

لا تكفي العلامة وحدها للحصول على Matched. يجب أن يتطابق AS المنشئ، وأن يقع طول البادئة ضمن المجال المسموح، وأن يصل الإعلان مباشرة من المنشئ أو من peerAsID مصرح له، وأن يحمل واحداً على الأقل من المجتمعات المذكورة. إذا غطى كائن صالح البادئة ولم تتطابق القيود تكون النتيجة Unmatched، وإذا لم يوجد كائن مغطٍ تكون NotFound.

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

هذا الفصل يمنع تحويل التوقيع إلى دليل على أكثر مما يثبت. فالـDOA الصالح يبين أن صاحب المورد أجاز تركيبة محددة. لكنه لا يثبت وقوع هجوم، ولا نية المُعلن الحالية، ولا صحة مسار AS كاملاً، ولا أن الإسقاط هو العلاج الملائم في اللحظة نفسها.

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

البديل يفسر سبب اقتراح كائن جديد. يمكن لصاحب المورد توسيع maxLength في ROA حتى تصبح البادئة الأكثر تحديداً صالحة في ROV، لكن ذلك يوسع أيضاً تفويض المنشأ العادي. وتحذر RFC 9319 من الحدود القصوى الأوسع من الحاجة. تحاول DOA حصر الاتساع في غرض الإسقاط وحده.

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

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

المصادر