الخلاصة

  • تثبت PATH_RESPONSE المطابقة أن الطرف الذي تلقى PATH_CHALLENGE غير متوقعة استطاع إعادة قيمتها ذات الثمانية بايتات.
  • لا تثبت هذه النتيجة هوية شخص أو جهاز أو حساب أو تطبيق، ولا التفويض أو الهوية التشفيرية أو MTU أو استمرار المسار.
  • ينبغي أن يفصل سجل التشغيل بين قابلية العودة وإثبات الهوية والنتيجة التطبيقية وسياسة الاحتفاظ.

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

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

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

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

ولا ينبغي الخلط بين تحقق المسار والتحقق من MTU. فقد ينجح تحدٍّ داخل مخطط بيانات أصغر من 1200 بايت في التحقق من عنوان النظير أو المسار من دون إثبات دعم MTU المطلوبة. ويتطلب فحص MTU تحديًا موسعًا منفصلًا. وتُوسَّع مخططات PATH_RESPONSE عادة إلى 1200 بايت على الأقل، لكن لا يجوز أن تتجاوز حد مكافحة التضخيم. ولهذا يجب أن يسجل الدفتر نتيجة تحقق العنوان ونتيجة تحقق MTU كلًّا على حدة، مع حجم مخطط البيانات وحالة مكافحة التضخيم.

لا يعني غياب رد واحد الفشل فورًا. يوصي RFC 9000 بمؤقت يعتمد على ثلاثة أضعاف الأكبر بين PTO للمسار الحالي وPTO للمسار الجديد، مع السماح بعدة PTO حتى لا يحسم فقد تحدٍّ أو رد واحد النتيجة. ولا يفشل التحقق إلا عندما يتخلى الطرف عن المحاولة. والتخلي عن مسار لا ينهي الاتصال بالضرورة إذا ظل مسار صالح آخر قابلًا للاستخدام. ويعني فشل اختبار المسار الجديد أن ذلك المسار غير صالح لهذا الاتصال، لا أن الاتصال كله انتهى.

عند اكتشاف تغير في عنوان النظير، بما في ذلك إعادة ربط NAT، يجب التحقق من المسار ما لم يكن العنوان قد تحقق سابقًا. وهذا لا يجعل تحقق المسار في QUIC آلية لعبور NAT؛ فـ RFC 9000 لا يقدم آليات المزامنة اللازمة لعبور فعال. وقد تختلف السعة والتوقيت بعد الترحيل، ولذلك يعيد QUIC ضبط حالة التحكم في الازدحام وRTT بدل اعتبار قياسات المسار السابق ضمانات للمسار الجديد.

يستحسن أن يسجل دفتر الأدلة معرف مسار خاصًا بالاتصال وملخصًا آمنًا للخصوصية للتحدي، وأوقات التحدي والرد، وزوج العناوين المحلي والبعيد المختبَر، وحجم مخطط البيانات، ونتيجة المطابقة، ومسار وصول الرد. كما يجب فصل حالة تحقق عنوان النظير عن حالة تحقق MTU، وتسجيل مكافحة التضخيم قبل التحقق وبعده، ومدخلات PTO للمسارين الحالي والمرشح، وسبب التخلي ونتيجة المؤقت. وينبغي تحديد سبب إعادة ربط NAT أو الترحيل، ودليل العنوان المتحقق سابقًا، والمسارات البديلة القابلة للاستخدام. الملخصات الآمنة وسياسات الاحتفاظ توصيات تشغيلية وليست متطلبات QUIC.

ينبغي الحفاظ على الفصل الخماسي مع الأعمال السابقة. يتناول TR-039 ميزانية مكافحة التضخيم قبل تحقق العنوان؛ ويتناول TR-033 دليل مسار العودة في DNS Cookie؛ ويتناول TR-043 سلامة Retry؛ ويفصل TR-040 بين connection ID والهوية؛ ويتناول TR-061 دليل تحقق العنوان بواسطة NEW_TOKEN في الاتصالات المستقبلية. لا يجوز استخدام PATH_RESPONSE بديلًا عن أي منها.