الخلاصة

  • تمر رسالة Source-Active عبر جلسة بين نظيرين، ويمكن حماية هذه الجلسة بمفتاح متفق عليه. هذا يربط البايتات بعلاقة النظير المتوقعة، ولا يثبت أن المصدر المعلن حقيقي أو مخوّل أو ما زال نشطاً.
  • بعد قبول الرسالة تبقى طبقات مستقلة: قرار peer-RPF، سياسة المصدر والمجموعة، الذاكرة المؤقتة، اهتمام المستقبِلين، بناء شجرة PIM، وصول الحزم وقبول التطبيق للمحتوى.

كان السر بين جهازين فقط

تنجح جلسة MSDP المحمية بالمفتاح. تصل رسالة SA من عنوان النظير المعروف، ولا يظهر خطأ في التوقيع أو في تنسيق TLV. يمكن للمشغّل أن يقول بثقة إن الرسالة عبرت الاتصال الذي يملك الطرف الآخر سره المتوقع. لا يستطيع بعد أن يقول إن عنوان المصدر داخل الرسالة يخص مرسلاً مخوّلاً.

نُشر RFC 3618 في أكتوبر 2003 بصفة Experimental، لا كمعيار إنترنت. يصف بروتوكولاً لـ IPv4 يربط نطاقات PIM-SM. عندما يعرف RP بمصدر جديد، مثلاً من PIM Register، ينشئ رسالة Source-Active تحمل عنوان المصدر والمجموعة وعنوان RP. تنتقل الرسالة بين النظراء، وقد يبدأ RP في نطاق مستقبِل عملية Join إذا وجد اهتماماً محلياً بالمجموعة.

الرسالة إذن شهادة صادرة عن RP عن ملاحظة محلية. مصادقة الاتصال تحدد من سلّم الشهادة إلى النظير التالي. لا تفحص الجهاز الذي بدأ البث، ولا العقد الذي يمنحه الحق في المجموعة، ولا النتيجة عند المستقبِل.

هذه ليست ثغرة لغوية صغيرة. إنها الحد الفاصل بين هوية ناقل الادعاء وسلطة موضوع الادعاء.

peer-RPF أضاف مساراً مقبولاً لا حقيقة جديدة

بعد استلام SA يشغّل النظير خوارزمية peer-RPF. يقارن عنوان RP الموجود في الرسالة بالنظير الذي جاءت منه، ويستخدم MRIB وقواعد مرتبة لاختيار الجار الواقع في الاتجاه المقبول نحو RP. تُقبل الرسالة من ذلك الجار وتُرفض من غيره.

هذه الآلية تحد من دوران الإعلان أثناء flood-and-join. وهي لا تعيد فحص المصدر. قد تمر رسالة صحيحة المسار تحمل ملاحظة قديمة أو سياسة خاطئة. وقد تُرفض نسخة عن مصدر حقيقي لأنها جاءت بعد تغير في BGP أو IGP أو من عنوان جلسة لا يتوافق مع الحساب المحلي.

يوضح RFC 4611 أن بعض البنى تستخدم default peer أو نظيراً وحيداً أو mesh-group أو اختياراً مبنياً على IGP، وقد تتجاوز فحص BGP المعتاد. عندئذ تصبح قاعدة الإعداد هي السلطة المباشرة. المصادقة تقول إن النظير الافتراضي هو الطرف المكوّن؛ لا تقول إن كل (S,G) يرسله مسموح.

لذلك يجب أن يسجل الإيصال نوع القرار: اتصال مصادق، مسار peer-RPF، استثناء ثابت، default peer، حدود السياسة وصاحب الإعداد. عبارة «SA authenticated» وحدها تمزج سلطات مختلفة.

قد يكون النظير صادقاً ومخطئاً

خيار TCP MD5 في RFC 2385 صُمم لحماية اتصالات BGP واستُخدم هنا لعلاقة MSDP. يطلب RFC 3618 أن تدعمه التطبيقات، وأن تستطيع أيضاً العمل مع نظراء لا يستخدمونه؛ وإذا اختلف إعداد الطرفين فلا ينبغي إنشاء الاتصال. حلّل RFC 6952 لاحقاً مشكلات المفاتيح والمصادقة في MSDP وبروتوكولات توجيه أخرى.

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

المصادقة لا تمنح الرسالة معرفة لم يجمعها الطرف البعيد. إنها تحمي سلسلة النقل ضمن نطاق محدد. ومن الخطر تحويلها إلى ختم عام على معنى الحقول.

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

الفلاتر كانت قرار التفويض الحقيقي

يوصي RFC 3618 بمرشحات لعناوين المصادر والمجموعات، وحد أعلى لعدد إدخالات SA-state، وحد لمعدل إنشاء الحالة. الهدف هو تقليل انفجار الحالة وهجمات الحرمان من الخدمة. وتعرض نماذج الإدارة في RFC 4624 وRFC 8916 النظراء والعدادات والذاكرة والمرشحات والحدود.

هذه الأدوات هي المكان الذي يعبّر فيه النطاق عن سلطته المحلية. يمكنه رفض مجموعة خارج نطاق إداري، تقييد مصادر نظير معين أو حماية ذاكرته. لكن filter pass لا يثبت أن المصدر مخوّل في نظام أعلى، وfilter drop لا يثبت أن المصدر عدائي.

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

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

cache حفظ الادعاء بعد لحظة المصادقة

يجب على متكلم MSDP تخزين رسائل SA. يعيد RP الأصلي الإعلان دورياً كل 60 ثانية ما دام يعد المصدر نشطاً، ويُستحسن إرسال الرسائل المخزنة عند قيام اتصال جديد. لكل إدخال مؤقت حالة يجدد بوصول SA آخر.

قد تصل بعد تدوير المفتاح أو إعادة الاتصال رسالة قديمة محفوظة. إثبات أن الجلسة الجديدة مصادق عليها لا يجعل الملاحظة القديمة جديدة. يجب الاحتفاظ بوقت الرصد الأصلي، ووقت إنشاء الرسالة، ووقت كل استقبال وسبب الإرسال: إعلان أول، إعلان دوري أو replay من cache.

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

والغياب بعد انتهاء المؤقت ليس حكماً على المصدر أيضاً. قد تكون الجلسة أو المسار أو المرشح قد منع التجديد.

المستقبِل لم يكن طرفاً في المفتاح

بعد قبول SA يبحث RP المحلي عن اهتمام (*,G). إذا وجد مستقبِلين، يطلق Join نحو المصدر. تبني PIM شجرة، ثم تصل الحزم إلى النطاق وقد تُسلّم إلى المضيف والتطبيق.

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

يمكن لرسالة SA أن تتضمن حزمة IPv4 اختيارية كي يصل burst صغير قبل اكتمال الشجرة. هذا يقدم عينة بيانات، لا تفويضاً دائماً ولا إثباتاً لمسار لاحق. يجب تسجيل الحزمة المغلفة منفصلة عن الحزم القادمة عبر الشجرة.

سلسلة الإثبات الكاملة تبدأ من الملاحظة المحلية في DR/RP، ثم SA، وهوية النظير، وpeer-RPF، والسياسة، وcache، واهتمام المستقبِل، وJoin، وحالة الشجرة، والحزمة ونتيجة التطبيق. لا يجوز للمفتاح أن يختصرها.

Anycast وmesh زادا عدد الشهود

يستخدم Anycast RP في RFC 3446 MSDP لمشاركة حالة المصادر بين عدة RPs تقدم عنوان خدمة واحداً. مع ذلك يجب أن تحمل SA عنوان RP فردياً، لا عنوان anycast، حتى يعمل peer-RPF وتبقى المنشأ قابلاً للنسبة.

وفي mesh-group يمتنع العضو عن إعادة SA إلى أعضاء المجموعة لأنه يفترض أن المنشئ أرسلها إلى الجميع. يلزم لذلك full mesh. جلسة مفقودة قد تجعل RP واحداً بلا معرفة بينما تظل الجلسات الأخرى مصادقاً عليها وسليمة.

زيادة عدد العلاقات الموثقة لا تنتج تلقائياً حقيقة مشتركة. يجب مقارنة caches وسياسات المرشحات وإصدارات المفاتيح بين كل RP. عنوان anycast القابل للوصول لا يثبت التزامن، واسم mesh-group لا يثبت اكتمال الحواف.

التفويض يحتاج نهاية قابلة للإبطال

قرار قبول نظير أو مصدر يجب أن يتضمن طريقة سحبه. عند انتهاء مفتاح، تغير مالك نطاق، تضييق مجموعة أو توقف مصدر، ينبغي معرفة أي SA بقي في cache وأي Join أو حالة PIM اشتُقت منه. حذف السر وحده لا يمحو كل الأثر.

الخطر من الدرجة الثانية هو انتشار ادعاء مصادق لكنه قديم إلى عدة RPs. الخطر من الدرجة الثالثة هو أن يستخدم التحقيق صحة المفاتيح بديلاً عن سجل المصدر والنتيجة. أما الخطر غير القابل للعكس فهو تغيير واسع يفقد الربط بين الادعاء والقاعدة والآثار التي يجب سحبها.

قدم RFC 3618 حماية مهمة لعلاقة التحكم، وحدد وسائل لاحتواء الحالة. لم يمنح المفتاح حقاً للمصدر، ولم يجعل SA إيصال تسليم. أثبت السر من تحدث إلى النظير؛ وبقي على الشبكة أن تثبت لماذا صدقته، وما الذي فعلته، وما الذي وصل فعلاً.

Sources