الملخص

  • تحقّق RFC 2385 من كل مقطع TCP محمي بسر مشترك، وألزم المستقبل بإسقاط المقطع بصمت عند فشل المطابقة.
  • وفّر التنسيق مساحة الخيارات بحذف هوية الخوارزمية والمفتاح؛ لذلك أثبتت البصمة مقطعاً واحداً ضمن إعداد محلي، لا حداثة المفتاح ولا سلطة النظير ولا شرعية المسار.

حين يسقط مقطع صغير جلسة توجيه

اعتمد BGP على TCP للحصول على تدفق مرتب وموثوق. هذا الاعتماد ربطه أيضاً بحالة اتصال TCP. فإذا خمن مهاجم خارج المسار العناوين وأرقام التسلسل بدرجة كافية، أمكنه إرسال RST مزوّر. ينغلق الاتصال، وقد يعيد الراوتر الجلسة أو يسحب مؤقتاً ما تعلمه من مسارات.

أضاف RFC 2385 الخيار Kind 19: بايت للنوع، وبايت للطول، وستة عشر بايتاً لبصمة MD5. شمل الحساب الرأس الزائف لـIPv4، ورأس TCP من دون الخيارات ومع اعتبار checksum صفراً، والبيانات، وسراً يعرفه الطرفان مسبقاً.

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

كان تنبيه IESG صريحاً: هذه ممارسة قائمة ضد بعض الهجمات البسيطة، ولها ضعف أمام هجمات منظمة. لم يوثّق RFC 2385 صحة BGP كله؛ بل ضيّق أي المقاطع يجوز لها دخول آلة حالة TCP.

ما الذي تشهده البصمة؟

تطابق البصمة يعني أن بايتات المقطع، وعناوين الرأس الزائف، والسر الذي اختاره التنفيذ محلياً أعطت النتيجة نفسها. لا يحدد ذلك هوية المشغّل القانونية، ولا يثبت حق AS في إعلان بادئة، ولا يثبت مرور UPDATE بسياسة الاستيراد أو دخوله RIB وFIB أو تسليمه حركة فعلية.

لا يحمل المقطع حتى اسم المفتاح. إذا اختلف سجلا التشغيل حول «المفتاح الحالي»، لا يستطيع السلك حسم الخلاف. يجرّب كل تنفيذ حالته المحلية ويحصل على نجاح أو فشل.

لهذا تبقى مراحل الإرسال، ووجود الخيار، واختيار المفتاح، والتحقق، وقبول TCP، واستمرار BGP، وقبول UPDATE، وتثبيت المسار، والتسليم إيصالات مستقلة. تغطي البصمة الجزء الأول فقط.

سياسة لا تفاوض عليها

لم يتفاوض TCP على استخدام الخيار. قررت سياسة الموقع والتطبيق ذلك. إذا غاب التوقيع عن SYN/ACK، لم يكن على المرسل المحمي أن يتراجع؛ يتجاهل الرد ولا ينشئ الاتصال. لم يمنح الطرف غير الموثّق سلطة تعطيل المتطلب المحلي.

لكن الاتفاق الفعلي على السر ووقت التفعيل بقي خارج الحزم. لم توجد KeyID. سمح النص بتغيير كلمة المرور أثناء الاتصال إذا تزامن الطرفان، ثم حذر من إعادة الإرسال: قد يصل مقطع صُنع بالمفتاح القديم بعدما انتقل المستقبل إلى الجديد. لا يخبر المقطع إلى أي حقبة ينتمي.

كانت معادلة التحقق حتمية، أما المدخل الذي يسمي «الحالة الحالية» فلم يكن حالة مشتركة قابلة للنقل.

بايت لم يُكتب

لا يتجاوز رأس TCP الكامل 60 بايتاً. بعد العشرين الثابتة، تتقاسم الخيارات أربعين بايتاً فقط. استهلك خيار MD5 ثمانية عشر بايتاً. وفي مثال RFC ملأت MSS وتوسعة النافذة والطابع الزمني وMD5 والحشو الحيز كله.

كانت مخاوف تصادم MD5 معروفة، لكن التنسيق المنشور والمطبق لم يتضمن نوع الخوارزمية. أوضح RFC أن إضافة بايت واحد تجعل الخيار 19 بايتاً، وغالباً 20 بعد المحاذاة. بدت بايتان فعليتان ثمناً مرتفعاً ضمن ميزانية أربعين.

سهّل القرار تشغيل الدفاع فوراً، لكنه حذف قدرة Kind 19 على تسمية بديل. احتاج تغيير الخوارزمية إلى خيار جديد وعقد توافق جديد. صححت Errata 4432 عبارة «كلمات من 32 بايت» إلى «32 بت». وصحح RFC 6691 حساب MSS: ينقص المرسل طول بياناته بحسب الخيارات الفعلية. لم يُعد أي تصحيح محدد الخوارزمية المفقود.

عمر المفتاح ظهر في العمليات

أوصى RFC 3562 بمفاتيح من 12 إلى 24 بايتاً، وبالحد من مشاركتها بين علاقات BGP، وبتغييرها كل 90 يوماً على الأقل. هكذا ظهر العمل الذي لم يحمله الخيار. يمكن تخمين سر قصير، وتوسّع إعادة الاستخدام أثر التسريب، ويقطع التبديل غير المتزامن جلسة سليمة.

استبدل RFC 5925 آلية TCP MD5 بخيار TCP-AO. أضاف خوارزميات قابلة للتوسعة، وKeyID، وإشارة للمفتاح التالي، واشتقاقاً خاصاً بالاتصال، وحماية من الإعادة. لكنه لم يوزع المفتاح الرئيسي ولم يمنح شرعية لمسار BGP.

توجد في سجل BTW مقالة أخرى عن حقبة مفاتيح TCP-AO. لا تكرر هذه المقالة ذلك الموضوع. حد RFC 2385 أسبق: استطاع المقطع أن يقول «يناسب حالتنا المشتركة»، ولم يستطع أن يسمي أي حالة قابلة للاستبدال يقصد.

الحد التاريخي الصحيح

لم يكن RFC 2385 عديم القيمة لأنه أُبطل لاحقاً. واجه مشكلة محددة بما كان متاحاً سنة 1998، وحافظ على سلطة المشغل في رفض التراجع. كانت فائدته نابعة من ضيق ادعائه.

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

حمى RFC 2385 المقطع. وبسبب غياب المحدد، احتاج استبدال الخوارزمية لاحقاً إلى سطح بروتوكولي جديد.

المصادر