الخلاصة

  • يعمل RVS في RFC 5204 كنقطة اتصال أولى: يبحث عن HIT المسجل ويمرر I1، ثم يسلك R1 وI2 وR2 طريقاً مباشراً بين الطرفين.
  • يثبت RVS_HMAC سلامة FROM والتحويل داخل علاقة التسجيل، ولا يثبت أن locator ما زال حياً أو أن المصادقة بين الطرفين اكتملت.
  • ينبغي ربط دليل DNS وعصر التسجيل والتحويل والإرسال باستلام الطرف الآخر والعودة المباشرة واكتمال التبادل وحركة البيانات ونتيجة الخدمة.

قاعدة سليمة وواقع تغيّر

لنفترض حالة تشغيلية مصطنعة. سجّل جهاز متنقل العنوان A، ثم انتقل إلى B قبل وصول التحديث إلى RVS. ما زال lifetime للسجل الأول سارياً. تصل I1، فيجد الخادم HIT ويختار A ويضيف FROM محمياً ويرسل الحزمة. كل فحوصه ناجحة، لكن الجهاز لا يرى شيئاً.

تكشف الحالة الفرق بين اتساق حالة الوسيط وحداثة العالم. RFC 5204 وثيقة Experimental من 2008 حلّ محلها RFC 8004. وهي تساعد على بدء الاتصال بعقد HIP المتنقلة أو متعددة المواقع. يسجل العميل HIT وعنوانه الحالي؛ يكتشف المبادر RVS، عادة عبر DNS، ويرسل إليه I1؛ يمرر الخادم الحزمة إذا وجد تسجيلاً مناسباً، وإلا أسقطها.

كلمة «الحالي» تخص ما قبله الخادم في قاعدته. ليست قياساً جديداً للمضيف عند كل طلب.

الوسيط يغادر المسار بعد البداية

يمر I1 عبر RVS، لكن المستجيب يرسل R1 مباشرة إلى المبادر، ويتبادل الطرفان I2 وR2 مباشرة أيضاً. ليس RVS نفق الجلسة ولا مراقب كل مراحلها.

لذلك تختلف الادعاءات التالية: وصل المبادر إلى RVS؛ اختار الخادم locator؛ خرج I1؛ استلمه المستجيب؛ عاد R1؛ اكتمل I2/R2؛ نشأت حالة الحماية؛ نجح التطبيق. لا يملك عداد الخادم دليلاً تلقائياً على المراحل اللاحقة.

ولا يغطي RFC 5204 الحالة العامة التي يستخدم فيها المبادر RVS الخاص به لعبور NAT أو firewall. إذا أضاف منتج هذا السلوك، فهو عقد آخر يحتاج إثباتاً آخر.

FROM يوثق إعادة الكتابة

قد يفرض egress filtering على RVS استبدال source IP بعنوانه. عندها يضع العنوان الأصلي في FROM ويحميه بـ RVS_HMAC اعتماداً على مفتاح السلامة المنشأ أثناء التسجيل. وإذا وجدت قيم سابقة، تُضاف القيمة الجديدة بعدها.

يثبت HMAC أن جهة تملك مفتاح التسجيل حمت التحويل للعميل. لكنه ليس توقيعاً من Host Identity للمبادر، ولا خريطة لكل hop، ولا إيصال استلام من المستجيب. ترتيب FROM سلسلة تحويلات معلنة، لا traceroute موثقاً بالكامل.

الوصف الدقيق هو: «تم التحقق من سلامة تحويل RVS ضمن التسجيل المحدد». أما «تم التحقق من المصدر» فعبارة أوسع من الدليل.

سلامة الوسيط ليست مصادقة الطرفين

لا يحمل I1 بعدُ HMAC والتوقيعات end-to-end في مراحل HIP اللاحقة؛ لذلك يستطيع RVS تعديل headers وإضافة parameters وإعادة حساب checksums. تأتي مصادقة المضيفين في base exchange بعد ذلك.

تجيب سلامة التسجيل عن فعل الوسيط. وتجيب base exchange عن العلاقة بين الطرفين. وحتى بعد نجاحهما تبقى حركة البيانات ونتيجة التطبيق طبقتين منفصلتين.

يناقش RFC مخاطر redirection وamplification وreflection والهجمات على HIP. ولأن RVS يحول هوية مسجلة إلى وجهة حركة، يجب أن يكون قراره قابلاً للتدقيق وألا يتجاوز وصفه نطاقه الحقيقي.

VIA_RVS قرينة للتشخيص

يضيف المستجيب VIA_RVS إلى R1 حين يستلم I1 الممرر. الغرض الأساسي تشخيص مشكلات إنشاء association. لا يثبت الحقل أن المبادر استلم R1 أو تحقّق منه، ولا يصف كل مسار الشبكة.

ينبغي إبقاء حالات إنشاء R1 وإرساله واستلامه والتحقق منه وإرسال I2 واستلام R2 منفصلة. تحويل قرينة التشخيص إلى علامة نجاح يخفي الموضع الذي قد يكون فشل فيه الاتصال.

ساعتان مختلفتان

يحدد DNS مكان RVS وله TTL وcache وسياق ثقة ووقت resolution. ويحدد التسجيل locator الذي قبله الخادم وله ID وlifetime وrenewal وآخر update. قد يقود RR جديد إلى خادم بلا تسجيل، وقد يحمل تسجيل صالح عنواناً قديماً، وقد تحجب السياسة عنواناً صحيحاً.

لذلك يحفظ الإيصال RR المستخدم وHIT وعصر التسجيل وبصمة I1 ونتيجة lookup والـ headers قبل التحويل وبعده وترتيب FROM وسياق HMAC وملاحظة الإرسال. ثم تضاف أدلة مستقلة على استلام المستجيب وR1 المباشر وI2/R2 والحماية والبيانات والنتيجة.

الاستبدال المعياري ليس قياساً للنشر

استبدل RFC 8004 وثيقة 5204، كما حدّثت RFC 7401 و8003 و8005 و8046 أجزاء HIP المجاورة. ينبغي للجرد أن يسجل الجيل المنفذ فعلاً. لكن مجرد ذكر RFC قديم لا يثبت وجوده في جهاز بعينه أو ضعفه أو نجاح ترحيله.

لا تكفي خانة «HIP rendezvous supported». يلزم إصدار وخوارزميات وأنواع تسجيل وقواعد parameters وسياسة وأثر تشغيل. المواصفة تصف العقد؛ running code يحدد الواقع.

Sources