الخلاصة

  • أعلنت IESG في 17 سبتمبر الدعوة الأخيرة لمسودة SAVNET رقم 21، وحددت الأول من أكتوبر للتعليقات الجوهرية بشأن نشرها بوصفها RFC معلوماتياً.
  • تختلف كلفة منع المرور المشروع والسماح بمصدر مزوّر عند واجهات العميل والنظير ومزوّد العبور.
  • إجماع فريق العمل ومراجعة IESG وتصميم آلية لاحقة وقرار المشغّل ونتيجة المرور المرصودة أدلة وقرارات منفصلة.

إذا قيّد عميل متعدد الوصلات إعلان بادئة إلى أحد مزوديه، فقد يصل مروره المشروع عبر وصلة لا ترى تلك البادئة في BGP. وقد يعيد خادم طرفي المحتوى مباشرة بعنوان anycast يُعلن من مكان آخر. تبيّن مسودة SAVNET رقم 21 كيف يمكن لقائمة سماح مستخرجة من مسار الرجوع وحده أن تحجب هذين النوعين من المرور. الرسوم فيها أمثلة تحليلية، وليست تقارير انقطاع لشبكات محددة.

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

طلب إعلان IESG المؤرخ 17 سبتمبر ملاحظات على بيان المشكلة وتحليل الثغرات ومتطلبات تحسينات مستقبلية. ويعرض السجل الرسمي الحالة بوصفها طلب نشر لمسودة إنترنت نشطة. تشمل المتطلبات دقة التحقق، وكلفة التشغيل، والمنفعة في النشر الجزئي، وحماية معلومات SAV الخاصة، وتقارب الجداول بعد التغييرات. لا تعني هذه الصياغة أن IETF أقرت تمديداً لـBGP أو كائناً جديداً في RPKI، ولا أنها ألزمت مشغّلاً بقاعدة حجب.

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

المصادر