الخلاصة

  • ينشر RFC 8955 شروط مطابقة الحركة وإجراءاتها عبر BGP، لكنه يقارن افتراضياً منشئ القاعدة بمنشئ أفضل مسار unicast مطابق، ويطلب إعادة التحقق كلما تغيّر ذلك المسار.
  • شاركت Susan Hares في تأليف RFC 8955 وفي تحرير امتداد IPv6 في RFC 8956. أما RFC 9117 فكتبه مؤلفون آخرون، ولا يخفف التحقق إلا لمتحكم مركزي أو route server داخل النطاق المحلي نفسه.

حين يتحول الإعلان إلى فعل

تتيح FlowSpec جمع بادئات المصدر والوجهة والبروتوكول والمنافذ وحقول ICMP وأعلام TCP وطول الحزمة وDSCP والتجزئة في قاعدة واحدة. وتحمل extended communities الإجراء: تحديد معدل بالبايت أو الحزمة، أخذ عينة، إنهاء سلسلة المطابقة، التحويل عبر route target، أو تغيير الوسم. المعدل الصفري يعني الإسقاط.

يفيد ذلك أثناء DDoS لأن القاعدة تصل بسرعة إلى عدد كبير من موجّهات الحافة. لكن الخطأ ينتشر بالسرعة نفسها. يغيّر مسار BGP التقليدي next hop في الغالب، بينما تغيّر FlowSpec معاملة الحزمة مباشرة. كون الرسالة صحيحة نحوياً لا يثبت أن الجار مخول بطلب النتيجة.

يسجل ملف Susan Hares الرسمي في IETF Datatracker مشاركتها الطويلة في المعايير. والدليل المحدد هنا سلسلة قصيرة: نُشر RFC 8955 على Standards Track في ديسمبر 2020 بأسماء Christoph Loibl وSusan Hares وRobert Raszuk وDanny McPherson وMartin Bacher، وألغى RFC 5575 وRFC 7674. ويسمي امتداد IPv6، RFC 8956، كلاً من Loibl وRaszuk وHares محررين.

هذه حصيلة جماعية لـIETF وليست اختراع شخص واحد. يثبت السجل مساهمة Hares في مراجعة المواصفة، ولا يثبت ملكية التقنية أو انتشارها لدى كل مشغل أو نجاحها في حادثة بعينها.

المسار القائم يمنح الصفة

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

يبحث التحقق الافتراضي عن أفضل مسار unicast يغطي بادئة الوجهة. ينبغي أن يطابق منشئ FlowSpec منشئ ذلك المسار. وقد تسقط صلاحية القاعدة عند وجود بادئة أكثر تحديداً من AS مجاور آخر. وفي EBGP تقارن أيضاً قيمة AS الواقعة في الطرف الأيسر من المسارين.

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

وتزول الصفة عند تغير الطريق. يطلب RFC 8955 إعادة تحقق FlowSpec كلما تغير مسار unicast المقابل. قد ينقل origin جديد أو more-specific من peer آخر الأساس إلى جهة مختلفة. الفحص مرة واحدة عند الاستقبال يحوّل الإذن المؤقت إلى امتياز دائم بلا مبرر.

المتحكم المركزي ليس عقدة تمرير

قد يفوض المشغل متحكماً مركزياً داخل شبكته لنشر قواعد التخفيف، مع أنه لا يقع على أفضل forwarding path لكل بادئة. سيرفضه اختبار origin الصارم لأنه يتحكم ولا يمرر.

حدّث RFC 9117 الإجراء في أغسطس 2021. مؤلفوه Jeffrey Uttaro وJorge Alcaide وClarence Filsfils وDavid Smith وPradosh Mohapatra؛ ليست Susan Hares من بينهم. يظهر النص هنا بوصفه تطوراً لاحقاً لحدود RFC 8955.

يبقى التخفيف داخل نطاق إداري محلي واحد. يستطيع المشغل الوثوق صراحة في route controller تابع له من دون اشتراط أن يكون origin لمسار unicast. ويصحح RFC 9117 أيضاً معالجة AS_PATH في حالة route server. لكنه لا يمنح متحكماً بعيداً حقاً عاماً في الترشيح بين النطاقات، ولا يلغي سياسة الشبكة المستقبلة.

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

القبول في control plane ليس النتيجة

يحذر RFC 8955 من ترشيح أو وسم أو تحويل غير مرغوب عند تخفيف التحقق. يمكن للإجراء أن يغير forwarding أو سياق VPN أو queue. وقد يرسل متحكم تالف أو مخترق تحديثات كثيفة، أو يستنفد سعة القواعد، أو يثبت match أوسع مما قصد المشغل.

ينبغي أن تقيد سياسة الاستقبال الإجراءات والبادئات والمنافذ والمعدلات وأهداف التحويل وعدد القواعد لكل peer. ثم يأتي اختبار التنفيذ: قد تقبل BGP القاعدة ولا تصل إلى ACL أو FIB أو ASIC. وقد تُثبت فعلاً لكنها تصيب خدمة غير متوقعة.

كما لا يثبت نشر RFC دعم كل مصنع أو تفعيل الميزة أو تساوي إعدادات الأجهزة أو نجاح التخفيف. يحدد المعيار معنى مشتركاً ودفاعاً افتراضياً؛ أما النتيجة فتثبتها الشبكة العاملة.

لغة مشتركة صغيرة ومسؤولية محلية

يقدم مقال Lu Heng عن Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption إطاراً مفيداً. تشمل الطبقة المشتركة match components وترميز الإجراءات والترتيب والتحقق المرتبط بـunicast. وتبقى لدى الشبكة المحلية قرارات peers والمتحكمات والإجراءات والحدود والتسجيل والسحب.

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

وفق Running-Code Primacy، لا يكفي ظهور القاعدة في جدول BGP. يجب فحص حالة التحقق والترتيب والتثبيت في العتاد والعدادات والأثر الفعلي والسحب والتعافي، واختبار إعادة حساب السلطة عند تغير مسار unicast. هذان المقالان اللاحقان إطار تحليلي تستخدمه Sofia Ren، ولا ينسبان إلى Hares أو مؤلفي RFC.

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

المصادر