الخلاصة

  • حددت RFC 2406 نطاق ESP حقلاً بحقل. أبقى نمط النقل رأس IP الأصلي خارج الحماية، بينما شفّر نمط النفق الرزمة الداخلية وأضاف رأساً خارجياً مرئياً. وظل SPI ورقم التسلسل غير مشفرين في الحالتين.
  • لم تكن السرية والسلامة ومنع الإعادة دليلاً واحداً. أمكن غياب المصادقة أو اختيار تشفير NULL، وكان المستقبل قادراً على تعطيل نافذة الإعادة رغم وجود رقم التسلسل الإلزامي. لذلك لم تثبت الحمولة المشفرة اختفاء علاقة المرور أو تنفيذ فحص الإعادة أو قبول التطبيق.

يحتاج الموجّه إلى عنوان يقرأه، ويحتاج المستقبل إلى SPI يعثر به على رابطة الأمان قبل أن يعرف المفتاح. لهذا تبدأ قصة ESP بما بقي خارج السر: معلومات لا بد من ظهورها كي يصل الجزء المحمي إلى السياق الصحيح.

نشرت RFC 2406 في نوفمبر 1998 بوصفها الجيل الثاني من Encapsulating Security Payload. لم تختزل ESP في عبارة «حزمة مشفرة»، بل عددت مزيجاً من الخدمات: السرية، والتحقق من مصدر البيانات، والسلامة بلا اتصال، ومنع الإعادة، وسرية محدودة لتدفق المرور. حددت رابطة الأمان وموقع التنفيذ أي مزيج يعمل.

كانت RFC 1827 الصادرة عام 1995 أقرب إلى هيكل مفتوح. كان SPI الحقل الإلزامي الوحيد المستقل عن التحويل، وتركت الوثائق الخاصة بالتحويلات الخوارزميات والحقول الإضافية. أوضحت RFC 2406 أن تضخم التركيبات دفع إلى مواصفة أساسية أكمل، فأدخلت رقم التسلسل والحشو وNext Header وAuthentication Data الاختيارية وترتيب المعالجة في القالب المشترك.

لم يحول القالب المشترك الخدمات إلى مفتاح واحد. أمكن اختيار السرية بلا مصادقة ESP، وأمكن اختيار المصادقة مع تشفير NULL بلا سرية. وجب اختيار واحدة منهما على الأقل. أما منع الإعادة فلم يجز إلا مع المصادقة، وكان قرار تفعيله للمستقبل وحده.

بدأ الشكل المنقول برأس IPv4 أو IPv6 خارجي يعلن البروتوكول 50. تبعه SPI من 32 بت ورقم تسلسل من 32 بت، ثم Payload Data والحشو وطوله وNext Header، وأخيراً Authentication Data إذا اختيرت المصادقة.

عند استخدام خوارزميتين منفصلتين، شمل التشفير Payload Data وPadding وPad Length وNext Header. لم يشمل رأس IP الخارجي ولا SPI ولا رقم التسلسل ولا قيمة ICV النهائية. وقد يظهر IV صريح في بداية Payload Data؛ ونبهت الوثيقة إلى أنه غالباً لا يكون مشفراً بذاته، وإن جرت تسميته جزءاً من النص المشفر.

غطت السلامة مساحة مختلفة. عند تفعيلها، شمل ICV حقول SPI وSequence Number والحمولة والحشو وطوله وNext Header، واستثنى Authentication Data الذي يحمل النتيجة. وقع التشفير أولاً، لذلك دخلت حقول الحمولة الحساب بصورتها المشفرة. وبقي رأس IP الخارجي خارج ICV الخاص بـESP.

في نمط النقل، جاء ESP بعد رأس IP الأصلي وقبل بروتوكول الطبقة العليا. ظلت عناوين المصدر والوجهة الأصلية ظاهرة. وفي IPv6 بقيت الرؤوس الإضافية الموضوعة قبل ESP خارج حمايته، بينما أمكن إدخال خيارات الوجهة الموضوعة بعده في النطاق المحمي. صار ترتيب الرؤوس قراراً أمنياً، لا مجرد تركيب نحوي.

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

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

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

إذا فُعّل منع الإعادة وجب تفعيل المصادقة أيضاً، وإلا أمكن تعديل الرقم. جاز للمستقبل إجراء فحص أولي لقيمة قديمة، لكنه لم يحدّث النافذة إلا بعد نجاح ICV. جمع الإثبات الكامل رابطة الأمان الصحيحة والرقم الموثق وحكم النافذة المحلية؛ ولم يحمل السلك إلا جزءاً من هذه السلسلة.

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

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

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

ولم تعن عبارة «قابل للتدقيق» أن سجلاً موجود بالفعل. على النظام الذي يملك تدقيقاً أن يدمج ESP ويتيح التحكم فيه، لكن كل نظام لم يكن ملزماً بتوفير التدقيق، وظلت الدقة محلية. أمكن تسجيل غياب الرابطة أو التجزؤ أو فيضان العداد أو فشل ICV؛ أما حفظ السجل فكان حقيقة تشغيلية منفصلة.

حلت RFC 4303 محل RFC 2406 عام 2005. أبقت الفصل بين الحقول الظاهرة والمنطقة المشفرة والسلامة والنمطين وقرار الإعادة لدى المستقبل، وأضافت أرقاماً موسعة وخوارزميات مركبة وحشواً صريحاً لسرية التدفق. لذلك تمثل وثيقة 1998 مرحلة في تاريخ التصميم لا توصية حالية بالخوارزميات.

تضيف قراءة Lu Heng سؤال المسؤولية: من حوّل قدرة الصيغة إلى أثر جار؟ اختارت السياسة الرابطة، وأرسل المصدر الرقم، واختار المستقبل النافذة، وقرر المشغل ما يُحفظ. لا تكفي عبارة «ESP مفعّل» لمعرفة أي هذه القرارات حدث، ولا ما ظل ظاهراً أو ما قبله التطبيق لاحقاً.

المصادر