الخلاصة

  • ‏NEW_TOKEN اعتماد يصدره الخادم للتحقق من العنوان في اتصال QUIC لاحق، بخلاف Retry المستخدم فوراً.
  • ‏التحقق الناجح دليل محدود على عنوان المصدر وفق سياسة الخادم، وليس دليلاً على عميل عائد أو جهاز أو حساب.
  • ‏ينبغي فصل تحقق الرمز عن مصادقة المصافحة وهوية التطبيق والتفويض والنتيجة في السجلات.

يعرض سجل العمليات حزمة Initial تحمل رمزاً، ثم يسميها «عميلًا عائداً». تبدو التسمية مفهومة لأن NEW_TOKEN قد يلغي جولة إضافية للتحقق من العنوان. لكنها تحول دليلاً محدوداً إلى ادعاء هوية. السؤال الفعلي أضيق: هل يستطيع الخادم قبول الرمز باعتباره دليلاً كافياً على علاقة عنوان المصدر بالاتصال الذي أصدره؟

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

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

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

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

يقدم DNS over QUIC مثالاً عملياً على حد الخصوصية. قد يتجنب الرمز المرتبط بعنوان IP جولة إضافية، لكن تغير العنوان من دون علم العميل قد يخلق قابلية للربط. ويمكن لاستئناف الجلسة تخفيف المشكلة من دون إزالتها. النتيجة التشغيلية هي استخدام فائدة النقل مع إبقاء الدليل محصوراً.

ينبغي أن يفصل دفتر الأدلة بين مُصدر الرمز وسلطة الخادم؛ نوع الرمز؛ وقت الإصدار والانتهاء؛ إصدار QUIC؛ معرّف الرمز أو ملخص آمن للخصوصية؛ مطابقة عنوان المصدر؛ قرار الاستخدام الأول أو إعادة الاستخدام؛ نتيجة التحقق؛ حالة منع التضخيم؛ قرار Retry؛ نتيجة مصادقة المصافحة؛ هوية الحساب أو الجهاز؛ التفويض؛ نتيجة الطلب أو المعاملة؛ وسياسة الاحتفاظ. الملخصات الآمنة والاحتفاظ المحدود توصيات تشغيلية وليست متطلبات QUIC.

يجب كذلك عدم الخلط بينه وبين الأبعاد الخمسة المجاورة: سلامة Retry تخص حزمة مستخدمة فوراً؛ قاعدة الثلاث مرات تحد سقف الإرسال قبل التحقق؛ Connection ID مقبض توجيه؛ قبول 0-RTT يتعلق ببيانات قابلة لإعادة التشغيل وبقرار الالتزام؛ وDNS Cookie دليل عودة لمسار في بروتوكول آخر. لا يوسع أي منها معنى NEW_TOKEN.