الخلاصة

  • عرضت RIPE NCC في RIPE 93 صورتين مختلفتين: ما يقارب 100٪ من الإعلانات المرصودة والمغطاة بـROA كانت صالحة عبر ROV، بينما لم يظهر نحو 37٪ من تعريفات ASN والبادئة في ROA ضمن BGP.
  • بعض التعريفات غير المرصودة تحمي مسارات احتياطية. وقد يبقى بعضها بعد سحب الإعلان، فيجعل انتحال مصدر ما يبدو صالحاً وفق RPKI.

التفويض الذي يبقى بعد المسار

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

في 28 أكتوبر، شرح Tim Bruijnzeels، مسؤول RPKI في RIPE NCC، المسألة من جهتين خلال اجتماع التوجيه في RIPE 93. قال إن نحو 73٪ من البادئات عالمياً لديها ROA عند جمع IPv4 وIPv6. وبين البادئات المعلنة والمغطاة فعلاً بـROA، كان ما يقارب 100٪ صالحاً عبر ROV. ووفق شرحه، يصحح المشغلون إعلانات Invalid أو يرشحونها سريعاً، فتتحسن الإعلانات المرصودة بسرعة.

ثم قلب المنظور: نحو 37٪ من تعريفات ASN والبادئة داخل ROA لم تكن مرصودة فعلياً في BGP. هذا عدّ لتعريفات التفويض، لا للمسارات أو حركة المرور أو مساحة العناوين أو عدد كائنات ROA. وقد يحتوي ROA على أكثر من تعريف لبادئة.

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

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

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

لهذا البقاء أثر تقني. تفحص آلية التحقق من مصدر BGP ما إذا كانت البادئة وASN المصدر يطابقان ROA مصرحاً به؛ ولا توثق كامل مسار AS. إذا أعلن طرف البادئة منتحلاً مصدراً ما زال ROA قديم يجيزه، فقد يصنف المدققون الإعلان على أنه Valid. وقد يواصل توقيع كان يصف مساراً حقيقياً منح الشرعية الظاهرية للمصدر بعد زوال السبب التشغيلي.

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

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

يكشف رقم RIPE NCC فجوة صيانة حقيقية. قد تتزامن صلاحية عالية بين المسارات المرصودة مع مخزون من الأذونات التي لا يراجعها أحد. والرقم التالي المفيد ليس خفض 37٪ بحذف الجميع، بل معرفة حصة التعريفات غير المرصودة التي صُنفت احتياطية أو مخططة أو نشطة أو متقاعدة، وعدد الأذونات المتقاعدة التي أزيلت فعلاً.

المصادر

محضر مجموعة التوجيه في RIPE 93 · واجهة RIPE NCC لإدارة RPKI · التحقق من مصدر BGP لدى RIPE NCC · RFC 6811: التحقق من مصدر بادئات BGP · RFC 6482: ملف تعريف ROA