إعادة الضبط التي تعذّر الوثوق بها: TCP-AO بعد إعادة تشغيل النظير

الملخص

• يستطيع TCP-AO توثيق إعادة الضبط ما دام الطرفان يحتفظان بحالة الاتصال ومفاتيح حركة المرور التشفيرية الخاصة به.
• بعد إعادة التشغيل، تُرفض إعادة الضبط التي لا يمكن التحقق منها؛ وتُترك إزالة الحالة القديمة لآليات الحيوية أو لتعافي التطبيق.

إعادة التشغيل تخلق حالة اتصال غير متناظرة

قبل العطل، يعرف الطرفان اتصال TCP وأرقام التسلسل الابتدائية والمفاتيح المشتقة لذلك الاتصال. لذلك يمكن قبول إعادة ضبط تحمل مُوثِّقاً صالحاً.

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

يقول طرف إن الاتصال لم يعد موجوداً، بينما يحتفظ الطرف الآخر بالاتصال القديم من دون دليل يمكنه قبوله.

لماذا يجب رفض إعادة الضبط الصادقة

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

والثمن هو بطء التنظيف. قد يحتفظ الطرف الباقي بالحالة القديمة حتى يقرر، بواسطة آليات الحيوية الخاصة به، أن الاتصال لم يعد يتقدم. توصي RFC 5925 باستخدام keepalive في TCP أو في بروتوكول التطبيق، كما تطلب أن تتمكن تنفيذات TCP-AO من رصد التراكم المفرط للاتصالات ومسحه لحماية الذاكرة.

المصادر

• RFC 5925 — The TCP Authentication Option