حد QUIC الثلاثي ميزانية للتحقق من العنوان، وليس حماية من هجمات DDoS

الملخص

• قبل التحقق من عنوان الطرف المقابل، لا يجوز لطرف QUIC الذي يرد أن يرسل أكثر من ثلاثة أمثال البايتات التي استلمها من ذلك العنوان.
• يحد هذا السجل من التضخيم باستعمال عنوان مصدر مزوّر في مرحلة محددة؛ لكنه لا يصادق على هوية العميل ولا يزيل سائر أخطار حجب الخدمة.
• يلزم حفظ عدادات البايتات وانتقال حالة التحقق لتمييز الانتظار الصحيح عن الفقد أو نفاد الموارد.

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

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

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

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

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

التحقق من العنوان يقدم استنتاجاً محدوداً أيضاً. أثناء الإنشاء قد يغيّر استلام رزمة Handshake أو نجاح فحص رمز في Initial الحالة. ويمكن لـ Retry أن يطلب من العميل إعادة رمز استلمه في العنوان المدعى. وعلى مسار جديد تستخدم الفقرة 8.2 PATH_CHALLENGE وPATH_RESPONSE المطابق لإثبات الوصول بين زوج محدد من العناوين. ولا يكفي ACK منفرد لأنه قابل للتزوير.

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

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

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

يشمل السجل الكامل الموصى به: معرّفي الاتصال والمسار؛ زوج IP/المنفذ المحلي ونظيره؛ وقت الرصد؛ حالة التحقق وانتقالها وطريقتها؛ البايتات المستلمة من العنوان غير المتحقق منه والمرسلة إليه؛ السقف الثلاثي الحالي والميزانية الباقية؛ بايتات دفعة المصافحة المنتظرة؛ نتيجة Retry أو الرمز؛ نتيجة PATH_CHALLENGE/PATH_RESPONSE عند انطباقها؛ سياق الفقد وإعادة الإرسال؛ توقيتي أول وآخر منع بسبب الحد؛ النتيجة بعد التحقق؛ ومؤشرات منفصلة لضغط المعالج والذاكرة وحالة الاتصال ومعدل الرزم.