الخلاصة

  • وزع RFC 2411 مواصفات IPsec على سبع مجموعات حتى لا تعيد وثائق الخوارزميات كتابة قواعد ESP وAH والقيم المسجلة وإدارة المفاتيح بصيغ متباعدة.
  • كانت الخريطة وثيقة معلوماتية تحدد مكان البحث عن القاعدة، ولا تثبت أي إصدار نُفذ أو أي اقتراح اتفق عليه الطرفان أو أي SA ثُبتت أو أي نتيجة وصلت إلى التطبيق.

الفهرس الجيد يمنع القارئ من البحث في المكان الخطأ. لكنه لا يخبره بما فعلته الآلة.

هذه هي المسافة التي نظمها RFC 2411 في نوفمبر 1998. كان IPsec قد أصبح عائلة: معمارية عامة، ESP، AH، وثائق للتشفير والمصادقة، مجال تفسير يحمل القيم المشتركة، ووثائق لإنشاء المفاتيح وإدارتها. وكان من المتوقع أن تصل خوارزميات جديدة بعد استقرار الوثائق الأساسية.

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

سمى RFC 2411 ذلك خطر «انفجار المسودات». ولم يعالجه بوثيقة مركزية أضخم، بل بحدود مسؤولية أضيق.

تحتفظ وثيقة المعمارية بالمفاهيم العامة ومتطلبات الأمن والآليات المشتركة. يحتفظ ESP وAH بتنسيق الحزمة والمعالجة العامة الخاصة بكل منهما. تشرح وثيقة التشفير كيف ترتبط خوارزمية بعينها بـ ESP. وتشرح وثيقة مصادقة واحدة السلوك المشترك بين ESP وAH حين يكون واحدًا. يحمل DOI الأرقام والمعلمات التي تحتاجها الأجزاء كي تشير إلى بعضها. أما وثائق إدارة المفاتيح فتملك إنشاء المادة المفتاحية وتدبيرها.

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

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

ثم يتوقف التوحيد عند الحد الذي لا يحتاجه الطرف الآخر.

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

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

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

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

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

لم تختبر الخريطة أيًا من ذلك. طلبت من الوثيقة الأقرب إلى الآلية أن تجعل الاختبار ممكنًا.

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

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

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

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

الملخص الموثوق يعلن موضعه الأدنى من المصدر.

وسجل RFC 6071 واقعين لم يكونا متطابقين. أبطل IPsec الجديد القديم، لكن القديم ظل شائعًا في التطبيقات. حل IKEv2 محل IKEv1، لكن IKEv1 بقي في التشغيل. «مبطل» علاقة بين وثائق؛ لا يحذف برنامجًا من جهاز بعيد. و«يعمل الآن» وصف لجرد ميداني؛ لا يعيد للخوارزمية توصية فقدتها.

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

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

يواصل RFC 8221 هذا المنطق بفصل متطلبات الخوارزميات وإرشادات استعمالها عن تنسيق ESP وAH. ويحافظ سجل IANA على أرقام ثابتة حتى تتخاطب الآلات دون غموض، لكنه لا يحول التسجيل إلى توصية أو تفعيل أو اختيار. ثم استطاع RFC 9395 إهمال IKEv1 وخوارزميات قديمة دون محو السجل التاريخي الذي يفسر وجودها في الأنظمة.

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

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

رسم RFC 2411 خريطة القواعد. وبقيت الحقيقة التشغيلية خارج الورقة، في الأجهزة التي كان عليها تنفيذها.

المصادر