وُقِّعت عملية تبديل المفاتيح كي يقرأها الوسيط

الخلاصة

• تنص RFC 5202 على أن وسيطاً يعتمد SPI يحتاج إلى فحص ESP_INFO أثناء إعادة المفتاح؛ وتحتفظ RFC 7402 بهذا القرار. يحمي HMAC والتوقيع السلامة والمصدر، ولا يحققان السرية.
• ينبغي فصل أدلة تشفير الحمولة، وتوثيق التحكم، ورؤية البيانات الوصفية، وتفعيل SA الجديدة، وانتهاء الاحتفاظ. لا يثبت أي واحد منها البقية.

ما الذي يظهر قبل النص المشفّر

يبدأ التدقيق الدقيق من بنية ESP نفسها. تضع RFC 4303 قيمة SPI ورقم التسلسل قبل الحمولة المشفّرة. يدخل الحقلان في حماية السلامة، لكنهما لا يُشفَّران على السلك. يحتاج المستقبل إلى SPI ليعثر على Security Association المناسبة للحزمة الواردة.

يمنح HIP هذه القيمة وظيفة إضافية: تمثيل مضغوط لزوج من HITs يمكن للأنظمة الوسيطة استعماله في ربط العناوين. غير أن الدلالة مؤقتة ومحلية. يحدد عنوان الوجهة مع SPI سياق HIT المستقبل في لحظة معينة؛ وقد تستعمل أجهزة مختلفة الرقم نفسه، وقد يتغير معنى الزوج لاحقاً.

لهذا لا يصح وصف SPI بأنه مفتاح أو هوية بشرية ثابتة. ولا يصح أيضاً اعتباره ضوضاء عديمة المعنى. إنه إحداثي تشغيلي محدود.

لماذا تُركت ESP_INFO مقروءة

تحمل عملية rekey في ESP_INFO قيمة SPI القديمة والجديدة وفهرس KEYMAT. وتتضمن رسالة UPDATE البادئة SEQ، وربما Diffie–Hellman، وHMAC، وتوقيع HIP. ويعيد الطرف الآخر معلوماته مع ACK.

تشرح RFC 5202 الغرض بلا مواربة: على الأنظمة الوسيطة التي تستخدم SPI أن تفحص رسائل HIP التي تحمل معلومات إعادة المفتاح. وتُوقَّع الحزمة لمصلحتها. ولأنها قد تحتاج قيم SPI الجديدة، لا يمكن تشفير المحتوى. أعادت RFC 7402 النص نفسه حين استبدلت الوثيقة التجريبية بمواصفة Standards Track.

إذن القابلية للقراءة ليست ثغرة منسية. إنها شرط وظيفة. يجعل التوقيع الانتقال المرئي موثوقاً لمن يملك سياق الارتباط؛ أما التشفير فكان سيمنع ذلك القارئ من أداء دوره.

لا يجوز للوحة تشغيل أن تحول توقيع صحيح إلى بيانات وصفية مخفية. كما لا يثبت UPDATE المقروء أن الطرفين ثبّتا SA الجديدة أو أن أي حزمة بيانات نجحت.

مساحة الاستدلال وحدودها

يحمل رأس HIP معرّفي HIT للمرسل والمستقبل، وتصل ESP_INFO القديم بالجديد، وتضيف عناوين IP ونقطة الرصد الزمن والموقع. يستطيع جدار ناري أو NAT واعٍ بـHIP أن يحدّث soft state كما أرادت المواصفة. وتذكر RFC 9063 أن مثل هذه الوسائط قد تراقب الحركة على المسار بصورة سلبية.

تعرّف RFC 6973 تحليل الحركة بأنه استنتاج من الوجود أو الاتجاه أو التوقيت أو الحجم أو التركيب أو التكرار، حتى مع تدفقات مشفّرة. تمثل لحظة تغيير SPI علامة منظمة لهذا النوع من التحليل.

لكن الدليل لا يمنح هوية مدنية تلقائية. لا تكشف القيمة منفردة الشخص أو المؤسسة أو الحمولة. يعتمد الربط الأقوى على سجل HITs والـlocators وأجهزة استشعار أخرى ومدة التخزين. الادعاء الصحيح هو إمكان ربط انتقال زمني، لا معرفة كل مراقب بصاحب الاتصال.

العشوائية تغيّر الرقم ولا تمحو السجل

توصي المواصفتان باختيار SPI عشوائياً، واستخدام قيمة مختلفة لكل exchange جديد مع النظير نفسه، وتلزمان بتغييره عند rekey. تقلل هذه القواعد إعادة الاستخدام وهجمات replay.

إلا أن سجل قديم ← جديد لا يختفي عندما يُختار رقم لاحق. قد تنتهي خريطة الجهاز خلال دقائق، بينما تبقى نسخة pcap أو SIEM أو تذكرة الدعم أو النسخة الاحتياطية أشهراً.

وتوصي RFC 9063 كذلك بتدوير Host Identities غير المنشورة لتعطيل linkability وtrackability. هذه سياسة طرف نهائي وليست أمراً بحذف السجلات من كل وسيط. يجب إدارة أعمار SPI وHIT والدليل على نحو مستقل.

سجل إفصاح قابل للتدقيق

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

يحتفظ إيصال الحدث بنقطة الرصد والاتجاه والـlocators ومرجع HIT محمي والقيمتين وSEQ/ACK ونتيجة HMAC والتوقيع والخوارزميات وإصدار القاعدة والمهلة. ثم تأتي إيصالات منفصلة: تثبيت SA الجديدة في الطرف، أول حزمة موثقة على SPI الجديد، آخر استعمال للقديم، وحذف الحالة.

الحذف نفسه نتيجة تحتاج دليلاً. اختفاء السطر من جدول live لا يثبت حذف الالتقاط الخام أو flow record المشتق أو مرفق التذكرة أو نسخة المعالج الخارجي.

قراءة حالة الوثيقة بدقة

نُشرت RFC 5202 عام 2008 بوصفها Experimental ثم أصبحت obsolete. يصحح erratum محتجز كلمة تتعلق بـtransform parameters ولا يغير موضوع المقال. استبدلتها RFC 7402 عام 2015 لاستخدام ESP مع HIPv2 ضمن Standards Track.

بقاء قاعدة الرؤية في الوثيقة الحالية يثبت أنها ليست بقايا عرضية. وتعرض RFC 6538 وRFC 9063 التوتر الأوسع بين ممارسات خصوصية الهوية ومشاركة middleboxes. لا يُحل التوتر بشعار واحد، بل بحدود صريحة للغرض والاحتفاظ.

قرار القيادة

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

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

المصادر

1. RFC 5202 HTML
2. نص RFC 5202
3. صفحة معلومات RFC 5202
4. IETF Datatracker: RFC 5202
5. تاريخ RFC 5202
6. مراجع RFC 5202
7. تصحيحات RFC 5202
8. RFC 7402 HTML
9. نص RFC 7402
10. صفحة معلومات RFC 7402
11. IETF Datatracker: RFC 7402
12. تاريخ RFC 7402
13. مراجع RFC 7402
14. تصحيحات RFC 7402
15. RFC 4303 — ESP
16. RFC 4301 — بنية IPsec
17. RFC 9063 — بنية HIP
18. RFC 6538 — تقرير تجربة HIP
19. RFC 6973 — اعتبارات الخصوصية
20. Heng Lu — طبقات الواقع والقوة الرمزية
21. Heng Lu — الحد الأدنى للمواصفة الأولية
22. Heng Lu — أولوية الكود الجاري