الخلاصة

  • أعلنت APNIC في 22 أكتوبر وجود 538 كائناً منشوراً من ASPA تحت جذر الثقة الخاص بها في RPKI، ونصحت بتشغيل التحقق من المسارات قبل اتساع مهمة المراجعة.
  • يقارن MyAPNIC التغييرات المقترحة بمسارات BGP المرصودة؛ ويراجع صاحب رقم النظام المستقل الطلب المعلّق ثم يضغط Commit لنشره.

كلما كبرت كومة التصاريح الموقعة، أصبح شعار «نفحصها لاحقاً» أقل إقناعاً. أحصت APNIC في شرحها الجديد 538 كائناً من ASPA تحت جذر الثقة التابع لها. وأتبعت الرقم بنصيحة عملية: البدء المبكر بالتحقق من مسارات BGP، لأن تأجيله يعني البحث عن أخطاء الضبط في مجموعة أكبر دفعة واحدة.

يتيح ASPA لصاحب رقم نظام مستقل أن يوقّع قائمة أنظمة المزوّدين المصرح لهم بنقل حركة شبكته. ويمكن للشبكات التي تستقبل إعلانات BGP أن تقارن مسار الإعلان بتلك العلاقات. تشرح صفحة خدمة ASPA لدى APNIC كيفية إتاحة هذه السجلات للمتحققين. نشر التصريح يضع الدليل في متناول الآخرين؛ أما أثره على اختيار المسار فيتوقف على قرار الشبكة المستقبِلة.

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

تحذر APNIC من أن قائمة خاطئة قد تجعل مسارات تشمل نظام العميل المستقل تُصنَّف غير صالحة عندما تبدأ الشبكات استخدام تحقق ASPA. تصحيح الخطأ وسط مجموعة صغيرة أسهل من تنظيف مئات التصاريح عند تشغيل القاعدة متأخراً. وبعد التشغيل يمكن إرجاع المشكلات الجديدة إلى الجهات التي وقّعت التغييرات. وتفصل وثيقة APNIC عن RPKI بين خوارزميتي اتجاهي المسار ونتائج Valid وInvalid وUnknown.

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