الخلاصة

  • يفحص GTSM قرب الحزمة عبر TTL في IPv4 أو Hop Limit في IPv6؛ ولا يصادق على المرسل ولا يستبدل الحماية التشفيرية لجلسة TCP الخاصة بـBGP.
  • تعتمد دلالة النجاح على نطاق القفزات المرخص، وترشيح الدخول، والثقة في الجار المباشر، وسلوك الأنفاق.
  • يتطلب ضمان النظير إيصالا موحدا يربط قيمة القفزة والواجهة والنفق والجار المعتمد وحالة مفتاح TCP-AO ودليل الجلسة بمالك كل تحكم.

نُقل الربط الفيزيائي للتو. لا يزال موجها BGP يرسلان حزم التحكم بقيمة TTL تساوي 255، وتجتاز كل حزمة مستلمة فحص GTSM. لذلك يعلن سجل التغيير أن النظير البعيد قد خضع للمصادقة.

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

يضع RFC 4271 بروتوكول BGP فوق TCP. ينشئ نظامان اتصال TCP ثم يتبادلان رسائل BGP. وهنا أربعة أسئلة مستقلة: هل وصلت حزمة IP من مسافة معقولة؟ هل ينتمي مقطع TCP إلى الاتصال المحمي؟ هل قبل الجار المضبوط الجلسة؟ وهل ما زالت المؤسسة التي تدير ذلك الجار مخولة بتبادل المسارات؟ لا تجيب إشارة خضراء واحدة عنها كلها.

يبني RFC 5082 آلية GTSM على فرق بسيط. يرسل النظير المتصل مباشرة بالقيمة القصوى 255. وكل موجه يمرر الحزمة يخفض القيمة؛ ومن ثم يستطيع المستقبل الذي ينتظر 255 رفض حركة يُحتمل أنها نشأت من مكان أبعد. وعندما يحدث التصنيف قرب العتاد السريع، يمنع أيضا الحزم المزورة من استهلاك موارد مستوى التحكم النادرة.

هذه حماية مفيدة: فهي تضيق سطح الهجوم وتقدم اختبارا طوبولوجيا قليل التكلفة قبل المعالجة المكلفة. لذلك يوصي RFC 7454 بأمن TTL لجلسات BGP المتصلة مباشرة.

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

يزيد التشغيل متعدد القفزات هذا الفرق وضوحا. يمكن قبول نطاق TTL مضبوط لجلسة loopback أو multihop بدلا من قفزة واحدة. وقد يكون ذلك التصميم الصحيح، لكن كل قفزة إضافية توسع مجموعة الأماكن التي يمكن أن تأتي منها حزمة مقبولة. وقد يتغير معنى العتبة بتغير الطوبولوجيا من دون أن يتغير الرقم.

تضيف الأنفاق غموضا آخر. يعالج RFC 5082 حالات IP وMPLS متعددة لأن TTL الداخلي الذي يراه النظير يعتمد على التغليف ونمط الانتشار وما إذا كانت نقطة فك التغليف هي نفسها نهاية البروتوكول. لذلك تصبح سلامة النفق ونقطة انتهائه جزءا من الدليل. قد يكشف إنذار GTSM بعد الهجرة مسارا جديدا؛ لكن النجاح لا يصادق على النفق.

تجيب المصادقة التشفيرية لمقاطع TCP عن سؤال مختلف. يعرّف RFC 5925 خيار TCP-AO للاتصالات الطويلة مثل BGP. فهو يحسب رمز مصادقة على مادة مرتبطة بالاتصال باستخدام مجموعات مفاتيح رئيسية مدارة ومفاتيح حركة خاصة بالاتصال. وتحمي امتدادات أرقام التسلسل من إعادة الإرسال عند التفاف فضاء تسلسل TCP. النتيجة الصالحة تدعم أن المقطع صدر عن حامل مادة مفتاح مقبولة لذلك الاتصال.

ولا يلغي TCP-AO الحوكمة. يجب ربط المفتاح بعلاقة النظير وتثبيته في الطرفين وتحديد مدة صلاحيته وتنسيق تدويره وحذف المادة القديمة. وقد يكون MAC صالحا تحت مفتاح كان ينبغي سحبه صحيحا تشفيريا لكنه غير مخول تشغيليا. كذلك لا يجوز ترقية نجاح GTSM مع غياب TCP-AO أو فشله إلى إثبات هوية.

تقوى الضوابط معا لأنها تفشل بطرق مختلفة. يرشح GTSM الحركة البعيدة غير المعقولة مبكرا، ويقلل ترشيح الدخول تزوير المصدر، ويصادق TCP-AO على المقاطع، ويربط إعداد جار BGP الجلسة بعلاقة التوجيه المقصودة. ولا ينبغي لأي منها استعارة اسم الآخر.

المصادر