الخلاصة

  • يتيح RFC 5201 وخليفته RFC 7401 للمستجيب اختيار R1 محسوبة مسبقاً بعد I1 والبقاء بلا حالة خاصة بالارتباط؛ يثبت التوقيع أن المفتاح أنشأ المادة في وقت ما، لا أنه حي الآن أو حجز مورداً.
  • قبول I2، والتحقق من R2، وتركيب ارتباط الحمولة، ومشاهدة تبادل تطبيقي محمي، درجات مختلفة من الدليل ولا يجوز أن تحل إحداها محل التالية.

رد بلا ذاكرة هو خاصية دفاعية

يتكون التبادل الأساسي في HIP من I1 وR1 وI2 وR2. تبدأ I1 العملية. تحمل R1 اللغز ومادة Diffie–Hellman وخيارات المستجيب وتوقيعه. تعيد I2 الحل ومساهمة المبادر الموثقة. وتكمل R2 التبادل.

لا يلزم أن يبدأ المستجيب بإنشاء جلسة عند I1. يمكنه إعداد مجموعة من حزم R1 مسبقاً، ثم اختيار واحدة استناداً إلى I1 وإرسالها من دون تخصيص حالة لذلك المبادر. يوضح رسم RFC 5201 أن المستجيب يظل stateless، ويحافظ RFC 7401 على السلوك نفسه في HIPv2.

الغاية مقاومة حجب الخدمة. لو فرضت كل I1 مزورة حجز ذاكرة أو تحققاً مكلفاً من توقيع أو حساب DH، لدفع المستجيب كلفة غير متناسبة. تؤجل R1 المحسوبة مسبقاً الالتزام المكلف حتى تصل I2 يمكن اختبارها.

لذلك فإن غياب سجل جلسة بعد R1 ليس بالضرورة فجوة في السجلات. قد يكون دليلاً على أن المسار المقاوم للهجوم عمل كما صُمم.

ماذا يؤرخ التوقيع فعلاً؟

يثبت توقيع R1 أن مفتاح Host Identity للمستجيب أنشأ الأجزاء المشمولة. تصوغ الوثيقتان النتيجة بدقة: أنشأ المستجيب R1 في وقت سابق. وبما أنها قد تكون محسوبة مسبقاً ولا تغطي كل المعلومات الخاصة بـI1، فإنها لا تمنع إعادة الإرسال وحدها.

وقت الاستلام المحلي يخص الراصد. لا يثبت وقت إنشاء R1، ولا وقت معالجة I1 المحددة، ولا وقت إنشاء ارتباط. تحويله إلى «حيوية النظير الآن» يضيف ساعة ليست داخل الدليل.

يساعد R1 generation counter المبادر على تفضيل جيل أحدث من الألغاز، لكنه ليس وقتاً عالمياً. يناقش HIPv2 حفظ العداد وفقده وإعادة ضبطه، ويُبقي قرار عدم وضع timestamp في R1 لتجنب الاعتماد على تزامن الساعات. لا يجوز للوحة المراقبة تحويل رقم الجيل إلى عمر بالثواني.

ينبغي أن يحفظ الإيصال HIT، ونتيجة التوقيع، والخوارزميات، والجيل، وعمر اللغز وصعوبته، والقيمة opaque، والوقت الرتيب المحلي. وإذا استُنتجت الحداثة فيجب تسجيل قاعدة الاستنتاج وحدودها.

حل اللغز يثبت إنفاق حساب لا استحقاق خدمة

يبحث المبادر عن قيمة J تجعل تجزئة التحدي I وHIT للطرفين وJ تحقق العدد المطلوب من البتات الصفرية. يتحقق المستجيب بتجزئة واحدة، فيرفض I2 السيئة قبل التحقق بالمفتاح العام وحساب السر المشترك.

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

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

عند I2 يبدأ أثر قرار المستجيب

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

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

تُربط الإيصالات بواسطة HIT والجيل والمعلمات والبصمات، لا بادعاء أن ساعتي الجهازين متطابقتان. وإذا ظهرت R1 صحيحة بلا جلسة لاحقة، فقد تكون I2 لم تصل أو انتهت صلاحيتها أو فشل اللغز أو التوقيع؛ وكلها نتائج طبيعية.

اكتمال HIP لا يعني أن بيانات المستخدم عبرت

ينشئ التبادل الأساسي حالة HIP ومادة مفاتيح، لكنه لا يحدد تنسيق نقل بيانات المستخدم. يحيل RFC 7401 ذلك إلى مواصفات منفصلة ويطلب دعماً لا يقل عن نقل ESP في RFC 7402. وفي وصف الاسترداد، يميز بين اكتمال التبادل، ثم إنشاء payload association جديدة، ثم بدء إرسال البيانات.

التحقق من R2 لا يثبت تركيب ESP Security Association في الطرفين. وجود SA محلية لا يثبت التناظر. إرسال حزمة محمية لا يثبت وصولها، ووصولها إلى الشبكة لا يثبت قبول التطبيق.

لإثبات جاهزية المسار، يلزم تسجيل النقل المتفاوض عليه، والخوارزميات، والـlocators، وحقبة المفتاح، ومعرفات الارتباط المحمية، ونتيجة التركيب عند الطرفين، وأول حزمة موثقة في كل اتجاه. ولإثبات الخدمة، يلزم رد تطبيقي آمن ومحدد.

سلم أدلة بدلاً من مصباح أخضر

الملاحظة ما تثبته ما لا تثبته بعد
إرسال I1 أصدر المبادر المحفز استلمه المستجيب
صحة توقيع R1 أنشأ مفتاح المستجيب المادة في وقت ما الحيوية الحالية أو الحجز
حل اللغز نُفذ العمل المطلوب قبله المستجيب
قبول I2 أُنشئت حالة HIP بسياسة معلومة وصلت R2 إلى المبادر
التحقق من R2 اكتمل التبادل الأساسي من ذلك الطرف أصبح مسار الحمولة عاملاً
تركيب SA للحمولة توجد حالة نقل مسماة نجح التطبيق في الاتجاهين
طلب ورد محميان وقع أثر خدمة محدود ستستمر الإتاحة

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

الوثيقة التاريخية وحدودها الحالية

صدر RFC 5201 في أبريل 2008 بصفة Experimental، وينص على أنه لا يحدد Internet Standard. أثارت ملاحظة IESG مسائل SHA-1 ومرونة MAC وخيارات RSA والسياسات المرتبطة بعنوان IP. ثم حدّث RFC 6253 جانب الشهادات.

أبطل RFC 7401 الوثيقة في 2015، وأضاف خبرة التنفيذ والمرونة التشفيرية ونشر HIPv2 كـProposed Standard. وجاء RFC 8002 وRFC 9374 بتحديثات لاحقة. لا ينبغي تقديم خوارزميات 2008 كخيار نشر حالي.

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

المصادر

  1. RFC 5201 بصيغة HTML
  2. نص RFC 5201
  3. صفحة معلومات RFC 5201
  4. Datatracker لـRFC 5201
  5. تاريخ RFC 5201
  6. مراجع RFC 5201
  7. تصويبات RFC 5201
  8. RFC 7401 — HIPv2
  9. نص RFC 7401
  10. صفحة معلومات RFC 7401
  11. تصويبات RFC 7401
  12. RFC 7402 — نقل ESP لـHIP
  13. RFC 4423 — معمارية HIP
  14. RFC 4987 — مواجهة إغراق SYN
  15. RFC 6253 — شهادات HIP
  16. RFC 8002 — شهادات HIPv2
  17. RFC 9374 — DRIP Entity Tag
  18. Heng Lu — طبقات الواقع والقوة الرمزية
  19. Heng Lu — الحد الأدنى للمواصفة الابتدائية
  20. Heng Lu — أولوية الشيفرة العاملة