Host Identity Protocol RFC 7401: دروس لعناوين IPvX

يُعد Host Identity Protocol RFC 7401 مفيدًا لنا بوصفه مثالًا منشورًا من IETF لبروتوكول يفصل دور المعرّف عن دور محدِّد الموقع في عناوين IP، وينشئ حالة مشتركة على مستوى IP بين المضيفين المتوافقين.² يستخدم HIP معرّفات مفاتيح عامة من فضاء Host Identity للمصادقة المتبادلة بين المشاركين، ويستند إلى تبادل Diffie-Hellman.² وعند تصميم عناوين IPvX، لا يمثل ذلك مخططًا جاهزًا، بل مجموعة من الأسئلة المعمارية التي سبق أن صيغت صراحةً في وثائق IETF الخاصة بـ HIP.¹

لماذا يُعد الفصل بين المعرّف ومحدِّد الموقع مهمًا

يصف RFC 7401 بروتوكول HIP بوصفه بديلًا للاستخدام المزدوج لعناوين IP: إذ يمكن لعناوين IP أن تؤدي دور locators، أي علامات توجيه، ودور identifiers، أي معرّفات للمضيفين أو نقاط النهاية.³ في HIP، تُستخدم المفاتيح التشفيرية العامة من زوج public/private key كمعرّفات للمضيفين، وترتبط بروتوكولات المستويات الأعلى بهذه المعرّفات بدلًا من ارتباطها بعنوان IP.³

يصوغ RFC 9063 المشكلة نفسها على نحو أوسع: لدى الإنترنت فضاءان عالميان مهمان للأسماء، هما عناوين IP وأسماء DNS، وقد أصبح كلا الفضاءين مثقلًا دلاليًا بسبب محاولة القيام بأمور كثيرة جدًا بهما.¹ في معمارية HIP، يُضاف فضاء Host Identity بين فضاءي IP وDNS، وتقع طبقة البروتوكول المقابلة بين طبقتي internetworking وtransport layers.¹

بالنسبة إلى IPvX، نستخلص من ذلك درسًا حذرًا: لا ينبغي للعنونة بالمفاتيح أن تخلط تلقائيًا بين الهوية التشفيرية، وتمثيل هذه الهوية في الحزم، ومسار التسليم الحالي.³ هذه هي بالضبط قراءتنا التصميمية لـ HIP، وليست مطلبًا يفرضه RFC 7401 على IPvX.³

المفتاح والهوية والوسم المدمج كيانات مختلفة

يميّز RFC 9063 بين Host Identity وHost Identifier: تشير Identity إلى الكيان المجرد الذي يجري تعريفه، أما Identifier فهو النمط البِتي المحدد المستخدم في عملية التعريف.¹ وفي الحالة المحورية لمعمارية HIP، يكون Host Identifier هو المفتاح العام لزوج غير متماثل.¹

يعرّف HIP أيضًا Host Identity Tag، أو HIT، بوصفه قيمة بطول 128 بت تُستخرج عبر التجزئة التشفيرية لـ Host Identifier مع إضافة بتات تشير إلى التجزئة المستخدمة.¹ ووفق مصطلحات RFC 9063، فإن Host Identity Hash هي التجزئة التشفيرية المستخدمة عند إنشاء HIT من Host Identifier.¹ وتعرّف الوثيقة أيضًا Local Scope Identifier بوصفه قيمة بطول 32 بت تدل على Host Identity ضمن نطاق محلي.¹

تمنحنا هذه التعريفات انضباطًا مفيدًا في المفردات عند الحديث عن IPvX: فـ«المفتاح» و«الهوية المجردة» و«الوسم المدمج» و«معرّف النطاق المحلي» ليست مفهومًا واحدًا في HIP.¹ ويمكننا استخدام هذا الانضباط عند وصف عناوين IPvX، لكن لا ينبغي أن نقدمه على أنه توجيه مباشر من RFC 9063 إلى IPvX.¹

يبين تاريخ HIT أيضًا أن صيغة التمثيل المدمج يمكن أن تتطور.⁶ ففي RFC 4423 وُصف HIT بأنه قيمة بطول 128 بت تُنشأ بتجزئة Host Identifier.⁶ أما في RFC 9063، فإن تعريف HIT يتضمن بالفعل بتات تشير إلى التجزئة المستخدمة.¹ هذا لا يثبت الشكل الذي ينبغي أن تكون عليه صيغة عنوان IPvX، لكنه يبيّن أن السياق الخوارزمي للوسم المدمج أصبح في HIP جزءًا من الوصف المعماري.¹

Base Exchange كنموذج لإنشاء الحالة

يعرّف RFC 7401 بروتوكول HIP الأساسي، أو base exchange، المستخدم بين المضيفين لإنشاء IP-layer communications context، يسمى HIP association، قبل الاتصال.³ وفي محتوى RFC 7401 تُدرج على حدة عملية إنشاء HIP Association، وHIP Puzzle Mechanism، وتبادل puzzle، وDiffie-Hellman المصادَق عليه مع التوافق على مجموعة DH، والحماية من الإعادة، ورفض base exchange، وقطع base exchange، وdowngrade protection، وopportunistic mode.²

تسرد مواصفة RFC 7401 أيضًا حزم التحكم I1 وR1 وI2 وR2 وUPDATE وNOTIFY وCLOSE وCLOSE_ACK.² وفي الوثيقة نفسها أقسام عن تحديث HIP association، ومعالجة الأخطاء، وHIP state machine، ومعالجة UPDATE باستخدام SEQ وACK، ومعالجة CLOSE وCLOSE_ACK، وكذلك handling state loss.²

بالنسبة إلى IPvX، تفيد هذه المجموعة من الموضوعات كقائمة تحقق لتصميم الاتصال، لا كدليل على أن IPvX ملزم بتكرار state machine الخاصة بـ HIP.² يمكننا اختبار تصميمنا على فئات الأسئلة نفسها: كيف تُنشأ الرابطة، وكيف يجري التوافق على المعاملات، وكيف تُكتشف الأخطاء، وكيف تُحدّث الحالة، وكيف يُغلق الاتصال.² وفي الوقت نفسه، لا ينبغي استنتاج مقولة «البدء الرخيص» من RFC 7401 وحده؛ فالمصدر يؤكد صراحة وجود puzzle mechanism وأقسام الحماية، لكنه لا يصوغ مطلبًا عامًا ينطبق على أي بروتوكول عنونة بالمفاتيح.²

أمن الحمولة والارتباطات طبقات منفصلة

يقول RFC 7401 إن HIP designed to be resistant to denial-of-service and man-in-the-middle attacks.² وتشير الوثيقة أيضًا إلى أنه عند استخدام HIP مع بروتوكول أمني مناسب، مثل ESP، فإنه يوفر integrity protection وoptional encryption لبروتوكولات المستوى الأعلى مثل TCP وUDP.²

يوضح RFC 9063 الدور المعماري: عند استخدام HIP، تكون الحمولة بين مضيفي HIP عادة، لكن ليس بالضرورة، محمية بواسطة Encapsulating Security Payload، وتُستخدم Host Identities لإنشاء ESP Security Associations اللازمة ولمصادقة المضيفين.¹ وهذه حدود مهمة بالنسبة إلى IPvX: يمكن أن تكون العنونة بالمفاتيح جزءًا من المصادقة، لكن حماية الحمولة، ومعاملات security association، ودورة حياة هذه الارتباطات تحتاج إلى وصف مستقل.¹

تبيّن وثائق HIP أيضًا أن المرونة التشفيرية كانت موضع تعديل صريح.² يفيد RFC 7401 بأن الوثيقة تعالج ملاحظات IESG، ولا سيما بشأن crypto agility، وتتضمن دروسًا من تطبيقات RFC 5201.² كما يقول RFC 9063 إنه يأخذ في الاعتبار concerns raised by the IESG, particularly crypto agility.¹ وبالنسبة إلى IPvX، لا يمثل ذلك قاعدة جاهزة بشأن تجزئات أو أنواع مفاتيح بعينها، لكنه سبب وجيه لتوثيق السياق الخوارزمي للعناوين وإجراء تطور الصيغ بوضوح.¹

Rendezvous والتنقلية وتغيّر العناوين

إحدى السمات المركزية لـ HIP في RFC 7401 هي الحفاظ على استمرارية الاتصال عند تغيّر عناوين IP بفضل فصل دوري identifier وlocator.² يصف RFC 9063 طبقة HIP بأنها تدعم end-host mobility وmultihoming وNAT traversal.¹

في مصطلحات RFC 9063، فإن Rendezvous Mechanism هي آلية للعثور على المضيفين المتنقلين بواسطة HIT الخاص بهم.¹ وفي RFC 4423 عُرّفت rendezvous mechanism أيضًا بأنها آلية تُستخدم للعثور على المضيفين المتنقلين بواسطة Host Identity Tag.⁶

بالنسبة إلى IPvX، ينتج عن ذلك صياغة حذرة للدرس: المعرّف المستقر القائم على مفتاح لا يصف بحد ذاته مكان وجود المستلم الآن.¹ فإذا أراد البروتوكول الحفاظ على الهوية عند تغيّر مسار التسليم، فهو يحتاج إلى طريقة مستقلة لربط المعرّف بمحدِّد الموقع أو المسار الحالي؛ ويسمي HIP هذا الصنف من المهام rendezvous mechanism.¹

من المهم عدم المبالغة في هذا الاستنتاج.² يؤكد RFC 7401 وجود إجراءات UPDATE وSEQ وACK لمعالجة تحديثات HIP association، لكن لا يترتب على ذلك تلقائيًا قاعدة توسّع خاصة بـ IPvX.² يمكننا استخدام HIP كمثال على أن تغيير حالة الرابطة مخصص له إجراءات منفصلة، إلا أن معاملات تحمل الأعطال والتوسع في IPvX يجب أن تُختبر بتجاربنا القابلة للإعادة.²

الشهادات: قابلية التوسّع من دون إثقال الحزمة الأولى

يحدّث RFC 8002 الوثيقة RFC 7401 ويعرّف CERT parameter بوصفه حاوية للشهادات الرقمية في حزم التحكم الخاصة بـ HIP.⁵ وتؤكد الوثيقة نفسها أن CERT parameter لا يحدد دلالات الشهادات، وأن سيناريوهات الاستخدام المحددة يجب أن تُعرّفها الوثائق التي تطبق هذا المعامل.⁵

هذا مثال جيد على الفصل بين الآلية وسياسة الثقة.⁵ يمكن للبروتوكول الأساسي أن يصف نقل الشهادات، وتجميع CERT parameters المرتبطة، والإبلاغ عن الأخطاء عند فشل التحقق، من دون أن يدمج كل القرارات السيناريوهية في صيغة عامة واحدة.⁵

يتضمن RFC 8002 درسًا سلبيًا أيضًا: لا يُوصى باستخدام CERT في أول حزمة Initiator packet I1، لأن ذلك قد يزيد زمن معالجة I1 ويصبح مشكلة عند processing storms of I1s.⁵ وبالنسبة إلى IPvX، يمكننا صياغة ذلك كفرضية تصميمية: لا ينبغي وضع الأدلة والشهادات والإثباتات تلقائيًا في أبكر حزمة وأكثرها كثافة في handshake.⁵ هذا بالضبط استنتاج لتصميمنا، وليس مطلبًا مقتبسًا من RFC 8002 موجّهًا إلى IPvX.⁵

يصف RFC 8002 أيضًا خيارات تمرير المؤشرات بدلًا من الشهادات نفسها: يمكن لـ Hash and URL وLDAP URL وDistinguished Name أن تقلل حجم HIP control packets، لكنها تتطلب من المستلم حل URL، أو جلب الشهادة، أو التحقق من الذاكرة المحلية المخبأة.⁸ لذلك، عند تصميم IPvX-handshake، يجب النظر على نحو منفصل في المفاضلة بين الرسالة المكتفية بذاتها والاعتماد على جلب بيانات الثقة من الخارج.⁸

توثيق النضج والقيود

كان RFC 4423 وثيقة معلوماتية، ووصف نفسه صراحة بأنه لقطة للتفكير في معمارية HIP في خريف 2003.⁶ كما ورد في RFC 4423 أن المعمارية ربما تكون قد تغيّرت، وأن الوثيقة تمثل نقطة مستقرة واحدة في تطور الفهم.⁶ هذا المثال مهم للبروتوكول البحثي: يجب أن يكون وضع الوثيقة ودرجة نضج المعمارية ظاهرين للقارئ.⁶

حل RFC 9063 محل RFC 4423 وبقي وثيقة من فئة Informational، في حين أن RFC 7401 وثيقة Standards Track بحالة Proposed Standard.⁴ وهذا يبيّن أن الوصف المعماري والمواصفة الأساسية للبروتوكول يمكن أن تكون لهما حالتان مختلفتان في مسار IETF.⁴

تشمل Security Considerations في RFC 9063 كلًا من flooding attacks، واستخدام identities في access control lists، وweaker types of identifiers، وtrust on first use.¹ كما تشمل ملاحق RFC 9063 كلًا من design considerations، وbenefits، وdrawbacks، وdeployment and adoption considerations، وdeployment analysis، وinfrastructure applications، وmanagement of identities in a commercial product.⁴ وبالنسبة إلى مشاريع RFC الخاصة بنا حول IPvX، يدعم ذلك ممارسة الفصل الصريح بين صيغة الحزمة من جهة، والقيود والافتراضات التشغيلية والمفاضلات المعروفة من جهة أخرى.⁴

يسجل تاريخ RFC 7401 في Datatracker نشر RFC في 9 أبريل 2015 وتحديث سجلات IANA في 10 أبريل 2015.⁷ ويُظهر التاريخ نفسه مزامنات لاحقة لبيانات RFC Editor الوصفية، بما في ذلك تغييرات abstract في 2018، وإضافة وسم Verified Errata في 2020، وتحديثات البيانات الوصفية في 2026.⁷ لا يثبت ذلك وجود كل RFC اللاحقة التي تُحدّثها، لكنه يبيّن أن السجل العام للوثيقة يستمر دعمه بعد النشر.⁷

ما نأخذه إلى IPvX

الدرس الأول: عند وصف عناوين IPvX القائمة على المفاتيح، من المفيد التمييز صراحة بين الهوية المجردة، والمفتاح العام كمعرّف، والتمثيل المدمج المجزأ، ومحدِّد الموقع الحالي، لأن HIP يميّز بين Host Identity وHost Identifier وHIT وlocator role IP address.¹³

الدرس الثاني: ينبغي تصميم إنشاء الاتصال كدورة حياة لحالة، لا كتبادل مفاتيح واحد، لأن RFC 7401 يصف HIP association وbase exchange وstate machine وUPDATE وNOTIFY وCLOSE وCLOSE_ACK وhandling state loss.²

الدرس الثالث: ينبغي اعتبار rendezvous مهمة مستقلة ضمن control plane، لأن RFC 9063 يعرّف آلية للعثور على المضيفين المتنقلين بواسطة HIT ويربط معمارية HIP بالتنقلية وmultihoming وNAT traversal.¹

الدرس الرابع: من المفيد فصل الشهادات والأدلة الإضافية عن الدلالة الأساسية للعنوان، لأن RFC 8002 يحدد CERT parameter كحاوية ويترك الدلالة السيناريوهية للوثائق التي تستخدم هذا المعامل.⁵

الدرس الخامس: يجب أن تكون القيود والنتائج السلبية وتاريخ القرارات جزءًا من مسوداتنا، لأن وثائق HIP تُظهر صراحة حالة النضج وsecurity considerations وdrawbacks وdeployment considerations.⁴⁶

الخلاصة بالنسبة إلينا حذرة: لا يعرّف HIP بروتوكول IPvX ولا يعفينا من واجب اختبار التوجيه، والإخفاقات، والتوسع في تجاربنا القابلة للإعادة.² لكنه يمنحنا لغة منشورة لمناقشة العناوين القائمة على المفاتيح، وارتباطات الأمان، وrendezvous، والتنقلية، والحدود بين المعمارية والمواصفة والقيود التشغيلية.¹²

المصادر

1. RFC 9063: Host Identity Protocol Architecture, rfc-editor.org, 01‏/07‏/2021
2. RFC 7401: Host Identity Protocol Version 2 (HIPv2), datatracker.ietf.org
3. RFC 7401: Host Identity Protocol Version 2 (HIPv2), datatracker.ietf.org
4. RFC 9063: Host Identity Protocol Architecture, datatracker.ietf.org
5. RFC 8002: Host Identity Protocol Certificates, datatracker.ietf.org
6. RFC 4423: Host Identity Protocol (HIP) Architecture, datatracker.ietf.org
7. History for rfc7401, datatracker.ietf.org
8. RFC 8002: Host Identity Protocol Certificates | RFC Editor, rfc-editor.org