RFC 10078: حين يُخلط الوصول بالإذن

الخلاصة

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

يرسل عميل حزمة من عنوان مخوّل باستخدامه. يفحص الموجّه قاعدة معلومات التوجيه (FIB)، فيرى أن البادئة تشير إلى واجهة أخرى أو لا تظهر فيها، فيحجب الحزمة. لقد أجاب الموجّه عن سؤال حقيقي؛ لكنه أجاب عن السؤال الخطأ.

هذه هي الفجوة التي تتناولها RFC 10078، وهي وثيقة معلوماتية نشرها IETF في أكتوبر 2026. تتناول التحقق من عناوين المصدر (SAV) داخل نظام مستقل واحد، على الواجهات الخارجية المواجهة لمضيفين أو شبكات عملاء ليست أنظمة مستقلة مجاورة. ولا يحتاج العميل إلى رقم نظام مستقل خاص به؛ فقد يستخدم بادئات خصصها المشغّل أو مساحة عناوين يملكها.

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

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

تزيد البادئات المخفية المشكلة تعقيداً. فقد يرسل مضيف أو عميل حركة مشروعة من عنوان لا يراه بروتوكول التوجيه الداخلي لدى المشغّل. وتذكر RFC حالة Direct Server Return (DSR): يصل الطلب إلى موقع خدمة anycast، ثم يرد خادم طرفي آخر مباشرة مستخدماً عنوان الخدمة مصدراً للحزمة. وتحدث فجوة مماثلة إذا لم تُعلن بادئات العميل داخل شبكة المشغّل. وإذا غابت البادئة عن FIB فقد يحجب النمطان الحزمة. ويمكن لقائمة التحكم بالوصول تحديد البادئات المسموح بها، لكن على جهة ما رصد تغيّر الإذن وتحديث القاعدة.

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

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