اختبار قابلية الرجوع في DTLS ليس إيصال انتقال

الخلاصة

• يضيف RFC 9853 إلى DTLS 1.2 و1.3 اختبار قابلية رجوع موثقاً ومشفراً. قد تسوّغ الاستجابة المرتبطة بالتحدي تحديث العنوان المقترن بمعرّف الاتصال، بينما يبقي انتهاء المهلة الربط القديم.
• النتيجة أضيق من إثبات الهوية أو التفويض أو اكتمال الانتقال. ينبغي للإيصال القابل للتدقيق أن يفصل بين المحفز ونموذج التهديد وميزانية الاختبار وربط الاستجابة ونقل السياق وقبول التطبيق وفترة المراقبة وهدف التراجع.

السجل الأول القادم من العنوان B صحيح تشفيرياً. يستخدم معرّف CID للوصول إلى ارتباط أنشئ حين كان النظير عند العنوان A، كما أن الحقبة ورقم التسلسل مقبولان ونجحت عملية فك التشفير الموثق. مع ذلك لم يُحسم السؤال التشغيلي: هل ينبغي إرسال الاستجابة التطبيقية التالية إلى B؟

تمنع Connection ID تحويل عنوان UDP ومنفذه إلى اسم دائم للاتصال. يستفيد الجهاز المتنقل أو المقيد أو الواقع خلف NAT من بقاء ارتباط DTLS بعد تغير العنوان. لكن الاستمرارية توسع أيضاً سطح إعادة التوجيه. قد تسبق نسخة من سجل أصلي النسخة الحقيقية عبر مسار أسرع، وقد يدفع عنوان مصدر محرّف الخادم إلى تضخيم الرد نحو ضحية.

وضع RFC 9146 ثلاثة شروط قبل استبدال عنوان النظير: نجاح التحقق التشفيري من السجل، وأن يكون أحدث من حيث الحقبة والتسلسل، ووجود استراتيجية تثبت قدرة العنوان الجديد على استقبال سجلات DTLS ومعالجتها. تركت الوثيقة الاستراتيجية الثالثة مفتوحة.

سدّ RFC 9853، المنشور على مسار معايير IETF في مارس 2026، تلك الفجوة في DTLS 1.2 و1.3، وحدّث RFC 9146 وRFC 9147. يجري بروتوكول Return Routability Check، أو RRC، قبل تعديل الاقتران المحلي بين CID والعنوان.

للترتيب دلالة حاكمة. يختار CID حالة الأمان، وتثبت طبقة السجلات انتماء الرزمة إلى تلك الحالة، ويختبر RRC مساراً، ثم يقرر المستقبل تغيير الربط. لا يرث أي شرط معنى الشرط التالي تلقائياً.

قدرة متفق عليها قبل الحركة

يُتفاوض على RRC بواسطة الامتداد الفارغ rrc ذي الرمز 61. على العميل الذي يعرضه أن يعرض أيضاً connection_id، ويقبله الخادم في ServerHello. لا يجوز لأي طرف استخدام RRC ما لم ينجح تبادل الامتداد بينهما.

حتى بعد التفاوض ليس RRC الخيار الوحيد. عند وصول سجل CID من عنوان مختلف ينبغي للمستقبل تشغيله، إلا إذا أمكنه تشغيل آلية تحقق خاصة بالتطبيق. يتيح Echo في CoAP، الذي يعرّفه RFC 9175، فرض حداثة الطلب أو إثبات الوصول وفق المورد والطريقة والسياسة. صلاحية مسار النقل وقبول العملية التطبيقية سؤالان مختلفان.

يحمل نوع المحتوى 27، return_routability_check، ثلاث رسائل: path_challenge وpath_response وpath_drop. تحمل كل رسالة cookie من ثمانية ثمانيات، أي 64 بت من الإنتروبيا، وتوثق وتشفّر بسياق DTLS النشط.

لا تمثل cookie هوية النظير أو ملكية العنوان أو إذن تنفيذ عمل. وظيفتها ربط استجابة بتحدّ محدد. إذا حفظ السجل عبارة «نجح RRC» فقط، ضاع نطاق الدليل: الاتصال والمحاولة والوجهة ووقت البدء والانتهاء.

الميزانية تسبق الثقة

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

هذه ميزانية تعرض للخطر وليست تقديراً للسعة. لا ينبغي لطلب صغير مزيف المصدر أن يحرر رداً كبيراً. يُرسل أولاً تحدّ صغير محمي؛ لا تستطيع الضحية التي لا تملك حالة DTLS فكّه أو توليد استجابة مطابقة، فيبقى الربط السابق.

في الإجراء الأساسي ينشئ البادئ cookie غير قابلة للتوقع، ويضعها في path_challenge، ويرسلها إلى العنوان الجديد ويشغل المؤقت T. يتحقق النظير من الرسالة ويعيد القيمة في path_response. لا يحدّث البادئ العنوان إلا بعد التحقق من التطابق. إذا انتهت T لا يحدث التحديث.

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

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

لماذا يُسأل المسار القديم أولاً

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

لذلك يبدأ الإجراء المعزز باختبار العنوان السابق. إذا عاد path_response على المسار الذي ما زال مفضلاً، يحتفظ المستقبل بالربط. وإذا عاد path_drop فهذا يعني أن الطريق يعمل لكنه لم يعد مفضلاً، فينتقل إلى الاختبار الأساسي للعنوان الجديد. وإذا صمت القديم حتى T يجري أيضاً اختبار الجديد، ولا تتم هجرة تلقائية بسبب الصمت.

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

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

قابلية الرجوع ليست هوية

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

ولا يقرر استمرار التطبيق. قد تتطلب عملية CoAP حداثة إضافية؛ وربما انتهت صلاحية عمل منتظر، أو لم يعد الطلب قابلاً للإعادة، أو تغيرت الصلاحية. استئناف إرسال البايتات نتيجة نقلية، والحفاظ على معنى العمل نتيجة تطبيقية.

توضح أطروحة Lu Heng عن الحد الأدنى للمواصفة الأولية والقرار المستقبلي المحلي والتبني الطوعي هذا التقسيم. تبقى في الطبقة المشتركة الأدلة الحتمية اللازمة للأمان والتوافق؛ ويظل نموذج التهديد والبديل التطبيقي والتوقيت والأثر لدى من يشغّلون الشيفرة. ويكشف Policy Mirror سطح القرار الحقيقي: الانتقال المحلي الذي يغير العنوان ويطلق مخرجات التطبيق، لا رقم IANA.

ما تخفيه الإشارة الخضراء

يوصي RFC 9853 بتسجيل الاختبارات الفاشلة والاستجابات المتعددة لتحد واحد وكثرة الفحوص. قد تشير، على الترتيب، إلى انتحال أو عطب في طريق الرجوع، أو سباق خارج المسار، أو عدم استقرار الاتصال.

يخفي DTLS 1.3 نوع السجل عن المراقب على المسار. في DTLS 1.2 قد يظهر نوع RRC إذا لم يكن داخل tls12_cid، فيستطيع وسيط إسقاطه؛ يقلل استخدام CID في الاتجاهين ذلك الخطر. ويتيح DTLS 1.3 طلب CIDs جديدة لمسارات مختلفة، بينما لا يستطيع 1.2 تجديدها أثناء الجلسة، ولذلك لا يلائم تعدد المسارات إذا كان الربط بين الحركة تهديداً مهماً.

يبقى المهاجم الموجود على المسار قادراً على الإضرار بالاتصال أو تمرير الاختبار إلى النظير الحقيقي. ينسق سجل IANA لمعاملات TLS النوع 27 والامتداد 61 والرسائل الثلاث، لكنه لا يصادق على التطبيق أو الهوية أو السلطة أو اكتمال الخدمة.

المصادر والحدود

تعتمد المقالة على RFC 9853 وصفحة حالته وتصويباته، وRFC 9146، وRFC 9147، وRFC 9175، وRFC 9000، وسجل IANA، وRFC 8126. تحدد هذه المصادر عقود البروتوكول والتسجيل، ولا تقيس الانتشار أو الإعدادات الافتراضية أو الأداء أو الحوادث أو سياسة مشغل بعينه.

ويحفظ سجل التصويبات المستقل لـRFC 9853 تاريخ التصحيحات الذي جرى التحقق منه عند إقفال البحث.