المترجم الذي غيّر الاتصال الموثَّق: TCP-AO وNAT

الخلاصة

• يمكن لوسيط يغيّر خيارات TCP فقط أن يتعايش مع TCP-AO إذا استبعد الطرفان جميع الخيارات غير الخاصة بـ TCP-AO من حساب MAC.
• يغيّر NAT أو NAPT العناوين أو المنافذ، وهي جزء من هوية الاتصال التي يوثّقها TCP-AO؛ لذلك لا يكفي مفتاح تغطية الخيارات.

ليست كل التغييرات متساوية

يتحكم علم Master Key Tuple في إدخال خيارات TCP الأخرى في حساب MAC. عند تفعيله تُحمى جميعها بترتيب الإرسال، وعند تعطيله تُستبعد كلها، بينما يبقى TCP-AO نفسه مشمولاً. يتيح ذلك التعامل مع جهاز يغيّر خياراً مثل الطابع الزمني، لكنه يضعف الحماية: فقد يتغير الطابع الزمني أو مقياس النافذة، بما يؤثر في الكفاءة أو التشغيل الصحيح.

أما عناوين IP ومنافذ TCP فليست اختيارية. يوضح RFC 5925 أنها تحدد الاتصال، ولذلك لا يمكن إلغاء تغطيتها. إذا غيّر المترجم tuple الاتصال، حسب الطرفان MAC لهويتين مختلفتين. ومن ثم لا يستطيع TCP-AO العمل أصلاً عبر NAT/NAPT غير المنسق.

يشير RFC إلى تنسيق القيم، أو التغليف، أو IPsec مع اجتياز NAT كبدائل ممكنة. لكنه لا يحدد بروتوكولاً أصلياً موحداً لاجتياز NAT ولا يفرض نفقاً بعينه.

حد يجب إثباته

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

المصادر

• RFC 5925 — The TCP Authentication Option