الخلاصة

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

إجراء واحد وثلاثة أسئلة إثبات

بدأ مجتمع RIPE مناقشة مقترح جديد يتناول إساءة استخدام الشبكات على مستوى البنية التحتية. نُشرت النسخة 1.0 في 13 أكتوبر 2026، وتشير الصفحة الرسمية إلى أن النقاش مستمر حتى 11 نوفمبر. ولا يظهر في السجل العام، عند تاريخ إعداد هذا المقال، ما يفيد اعتماد المقترح أو تنفيذه أو معالجة حالة بموجبه. فهو يصف التزامات مقترحة، لا إجراءً قائماً تتخذه RIPE NCC.

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

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

بعد ذلك تظهر ثلاث محطات إثبات لا ينبغي دمجها:

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

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

نطاق ROA أضيق من نطاق ادعاء الإساءة

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

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

يترك النص رابطين بلا تعريف. ما الحالة التي تجعل RPKI «معنية»؟ وأي ROA يكون «مناسباً» عندما يدير مالك المورد بادئات أو أنظمة منشأ أو تفويضات متعددة؟ ليست هذه تفاصيل لفظية. فهي تحدد التغيير المطلوب من المشغّل والأساس الذي ستقبله RIPE NCC لرفع حالة عدم الامتثال المنشورة علناً.

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

سياسة abuse-c تجيب عن سؤال آخر

تتناول RIPE-705 طبقة الاتصال: فهي تنظم سمة abuse-c في سجلات الموارد المعنية، وتقتضي وجود صندوق بريد صالح لتلقي البلاغات، والتحقق السنوي والمتابعة وفق السياسات والإجراءات ذات الصلة. وتعرض RIPE NCC هذه السجلات بوصفها وسيلة لإيصال التقارير إلى مالك المورد المناسب.

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

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

يصف صاحب المقترح استمرار عدم المعالجة بأنه إخلال تعاقدي. وهذا جزء من تبريره، لا حكم قانوني مستقر. وما زال مسار تطوير سياسات RIPE مفتوحاً وقائماً على التوافق. والسؤال العملي الأقرب هو: ما الدليل الذي يرافق كل انتقال بين الحالات؟

إيصال إثبات لكل إخطار

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

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

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

تصف RIPE-781 أربع مراحل مفتوحة لتطوير السياسات، وعملية توافق، ودعماً إدارياً من RIPE NCC يشمل تقييم الأثر وأعباء التنفيذ. لذا يمكن للنقاش أن يختبر أكثر من عتبة الأيام الأربعة عشر: ما الدليل الذي يربط العنوان بمالكه، والسلوك بكائن التفويض، والتصحيح برفع الحالة العامة؟

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

المصادر