الخلاصة

  • أوضحت APNIC في APNIC 62 أن واجهتها المستضافة لإنشاء ASPA تستمد اقتراحات المزوّدين من RIPE RIS. هذه الاقتراحات احتمالية، تحتاج إلى مراجعة، ويُرجّح أن تزيد على الحاجة أكثر من أن تنقص عنها.
  • تفحص الواجهة أيضاً كيف سيؤثر التعديل المقترح في مسارات BGP المرصودة. إنه اختبار مفيد للحاضر، لا تمرين شامل لكل مسار قد يظهر مستقبلاً.
  • توصي مسودة IETF الحالية بإضافة مزوّد الاحتياط أو الطوارئ مسبقاً، كي لا يسبق انتشار المسار توزيع كائن RPKI. غير أن المزوّد الساكن حقاً لا يملك بعد مساراً حياً ترصده الأداة.
  • تحتاج APNIC إلى إيصال يميّز بين اقتراح ناتج من الرصد، وإقرار بشري بالتفويض، ومرشح مرفوض، وفحص للمسارات الحالية، وسيناريو تبديل لم يُختبر.

تبدأ سلامة القائمة قبل أن تُوقَّع

يسمح كائن ASPA لحامل ASN بأن ينشر قائمة موقعة بالأنظمة الذاتية المسموح لها بأن تكون مزوّديه في اتجاه أعلى الشبكة. تحمي RPKI هوية الموقّع ومحتوى الكائن، ثم يستخدم المدققون القائمة عند تقييم علاقات الأزواج داخل AS_PATH. لكن التوقيع لا يجيب عن السؤال الذي يسبقه: هل اختيرت القائمة كاملة وبالتصنيف الصحيح؟

تحاول APNIC مساعدة العضو في هذه المرحلة. ففي عرض «APNIC RPKI Updates» أمام Routing Security SIG في APNIC 62، قالت إن الواجهة المستضافة تستخدم نقطة asn-neighbours في RIPEstat. وتحوّل علاقات الجوار التي رآها RIPE Routing Information Service إلى مرشحين، على نحو يشبه وظيفة اقتراح كائنات المسارات.

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

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

ترى RIPE RIS جواراً ولا ترى العقد

توثّق RIPEstat معنى البيانات بدقة. تعرض ASN Neighbours الأنظمة المجاورة التي رُصدت في RIS، ويمكن أن تضيف موقع الجار إلى يسار ASN أو يمينه، وعدد المسارات، وعدد نظراء الجداول الكاملة الذين رأوا العلاقة، ووقت الاستعلام أو نافذة صلاحية النتيجة. وقد تضع وسم uncertain عندما يكون الاتصال المباشر بمجمّع RIS قد صنع مظهر الجوار نفسه.

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

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

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

تضع مسودة IETF التفويض في فترة الصمت

تجعل مسودتا IETF المجمدتان المشكلة سباقاً زمنياً. تقترح المراجعة 29 من ملف ASPA كائناً واحداً لكل Customer AS يحتوي جميع المزوّدين، ومنهم خوادم المسارات غير الشفافة حين تنطبق. وتقلل وحدة الكائن واكتماله من سباقات التحديث التي قد تؤثر في انتشار BGP.

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

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

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

لا تثبت المواد العامة أن APNIC أغفلت حقلاً خاصاً أو أن عضواً أخطأ أو أن مساراً رُفض. العرض نفسه يطلب الآراء بشأن الاقتراحات والتحقق. كما أن نصوص IETF ما زالت Internet-Drafts قابلة للتغيير وليست RFC نهائية. النتيجة الأضيق هي أن الاختبار الموصوف يتعامل مع مسارات مرصودة، بينما توصي الأعمال الجارية بفئة من التفويض قد يكون مسارها غائباً على نحو مشروع.

لا يعني «لا تعارض حالياً» أن خطة التحويل نجحت

لنفترض أن ASN عميلاً يستخدم A وB كل يوم، ويحتفظ بـC للتخفيف في الطوارئ. ترى RIS كلاً من A وB، وربما ترى نداً D. تقترح الواجهة A وB وD؛ يحذف المشغّل D ويضيف C يدوياً.

تستطيع الأداة بيان أن حذف A سيؤثر في مسار قائم، أو أن B لم يظهر إلا في IPv6، أو أن D جاء من علاقة موسومة بعدم اليقين. ويمكنها القول إن مجموعة المسارات التي فُحصت لا تتعارض مع القائمة النهائية.

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

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

إيصال لمسار لم يظهر بعد

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

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

ويحمل المزوّد الساكن فئة التشغيل، وعائلات العناوين المعنية، والدور المسؤول، وتاريخ آخر تمرين مكتبي أو مختبري، وموعد المراجعة التالية. ويحفظ فحص المسارات نافذة الرصد، وبصمة مجموعة المسارات، والقائمة المقترحة والنتيجة. والأهم أن يسمي المزوّدين المفوضين الذين لم يُرصدوا، وبالتالي لم يختبرهم ذلك الفحص.

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

أظهر عرض APNIC 62 لقطة تضم 293 كائن ASPA لدى APNIC: 257 في سلطات تصديق مستضافة و36 في سلطات مفوضة. هذا عدّ للكائنات في لحظة، لا للشبكات التي تطبق التحقق ولا لاكتمال القوائم ولا لاختبار الاحتياط. ويمكن لصفحة ASPA الجديدة في DASH أن تفصل بين «منشور» و«مرصود» و«راجع السيناريو» و«حل موعد المراجعة».

يبقى قرار التوجيه عند مشغّل الشبكة

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

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

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

المصادر