الخلاصة

  • يميّز RFC 5269 بين زوج CGA/SEND الذي يسند ادعاء عنوان المصدر، وزوج مستقل لا يستخدم إلا لنقل السر، ومفتاح انتقال مشترك يحسب موثّق FBU.
  • نجاح MAC يجيز للموجّه السابق تعديل forwarding لعنوان previous care-of CGA محدد. ولا يثبت attachment أو NCoA أو وصول البيانات أو هوية مستخدم أو تطبيق أو قبول ربط Mobile IPv6 لاحق.

الخطر كان أمراً بتحويل المرور لا فكرة عامة عن التنقل

تسمح رسالة Fast Binding Update للعقدة المتنقلة بأن تطلب من previous access router تحويل المرور الذي ما زال يصل إلى عنوانها القديم. ولو تمكن مرسل غير مخوّل من إصدار هذا الأمر، لاستطاع أخذ حزم الضحية إلى مسار آخر من دون كسر تشفير بياناتها.

ينشئ RFC 5269 shared handover key قبل الحركة. تحسب العقدة MAC للإجازة داخل FBU، ويبحث PAR عن العلاقة المقترنة بالـ care-of CGA القديم، ثم يتحقق قبل تغيير إعادة التوجيه. إذا لم يجد المفتاح المطابق فلا يجوز له تنفيذ التغيير.

هذه حماية حقيقية، لكنها محصورة بالفعل الذي قيس. لم يراقب MAC ارتباطاً لاسلكياً، ولم ينفذ DAD على NCoA، ولم يشاهد الموجّه الجديد يفرغ مخزونه، ولم ير التطبيق يستلم البيانات. لذلك فإن عبارة «تم توثيق الانتقال» توسّع النتيجة إلى وقائع لم تدخل الحساب.

ثلاثة مفاتيح لأن الادعاءات الثلاثة ليست شيئاً واحداً

الأول هو زوج CGA/SEND. ترسل العقدة RtSolPr من care-of CGA وتدرج معلمات CGA وتوقيع SEND. وعندما ينجح التحقق يستطيع الموجّه قبول أن المرسل مخوّل بادعاء عنوان المصدر هذا في ذلك التبادل، لا أنه صاحب سلطة عامة على الشبكة.

الثاني زوج يولّد خصيصاً لتشفير مفتاح الانتقال. يستخدم الخوارزمية والمعلمات العامة نفسها التي يستخدمها SEND، لكن يجب أن يبقى مستقلاً. يمنع RFC 5269 استعماله لأي تشفير آخر أو للتوقيع. ينتقل المفتاح العام في Handover Key Request Option، ويبقى المفتاح الخاص لدى العقدة لفتح الرد.

الثالث هو السر المشترك الذي ينشئه access router أو يستعيده. يشفّره بالمفتاح العام المخصص ويعيده في Handover Key Reply Option. بعد ذلك يستخدمه الطرفان لحساب موثّق FBU.

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

لا تخصيص للحالة قبل نجاح SEND

تتضمن RtSolPr المفتاح العام المخصص، وAlgorithm Type المفضل لموثّق FBU، وخياري CGA وSignature، وnonce من SEND. يجب على access router التحقق من SEND أولاً. عند الفشل لا يعيد Handover Key Reply، ولا يولّد مفتاحاً، ولا يعدّل سجلاً صحيحاً موجوداً لذلك العنوان. لا يجوز لطلب مزور أن يمحو حالة العقدة الشرعية عبر مسار الخطأ.

يحمي هذا الترتيب القدرة التشغيلية أيضاً. فتوليد سر عشوائي قوي وتشفيره وحجز مكان له في الذاكرة أعمال مكلفة. إن حدثت قبل التحقق أمكن للمهاجم ملء الحالة المؤقتة. وحتى الطلبات الموقعة تحتاج إلى rate limiting وحدود للطلبات المعلقة وسياسة واضحة للذاكرة المؤقتة.

لهذا يلزم إيصالان منفصلان: نتيجة تحقق SEND وقرار admission. عبارة «التوقيع صحيح» لا تبيّن إن كان الموجّه قد قبل عبء الحالة، وعبارة «أعيد المفتاح» لا تثبت أن التحقق سبق التخصيص.

فك التشفير لا يكفي لإثبات هوية الموجّه المجيب

بعد الطلب الصحيح يعيد الموجّه المفتاح المرتبط بالـ CGA أو ينشئ واحداً جديداً. يحمل PrRtAdv السر المشفر وHK-LIFETIME والخوارزمية المختارة والـ nonce الأصلي.

لكن جانب الموجّه له متطلبات هوية أيضاً. ينبغي أن يملك access router شهادة مناسبة لـ SEND، وأن يدعم اكتشاف الشهادات، وأن يوقع الرد بالمفتاح المعتمد. إذا لم يكن مسار الشهادة محفوظاً تستخدم رسائل CPS/CPA للحصول عليه. تتحقق العقدة من المسار وtrust anchor والتوقيع، وترفض أي رد لا يرتبط بمفتاح موجّه معتمد.

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

إذن يتكون الإيصال من جيل الطلب وادعاء CGA وتوقيع SEND وقرار الموجّه ومسار الشهادة وتوقيع PrRtAdv وnonce المعاد واختيار الخوارزمية والمفتاح الخاص المطابق والعمر. نجاح فك التشفير حلقة في السلسلة وليس السلسلة كلها.

مفتاح الفهرسة علاقة بين أطراف لا اسم جهاز

يربط الموجّه السر المشترك بـ CGA الخاصة بالعقدة والخوارزمية ووقت الانتهاء. وعندما تختار العقدة مفتاح FBU لاحقاً تحتاج إلى هوية previous access router وإلى previous care-of CGA التي استخدمتها على وصلة ذلك الموجّه. يحمل Home Address Option في FBU العنوان القديم ليتمكن PAR من العثور على السجل.

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

قد يختار join خاطئ في قاعدة البيانات مفتاحاً صالحاً لسياق آخر، ثم ينتج MAC صحيحاً رياضياً. تؤكد المشفرات العملية التي أجريت بالمادة المختارة؛ ولا تؤكد أن التطبيق اختار العلاقة الصحيحة.

اختيار الخوارزمية جزء من الدليل

ترسل العقدة Algorithm Type المفضل لتوثيق FBU. إذا دعمه الموجّه يعيده، وإن لم يدعمه فعليه اختيار بديل بقوة مساوية أو أكبر. تستخدم العقدة القيمة التي وصلتها فعلاً.

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

لا يحتفظ السطر MAC valid بهذه السياسة. يجب أن ترافق النتيجة الخوارزمية المطلوبة والمختارة وجيل السياسة والتنفيذ الذي عمل. ولا ينبغي لتغيير مستقبلي في القواعد أن يعيد تفسير تحقق قديم بصمت.

وجود نسخة لم تنته لا يعني تجديد السلطة

يقترح RFC 5269 لزوج النقل المخصص حداً أقصى قدره اثنتا عشرة ساعة أو عشر عمليات handover، أيهما يأتي أولاً. أما المفتاح المشترك فعمره الافتراضي اثنتا عشرة ساعة، أي 43,200 ثانية.

ينشئ الموجّه سراً عشوائياً بقوة تناسب الخوارزمية، وقيمة فريدة لكل مفتاح عام لـ CGA. وينبغي ألا تكون مفاتيح الانتقال مترابطة بعضها مع بعض أو مع مفاتيح CGA.

قد يحتفظ PAR بمفتاح ساري لأن العقدة ربما تتحرك مرة أخرى قبل إكمال Mobile IPv6 binding العادي. وإذا عادت بالـ care-of CGA نفسه يستطيع الموجّه إرسال السر نفسه مجدداً. لكن وجود نسخة محلية داخل العمر لا يعطي العقدة حق افتراض التجديد؛ يجب أن تستلم المفتاح من الموجّه مرة أخرى.

الحيازة المحلية وعدم انتهاء المؤقت واحتفاظ الموجّه وإعادة الإصدار أربع حالات مستقلة. بعد اكتمال الربط العادي ينبغي للعقدة حذف السر، ويغلق PAR السجل عند انتهاء forwarding أو HK-LIFETIME.

المفتاح المصمم لغرض واحد ليس وثيقة هوية عامة

لا يشفّر السر المشترك مرور المستخدم، وليس مفتاح جلسة لتطبيق، ولا إثبات مشترك أو موظف أو حق فوترة. لا يتحقق من NCoA المقترحة، ولا يحل محل Binding Update أو Return Routability، ولا يثبت أن home agent أو correspondent node قبلا binding.

حل RFC 5568 محل RFC 5268 بوصفه أساس FMIPv6 الحالي، وما زال يحيل إلى RFC 5269 لإنشاء المفتاح المستخدم في FBU authenticator. لذا تقرأ الإضافة مع الصيغة الحالية؛ أما استعمال بنية حزمة قديمة فهو عيب آخر منفصل.

قد تقوي أعمال SEND اللاحقة الشهادات وتوزيع trust anchors. يزيد ذلك الثقة في الموقّع ضمن النموذج نفسه، لكنه لا يوسّع معنى MAC. قوة الدليل لا تبدل القضية التي يثبتها.

الكود الذي نُفذ يكشف السلسلة التي يخفيها الملخص

تطلب Running-Code Primacy لدى Lu Heng تسمية العمليات الفعلية: ادعاء CGA، تحقق SEND، مفتاح عام مخصص، رد موقّع من موجّه معتمد، nonce مطابق، علاقة في الذاكرة المؤقتة، خوارزمية، موثّق FBU، وقرار forwarding.

يفصل منظور reality layers بين الحيازة والإجازة والنتيجة. التحكم في مفتاح خاص يثبت القدرة على عملية مشفرة. يثبت SEND ادعاء عنوان محدوداً. تضع الشهادة الموجّه داخل نموذج ثقة. يربط nonce رسالتين. يجيز MAC تغيير المسار. لا تقيس أي واحدة منها اتصال الجهاز أو استمرارية الخدمة.

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

المصادر