SSU2

الحالة

خطة النشر:

نظرة عامة

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

الاقتراح منظم كما يلي: يتم عرض الأهداف الأمنية، يليها مناقشة للبروتوكول الأساسي. بعد ذلك، يتم تقديم مواصفات كاملة لجميع رسائل البروتوكول. وأخيراً، يتم مناقشة عناوين الـ router وتحديد الإصدار.

كما هو الحال مع transports أخرى في I2P، تم تعريف SSU2 للنقل نقطة إلى نقطة (router-to-router) لرسائل I2NP. وهو ليس أنبوب بيانات عام الغرض. مثل SSU، يوفر أيضاً خدمتين إضافيتين: التتابع (Relaying) لاجتياز NAT، واختبار الند (Peer Testing) لتحديد قابلية الوصول الواردة. كما يوفر خدمة ثالثة، غير موجودة في SSU، لترحيل الاتصال عندما يغير الند عنوان IP أو المنفذ.

الدافع

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

أهداف التصميم

• تقليل استخدام المعالج عن طريق إلغاء ElGamal. استخدم X25519 لـ DH.

• الحفاظ على وظائف Peer Test و Relay، وزيادة الأمان لها.

• جعل التنفيذ أسهل من خلال السماح بخوارزميات التحكم في التدفق القياسية.

• تقليل زمن الإعداد. الوقت الوسيط للإعداد حالياً حوالي 135 ميللي ثانية لـ NTCP2 و 187 ميللي ثانية لـ SSU، على الرغم من أن NTCP2 لديه رحلة ذهاب وإياب إضافية؛ استبدال ElGamal في SSU2 يجب أن يقللها، لكن التغييرات الأخرى قد تساعد أيضاً.

• الحفاظ على أو زيادة الإنتاجية القصوى مقارنة بـ SSU 1، كما تم قياسها عبر مجموعة من زمن الاستجابة المحاكي ونسب فقدان الحزم على testnet.

• منع هجمات تضخيم حركة البيانات وإعادة التوجيه الخاطئ من عناوين المصدر المزيفة عبر “address validation”.

• جعل تحديد الحزم أسهل، لتقليل الاعتماد على البدائل الاحتياطية والاستدلالات التي تجعل الكود معقداً بشكل مفرط.

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

• دعم SSU 1 و 2 على منفذ واحد، مع الاكتشاف التلقائي، والنشر كـ “transport” واحد (أي RouterAddress) في NetDB.

• نشر دعم الإصدار 1 فقط، أو 2 فقط، أو 1+2 في NetDB في حقل منفصل، والافتراض إلى الإصدار 1 فقط (لا تربط دعم الإصدار بإصدار router معين)

• تأكد من أن جميع التطبيقات (Java/i2pd/Go) يمكنها إضافة دعم الإصدار 2 (أو عدم إضافته) وفقاً لجداولها الزمنية الخاصة

• أضف حشو عشوائي إلى جميع الرسائل بما في ذلك رسائل المصافحة ورسائل البيانات. يجب أن يكون جميع الحشو مغطى بواسطة MAC، على عكس حشو نهاية الحزمة في SSU 1. توفير آلية خيارات لكلا الجانبين لطلب الحد الأدنى والأقصى للحشو و/أو توزيع الحشو. تفاصيل توزيع الحشو تعتمد على التطبيق وقد يتم تحديدها أو لا يتم تحديدها في البروتوكول نفسه.

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

• إصلاح فقدان البتات في DH بسبب تنسيق Java Ticket1112، وتسريع DH عن طريق التبديل إلى X25519.

• التبديل إلى دالة اشتقاق مفاتيح حقيقية (KDF) بدلاً من استخدام نتيجة DH كما هي

• أضف “مقاومة الاستطلاع” (كما يسميها Tor)؛ وهذا يشمل مقاومة إعادة التشغيل.

• حافظ على تبادل المفاتيح المصادق عليه ثنائي الاتجاه (2W-AKE). التبادل أحادي الاتجاه (1W-AKE) غير كافٍ لتطبيقنا.

• الاعتماد على المفتاح العام الثابت المنشور في RouterInfo كجزء آخر من المصادقة.

• إضافة خيارات/إصدار في handshake للقابلية للتوسع المستقبلي.

• لا تضيف بشكل كبير إلى وحدة المعالجة المركزية المطلوبة لإعداد الاتصال؛ إذا أمكن، قلل منها بشكل كبير.

• إزالة متطلب الحشو إلى مضاعف من 16 بايت المفروض بواسطة تشفير AES في SSU 1.

• استخدام ChaCha/Poly1305 القياسي للتشفير و MAC، لاستبدال تشفير AES و MAC غير القياسي HMAC-MD5-128 المستخدم في SSU 1.

• استخدم مفاتيح تشفير منفصلة للإرسال والاستقبال، بدلاً من المفاتيح المشتركة للاتجاهين المستخدمة في SSU 1.

• استخدم مصافحة من 3 رسائل ورحلة ذهاب وإياب واحدة، كما هو الحال في NTCP2. قم بإزالة التأخير في انتظار رسائل البيانات الذي يجعل SSU فعلياً مصافحة من رحلتي ذهاب وإياب.

• تحسين كفاءة رسائل ACKs و NACKs بشكل كبير، والتي كانت سيئة في SSU 1. تقليل النطاق الترددي المطلوب لرسائل ACKs و NACKs، وزيادة حجم الحزمة المتاح للبيانات. ترميز رسائل NACKs بكفاءة لدفعة من الرسائل المفقودة، وهو أمر شائع عبر WiFi.

• تقليل التعقيد المطلوب لتنفيذ تجزئة رسائل I2NP. تجاوز آليات التجزئة والترميز لرسائل I2NP الكاملة.

• تقليل الحمولة الإضافية للبروتوكول قبل الحشو، خاصة لرسائل ACK. بينما سيتم إضافة الحشو، الحمولة الإضافية قبل الحشو تبقى حمولة إضافية. يجب أن تكون العقد ذات النطاق الترددي المنخفض قادرة على استخدام SSU2.

• الحفاظ على timestamps لكشف الإعادة والانحراف الزمني.

• تجنب أي مشاكل عام 2038 في الطوابع الزمنية، يجب أن تعمل حتى عام 2106 على الأقل.

• زيادة الحد الأدنى لـ MTU من 620 إلى 1280 للكفاءة وسهولة التنفيذ وزيادة الحد الأقصى لحجم رسائل I2NP. التجزئة وإعادة التجميع مكلفة جداً. من خلال توفير مساحة لرسائل النفق بحجم 1028 بايت، فإن الغالبية العظمى من رسائل I2NP لن تتطلب تجزئة.

• زيادة الحد الأقصى لـ MTU من 1488 (1484 لـ IPv6) إلى 1500 لتحسين الكفاءة. إزالة متطلب أن يكون MTU مضاعفاً للعدد 16.

• زيادة الحد الأقصى لحجم رسائل I2NP من حوالي 32K في SSU 1 إلى حوالي 64 KB كما في NTCP2.

• إزالة توقيع حقول IP والمنفذ من المصافحة، بحيث يتمكن أجهزة router التي لا تعرف عنوان IP الخارجي والمنفذ الخاص بها من الاتصال.

• الاحتفاظ بآلية اكتشاف IP/port من SSU 1 في handshake، بحيث يمكن للـ routers تعلم IP الخارجي والـ port الخاص بها.

• تضمين ممثلين من مطوري router في Java و C++ و Go في التصميم.

Non-Goals

• مقاومة فحص الحزم العميق (DPI) المضمونة… وهذا ما يُعرف بالنقل القابل للتوصيل، Proposal 109.

• نقل مبني على TLS (أو يشبه HTTPS)… وهو الاقتراح 104.

• مقاومة فحص الحزم العميق القائم على التوقيت (يمكن أن يعتمد توقيت/تأخير ما بين الرسائل على التنفيذ؛ يمكن إدخال تأخيرات داخل الرسائل في أي نقطة، بما في ذلك قبل إرسال الحشو العشوائي، على سبيل المثال). التأخيرات الاصطناعية (ما يسميه obfs4 بـ IAT أو وقت الوصول البيني) مستقلة عن البروتوكول نفسه.

• إنكار المشاركة في جلسة (توجد توقيعات هناك).

الأهداف غير المرغوبة التي قد يُعاد النظر فيها جزئياً أو مناقشتها:

• درجة الحماية ضد فحص الحزم العميق (DPI)

• أمان ما بعد الكم (PQ)

• إنكار المسؤولية

Security Goals

نحن نعتبر ثلاثة أطراف:

• أليس، التي ترغب في إنشاء جلسة جديدة.
• بوب، الذي ترغب أليس في إنشاء جلسة معه.
• مالوري، “الرجل في المنتصف” بين أليس وبوب.

على الأكثر يمكن لمشاركين اثنين الانخراط في هجمات نشطة.

أليس وبوب كلاهما يمتلك زوج مفاتيح ثابت، والذي يكون موجوداً في RouterIdentity الخاص بكل منهما.

البروتوكول المقترح يحاول السماح لأليس وبوب بالاتفاق على مفتاح سري مشترك (K) تحت المتطلبات التالية:

1. أمان المفتاح الخاص: لا يتعلم Bob ولا Mallory أي شيء عن المفتاح الخاص الثابت لـ Alice. وبشكل متماثل، لا تتعلم Alice أي شيء عن المفتاح الخاص الثابت لـ Bob.

2. مفتاح الجلسة K معروف فقط لدى Alice و Bob.

3. السرية الأمامية المثالية: يبقى مفتاح الجلسة المتفق عليه سرياً في المستقبل، حتى عندما يتم الكشف عن المفاتيح الخاصة الثابتة لأليس و/أو بوب بعد الاتفاق على المفتاح.

4. المصادقة ثنائية الاتجاه: أليس متأكدة من أنها أنشأت جلسة مع بوب، والعكس صحيح.

5. الحماية من فحص الحزم العميق عبر الإنترنت: ضمان أنه ليس من السهل اكتشاف أن أليس وبوب منخرطان في البروتوكول باستخدام تقنيات فحص الحزم العميق (DPI) المباشرة فقط. انظر أدناه.

6. إنكارية محدودة: لا يستطيع أليس ولا بوب إنكار المشاركة في البروتوكول، لكن إذا سرب أي منهما المفتاح المشترك فيمكن للطرف الآخر إنكار صحة محتويات البيانات المرسلة.

يحاول الاقتراح الحالي توفير جميع المتطلبات الخمسة بناءً على بروتوكول Station-To-Station (STS). لاحظ أن هذا البروتوكول هو أيضاً الأساس لبروتوكول SSU.

Additional DPI Discussion

نفترض وجود مكونين لـ DPI:

Online DPI

فحص DPI عبر الإنترنت يراقب جميع التدفقات في الوقت الفعلي. قد يتم حظر الاتصالات أو التلاعب بها بطرق أخرى. قد يتم تحديد وتخزين بيانات الاتصال أو البيانات الوصفية للتحليل دون اتصال. فحص DPI عبر الإنترنت لا يملك وصولاً إلى قاعدة بيانات شبكة I2P. فحص DPI عبر الإنترنت لديه قدرة حاسوبية محدودة في الوقت الفعلي، تشمل حساب الطول وفحص الحقول والحسابات البسيطة مثل XOR. فحص DPI عبر الإنترنت لديه القدرة على تنفيذ وظائف التشفير السريعة في الوقت الفعلي مثل ChaCha20 و AEAD والتشفير التجميعي، لكن هذه ستكون مكلفة جداً لتطبيقها على معظم أو جميع التدفقات. أي تطبيق لهذه العمليات التشفيرية سيطبق فقط على التدفقات على مجموعات IP/Port التي تم تحديدها مسبقاً من خلال التحليل دون اتصال. فحص DPI عبر الإنترنت لا يملك القدرة على تنفيذ وظائف التشفير عالية التكلفة مثل DH أو elligator2. فحص DPI عبر الإنترنت غير مصمم تحديداً لكشف I2P، رغم أنه قد يملك قواعد تصنيف محدودة لهذا الغرض.

الهدف هو منع تحديد البروتوكول بواسطة فحص الحزم العميق (DPI) عبر الإنترنت.

مفهوم فحص البيانات العميق (DPI) عبر الإنترنت أو “المباشر” يشمل هنا قدرات الخصم التالية:

1. القدرة على فحص جميع البيانات المرسلة أو المستلمة من قبل الهدف.

2. القدرة على تنفيذ عمليات على البيانات المرصودة، مثل تطبيق block ciphers أو hash functions.

3. القدرة على تخزين ومقارنة الرسائل المرسلة سابقاً.

4. القدرة على تعديل أو تأخير أو تقسيم الحزم.

ومع ذلك، يُفترض أن يكون للـ DPI الفوري القيود التالية:

5. عدم القدرة على ربط عناوين IP بـ router hashes. بينما يكون هذا أمراً بسيطاً مع الوصول في الوقت الفعلي إلى قاعدة بيانات الشبكة، فإنه يتطلب نظام DPI مصمماً خصيصاً لاستهداف I2P.

6. عدم القدرة على استخدام معلومات التوقيت لاكتشاف البروتوكول.

7. بشكل عام، لا تحتوي مجموعة أدوات DPI المتاحة عبر الإنترنت على أي أدوات مدمجة مصممة خصيصاً لاكتشاف I2P. يشمل ذلك إنشاء “honeypots”، والتي قد تتضمن على سبيل المثال حشو غير عشوائي في رسائلها. لاحظ أن هذا لا يستبعد أنظمة التعلم الآلي أو أدوات DPI القابلة للتكوين بدرجة عالية طالما أنها تلبي المتطلبات الأخرى.

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

للحماية من النقطة السادسة المذكورة أعلاه، يجب أن تتضمن التطبيقات تأخيرات عشوائية في البروتوكول. هذه التقنيات غير مغطاة بهذا الاقتراح، لكنها قد تحل أيضاً مشاكل طول الحشو. باختصار، يوفر الاقتراح حماية جيدة ضد تحليل الحمولة (عند أخذ الاعتبارات الموجودة في الملحق A بعين الاعتبار)، لكنه يوفر حماية محدودة فقط ضد تحليل التدفق.

Offline DPI

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

لا يملك DPI غير المتصل القدرة على حجب الاتصالات الموجودة. يملك DPI غير المتصل القدرة على الإرسال شبه الفوري (خلال دقائق من الإعداد) إلى المضيف/المنفذ للأطراف عبر حقن الحزم. يملك DPI غير المتصل القدرة على إعادة التشغيل شبه الفوري (خلال دقائق من الإعداد) للرسائل السابقة (معدلة أو غير معدلة) لأغراض “الفحص” أو أسباب أخرى.

ليس من الأهداف منع التعرف على البروتوكول بواسطة DPI غير المتصل. جميع عمليات فك التشفير للبيانات المشوشة في الرسالتين الأوليين، والتي يتم تنفيذها بواسطة I2P routers، يمكن أيضاً تنفيذها بواسطة DPI غير المتصل.

الهدف هو رفض محاولات الاتصال التي تستخدم إعادة تشغيل الرسائل السابقة.

Address Validation

ما يلي منسوخ من QUIC RFC 9000. لكل قسم، راجع وعدّل.

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

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

يتم تنفيذ التحقق من صحة العنوان أثناء إنشاء الاتصال (انظر القسم 8.1) وأثناء ترحيل الاتصال (انظر القسم 8.2).

Address Validation during Connection Establishment

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

بالإضافة إلى ذلك، قد تعتبر نقطة النهاية أن عنوان النظير مُتحقق منه إذا استخدم النظير معرف اتصال مُختار من قبل نقطة النهاية ويحتوي معرف الاتصال على 64 بت على الأقل من العشوائية (entropy).

بالنسبة للعميل، فإن قيمة حقل Destination Connection ID في أول حزمة Initial تسمح له بالتحقق من صحة عنوان الخادم كجزء من المعالجة الناجحة لأي حزمة. يتم حماية حزم Initial من الخادم بمفاتيح مشتقة من هذه القيمة (انظر القسم 5.2 من QUIC-TLS). وكبديل، يتم إرجاع هذه القيمة من قبل الخادم في حزم Version Negotiation (القسم 6) أو تضمينها في Integrity Tag في حزم Retry (القسم 5.8 من QUIC-TLS).

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

يجب على العملاء (Clients) التأكد من أن مخططات بيانات UDP التي تحتوي على حزم Initial تحتوي على حمولات UDP بحجم 1200 بايت على الأقل، مع إضافة إطارات PADDING حسب الضرورة. العميل الذي يرسل مخططات بيانات مبطنة يسمح للخادم بإرسال المزيد من البيانات قبل إكمال التحقق من صحة العنوان.

فقدان حزمة Initial أو Handshake من الخادم يمكن أن يسبب تجمد إذا لم يرسل العميل حزم Initial أو Handshake إضافية. يمكن أن يحدث تجمد عندما يصل الخادم إلى حد مكافحة التضخيم الخاص به ويكون العميل قد تلقى إقرارات لجميع البيانات التي أرسلها. في هذه الحالة، عندما لا يكون لدى العميل سبب لإرسال حزم إضافية، سيكون الخادم غير قادر على إرسال المزيد من البيانات لأنه لم يتحقق من عنوان العميل. لمنع هذا التجمد، يجب على العملاء إرسال حزمة عند انتهاء مهلة التحقيق (PTO)؛ انظر القسم 6.2 من QUIC-RECOVERY. تحديداً، يجب على العميل إرسال حزمة Initial في datagram UDP يحتوي على 1200 بايت على الأقل إذا لم يكن لديه مفاتيح Handshake، وإلا فيرسل حزمة Handshake.

قد يرغب الخادم في التحقق من صحة عنوان العميل قبل بدء المصافحة التشفيرية. يستخدم QUIC رمزاً مميزاً في حزمة Initial لتوفير التحقق من صحة العنوان قبل إكمال المصافحة. يتم تسليم هذا الرمز المميز إلى العميل أثناء إنشاء الاتصال باستخدام حزمة Retry (انظر القسم 8.1.2) أو في اتصال سابق باستخدام إطار NEW_TOKEN (انظر القسم 8.1.3).

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

Token Construction

يجب إنشاء الرمز المميز المُرسل في إطار NEW_TOKEN أو حزمة Retry بطريقة تسمح للخادم بتحديد كيفية توفيره للعميل. يتم حمل هذه الرموز المميزة في نفس الحقل ولكنها تتطلب معالجة مختلفة من الخوادم.

Address Validation Using Retry Packets

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

استجابةً لمعالجة حزمة Initial تحتوي على token تم توفيره في حزمة Retry، لا يمكن للخادم إرسال حزمة Retry أخرى؛ يمكنه فقط رفض الاتصال أو السماح له بالمتابعة.

طالما أنه ليس من الممكن للمهاجم إنتاج token صالح لعنوانه الخاص (انظر القسم 8.1.4) وكان العميل قادراً على إرجاع ذلك الـ token، فإن هذا يثبت للخادم أنه استلم الـ token.

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

إذا استقبل الخادم Initial من العميل يحتوي على Retry token غير صالح لكن صالح فيما عدا ذلك، فهو يعلم أن العميل لن يقبل Retry token آخر. يمكن للخادم أن يتجاهل هذه الحزمة ويسمح للعميل بانتهاء المهلة الزمنية لاكتشاف فشل المصافحة، لكن ذلك قد يفرض عقوبة كمون كبيرة على العميل. بدلاً من ذلك، يجب على الخادم أن يغلق (القسم 10.2) الاتصال فوراً مع خطأ INVALID_TOKEN. لاحظ أن الخادم لم ينشئ أي حالة للاتصال في هذه النقطة وبالتالي لا يدخل فترة الإغلاق.

يُظهر الشكل 9 مخططًا توضيحيًا لاستخدام حزمة Retry.

Client                                                  Server

Initial[0]: CRYPTO[CH] ->

                                                <- Retry+Token

Initial+Token[1]: CRYPTO[CH] ->

                                 Initial[0]: CRYPTO[SH] ACK[1]
                       Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
                                 <- 1-RTT[0]: STREAM[1, "..."]

                Figure 9: Example Handshake with Retry

Address Validation for Future Connections

يجوز للخادم أن يزود العملاء برمز التحقق من العنوان (address validation token) خلال اتصال واحد يمكن استخدامه في اتصال لاحق. يُعتبر التحقق من العنوان مهمًا بشكل خاص مع 0-RTT لأن الخادم قد يرسل كمية كبيرة من البيانات إلى العميل ردًا على بيانات 0-RTT.

يستخدم الخادم إطار NEW_TOKEN (القسم 19.7) لتزويد العميل برمز التحقق من صحة العنوان الذي يمكن استخدامه للتحقق من صحة الاتصالات المستقبلية. في اتصال مستقبلي، يتضمن العميل هذا الرمز في حزم Initial لتوفير التحقق من صحة العنوان. يجب على العميل تضمين الرمز في جميع حزم Initial التي يرسلها، ما لم تستبدل Retry الرمز بآخر أحدث. يجب ألا يستخدم العميل الرمز المُقدم في Retry للاتصالات المستقبلية. يجوز للخوادم تجاهل أي حزمة Initial لا تحمل الرمز المتوقع.

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

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

من غير المرجح أن يكون رقم منفذ العميل متطابقًا في اتصالين مختلفين؛ لذلك من غير المرجح أن يكون التحقق من صحة المنفذ ناجحًا.

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

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

يجب على العميل عدم إعادة استخدام رمز من إطار NEW_TOKEN لمحاولات اتصال مختلفة. إعادة استخدام الرمز يسمح بربط الاتصالات من قبل الكيانات الموجودة في مسار الشبكة؛ انظر القسم 9.5.

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

عندما يتلقى الخادم حزمة Initial تحتوي على رمز التحقق من صحة العنوان، يجب عليه محاولة التحقق من صحة الرمز، إلا إذا كان قد أكمل بالفعل عملية التحقق من صحة العنوان. إذا كان الرمز غير صالح، فيجب على الخادم المتابعة كما لو أن العميل لم يكن لديه عنوان محقق، بما في ذلك إرسال حزمة Retry محتملة. يمكن للخوادم التمييز بين الرموز المقدمة مع إطارات NEW_TOKEN وحزم Retry (انظر القسم 8.1.1)، ويمكن التحقق من صحة الأخيرة بصرامة أكبر. إذا نجح التحقق من الصحة، فيجب على الخادم السماح لعملية المصافحة بالمتابعة.

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

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

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

Address Validation Token Integrity

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

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

لا توجد حاجة لتنسيق واحد محدد جيداً للرمز المميز لأن الخادم الذي ينشئ الرمز المميز هو نفسه الذي يستهلكه. الرموز المميزة المرسلة في حزم Retry يجب أن تتضمن معلومات تسمح للخادم بالتحقق من أن عنوان IP المصدر والمنفذ في حزم العميل يبقيان ثابتين.

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

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

فحص الحزم العميق عبر الإنترنت

يتم استخدام التحقق من المسار بواسطة كلا النظيرين أثناء ترحيل الاتصال (انظر القسم 9) للتحقق من إمكانية الوصول بعد تغيير العنوان. في التحقق من المسار، تختبر نقاط النهاية إمكانية الوصول بين عنوان محلي محدد وعنوان نظير محدد، حيث يكون العنوان عبارة عن زوج من عنوان IP والمنفذ.

اختبارات التحقق من المسار تتأكد من أن الحزم المرسلة على مسار إلى peer يتم استلامها من قبل ذلك الـ peer. يُستخدم التحقق من المسار لضمان أن الحزم المستلمة من peer مهاجر لا تحمل عنوان مصدر مزيف.

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

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

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

يمكن لنقطة النهاية أن تتضمن إطارات أخرى مع إطارات PATH_CHALLENGE و PATH_RESPONSE المستخدمة للتحقق من صحة المسار. على وجه الخصوص، يمكن لنقطة النهاية أن تتضمن إطارات PADDING مع إطار PATH_CHALLENGE لاكتشاف الحد الأقصى لوحدة الإرسال للمسار (PMTUD)؛ راجع القسم 14.2.1. يمكن لنقطة النهاية أيضاً أن تتضمن إطار PATH_CHALLENGE الخاص بها عند إرسال إطار PATH_RESPONSE.

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

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

فحص الحزم العميق في وضع عدم الاتصال

لبدء التحقق من المسار، ترسل نقطة النهاية إطار PATH_CHALLENGE يحتوي على حمولة غير قابلة للتنبؤ على المسار المراد التحقق منه.

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

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

يجب على النقطة النهائية استخدام بيانات غير قابلة للتنبؤ في كل إطار PATH_CHALLENGE بحيث يمكنها ربط استجابة النظير مع PATH_CHALLENGE المقابل.

يجب على نقطة النهاية توسيع الـ datagrams التي تحتوي على إطار PATH_CHALLENGE إلى ما لا يقل عن أصغر حجم أقصى مسموح للـ datagram وهو 1200 بايت، ما لم يكن حد مكافحة التضخيم للمسار لا يسمح بإرسال datagram بهذا الحجم. إرسال UDP datagrams بهذا الحجم يضمن أن مسار الشبكة من نقطة النهاية إلى النظير يمكن استخدامه لـ QUIC؛ انظر القسم 14.

عندما يكون endpoint غير قادر على توسيع حجم الـ datagram إلى 1200 بايت بسبب حد مكافحة التضخيم، فإن path MTU لن يتم التحقق من صحتها. لضمان أن path MTU كبيرة بما فيه الكفاية، يجب على الـ endpoint تنفيذ تحقق ثانٍ من المسار عن طريق إرسال إطار PATH_CHALLENGE في datagram بحجم 1200 بايت على الأقل. يمكن تنفيذ هذا التحقق الإضافي بعد استلام PATH_RESPONSE بنجاح أو عندما يتم استلام بايتات كافية على المسار بحيث إرسال الـ datagram الأكبر لن يؤدي إلى تجاوز حد مكافحة التضخيم.

بخلاف الحالات الأخرى حيث يتم توسيع البيانات المجمعة (datagrams)، يجب على نقاط النهاية عدم تجاهل البيانات المجمعة التي تبدو صغيرة جداً عندما تحتوي على PATH_CHALLENGE أو PATH_RESPONSE.

Path Validation Responses

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

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

يجب على نقطة النهاية توسيع الـ datagrams التي تحتوي على إطار PATH_RESPONSE إلى ما لا يقل عن أصغر حد أقصى مسموح لحجم الـ datagram وهو 1200 بايت. هذا يتحقق من أن المسار قادر على حمل datagrams بهذا الحجم في كلا الاتجاهين. ومع ذلك، يجب على نقطة النهاية عدم توسيع الـ datagram الذي يحتوي على PATH_RESPONSE إذا كانت البيانات الناتجة تتجاوز حد مكافحة التضخيم. من المتوقع أن يحدث هذا فقط إذا لم يتم إرسال PATH_CHALLENGE المستلم في datagram موسع.

يجب على نقطة النهاية ألا ترسل أكثر من إطار PATH_RESPONSE واحد ردًا على إطار PATH_CHALLENGE واحد؛ انظر القسم 13.3. من المتوقع أن يرسل النظير المزيد من إطارات PATH_CHALLENGE حسب الضرورة لاستثارة إطارات PATH_RESPONSE إضافية.

التحقق من صحة العنوان أثناء إنشاء الاتصال

يتم التحقق من صحة المسار بنجاح عندما يتم استلام إطار PATH_RESPONSE يحتوي على البيانات التي تم إرسالها في إطار PATH_CHALLENGE سابق. إطار PATH_RESPONSE المستلم على أي مسار شبكة يتحقق من صحة المسار الذي تم إرسال PATH_CHALLENGE عليه.

إذا أرسل endpoint إطار PATH_CHALLENGE في datagram لم يتم توسيعه إلى 1200 بايت على الأقل وإذا كان الرد عليه يتحقق من عنوان النظير، فإن المسار يتم التحقق منه لكن ليس path MTU. ونتيجة لذلك، يمكن للـ endpoint الآن إرسال أكثر من ثلاثة أضعاف كمية البيانات التي تم استقبالها. ومع ذلك، يجب على الـ endpoint بدء التحقق من المسار مرة أخرى باستخدام datagram موسع للتأكد من أن المسار يدعم الـ MTU المطلوب.

استلام إقرار لحزمة تحتوي على إطار PATH_CHALLENGE غير كافٍ للتحقق، حيث يمكن للنظير الخبيث تزوير الإقرار.

بناء الرمز المميز

التحقق من المسار يفشل فقط عندما تتخلى النقطة النهائية التي تحاول التحقق من المسار عن محاولتها للتحقق من المسار.

يجب على endpoints التخلي عن path validation بناءً على مؤقت. عند تعيين هذا المؤقت، يُحذر المطبقون من أن المسار الجديد قد يكون له وقت رحلة ذهاب وإياب أطول من المسار الأصلي. يُوصى بقيمة تساوي ثلاثة أضعاف الأكبر من PTO الحالي أو PTO للمسار الجديد (باستخدام kInitialRtt، كما هو محدد في QUIC-RECOVERY).

هذا المهلة الزمنية تسمح بانتهاء صلاحية عدة PTOs قبل فشل التحقق من صحة المسار، بحيث أن فقدان إطار PATH_CHALLENGE أو PATH_RESPONSE واحد لا يتسبب في فشل التحقق من صحة المسار.

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

عندما تتخلى نقطة نهاية عن التحقق من المسار، فإنها تحدد أن المسار غير قابل للاستخدام. هذا لا يعني بالضرورة فشل الاتصال – يمكن لنقاط النهاية الاستمرار في إرسال الحزم عبر مسارات أخرى حسب الحاجة. إذا لم تكن هناك مسارات متاحة، يمكن لنقطة النهاية انتظار توفر مسار جديد أو إغلاق الاتصال. نقطة النهاية التي ليس لديها مسار شبكة صالح إلى النظير يمكنها الإشارة إلى هذا باستخدام خطأ الاتصال NO_VIABLE_PATH، مع ملاحظة أن هذا ممكن فقط إذا كان مسار الشبكة موجوداً ولكن لا يدعم MTU المطلوب (القسم 14).

قد يتم التخلي عن التحقق من المسار لأسباب أخرى غير الفشل. في المقام الأول، يحدث هذا إذا تم بدء ترحيل الاتصال إلى مسار جديد بينما التحقق من المسار على المسار القديم قيد التقدم.

Connection Migration

ما يلي منسوخ من QUIC RFC 9000. لكل قسم، راجع وعدّل.

يتيح استخدام معرف الاتصال (connection ID) للاتصالات البقاء رغم التغييرات في عناوين نقاط النهاية (عنوان IP والمنفذ)، مثل تلك التي تحدث عندما تنتقل نقطة النهاية إلى شبكة جديدة. يصف هذا القسم العملية التي تنتقل بها نقطة النهاية إلى عنوان جديد.

يعتمد تصميم QUIC على احتفاظ نقاط النهاية بعنوان مستقر طوال مدة المصافحة. يجب على نقطة النهاية عدم بدء ترحيل الاتصال قبل تأكيد المصافحة، كما هو محدد في القسم 4.1.2 من QUIC-TLS.

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

ليست جميع تغييرات عنوان النظير مقصودة أو فعالة للهجرة. يمكن أن يواجه النظير إعادة ربط NAT: تغيير في العنوان بسبب صندوق وسطي، عادة NAT، يخصص منفذ صادر جديد أو حتى عنوان IP صادر جديد للتدفق. يجب على نقطة النهاية تنفيذ التحقق من المسار (القسم 8.2) إذا اكتشفت أي تغيير في عنوان النظير، ما لم تكن قد تحققت مسبقاً من ذلك العنوان.

عندما لا تحتوي نقطة النهاية على مسار موثوق لإرسال الحزم عليه، قد تتجاهل حالة الاتصال. قد تنتظر نقطة النهاية القادرة على ترحيل الاتصال حتى يصبح مسار جديد متاحًا قبل تجاهل حالة الاتصال.

تقيد هذه الوثيقة انتقال الاتصالات إلى عناوين العملاء الجديدة، باستثناء ما هو موضح في القسم 9.6. العملاء مسؤولون عن بدء جميع عمليات الانتقال. لا ترسل الخوادم حزم غير استطلاعية (انظر القسم 9.1) نحو عنوان عميل حتى ترى حزمة غير استطلاعية من ذلك العنوان. إذا تلقى عميل حزماً من عنوان خادم غير معروف، يجب على العميل تجاهل هذه الحزم.

التحقق من صحة العنوان باستخدام حزم إعادة المحاولة

يمكن لنقطة النهاية أن تختبر إمكانية الوصول إلى النظير من عنوان محلي جديد باستخدام التحقق من صحة المسار (القسم 8.2) قبل ترحيل الاتصال إلى العنوان المحلي الجديد. فشل التحقق من صحة المسار يعني ببساطة أن المسار الجديد غير قابل للاستخدام لهذا الاتصال. فشل التحقق من صحة المسار لا يؤدي إلى إنهاء الاتصال إلا إذا لم تكن هناك مسارات بديلة صحيحة متاحة.

إطارات PATH_CHALLENGE و PATH_RESPONSE و NEW_CONNECTION_ID و PADDING هي “إطارات استكشاف”، وجميع الإطارات الأخرى هي “إطارات غير استكشافية”. الحزمة التي تحتوي على إطارات استكشاف فقط هي “حزمة استكشاف”، والحزمة التي تحتوي على أي إطار آخر هي “حزمة غير استكشافية”.

التحقق من صحة العنوان للاتصالات المستقبلية

يمكن لنقطة النهاية ترحيل اتصال إلى عنوان محلي جديد عن طريق إرسال حزم تحتوي على إطارات غير استقصائية من ذلك العنوان.

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

لإنشاء قابلية الوصول على المسار الجديد، تبدأ نقطة النهاية path validation (القسم 8.2) على المسار الجديد. يمكن لنقطة النهاية تأجيل path validation حتى بعد أن يرسل النظير الإطار non-probing التالي إلى عنوانها الجديد.

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

المسار الجديد قد لا يحتوي على نفس قدرة ECN. لذلك، تقوم نقطة النهاية بالتحقق من صحة قدرة ECN كما هو موضح في القسم 13.4.

سلامة رمز التحقق من صحة العنوان

استلام حزمة من عنوان نظير جديد تحتوي على إطار غير استكشافي يشير إلى أن النظير قد انتقل إلى ذلك العنوان.

إذا سمح المُستقبِل بالترحيل، فيجب عليه إرسال الحزم اللاحقة إلى عنوان النظير الجديد ويجب عليه بدء التحقق من صحة المسار (القسم 8.2) للتأكد من ملكية النظير للعنوان إذا لم يكن التحقق جاريًا بالفعل. إذا لم تكن لدى المُستقبِل معرفات اتصال غير مستخدمة من النظير، فلن يتمكن من إرسال أي شيء على المسار الجديد حتى يوفر النظير واحدًا؛ انظر القسم 9.5.

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

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

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

استقبال حزمة من عنوان نظير جديد يمكن أن يكون نتيجة إعادة ربط NAT عند النظير.

بعد التحقق من عنوان عميل جديد، يجب على الخادم إرسال رموز التحقق من العنوان الجديدة (القسم 8) إلى العميل.

التحقق من صحة المسار

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

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

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

بدء التحقق من المسار

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

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

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

ردود التحقق من صحة المسار

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

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

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

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

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

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

يمكن لنقطة النهاية أيضًا استخدام الاستدلالات (heuristics) لتحسين اكتشاف هذا النوع من الهجمات. على سبيل المثال، إعادة ربط NAT غير محتملة إذا تم استقبال حزم مؤخرًا على المسار القديم؛ وبالمثل، إعادة الربط نادرة على مسارات IPv6. يمكن لنقاط النهاية أيضًا البحث عن الحزم المكررة. وعلى النقيض، فإن التغيير في معرف الاتصال (connection ID) أكثر احتمالاً للإشارة إلى هجرة مقصودة بدلاً من هجوم.

التحقق الناجح من المسار

السعة المتاحة على المسار الجديد قد لا تكون مماثلة للمسار القديم. يجب ألا تساهم الحزم المرسلة على المسار القديم في التحكم بالازدحام أو تقدير RTT للمسار الجديد.

عند تأكيد ملكية النظير لعنوانه الجديد، يجب على نقطة النهاية إعادة تعيين متحكم الازدحام ومقدر زمن الرحلة الإجمالية للمسار الجديد إلى القيم الأولية فوراً (راجع الملاحق A.3 و B.3 من QUIC-RECOVERY) إلا إذا كان التغيير الوحيد في عنوان النظير هو رقم المنفذ الخاص به. نظراً لأن التغييرات المقتصرة على المنفذ عادة ما تكون نتيجة إعادة ربط NAT أو نشاط middlebox آخر، قد تحتفظ نقطة النهاية بدلاً من ذلك بحالة التحكم في الازدحام وتقدير زمن الرحلة الإجمالية في تلك الحالات بدلاً من العودة إلى القيم الأولية. في الحالات التي يتم فيها استخدام حالة التحكم في الازدحام المحتفظ بها من مسار قديم على مسار جديد ذو خصائص مختلفة جوهرياً، قد يقوم المرسل بالإرسال بقوة مفرطة حتى يتكيف متحكم الازدحام ومقدر RTT. بشكل عام، يُنصح التطبيقات بالحذر عند استخدام القيم السابقة على مسار جديد.

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

بينما قد يتم استخدام مسارات متعددة أثناء ترحيل الاتصال، قد يكون سياق تحكم واحد في الازدحام وسياق واحد لاستعادة الفقدان (كما هو موصوف في QUIC-RECOVERY) كافيين. على سبيل المثال، قد تؤخر نقطة النهاية التبديل إلى سياق تحكم جديد في الازدحام حتى يتم التأكد من أن المسار القديم لم يعد مطلوباً (مثل الحالة الموصوفة في القسم 9.3.3).

يمكن للمُرسل إنشاء استثناءات لحزم الاستطلاع بحيث يكون اكتشاف فقدانها مستقلاً ولا يؤدي بشكل غير مبرر إلى قيام مُتحكم الازدحام بتقليل معدل الإرسال. قد تقوم نقطة النهاية بتعيين مؤقت منفصل عند إرسال PATH_CHALLENGE، والذي يتم إلغاؤه إذا تم استقبال PATH_RESPONSE المطابق. إذا انتهت صلاحية المؤقت قبل استقبال PATH_RESPONSE، فقد تقوم نقطة النهاية بإرسال PATH_CHALLENGE جديد وإعادة تشغيل المؤقت لفترة زمنية أطول. يجب (SHOULD) تعيين هذا المؤقت كما هو موضح في القسم 6.2.1 من QUIC-RECOVERY ويجب ألا (MUST NOT) يكون أكثر عدوانية.

فشل التحقق من المسار

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

في أي وقت، يُمكن لنقاط النهاية تغيير معرف اتصال الوجهة (Destination Connection ID) الذي ترسله إلى قيمة لم يتم استخدامها في مسار آخر.

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

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

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

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

نقطة نهاية يجب ألا تبدأ migration مع peer طلب connection ID بطول صفر، لأن حركة البيانات عبر المسار الجديد قد تكون قابلة للربط بشكل تافه مع حركة البيانات عبر المسار القديم. إذا كان الخادم قادراً على ربط الحزم التي تحتوي على connection ID بطول صفر بالاتصال الصحيح، فهذا يعني أن الخادم يستخدم معلومات أخرى لفصل الحزم. على سبيل المثال، قد يوفر الخادم عنواناً فريداً لكل عميل – على سبيل المثال، باستخدام HTTP alternative services ALTSVC. المعلومات التي قد تسمح بالتوجيه الصحيح للحزم عبر مسارات شبكة متعددة ستسمح أيضاً بربط النشاط على تلك المسارات من قبل كيانات أخرى غير الـ peer.

قد يرغب العميل في تقليل إمكانية الربط من خلال التبديل إلى connection ID جديد، أو منفذ UDP مصدر جديد، أو عنوان IP جديد (انظر RFC8981) عند إرسال حركة البيانات بعد فترة من عدم النشاط. تغيير العنوان الذي يرسل منه الحزم في نفس الوقت قد يتسبب في قيام الخادم بكشف migration الاتصال. هذا يضمن أن الآليات التي تدعم migration يتم تفعيلها حتى للعملاء الذين لا يواجهون إعادة ربط NAT أو migration حقيقية. تغيير العنوان يمكن أن يتسبب في قيام النظير بإعادة تعيين حالة congestion control الخاصة به (انظر القسم 9.4)، لذلك يجب تغيير العناوين بشكل نادر فقط.

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

Server’s Preferred Address

يسمح QUIC للخوادم بقبول الاتصالات على عنوان IP واحد ومحاولة نقل هذه الاتصالات إلى عنوان مفضل بعد وقت قصير من المصافحة. هذا مفيد بشكل خاص عندما يتصل العملاء في البداية بعنوان مشترك بين عدة خوادم ولكنهم يفضلون استخدام عنوان unicast لضمان استقرار الاتصال. يصف هذا القسم البروتوكول لترحيل اتصال إلى عنوان خادم مفضل.

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

استطلاع مسار جديد

يقوم الخادم بنقل العنوان المفضل من خلال تضمين معامل النقل preferred_address في مصافحة TLS.

يمكن للخوادم إرسال عنوان مفضل من كل عائلة عناوين (IPv4 و IPv6) للسماح للعملاء باختيار الأنسب لاتصالهم بالشبكة.

بمجرد تأكيد المصافحة، يجب على العميل اختيار أحد العنوانين المقدمين من الخادم وبدء التحقق من المسار (انظر القسم 8.2). يقوم العميل ببناء الحزم باستخدام أي معرف اتصال نشط غير مستخدم سابقاً، مأخوذ إما من معامل النقل preferred_address أو من إطار NEW_CONNECTION_ID.

بمجرد نجاح التحقق من المسار، يجب على العميل البدء في إرسال جميع الحزم المستقبلية إلى عنوان الخادم الجديد باستخدام معرف الاتصال الجديد والتوقف عن استخدام عنوان الخادم القديم. إذا فشل التحقق من المسار، يجب على العميل الاستمرار في إرسال جميع الحزم المستقبلية إلى عنوان IP الأصلي للخادم.

بدء ترحيل الاتصال

العميل الذي ينتقل إلى عنوان مفضل يجب أن يتحقق من صحة العنوان الذي يختاره قبل الانتقال؛ انظر القسم 21.5.3.

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

يجب على الخادم أن يقوم بالفحص على المسار نحو العميل من عنوانه المفضل. هذا يساعد في الحماية من الهجرة المزيفة التي يبدأها مهاجم.

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

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

الاستجابة لترحيل الاتصال

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

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

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

يجب على الخوادم بدء التحقق من المسار إلى عنوان العميل الجديد عند استلام حزمة probe من عنوان مختلف؛ انظر القسم 8.

العميل الذي ينتقل إلى عنوان جديد يجب أن يستخدم عنواناً مفضلاً من نفس عائلة العناوين للخادم.

معرف الاتصال المُقدم في معامل النقل preferred_address ليس محددًا للعناوين المُقدمة. يتم توفير معرف الاتصال هذا لضمان أن العميل لديه معرف اتصال متاح للترحيل، لكن العميل قد يستخدم معرف الاتصال هذا على أي مسار.

انتحال عنوان النظير

يُوصي QUIC بأن النقاط الطرفية التي ترسل البيانات باستخدام IPv6 يجب أن تطبق تسمية تدفق IPv6 وفقاً لـ RFC 6437، ما لم تكن واجهة برمجة التطبيقات المحلية لا تسمح بتعيين تسميات تدفق IPv6.

لسوء الحظ، لا تسمح Java API بتعيين تسميات تدفق IPv6.

الأهداف غير المطلوبة

فيما يلي نسخة من QUIC RFC 9000. لكل قسم، راجع وحرر.

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

انتحال العنوان على المسار

تحليل أمني كامل لـ QUIC خارج نطاق هذه الوثيقة. يوفر هذا القسم وصفاً غير رسمي للخصائص الأمنية المرغوبة كمساعدة للمطورين وللمساعدة في توجيه تحليل البروتوكول.

يفترض QUIC نموذج التهديد الموصوف في SEC-CONS ويوفر حماية ضد العديد من الهجمات التي تنشأ من هذا النموذج.

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

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

خصائص المصافحة والحزم المحمية وترحيل الاتصال تُعتبر بشكل منفصل.

إعادة توجيه الحزم خارج المسار

تتضمن مصافحة QUIC مصافحة TLS 1.3 وترث الخصائص التشفيرية الموضحة في الملحق E.1 من TLS13. تعتمد العديد من خصائص الأمان في QUIC على مصافحة TLS التي توفر هذه الخصائص. أي هجوم على مصافحة TLS يمكن أن يؤثر على QUIC.

أي هجوم على TLS handshake يؤثر على سرية أو تفرد مفاتيح الجلسة، أو على مصادقة الأطراف المشاركة، يؤثر على الضمانات الأمنية الأخرى التي يوفرها QUIC والتي تعتمد على تلك المفاتيح. على سبيل المثال، يعتمد migration (القسم 9) على فعالية حماية السرية، سواء لتفاوض المفاتيح باستخدام TLS handshake أو لحماية حزم QUIC، لتجنب إمكانية الربط عبر مسارات الشبكة.

هجوم على سلامة مصافحة TLS قد يسمح للمهاجم بالتأثير على اختيار بروتوكول التطبيق أو إصدار QUIC.

بالإضافة إلى الخصائص التي يوفرها TLS، فإن مصافحة QUIC توفر بعض الدفاع ضد هجمات DoS على المصافحة.

كشف الفقدان والتحكم في الازدحام

التحقق من العنوان (القسم 8) يُستخدم للتأكد من أن الكيان الذي يدعي عنوانًا معينًا قادر على استقبال الحزم على ذلك العنوان. يحد التحقق من العنوان من أهداف هجمات التضخيم إلى العناوين التي يمكن للمهاجم مراقبة الحزم عليها.

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

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

الآثار المترتبة على الخصوصية من هجرة الاتصال

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

عنوان الخادم المفضل

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

يمكن للمهاجم الموجود على المسار أيضًا استبدال عناوين الحزم على أي من الجانبين وبالتالي جعل العميل أو الخادم يحصل على رؤية غير صحيحة للعناوين البعيدة. مثل هذا الهجوم لا يمكن تمييزه عن الوظائف التي يؤديها NAT.

التواصل مع عنوان مُفضّل

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

معرفات الاتصال غير مشفرة ولكنها محمية من ناحية التكامل في جميع الحزم.

هذا الإصدار من QUIC لا يتضمن آلية تفاوض الإصدار؛ تطبيقات الإصدارات غير المتوافقة ستفشل ببساطة في إنشاء اتصال.

الانتقال إلى عنوان مفضل

حماية الحزم (القسم 12.1) تطبق التشفير المصادق عليه على جميع الحزم باستثناء حزم التفاوض على الإصدار، رغم أن الحزم الأولية وحزم إعادة المحاولة لديها حماية محدودة بسبب استخدام مادة المفاتيح الخاصة بالإصدار؛ انظر QUIC-TLS لمزيد من التفاصيل. يتناول هذا القسم الهجمات السلبية والنشطة ضد الحزم المحمية.

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

مهاجم يحقن حزم دون أن يكون قادراً على مراقبة حزم صالحة لاتصال معين من غير المرجح أن ينجح، حيث أن حماية الحزم تضمن أن الحزم الصالحة يتم إنتاجها فقط بواسطة نقاط النهاية التي تمتلك المواد الرئيسية المُؤسسة أثناء المصافحة؛ راجع الأقسام 7 و 21.1.1. وبالمثل، أي مهاجم نشط يراقب الحزم ويحاول إدراج بيانات جديدة أو تعديل البيانات الموجودة في تلك الحزم لا ينبغي أن يكون قادراً على إنتاج حزم تُعتبر صالحة من قِبل نقطة النهاية المستقبِلة، باستثناء حزم Initial.

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

يمكن للمهاجم أيضاً تعديل الحدود بين الحزم و UDP datagrams، مما يؤدي إلى دمج عدة حزم في datagram واحد أو تقسيم الحزم المدمجة إلى عدة datagrams. باستثناء datagrams التي تحتوي على حزم Initial والتي تتطلب padding، فإن تعديل طريقة ترتيب الحزم في datagrams لا يؤثر وظيفياً على الاتصال، رغم أنه قد يغير بعض خصائص الأداء.

تفاعل ترحيل العميل والعنوان المفضل

ترحيل الاتصال (القسم 9) يوفر لنقاط النهاية القدرة على الانتقال بين عناوين IP والمنافذ على مسارات متعددة، باستخدام مسار واحد في كل مرة لإرسال واستقبال الإطارات غير الاستطلاعية. التحقق من صحة المسار (القسم 8.2) يؤكد أن النظير راغب وقادر على استقبال الحزم المرسلة على مسار معين. هذا يساعد في تقليل آثار انتحال العناوين من خلال الحد من عدد الحزم المرسلة إلى عنوان منتحل.

يصف هذا القسم خصائص الأمان المقصودة لهجرة الاتصال تحت أنواع مختلفة من هجمات DoS.

استخدام تسمية تدفق IPv6 والترحيل

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

يمكن للمهاجم الموجود على المسار أن:

• فحص الحزم

• تعديل رؤوس حزم IP و UDP

• حقن حزم جديدة

• تأخير الحزم

• إعادة ترتيب الحزم

• إسقاط الحزم

• تقسيم ودمج البيانات المجمعة (datagrams) على حدود الحزم

المهاجم الموجود على المسار لا يستطيع:

• تعديل جزء مصادق عليه من حزمة البيانات والتسبب في قبول المستقبل لتلك الحزمة

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

يهدف QUIC إلى تقييد قدرات المهاجم الموجود على المسار كما يلي:

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

2. يمكن للمهاجم الموجود على المسار منع الانتقال إلى مسار جديد يكون المهاجم موجوداً عليه أيضاً من خلال التسبب في فشل التحقق من صحة المسار الجديد.

3. لا يمكن للمهاجم الموجود على المسار منع العميل من الانتقال إلى مسار لا يكون المهاجم موجوداً عليه.

4. يمكن للمهاجم الموجود على المسار أن يقلل من إنتاجية الاتصال عن طريق تأخير الحزم أو إسقاطها.

5. لا يمكن لمهاجم على المسار أن يتسبب في قبول نقطة النهاية لحزمة قام بتعديل جزء مُصادق عليه من تلك الحزمة.

Off-Path Active Attacks

مهاجم خارج المسار ليس موجوداً مباشرة على المسار بين العميل والخادم ولكن قد يكون قادراً على الحصول على نسخ من بعض أو جميع الحزم المرسلة بين العميل والخادم. كما أنه قادر على إرسال نسخ من تلك الحزم إلى أي من نقطتي النهاية.

يمكن للمهاجم خارج المسار أن:

• فحص الحزم

• حقن حزم جديدة

• إعادة ترتيب الحزم المحقونة

مهاجم خارج المسار لا يستطيع:

• تعديل الحزم المرسلة من نقاط النهاية

• تأخير الحزم

• إسقاط الحزم

• إعادة ترتيب الحزم الأصلية

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

لأغراض هذه المناقشة، يُفترض أن المهاجم خارج المسار لديه القدرة على حقن نسخة معدلة من الحزمة في الشبكة ستصل إلى نقطة النهاية الوجهة قبل وصول الحزمة الأصلية التي لاحظها المهاجم. بعبارة أخرى، المهاجم لديه القدرة على “الفوز” باستمرار في سباق مع الحزم المشروعة بين نقاط النهاية، مما قد يؤدي إلى تجاهل المستقبِل للحزمة الأصلية.

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

يهدف QUIC إلى تقييد قدرات المهاجم خارج المسار كما يلي:

1. يمكن للمهاجم خارج المسار (off-path attacker) أن يتسابق مع الحزم ويحاول أن يصبح مهاجماً “محدوداً” على المسار (on-path attacker).

2. يمكن لمهاجم خارج المسار (off-path attacker) أن يتسبب في نجاح التحقق من صحة المسار للحزم المُعاد توجيهها مع عنوان المصدر المُدرج كمهاجم خارج المسار طالما أنه يستطيع توفير اتصال محسّن بين العميل والخادم.

3. لا يستطيع المهاجم خارج المسار إغلاق الاتصال بمجرد اكتمال عملية المصافحة.

4. مهاجم خارج المسار لا يمكنه التسبب في فشل الهجرة إلى مسار جديد إذا لم يتمكن من مراقبة المسار الجديد.

5. يمكن للمهاجم خارج المسار (off-path attacker) أن يصبح مهاجماً محدوداً على المسار (limited on-path attacker) أثناء الانتقال إلى مسار جديد يكون فيه أيضاً مهاجماً خارج المسار.

6. يمكن للمهاجم خارج المسار (off-path attacker) أن يصبح مهاجماً محدوداً على المسار من خلال التأثير على حالة NAT المشتركة بحيث يرسل حزم البيانات إلى الخادم من نفس عنوان IP والمنفذ الذي استخدمه العميل في الأصل.

نظرة عامة على خصائص الأمان

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

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

يمكن لمهاجم محدود على المسار أن:

• فحص الحزم

• حقن حزم جديدة

• تعديل رؤوس الحزم غير المشفرة

• إعادة ترتيب الحزم

مهاجم محدود على المسار لا يمكنه:

• تأخير الحزم بحيث تصل متأخرة عن الحزم المرسلة عبر المسار الأصلي

• إسقاط الحزم

• تعديل الجزء المُصادق عليه والمُشفر من الحزمة وجعل المُستقبِل يقبل تلك الحزمة

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

يهدف QUIC إلى تقييد قدرات مهاجم محدود خارج المسار كما يلي:

1. مهاجم محدود على المسار لا يمكنه إجبار الاتصال على الإغلاق بمجرد اكتمال المصافحة.

2. مُهاجم محدود على المسار لا يمكنه إجبار اتصال خامل على الإغلاق إذا كان العميل أول من يستأنف النشاط.

3. يمكن للمهاجم المحدود على المسار أن يتسبب في اعتبار الاتصال الخامل مفقوداً إذا كان الخادم أول من يستأنف النشاط.

لاحظ أن هذه الضمانات هي نفس الضمانات المقدمة لأي NAT، لنفس الأسباب.

مصافحة

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

بمجرد إنشاء الاتصال، قد تقبل نقاط النهاية QUIC بعض حزم ICMP غير المصادق عليها (انظر القسم 14.2.1)، لكن استخدام هذه الحزم محدود للغاية. النوع الوحيد الآخر من الحزم التي قد تقبله نقطة النهاية هو إعادة تعيين بلا حالة (القسم 10.3)، والذي يعتمد على الاحتفاظ بالرمز المميز سرياً حتى يتم استخدامه.

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

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

حقول Source و Destination Connection ID هي الوسيلة الأساسية للحماية ضد الهجمات خارج المسار أثناء المصافحة؛ راجع القسم 8.1. يجب أن تتطابق هذه الحقول مع تلك التي حددها النظير. باستثناء Initial و Stateless Resets، تقبل نقطة النهاية فقط الحزم التي تتضمن حقل Destination Connection ID يطابق قيمة اختارتها نقطة النهاية مسبقاً. هذه هي الحماية الوحيدة المقدمة لحزم Version Negotiation.

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

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

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

مكافحة التضخيم

قد يتمكن مهاجم من استقبال رمز التحقق من العنوان (القسم 8) من خادم ثم تحرير عنوان IP الذي استخدمه للحصول على ذلك الرمز. في وقت لاحق، يمكن للمهاجم بدء اتصال 0-RTT مع خادم عبر انتحال نفس العنوان، والذي قد يشير الآن إلى نقطة نهاية مختلفة (ضحية). وبالتالي يمكن للمهاجم أن يتسبب في قيام الخادم بإرسال كمية من البيانات تعادل نافذة الازدحام الأولية نحو الضحية.

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

هجمات حجب الخدمة من جانب الخادم

نقطة نهاية تقر بوصول حزم لم تتلقها قد تتسبب في السماح لمتحكم الازدحام بالإرسال بمعدلات تتجاوز ما تدعمه الشبكة. يمكن لنقطة النهاية تخطي أرقام الحزم عند إرسال الحزم لاكتشاف هذا السلوك. يمكن لنقطة النهاية حينها إغلاق الاتصال فوراً مع خطأ اتصال من نوع PROTOCOL_VIOLATION؛ انظر القسم 10.2.

إنهاء المصافحة على المسار

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

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

على سبيل المثال، استغلال تزوير الطلبات عبر المواقع CSRF على الويب يؤدي إلى قيام العميل بإصدار طلبات تتضمن ملفات تعريف الارتباط للتفويض COOKIE، مما يسمح لموقع واحد بالوصول إلى المعلومات والإجراءات التي من المفترض أن تكون مقيدة على موقع مختلف.

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

يناقش هذا القسم الطرق التي قد يُستخدم بها QUIC في هجمات تزوير الطلبات.

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

نظرًا لأن هجوم الترحيل الموصوف في القسم 21.5.4 قوي جداً ولا يحتوي على تدابير مضادة كافية، يجب على تطبيقات خادم QUIC أن تفترض أن المهاجمين يمكنهم جعلها تولد حمولات UDP عشوائية إلى وجهات عشوائية. يجب ألا يتم نشر خوادم QUIC في الشبكات التي لا تنشر ترشيح الدخل BCP38 والتي تحتوي أيضاً على نقاط نهاية UDP غير محمية بشكل كافٍ.

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

تفاوض المعاملات

يوفر QUIC بعض الفرص للمهاجم للتأثير أو السيطرة على المكان الذي يرسل إليه نظيره حزم UDP البيانية:

• إنشاء الاتصال الأولي (القسم 7)، حيث يمكن للخادم اختيار المكان الذي يرسل إليه العميل البيانات – على سبيل المثال، عن طريق ملء سجلات DNS؛

• العناوين المفضلة (القسم 9.6)، حيث يتمكن الخادم من اختيار المكان الذي يرسل إليه العميل البيانات؛

• هجرات الاتصال المزيفة (القسم 9.3.1)، حيث يكون العميل قادراً على استخدام انتحال عنوان المصدر لتحديد المكان الذي يرسل إليه الخادم الرسائل اللاحقة؛ و

• الحزم المزيفة التي تتسبب في قيام الخادم بإرسال حزمة Version Negotiation (القسم 21.5.5).

في جميع الحالات، يمكن للمهاجم أن يتسبب في قيام النظير الخاص به بإرسال رزم البيانات إلى ضحية قد لا تفهم QUIC. أي أن هذه الحزم يتم إرسالها من قِبل النظير قبل التحقق من صحة العنوان؛ انظر القسم 8.

خارج الجزء المشفر من الحزم، يوفر QUIC لنقطة النهاية عدة خيارات للتحكم في محتوى مخططات بيانات UDP التي يرسلها النظير الخاص بها. يوفر حقل معرف الاتصال الوجهة تحكماً مباشراً في البايتات التي تظهر مبكراً في الحزم المرسلة من قبل النظير؛ انظر القسم 5.1. يوفر حقل الرمز المميز في الحزم الأولية للخادم تحكماً في بايتات أخرى من الحزم الأولية؛ انظر القسم 17.2.2.

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

يفترض هذا القسم أن تقييد التحكم في محتوى datagram غير قابل للتطبيق. ينصب تركيز التدابير الوقائية في الأقسام اللاحقة على تقييد الطرق التي يمكن من خلالها استخدام datagrams التي يتم إرسالها قبل التحقق من صحة العنوان لتزوير الطلبات.

الحزم المحمية

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

حماية الحزم الأولية (القسم 5.2 من QUIC-TLS) تجعل من الصعب على الخوادم التحكم في محتوى الحزم الأولية المرسلة من العملاء. اختيار العميل لـ Destination Connection ID غير قابل للتنبؤ يضمن أن الخوادم غير قادرة على التحكم في أي جزء من الأجزاء المشفرة للحزم الأولية من العملاء.

ومع ذلك، فإن حقل Token مفتوح لتحكم الخادم ويسمح للخادم باستخدام العملاء لشن هجمات تزوير الطلبات. إن استخدام الرموز المميزة المقدمة مع إطار NEW_TOKEN (القسم 8.1.3) يوفر الخيار الوحيد لتزوير الطلبات أثناء إنشاء الاتصال.

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

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

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

ترحيل الاتصال

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

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

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

الهجمات النشطة على المسار

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

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

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

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

هجمات نشطة خارج المسار

العملاء الذين يمكنهم عرض عنوان مصدر مزيف على الحزمة يمكن أن يتسببوا في قيام الخادم بإرسال حزمة Version Negotiation (القسم 17.2.1) إلى ذلك العنوان.

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

لا يتم توفير تدابير مضادة محددة لهذا الهجوم، رغم أن الحماية العامة (القسم 21.5.6) يمكن أن تنطبق. في هذه الحالة، تكون تصفية ingress BCP38 فعالة أيضاً.

هجمات نشطة محدودة على المسار

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

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

وبالمثل، يمكن للنقاط النهائية اعتبار تغيير العنوان إلى عنوان محلي للرابط RFC4291 أو عنوان في نطاق الاستخدام الخاص RFC1918 من عنوان عالمي، أو محلي فريد RFC4193، أو عنوان غير خاص كمحاولة محتملة لتزوير الطلب. يمكن للنقاط النهائية رفض استخدام هذه العناوين بالكامل، ولكن ذلك يحمل خطراً كبيراً من التدخل في الاستخدامات المشروعة. يجب على النقاط النهائية عدم رفض استخدام عنوان ما إلا إذا كان لديها معرفة محددة حول الشبكة تشير إلى أن إرسال حزم البيانات إلى عناوين غير مُتحقق منها في نطاق معين غير آمن.

قد تختار نقاط النهاية تقليل مخاطر تزوير الطلبات من خلال عدم تضمين القيم من إطارات NEW_TOKEN في حزم Initial أو من خلال إرسال إطارات الاستكشاف فقط في الحزم قبل إكمال التحقق من صحة العنوان. لاحظ أن هذا لا يمنع المهاجم من استخدام حقل Destination Connection ID في الهجوم.

لا يُتوقع من endpoints أن تمتلك معلومات محددة حول موقع الخوادم التي يمكن أن تكون أهدافاً ضعيفة لهجوم تزوير الطلبات. ومع ذلك، قد يكون من الممكن بمرور الوقت تحديد منافذ UDP معينة تُعتبر أهدافاً شائعة للهجمات أو أنماط معينة في datagrams تُستخدم للهجمات. يجوز لـ endpoints اختيار تجنب إرسال datagrams إلى هذه المنافذ أو عدم إرسال datagrams التي تطابق هذه الأنماط قبل التحقق من صحة عنوان الوجهة. يجوز لـ endpoints إلغاء connection IDs التي تحتوي على أنماط معروفة بكونها مشكلة دون استخدامها.

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

رفض الخدمة في المصافحة

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

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

هجوم التضخيم

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

قد يتعمد مستقبل عدائي عدم إقرار الحزم التي تحتوي على بيانات التدفق في محاولة لإجبار المرسل على تخزين بيانات التدفق غير المُقرة لإعادة الإرسال.

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

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

هجوم الإقرار المتفائل

يمكن لنقطة نهاية عدائية فتح عدد كبير من التدفقات، مما يستنزف الحالة على نقطة النهاية. يمكن لنقطة النهاية العدائية تكرار العملية على عدد كبير من الاتصالات، بطريقة مشابهة لهجمات SYN flooding في TCP.

عادةً، ستفتح العملاء التدفقات بشكل تسلسلي، كما هو موضح في القسم 2.1. ومع ذلك، عند بدء عدة تدفقات على فترات قصيرة، يمكن أن يتسبب فقدان البيانات أو إعادة ترتيبها في استقبال إطارات STREAM التي تفتح التدفقات خارج التسلسل المطلوب. عند استقبال معرف تدفق ذو رقم أعلى، يُطلب من المستقبل فتح جميع التدفقات المتداخلة من نفس النوع؛ انظر القسم 3.2. وبالتالي، على اتصال جديد، فإن فتح التدفق 4000000 يفتح مليون و1 من التدفقات ثنائية الاتجاه المبدوءة من العميل.

عدد التدفقات النشطة محدود بمعاملات النقل initial_max_streams_bidi و initial_max_streams_uni كما يتم تحديثها بواسطة أي إطارات MAX_STREAMS مستلمة، كما هو موضح في القسم 4.6. إذا تم اختيار هذه الحدود بحكمة، فإنها تخفف من تأثير هجوم التزام التدفق. ومع ذلك، قد يؤثر تعيين الحد المنخفض جداً على الأداء عندما تتوقع التطبيقات فتح عدد كبير من التدفقات.

هجمات تزوير الطلبات

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

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

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

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

خيارات التحكم لنقاط النهاية

يمكن لمهاجم على المسار التلاعب بقيمة حقول ECN في رأس IP للتأثير على معدل المرسل. يناقش RFC3168 التلاعبات وتأثيراتها بمزيد من التفصيل.

يمكن لمهاجم محدود على المسار تكرار وإرسال حزم مع حقول ECN معدلة للتأثير على معدل المرسل. إذا تم تجاهل الحزم المكررة من قبل المستقبل، فسيحتاج المهاجم إلى سباق الحزمة المكررة ضد الأصلية لينجح في هذا الهجوم. لذلك، تتجاهل نقاط نهاية QUIC حقل ECN في حزمة IP إلا إذا تمت معالجة حزمة QUIC واحدة على الأقل في تلك الحزمة IP بنجاح؛ راجع القسم 13.4.

تزوير الطلبات باستخدام حزم العميل الأولية

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

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

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

في حالة وجود cluster يستخدم موازنة الأحمال الديناميكية، من الممكن أن يحدث تغيير في تكوين load-balancer بينما تحتفظ instance نشطة بحالة الاتصال. حتى لو احتفظت instance بحالة الاتصال، فإن التغيير في التوجيه والإعادة تعيين عديمة الحالة الناتجة ستؤدي إلى إنهاء الاتصال. إذا لم تكن هناك فرصة لتوجيه الحزمة إلى الـ instance الصحيحة، فمن الأفضل إرسال إعادة تعيين عديمة الحالة بدلاً من انتظار انتهاء مهلة الاتصال. ومع ذلك، هذا مقبول فقط إذا كان لا يمكن للمهاجم التأثير على التوجيه.

تزوير الطلبات باستخدام العناوين المفضلة

تحدد هذه الوثيقة حزم التفاوض على إصدار QUIC (القسم 6)، والتي يمكن استخدامها للتفاوض على إصدار QUIC المستخدم بين نقطتي نهاية. ومع ذلك، لا تحدد هذه الوثيقة كيفية أداء هذا التفاوض بين هذا الإصدار والإصدارات المستقبلية اللاحقة. وبشكل خاص، لا تحتوي حزم Version Negotiation على أي آلية لمنع هجمات تقليل الإصدار. الإصدارات المستقبلية من QUIC التي تستخدم حزم Version Negotiation يجب أن تحدد آلية قوية ضد هجمات تقليل الإصدار.

طلب مزيف مع هجرة مزورة

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

تزوير الطلبات مع تفاوض الإصدار

يمكن أن يكشف طول حزم QUIC معلومات حول طول محتوى تلك الحزم. يتم توفير إطار PADDING بحيث تكون للنقاط النهائية بعض القدرة على إخفاء طول محتوى الحزمة؛ انظر القسم 19.1.

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

Relay Security

فيما يلي تحليل لـ Relay Request و Relay Response و Relay Intro و Hole Punch في SSU1.

القيود: من المهم أن تكون الـ Relays سريعة. يجب تقليل الرحلات ذهاباً وإياباً إلى أدنى حد. عرض النطاق الترددي ووحدة المعالجة المركزية ليسا بنفس الأهمية.

SSU 1: أليس تتصل أولاً بـ introducer بوب، الذي يقوم بترحيل الطلب إلى تشارلي (الذي محمي بجدار ناري). بعد hole punch، يتم إنشاء الجلسة بين أليس وتشارلي كما في الإنشاء المباشر.

Alice                         Bob                  Charlie
1. RelayRequest ---------------------->
2.      <-------------- RelayResponse    RelayIntro ----------->
3.      <-------------------------------------------- HolePunch
4. SessionRequest -------------------------------------------->
5.      <-------------------------------------------- SessionCreated
6. SessionConfirmed ------------------------------------------>

المصادقة: طلب Relay Request وردود Relay Response غير مصادق عليها بشكل آمن، حيث أن Alice وBob عادة لا يملكان جلسة موجودة؛ هذه الرسائل تستخدم مفاتيح intro المنشورة. Relay Request/Response داخل الجلسة مسموح ومُفضل إذا كانت الجلسة موجودة.

Relay Intro من Bob إلى Charlie مطلوب أن يكون في جلسة موجودة، لذا يُفترض أنه آمن.

قد يقوم Bob بتزوير Relay Intros أو تغيير IP/port من Relay Request. لا توجد آليات لربط الطلبات بـ intros تشفيريًا أو منع أو كشف Bobs الضارة بطريقة أخرى.

hash الخاص بـ router الخاص بـ Bob غير منشور حالياً في Router Info الخاص بـ Charlie، لذلك يجب إضافته إذا كنا نريد أن تكون رسائل Alice-Bob مصادق عليها. بالإضافة إلى ذلك، يجب نشر معاملات SSU2 أخرى في Router Info الخاص بـ Charlie، أو يجب على Alice البحث عن Router Info الخاص بـ Bob في قاعدة بيانات الشبكة، مما يضيف تأخيراً إضافياً. ستضيف المصادقة رحلة ذهاب وإياب بين Alice وBob.

من خلال إعادة توجيه router hash الخاص بأليس إلى تشارلي، يمكن لتشارلي أن يحدد بسهولة أكبر ما إذا كان يرغب في استقبال اتصال من أليس، وذلك من خلال فحص قائمة الحظر المحلية. لا توجد آلية لتشارلي لرفض الترحيل عبر إرسال رفض من خلال بوب إلى أليس. لا توجد آلية لتشارلي لقبول الترحيل عبر إرسال قبول من خلال بوب إلى أليس. يجب على أليس أن تنتظر HolePunch، أو ببساطة ترسل SessionRequest بشكل أعمى. قد يأتي HolePunch من منفذ مختلف عما كانت تتوقعه أليس، بسبب NAT، مما قد يجعل من الصعب التعرف على أي router جاء منه HolePunch.

يمكن لـ Alice أن ترسل معلومات الـ Router الكاملة الخاصة بها في طلب الـ Relay Request إلى Bob، وتُرسل إلى Charlie في الـ Relay Intro.

طلب الترحيل لا يحتوي على طابع زمني، لذا فهو لا يملك حماية من إعادة التشغيل. يمكن انتحال عنوان IP المصدر، لجعل Charlie يرسل Hole Punch إلى أي IP/منفذ. طلب الترحيل غير موقع، وحتى لو كان موقعاً ومؤرخاً بطابع زمني، فإن Charlie لا يملك Router Identity الكاملة ليتمكن من التحقق من التوقيع.

يعرّف البروتوكول حقل تحدي بطول متغير من 0-255 بايت. يتم تمرير التحدي في طلب الترحيل (Relay Request) إلى Charlie في مقدمة الترحيل (Relay Intro). ومع ذلك، لا يحدد البروتوكول كيفية إنشاء أو استخدام أو التحقق من التحدي، وهو غير مُطبق. إذا احتوى HolePunch على التحدي، فستتمكن Alice من ربط HolePunch بـ Charlie بسهولة.

قد تحتاج nonce الأربعة بايت إلى استبدال أو تكملة بمعرف اتصال من 8 بايت.

رسالة Hole Punch الفارغة فريدة من نوعها وقد يستخدمها المراقبون على المسار لتحديد البروتوكول، يجب تغيير هذا.

مناقشة إضافية حول DPI

فيما يلي تحليل لـ Peer Test في SSU1.

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

SSU 1:

Alice                     Bob                  Charlie
1. PeerTest ------------------->
2.                          PeerTest-------------------->
3.                             <-------------------PeerTest
4.      <-------------------PeerTest

5.      <------------------------------------------PeerTest
6. PeerTest------------------------------------------>
7.      <------------------------------------------PeerTest

نظرًا لأن مواصفات SSU1 صعبة المتابعة، نقوم بتوثيق محتويات الرسالة أدناه.

بوب يختار تشارلي الذي لديه معه جلسة موجودة. الرسائل 2 و 3 يتم إرسالها داخل الجلسة. لذلك، الرسائل 2 و 3 آمنة ومُصادق عليها.

يجب إرسال الرسالة 4 داخل الجلسة؛ ومع ذلك، كانت مواصفات SSU 1 تنص سابقاً على أنها ترسل بمفتاح التقديم المنشور لـ Alice، مما يعني عدم إرسالها داخل الجلسة. قبل الإصدار 0.9.52، كان Java I2P يرسل الرسالة بمفتاح التقديم. اعتباراً من الإصدار 0.9.52، تنص المواصفات على أنه يجب استخدام مفتاح الجلسة، و Java I2P يرسل الرسالة داخل الجلسة اعتباراً من الإصدار 0.9.52.

يجب ألا يكون لدى Alice جلسة موجودة مع Charlie حتى يتمكن الاختبار من المتابعة؛ تُلغي Alice الاختبار إذا اختار Bob Charlie الذي لديه جلسة مع Alice. لذلك، الرسائل 5-7 ليست آمنة ومُوثقة.

جميع رسائل Peer Test تحتوي على nonce بحجم 4 بايت يتم اختياره بواسطة Alice. هذا الـ nonce لا يُستخدم تشفيريًا.

الهجمات المحتملة على الرسائل 5-7: يجب بحثها.

hash الخاص بـ router الخاص بأليس غير معروف لتشارلي. hash الخاص بـ router الخاص بتشارلي غير معروف لأليس. يجب إضافة هذين إلى البروتوكول إذا كنا نريد أن تكون رسائل أليس-تشارلي موثقة. بالإضافة إلى ذلك، سيتعين توفير معاملات SSU2 أخرى في رسائل Peer Test، أو سيتعين على تشارلي البحث عن Router Info الخاص بأليس في قاعدة بيانات الشبكة، مما يضيف تأخيراً إضافياً. التوثيق سيضيف رحلة ذهاباً وإياباً بين تشارلي وأليس.

من خلال إرسال router hash الخاص بأليس إلى تشارلي، يمكن لتشارلي أن يحدد بسهولة أكبر ما إذا كان يرغب في المشاركة في Peer Test مع أليس، وذلك عن طريق فحص قائمة الحظر المحلية.

قد تحتاج القيمة العشوائية المكونة من أربعة بايت إلى استبدالها أو تكميلها بمعرف اتصال مكون من 8 بايت.

Relay and Peer Test Design Goals

التتابع (Relay) واختبار النظير (Peer Test) لهما بنية متشابهة. في كلا الحالتين، تطلب Alice من Bob إعادة توجيه طلب خدمة إلى Charlie، وبعدها يتصرف Charlie بناءً على هذا الطلب.

مشاكل SSU1 Peer Test الحالية:

• Peer Test ليس لديه حماية ضد Bob ضار
• Peer Test ليس لديه طريقة لـ Bob أو Charlie لرفض طلب
• Peer Test ليس لديه طريقة لـ Alice لمعرفة هوية Charlie أو لـ Alice لرفض Charlie
• Peer Test ليس لديه طريقة لـ Charlie لمعرفة هوية Alice أو لـ Charlie لرفض Alice
• Peer Test لديه نظام إعادة إرسال مخصص خاص به
• Peer Test يتطلب آلة حالة معقدة لمعرفة أي رسالة لأي حالة
• بدون معرفة أن Charlie قد رفضها، Alice ستتعامل مع الاختبار كفشل.

مشاكل SSU1 Relay الحالية:

معظم مشاكل Peer Test المذكورة أعلاه تنطبق أيضاً على Peer Test.

لدينا الأهداف التالية في تحسين أمان Relay و Peer Test:

• يجب أن ينشر Charlie معلومات كافية حول المعرِّفين له (Bobs) في netDb لتتمكن Alice من التحقق من المعلومات إذا لزم الأمر. على سبيل المثال، نشر router hash لكل معرِّف سيمكن Alice، إذا سمح الوقت، من جلب معلومات الموجه من netDb.

• الحماية من انتحال العناوين أو التهديدات على المسار التي قد تنتحل أو تغير أو تزور أو تعيد تشغيل الطلبات من Alice إلى Bob. يجب على Bob التأكد من أن Alice هو router I2P فعلي وأن الطلب وعنوان الاختبار المقدمين صالحان.

• الحماية ضد Bob الخبيثين الذين قد يقومون بانتحال الهوية أو تغيير أو تزوير أو إعادة تشغيل الطلبات المُرسلة إلى Charlie. يجب على Charlie التأكد من أن كلاً من Alice و Bob هما router فعليان في I2P وأن الطلب وعنوان الاختبار المُقدمين صالحان.

• يجب على Bob أن يتلقى معلومات كافية من Alice ليتمكن من التحقق من صحة الطلب ثم قبوله أو رفضه. يجب على Bob أن يملك آلية لإرسال القبول أو الرفض مرة أخرى إلى Alice. يجب ألا يُطلب من Bob أبداً تنفيذ الإجراء المطلوب.

• يجب على Charlie تلقي معلومات كافية من Bob لتتمكن من التحقق من صحة الطلب ثم قبوله أو رفضه. يجب أن يكون لدى Charlie آلية لإرسال القبول أو الرفض مرة أخرى إلى Bob، ليتم إعادة توجيهه إلى Alice. يجب ألا يُطلب من Charlie أبداً تنفيذ الإجراء المطلوب.

• يجب أن تكون Alice قادرة على التحقق من أن الاستجابة المُحوّلة عبر Bob نشأت فعلاً من Charlie.

• يجب أن تكون Alice وCharlie قادرتين على التحقق من أن رسائلهما المباشرة اللاحقة (غير المُرحّلة عبر Bob) من المصدر المتوقع وأنها من I2P routers فعلية.

الآليات التالية قد تساعد في تحقيق هذه الأهداف:

• الطوابع الزمنية

• التوقيعات باستخدام مفتاح التوقيع الخاص بال router

• استخدام بيانات التحدي المضمنة في الطلب

• التشفير باستخدام مفتاح تشفير الـ router

• إرسال hashes الموجهات، وهويات الموجهات (Router Identities)، أو معلومات الموجهات (Router Infos)، وليس فقط عناوين IP والمنافذ.

• التحقق من معلومات الموجه عبر استعلام قاعدة بيانات الشبكة

• فحص معلومات الراوتر وعناوين IP والمنافذ مقابل قوائم الحظر

• تحديد المعدل

• يتطلب إنشاء الجلسة

هذه الآليات المحتملة قد تزيد من وقت المعالجة وزمن الاستجابة لوظائف Relay أو Peer Test. يجب تقييم جميع التأثيرات.

يجب أيضاً دعم التبديل والاختبار النظير عبر الإصدارات إذا كان ذلك ممكناً. هذا سيسهل الانتقال التدريجي من SSU 1 إلى SSU 2. تركيبات الإصدارات الممكنة هي:

أهداف الأمان

Summary

نحن نعتمد على عدة بروتوكولات موجودة، سواء داخل I2P أو معايير خارجية، للإلهام والتوجيه وإعادة استخدام الكود:

• نماذج التهديد: من NTCP2 NTCP2، مع تهديدات إضافية مهمة ذات صلة بنقل UDP كما حللها QUIC RFC 9000 RFC 9001.

• الخيارات التشفيرية: من NTCP2.

• المصافحة: Noise XK من NTCP2 و NOISE. تبسيطات كبيرة لـ NTCP2 ممكنة بسبب التغليف (حدود الرسائل المتأصلة) المقدمة بواسطة UDP.

• إخفاء مفتاح المصافحة المؤقت: مقتبس من NTCP2 ولكن باستخدام ChaCha20 من ECIES بدلاً من AES.

• رؤوس الحزم: مُقتبسة من WireGuard WireGuard و QUIC RFC 9000 RFC 9001.

• إخفاء رؤوس الحزم: مُقتبس من NTCP2 ولكن باستخدام ChaCha20 من ECIES بدلاً من AES.

• حماية رأس الحزمة: مُقتبس من QUIC RFC 9001 و Nonces

• الرؤوس المستخدمة كبيانات مرتبطة لـ AEAD كما في ECIES.

• ترقيم الحزم: مُقتبس من WireGuard WireGuard و QUIC RFC 9000 RFC 9001.

• الرسائل: مقتبس من SSU

• تجزئة I2NP: مقتبس من SSU

• الترحيل واختبار الأقران: مُقتبس من SSU

• توقيعات بيانات Relay و Peer Test: من مواصفات الهياكل المشتركة Common

• تنسيق الكتلة: من NTCP2 و ECIES.

• الحشو والخيارات: من NTCP2 و ECIES.

• Acks، nacks: مقتبس من QUIC RFC 9000.

• التحكم في التدفق: TBD

لا توجد أساسيات تشفير جديدة لم يتم استخدامها في I2P من قبل.

التحقق من صحة العنوان

كما هو الحال مع وسائل النقل الأخرى في I2P وهي NTCP و NTCP2 و SSU 1، فإن وسيلة النقل هذه ليست منشأة للاستخدام العام لتسليم تدفق مرتب من البايتات. إنها مصممة لنقل رسائل I2NP. لا يوجد تجريد “تدفق” متوفر.

بالإضافة إلى ذلك، كما هو الحال مع SSU، فإنه يحتوي على تسهيلات إضافية لاجتياز NAT بمساعدة النظراء واختبار إمكانية الوصول (الاتصالات الواردة).

بالنسبة لـ SSU 1، فهو لا يوفر تسليم رسائل I2NP بالترتيب. كما أنه لا يوفر ضمان تسليم رسائل I2NP. من أجل الكفاءة، أو بسبب التسليم غير المرتب لحزم UDP أو فقدان تلك الحزم، قد يتم تسليم رسائل I2NP إلى الطرف البعيد خارج الترتيب، أو قد لا يتم تسليمها على الإطلاق. قد يتم إعادة إرسال رسالة I2NP عدة مرات إذا لزم الأمر، لكن التسليم قد يفشل في النهاية دون التسبب في قطع الاتصال الكامل. أيضاً، قد تستمر رسائل I2NP جديدة في الإرسال حتى أثناء حدوث إعادة الإرسال (استرداد المفقود) لرسائل I2NP أخرى.

هذا البروتوكول لا يمنع تماماً التسليم المكرر لرسائل I2NP. يجب على الـ router فرض انتهاء صلاحية I2NP واستخدام مرشح Bloom أو آلية أخرى مبنية على معرّف رسالة I2NP. راجع قسم تكرار رسائل I2NP أدناه.

Noise Protocol Framework

يقدم هذا الاقتراح المتطلبات بناءً على إطار عمل Noise Protocol Framework NOISE (المراجعة 33، 2017-10-04). يحتوي Noise على خصائص مشابهة لبروتوكول Station-To-Station (STS)، والذي يُعتبر الأساس لبروتوكول SSU. في مصطلحات Noise، Alice هو المُبادِر، وBob هو المُستجيب.

SSU2 مبني على بروتوكول Noise وهو Noise_XK_25519_ChaChaPoly_SHA256. (المعرف الفعلي لدالة اشتقاق المفتاح الأولي هو “Noise_XKchaobfse+hs1+hs2+hs3_25519_ChaChaPoly_SHA256” للإشارة إلى امتدادات I2P - انظر قسم KDF 1 أدناه)

ملاحظة: هذا المعرف مختلف عن ذلك المستخدم لـ NTCP2، لأن جميع رسائل المصافحة الثلاث تستخدم الرأس كبيانات مرتبطة.

يستخدم بروتوكول Noise التالي العناصر الأساسية التالية:

• نمط المصافحة: XK أليس ترسل مفتاحها إلى بوب (X) أليس تعرف المفتاح الثابت لبوب مسبقاً (K)

• دالة DH: X25519 X25519 DH بطول مفتاح 32 بايت كما هو محدد في RFC 7748.

• Cipher Function: ChaChaPoly AEAD_CHACHA20_POLY1305 كما هو محدد في RFC 7539 القسم 2.8. 12 بايت nonce، مع تعيين أول 4 بايتات إلى الصفر.

• Hash Function: SHA256 دالة تجزئة قياسية بحجم 32 بايت، مستخدمة بالفعل على نطاق واسع في I2P.

Additions to the Framework

تحدد هذه المقترحة التحسينات التالية لـ Noise_XK_25519_ChaChaPoly_SHA256. تتبع هذه عمومًا الإرشادات في NOISE القسم 13.

1. رسائل المصافحة (Session Request، Created، Confirmed) تتضمن رأسية بحجم 16 أو 32 بايت.

2. يتم استخدام رؤوس رسائل المصافحة (Session Request، Created، Confirmed) كمدخل لـ mixHash() قبل التشفير/فك التشفير لربط الرؤوس بالرسالة.

3. الرؤوس مشفرة ومحمية.

4. مفاتيح ephemeral النصية الواضحة مموهة بتشفير ChaCha20 باستخدام مفتاح و IV معروفين. هذا أسرع من elligator2.

5. تم تحديد تنسيق البيانات المفيدة للرسائل 1 و 2 ومرحلة البيانات. بالطبع، هذا غير محدد في Noise.

تستخدم مرحلة البيانات تشفيراً مشابهاً لمرحلة بيانات Noise، ولكنه غير متوافق معها.

Processing overhead estimate

سيتم تحديده لاحقاً

Definitions

نحدد الوظائف التالية المقابلة للوحدات البنائية التشفيرية المستخدمة.

ZEROLEN

zero-length byte array

H(p, d)

SHA-256 hash function that takes a personalization string p and data d, and
produces an output of length 32 bytes.
As defined in [NOISE](https://noiseprotocol.org/noise.html).
|| below means append.

Use SHA-256 as follows::

    H(p, d) := SHA-256(p || d)

MixHash(d)

SHA-256 hash function that takes a previous hash h and new data d,
and produces an output of length 32 bytes.
|| below means append.

Use SHA-256 as follows::

    MixHash(d) := h = SHA-256(h || d)

STREAM

The ChaCha20/Poly1305 AEAD as specified in [RFC 7539](https://tools.ietf.org/html/rfc7539).
S_KEY_LEN = 32 and S_IV_LEN = 12.

ENCRYPT(k, n, plaintext, ad)
    Encrypts plaintext using the cipher key k, and nonce n which MUST be unique for
    the key k.
    Associated data ad is optional.
    Returns a ciphertext that is the size of the plaintext + 16 bytes for the HMAC.

    The entire ciphertext must be indistinguishable from random if the key is secret.

DECRYPT(k, n, ciphertext, ad)
    Decrypts ciphertext using the cipher key k, and nonce n.
    Associated data ad is optional.
    Returns the plaintext.

DH

X25519 public key agreement system. Private keys of 32 bytes, public keys of 32
bytes, produces outputs of 32 bytes. It has the following
functions:

GENERATE_PRIVATE()
    Generates a new private key.

DERIVE_PUBLIC(privkey)
    Returns the public key corresponding to the given private key.

DH(privkey, pubkey)
    Generates a shared secret from the given private and public keys.

HKDF(salt, ikm, info, n)

A cryptographic key derivation function which takes some input key material ikm (which
should have good entropy but is not required to be a uniformly random string), a salt
of length 32 bytes, and a context-specific 'info' value, and produces an output
of n bytes suitable for use as key material.

Use HKDF as specified in [RFC 5869](https://tools.ietf.org/html/rfc5869), using the HMAC hash function SHA-256
as specified in [RFC 2104](https://tools.ietf.org/html/rfc2104). This means that SALT_LEN is 32 bytes max.

MixKey(d)

Use HKDF() with a previous chainKey and new data d, and
sets the new chainKey and k.
As defined in [NOISE](https://noiseprotocol.org/noise.html).

Use HKDF as follows::

    MixKey(d) := output = HKDF(chainKey, d, "", 64)
                 chainKey = output[0:31]
                 k = output[32:63]

Messages

كل UDP datagram يحتوي على رسالة واحدة بالضبط. طول الـ datagram (بعد الـ IP و UDP headers) هو طول الرسالة. الحشو، إن وُجد، يكون موجوداً في كتلة حشو داخل الرسالة. في هذا المستند، نستخدم مصطلحي “datagram” و “packet” بشكل متبادل في الغالب. كل datagram (أو packet) يحتوي على رسالة واحدة (على عكس QUIC، حيث قد يحتوي الـ datagram على عدة QUIC packets). الـ “packet header” هو الجزء الذي يأتي بعد الـ IP/UDP header.

استثناء: رسالة Session Confirmed فريدة من نوعها في أنه يمكن تجزئتها عبر عدة حزم. راجع قسم Session Confirmed Fragmentation أدناه للحصول على مزيد من المعلومات.

جميع رسائل SSU2 يبلغ طولها 40 بايت على الأقل. أي رسالة يتراوح طولها بين 1-39 بايت تعتبر غير صالحة. جميع رسائل SSU2 أقل من أو تساوي 1472 (IPv4) أو 1452 (IPv6) بايت في الطول. تنسيق الرسالة مبني على رسائل Noise، مع تعديلات للتأطير وعدم القابلية للتمييز. التطبيقات التي تستخدم مكتبات Noise القياسية يجب أن تقوم بمعالجة مسبقة للرسائل المستلمة إلى تنسيق رسالة Noise القياسي. جميع الحقول المشفرة هي نصوص مشفرة AEAD.

الرسائل التالية معرّفة:

Session Establishment

تسلسل التأسيس المعياري، عندما تمتلك Alice رمزًا صالحًا تم استلامه مسبقًا من Bob، هو كما يلي:

Alice                           Bob

SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->

عندما لا تمتلك Alice رمزاً صالحاً، تكون تسلسل الإنشاء كما يلي:

Alice                           Bob

TokenRequest --------------------->
<---------------------------  Retry
SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->

عندما تعتقد Alice أن لديها رمزاً صالحاً، ولكن Bob يرفضه (ربما لأن Bob أعاد التشغيل)، تكون تسلسل الإنشاء كما يلي:

Alice                           Bob

SessionRequest ------------------->
<---------------------------  Retry
SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->

قد يرفض Bob طلب Session أو Token بالرد برسالة Retry تحتوي على كتلة Termination مع رمز السبب. بناءً على رمز السبب، يجب على Alice عدم محاولة طلب آخر لفترة زمنية معينة:

Alice                           Bob

SessionRequest ------------------->
<---------------------------  Retry containing a Termination block

or

TokenRequest --------------------->
<---------------------------  Retry containing a Termination block

باستخدام مصطلحات Noise، تسلسل التأسيس والبيانات كما يلي: (خصائص أمان الحمولة)

XK(s, rs):           Authentication   Confidentiality
    <- s
    ...
    -> e, es                  0                2
    <- e, ee                  2                1
    -> s, se                  2                5
    <-                        2                5

بمجرد إنشاء جلسة، يمكن لأليس وبوب تبادل رسائل البيانات.

Packet Header

جميع الحزم تبدأ برأس مشوش (مشفر). هناك نوعان من الرؤوس، طويل وقصير. لاحظ أن البايتات الـ13 الأولى (معرف اتصال الوجهة، رقم الحزمة، والنوع) هي نفسها لجميع الرؤوس.

تدابير مواجهة تزوير الطلبات العامة

الرأس الطويل يبلغ 32 بايت. يُستخدم قبل إنشاء الجلسة، لطلب Token Request وطلب الجلسة SessionRequest وإنشاء الجلسة SessionCreated وإعادة المحاولة Retry. كما يُستخدم أيضاً لرسائل اختبار النظير Peer Test وثقب الاتصال Hole Punch خارج الجلسة.

قبل تشفير الرأسية:

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: 8 bytes, unsigned big endian integer

  Packet Number :: 4 bytes, unsigned big endian integer

  type :: The message type = 0, 1, 7, 9, 10, or 11

  ver :: The protocol version, equal to 2

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: 8 bytes, unsigned big endian integer

  Token :: 8 bytes, unsigned big endian integer

هجمات Slowloris

العنوان المختصر يبلغ 16 بايت. يتم استخدامه لرسائل Session Created ولرسائل البيانات. الرسائل غير المصادق عليها مثل Session Request وRetry وPeer Test ستستخدم دائماً العنوان الطويل.

16 بايت مطلوبة، لأن المستقبل يجب أن يفك تشفير أول 16 بايت للحصول على نوع الرسالة، ثم يجب أن يفك تشفير 16 بايت إضافية إذا كان في الواقع header طويل، كما هو مشار إليه بواسطة نوع الرسالة.

للجلسة المؤكدة، قبل تشفير الرأس:

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type|frag|  flags  |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: 8 bytes, unsigned big endian integer

  Packet Number :: 4 bytes, all zeros

  type :: The message type = 2

  frag :: 1 byte fragment info:
         bit order: 76543210 (bit 7 is MSB)
         bits 7-4: fragment number 0-14, big endian
         bits 3-0: total fragments 1-15, big endian

  flags :: 2 bytes, unused, set to 0 for future compatibility

راجع قسم Session Confirmed Fragmentation أدناه للحصول على مزيد من المعلومات حول حقل frag.

بالنسبة لرسائل البيانات، قبل تشفير الرأس:

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type|flag|moreflags|
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: 8 bytes, unsigned big endian integer

  Packet Number :: 4 bytes, unsigned big endian integer

  type :: The message type = 6

  flag :: 1 byte flags:
         bit order: 76543210 (bit 7 is MSB)
         bits 7-1: unused, set to 0 for future compatibility
         bits 0: when set to 1, immediate ack requested

  moreflags :: 2 bytes, unused, set to 0 for future compatibility

هجمات تجزئة وإعادة تجميع التدفق

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

على عكس QUIC، نحن لا نغير معرفات الاتصال أثناء أو بعد المصافحة، حتى بعد رسالة Retry. تبقى المعرفات ثابتة من الرسالة الأولى (Token Request أو Session Request) إلى الرسالة الأخيرة (Data مع Termination). بالإضافة إلى ذلك، لا تتغير معرفات الاتصال أثناء أو بعد تحدي المسار أو هجرة الاتصال.

كما أنه مختلف عن QUIC في أن معرفات الاتصال في الرؤوس تكون دائماً مشفرة على مستوى الرأس. انظر أدناه.

هجوم الالتزام بالتيار

إذا لم يتم إرسال كتلة رقم الحزمة الأولى في المصافحة، فإن الحزم يتم ترقيمها داخل جلسة واحدة، لكل اتجاه، بدءاً من 0، إلى حد أقصى قدره (2**32 -1). يجب إنهاء الجلسة، وإنشاء جلسة جديدة، قبل وقت كافٍ من إرسال العدد الأقصى من الحزم.

إذا تم إرسال كتلة First Packet Number في المصافحة، يتم ترقيم الحزم داخل جلسة واحدة، لذلك الاتجاه، بدءاً من رقم تلك الحزمة. قد يلتف رقم الحزمة حول نفسه أثناء الجلسة. عند إرسال حد أقصى من 2**32 حزمة، مما يلف رقم الحزمة للعودة إلى رقم الحزمة الأولى، تلك الجلسة لم تعد صالحة. يجب إنهاء الجلسة، وإنشاء جلسة جديدة، قبل إرسال العدد الأقصى من الحزم بوقت كاف.

TODO دوران المفاتيح، تقليل الحد الأقصى لرقم الحزمة؟

رزم Handshake التي يتم تحديدها كمفقودة يعاد إرسالها بالكامل، مع رأس مطابق بما في ذلك رقم الرزمة. رسائل handshake وهي Session Request و Session Created و Session Confirmed يجب إعادة إرسالها بنفس رقم الرزمة ونفس المحتويات المشفرة تماماً، بحيث يتم استخدام نفس chained hash لتشفير الاستجابة. رسالة Retry لا يتم إرسالها مطلقاً.

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

إعادة إرسال حزمة كاملة دون تغيير كما هي، بنفس رقم الحزمة، غير مسموح لعدة أسباب. للخلفية راجع QUIC RFC 9000 القسم 12.3.

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

يتم استخدام الحزم الجديدة لحمل المعلومات التي يتم تحديد أنها قد فُقدت. بشكل عام، يتم إرسال المعلومات مرة أخرى عندما يتم تحديد أن الحزمة التي تحتوي على تلك المعلومات قد فُقدت، ويتوقف الإرسال عندما يتم الإقرار بالحزمة التي تحتوي على تلك المعلومات (تبقى كما هي).

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

الحزم التالية تحتوي على رقم حزمة عشوائي يتم تجاهله:

• طلب الجلسة
• تم إنشاء الجلسة
• طلب الرمز المميز
• إعادة المحاولة
• اختبار النظير
• ثقب الاتصال

بالنسبة لأليس، ترقيم الحزم الصادرة يبدأ من 0 مع Session Confirmed. بالنسبة لبوب، ترقيم الحزم الصادرة يبدأ من 0 مع أول حزمة Data، والتي يجب أن تكون ACK للـ Session Confirmed. أرقام الحزم في مثال المصافحة القياسية ستكون:

Alice                           Bob

SessionRequest (r)    ------------>
<-------------   SessionCreated (r)
SessionConfirmed (0)  ------------>
<-------------             Data (0) (Ack-only)
Data (1)              ------------> (May be sent before Ack is received)
<-------------             Data (1)
Data (2)              ------------>
Data (3)              ------------>
Data (4)              ------------>
<-------------             Data (2)

r = random packet number (ignored)
Token Request, Retry, and Peer Test
also have random packet numbers.

أي إعادة إرسال لرسائل المصافحة (SessionRequest أو SessionCreated أو SessionConfirmed) يجب أن تُرسل دون تغيير، بنفس رقم الحزمة. لا تستخدم مفاتيح مؤقتة مختلفة أو تُغيّر الحمولة عند إعادة إرسال هذه الرسائل.

هجوم حرمان الخدمة من الأقران

الرأس (قبل التشويش والحماية) مُضمّن دائماً في البيانات المرتبطة لوظيفة AEAD، لربط الرأس بالبيانات بشكل تشفيري.

هجمات إشعار الازدحام الصريح

تشفير الرأس له عدة أهداف. راجع قسم “مناقشة DPI الإضافية” أعلاه للخلفية والافتراضات.

• منع DPI الإلكتروني من تحديد البروتوكول
• منع الأنماط في سلسلة من الرسائل في نفس الاتصال، باستثناء إعادة إرسال المصافحة
• منع الأنماط في الرسائل من نفس النوع في اتصالات مختلفة
• منع فك تشفير رؤوس المصافحة دون معرفة مفتاح التقديم الموجود في netDb
• منع تحديد مفاتيح X25519 المؤقتة دون معرفة مفتاح التقديم الموجود في netDb
• منع فك تشفير رقم ونوع حزمة مرحلة البيانات من قبل أي مهاجم متصل أو غير متصل
• منع حقن حزم مصافحة صحيحة من قبل مراقب في المسار أو خارج المسار دون معرفة مفتاح التقديم الموجود في netDb
• منع حقن حزم بيانات صحيحة من قبل مراقب في المسار أو خارج المسار
• السماح بتصنيف سريع وفعال للحزم الواردة
• توفير مقاومة “التحقق” بحيث لا تكون هناك استجابة لطلب Session سيء، أو إذا كانت هناك استجابة Retry، فلا يمكن التعرف على الاستجابة كـ I2P دون معرفة مفتاح التقديم الموجود في netDb
• معرف اتصال الوجهة ليس بيانات حرجة، ولا بأس إذا كان يمكن فك تشفيره من قبل مراقب لديه معرفة بمفتاح التقديم الموجود في netDb
• رقم الحزمة لحزمة مرحلة البيانات هو nonce AEAD وهو بيانات حرجة. يجب ألا يكون قابلاً للفك من قبل مراقب حتى مع معرفة مفتاح التقديم الموجود في netDb. انظر Nonces.

تُشفر الرؤوس بمفاتيح معروفة منشورة في قاعدة بيانات الشبكة أو محسوبة لاحقاً. في مرحلة handshake، هذا فقط لمقاومة DPI، حيث أن المفتاح عام والمفتاح وال nonces يُعاد استخدامها، لذا فهو فعلياً مجرد تشويش. لاحظ أن تشفير الرأس يُستخدم أيضاً لتشويش المفاتيح المؤقتة X (في Session Request) وY (في Session Created).

راجع قسم معالجة الحزم الواردة أدناه للحصول على إرشادات إضافية.

البايتات 0-15 من جميع الرؤوس مشفرة باستخدام مخطط حماية الرأس عن طريق XOR مع البيانات المحسوبة من المفاتيح المعروفة، باستخدام ChaCha20، مماثل لـ QUIC RFC 9001 و Nonces. هذا يضمن أن الرأس القصير المشفر والجزء الأول من الرأس الطويل سيبدوان عشوائيين.

بالنسبة لـ Session Request و Session Created، يتم تشفير البايتات 16-31 من الـ long header ومفتاح Noise ephemeral الذي يبلغ طوله 32 بايت باستخدام ChaCha20. البيانات غير المشفرة عشوائية، لذا ستبدو البيانات المشفرة عشوائية أيضاً.

بالنسبة للإعادة المحاولة، يتم تشفير البايتات 16-31 من الرأس الطويل باستخدام ChaCha20. البيانات غير المشفرة عشوائية، لذلك ستبدو البيانات المشفرة عشوائية.

على عكس مخطط حماية رأس QUIC RFC 9001، جميع أجزاء كافة الرؤوس، بما في ذلك معرفات الاتصال للوجهة والمصدر، مشفرة. QUIC RFC 9001 وNonces يركزان بشكل أساسي على تشفير الجزء “الحرج” من الرأس، أي رقم الحزمة (ChaCha20 nonce). بينما يجعل تشفير معرف الجلسة تصنيف الحزم الواردة أكثر تعقيداً قليلاً، إلا أنه يجعل بعض الهجمات أكثر صعوبة. QUIC يعرّف معرفات اتصال مختلفة لمراحل مختلفة، ولتحدي المسار وترحيل الاتصال. هنا نستخدم نفس معرفات الاتصال في جميع الأوقات، حيث أنها مشفرة.

هناك سبع مراحل لمفاتيح حماية الرأس:

• طلب الجلسة وطلب الرمز المميز
• تم إنشاء الجلسة
• إعادة المحاولة
• تأكيد الجلسة
• مرحلة البيانات
• اختبار النظير
• ثقب الاتصال

لاحظ أن Session Created و Retry هما الرسائل الوحيدة التي تتطلب معالجة احتياطية لـ k_header_1 لفك تشفير Connection ID، لأنهما يستخدمان مفتاح التقديم (intro key) الخاص بالمرسل (Bob). جميع الرسائل الأخرى تستخدم مفتاح التقديم الخاص بالمستقبل لـ k_header_1. المعالجة الاحتياطية تحتاج فقط للبحث عن الاتصالات الصادرة المعلقة حسب IP/port المصدر.

إذا فشلت المعالجة الاحتياطية بواسطة IP/port المصدر في العثور على اتصال صادر معلق، فقد تكون هناك عدة أسباب:

• ليست رسالة SSU2
• رسالة SSU2 تالفة
• الرد مزيف أو معدّل من قبل مهاجم
• Bob لديه NAT متماثل
• Bob غيّر عنوان IP أو المنفذ أثناء معالجة الرسالة
• Bob أرسل الرد عبر واجهة مختلفة

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

راجع قسم التعامل مع الحزم الواردة أدناه للحصول على إرشادات إضافية.

راجع أقسام KDF الفردية أدناه لاشتقاق مفاتيح تشفير الرأس لتلك المرحلة.

أوراكل إعادة التعيين عديم الحالة

// incoming encrypted packet
  packet = incoming encrypted packet
  len = packet.length

  // take the next-to-last 12 bytes of the packet
  iv = packet[len-24:len-13]
  k_header_1 = header encryption key 1
  data = {0, 0, 0, 0, 0, 0, 0, 0}
  mask = ChaCha20.encrypt(k_header_1, iv, data)

  // encrypt the first part of the header by XORing with the mask
  packet[0:7] ^= mask[0:7]

  // take the last 12 bytes of the packet
  iv = packet[len-12:len-1]
  k_header_2 = header encryption key 2
  data = {0, 0, 0, 0, 0, 0, 0, 0}
  mask = ChaCha20.encrypt(k_header_2, iv, data)

  // encrypt the second part of the header by XORing with the mask
  packet[8:15] ^= mask[0:7]


  // For Session Request and Session Created only:
  iv = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}

  // encrypt the third part of the header and the ephemeral key
  packet[16:63] = ChaCha20.encrypt(k_header_2, iv, packet[16:63])


  // For Retry, Token Request, Peer Test, and Hole Punch only:
  iv = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}

  // encrypt the third part of the header
  packet[16:31] = ChaCha20.encrypt(k_header_2, iv, packet[16:31])

تستخدم KDF هذه آخر 24 بايت من الحزمة كـ IV لعمليتي ChaCha20. نظراً لأن جميع الحزم تنتهي بـ MAC بحجم 16 بايت، فإن هذا يتطلب أن تكون جميع حمولات الحزم بحد أدنى 8 بايت. هذا المتطلب موثق إضافياً في أقسام الرسائل أدناه.

تخفيض الإصدار

بعد فك تشفير البايتات الثمانية الأولى من الرأس، سيعرف المستقبل معرف الاتصال الوجهة (Destination Connection ID). من هناك، يعرف المستقبل أي مفتاح تشفير رأس يستخدم لبقية الرأس، بناءً على مرحلة المفتاح للجلسة.

فك تشفير البايتات الثمانية التالية من الرأس سيكشف بعدها نوع الرسالة ويمكن من تحديد ما إذا كان رأساً قصيراً أم طويلاً. إذا كان رأساً طويلاً، يجب على المستقبل التحقق من صحة حقلي الإصدار و netid. إذا كان الإصدار != 2، أو netid != القيمة المتوقعة (عادة 2، باستثناء الشبكات التجريبية)، يجب على المستقبل إسقاط الرسالة.

Packet Integrity

جميع الرسائل تحتوي على ثلاثة أو أربعة أجزاء:

• رأس الرسالة
• للـ Session Request و Session Created فقط، مفتاح مؤقت
• حمولة مشفرة بـ ChaCha20
• Poly1305 MAC

في جميع الحالات، يكون الرأس (وإذا كان موجوداً، المفتاح المؤقت) مرتبطاً بـ MAC المصادقة لضمان سلامة الرسالة بأكملها.

• بالنسبة لرسائل المصافحة Session Request وSession Created وSession Confirmed، يتم تطبيق mixHash() على رأس الرسالة قبل مرحلة معالجة Noise
• المفتاح المؤقت، إن وُجد، يكون مغطى بواسطة misHash() القياسي لـ Noise
• بالنسبة للرسائل خارج مصافحة Noise، يُستخدم الرأس كبيانات مرتبطة لتشفير ChaCha20/Poly1305.

معالجات الحزم الواردة يجب أن تفك تشفير حمولة ChaCha20 دائماً وتتحقق من صحة MAC قبل معالجة الرسالة، مع استثناء واحد: للتخفيف من هجمات DoS من الحزم المنتحلة العنوان التي تحتوي على رسائل Session Request ظاهرية برمز غير صحيح، لا يحتاج المعالج لمحاولة فك التشفير والتحقق من صحة الرسالة كاملة (مما يتطلب عملية DH مكلفة بالإضافة إلى فك تشفير ChaCha20/Poly1305). يمكن للمعالج الرد برسالة Retry باستخدام القيم الموجودة في رأس رسالة Session Request.

Authenticated Encryption

هناك ثلاث حالات تشفير مصدّقة منفصلة (CipherStates). واحدة أثناء مرحلة المصافحة، واثنتان (إرسال واستقبال) لمرحلة البيانات. كل واحدة لها مفتاحها الخاص من KDF.

البيانات المشفرة/المصادق عليها ستكون ممثلة كـ

+----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   Encrypted and authenticated data    |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

الهجمات المستهدفة عبر التوجيه

تنسيق البيانات المُشفرة والمُصادق عليها.

المدخلات لدوال التشفير/فك التشفير:

k :: 32 byte cipher key, as generated from KDF

  nonce :: Counter-based nonce, 12 bytes.
           Starts at 0 and incremented for each message.
           First four bytes are always zero.
           Last eight bytes are the counter, little-endian encoded.
           Maximum value is 2**64 - 2.
           Connection must be dropped and restarted after
           it reaches that value.
           The value 2**64 - 1 must never be sent.

  ad :: In handshake phase:
        Associated data, 32 bytes.
        The SHA256 hash of all preceding data.
        In data phase:
        The packet header, 16 bytes.

  data :: Plaintext data, 0 or more bytes

مخرجات دالة التشفير، مدخلات دالة فك التشفير:

+----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |       ChaCha20 encrypted data         |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +              (MAC)                    +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+

  encrypted data :: Same size as plaintext data, 0 - 65519 bytes

  MAC :: Poly1305 message authentication code, 16 bytes

بالنسبة لـ ChaCha20، ما هو موصوف هنا يتوافق مع RFC 7539، والذي يُستخدم أيضاً بشكل مشابه في TLS RFC 7905.

تحليل حركة البيانات

• نظرًا لأن ChaCha20 هو شفرة تدفق، فإن النصوص الواضحة لا تحتاج إلى حشو. يتم تجاهل البايتات الإضافية لتدفق المفاتيح.

• يتم الاتفاق على مفتاح التشفير (256 بت) باستخدام SHA256 KDF. تفاصيل KDF لكل رسالة موجودة في أقسام منفصلة أدناه.

AEAD Error Handling

• في جميع الرسائل، حجم رسالة AEAD معروف مسبقاً. عند فشل مصادقة AEAD، يجب على المستقبِل إيقاف معالجة الرسائل الإضافية و تجاهل الرسالة.

• يجب على Bob الاحتفاظ بقائمة سوداء لعناوين IP التي تعاني من إخفاقات متكررة.

KDF for Session Request

تقوم دالة اشتقاق المفتاح (KDF) بتوليد مفتاح تشفير لمرحلة المصافحة k من نتيجة DH، باستخدام HMAC-SHA256(key, data) كما هو محدد في RFC 2104. هذه هي دوال InitializeSymmetric()، وMixHash()، وMixKey()، تماماً كما هو محدد في مواصفات Noise.

KDF for Initial ChainKey

// Define protocol_name.
  Set protocol_name = "Noise_XKchaobfse+hs1+hs2+hs3_25519_ChaChaPoly_SHA256"
   (52 bytes, US-ASCII encoded, no NULL termination).

  // Define Hash h = 32 bytes
  h = SHA256(protocol_name);

  Define ck = 32 byte chaining key. Copy the h data to ck.
  Set ck = h

  // MixHash(null prologue)
  h = SHA256(h);

  // up until here, can all be precalculated by Alice for all outgoing connections

  // Bob's X25519 static keys
  // bpk is published in routerinfo
  bsk = GENERATE_PRIVATE()
  bpk = DERIVE_PUBLIC(bsk)

  // Bob static key
  // MixHash(bpk)
  // || below means append
  h = SHA256(h || bpk);

  // Bob introduction key
  // bik is published in routerinfo
  bik = RANDOM(32)

  // up until here, can all be precalculated by Bob for all incoming connections

KDF for Session Request

// MixHash(header)
  h = SHA256(h || header)

  This is the "e" message pattern:

  // Alice's X25519 ephemeral keys
  aesk = GENERATE_PRIVATE()
  aepk = DERIVE_PUBLIC(aesk)

  // Alice ephemeral key X
  // MixHash(aepk)
  h = SHA256(h || aepk);

  // h is used as the associated data for the AEAD in Session Request
  // Retain the Hash h for the Session Created KDF


  End of "e" message pattern.

  This is the "es" message pattern:

  // DH(e, rs) == DH(s, re)
  sharedSecret = DH(aesk, bpk) = DH(bsk, aepk)

  // MixKey(DH())
  //[chainKey, k] = MixKey(sharedSecret)
  // ChaChaPoly parameters to encrypt/decrypt
  keydata = HKDF(chainKey, sharedSecret, "", 64)
  chainKey = keydata[0:31]

  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, payload, ad)

  // retain the chainKey for Session Created KDF


  End of "es" message pattern.

  // Header encryption keys for this message
  // bik = Bob's intro key
  k_header_1 = bik
  k_header_2 = bik

  // Header encryption keys for next message (Session Created)
  k_header_1 = bik
  k_header_2 = HKDF(chainKey, ZEROLEN, "SessCreateHeader", 32)

  // Header encryption keys for next message (Retry)
  k_header_1 = bik
  k_header_2 = bik

SessionRequest (Type 0)

أليس ترسل إلى بوب، إما كأول رسالة في handshake، أو كاستجابة لرسالة Retry. بوب يستجيب برسالة Session Created. الحجم: 80 + حجم payload. الحد الأدنى للحجم: 88

إذا لم تكن Alice تملك token صالح، يجب على Alice إرسال رسالة Token Request بدلاً من Session Request، لتجنب العبء الإضافي للتشفير غير المتماثل في إنشاء Session Request.

عنوان طويل. محتوى Noise: مفتاح Alice المؤقت X حمولة Noise: DateTime وكتل أخرى الحد الأقصى لحجم الحمولة: MTU - 108 (IPv4) أو MTU - 128 (IPv6). للـ 1280 MTU: الحد الأقصى للحمولة هو 1172 (IPv4) أو 1152 (IPv6). للـ 1500 MTU: الحد الأقصى للحمولة هو 1392 (IPv4) أو 1372 (IPv6).

خصائص أمان الحمولة:

XK(s, rs):           Authentication   Confidentiality
    -> e, es                  0                2

    Authentication: None (0).
    This payload may have been sent by any party, including an active attacker.

    Confidentiality: 2.
    Encryption to a known recipient, forward secrecy for sender compromise
    only, vulnerable to replay.  This payload is encrypted based only on DHs
    involving the recipient's static key pair.  If the recipient's static
    private key is compromised, even at a later date, this payload can be
    decrypted.  This message can also be replayed, since there's no ephemeral
    contribution from the recipient.

    "e": Alice generates a new ephemeral key pair and stores it in the e
         variable, writes the ephemeral public key as cleartext into the
         message buffer, and hashes the public key along with the old h to
         derive a new h.

    "es": A DH is performed between the Alice's ephemeral key pair and the
          Bob's static key pair.  The result is hashed along with the old ck to
          derive a new ck and k, and n is set to zero.

يتم تشفير قيمة X لضمان عدم القابلية للتمييز والتفرد للحمولة، والتي تعد إجراءات مضادة ضرورية لـ DPI. نحن نستخدم تشفير ChaCha20 لتحقيق ذلك، بدلاً من البدائل الأكثر تعقيداً وبطئاً مثل elligator2. التشفير غير المتماثل لمفتاح router العام الخاص ببوب سيكون بطيئاً جداً. يستخدم تشفير ChaCha20 مفتاح intro الخاص ببوب كما هو منشور في قاعدة بيانات الشبكة.

تشفير ChaCha20 مخصص لمقاومة DPI فقط. أي طرف يعرف مفتاح التقديم الخاص ببوب، والذي يتم نشره في قاعدة بيانات الشبكة، قد يفك تشفير الرأس وقيمة X في هذه الرسالة.

المحتويات الخام:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key         +
  |    See Header Encryption KDF          |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Bob intro key n=0     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       X, ChaCha20 encrypted           +
  |       with Bob intro key n=0          |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data             |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

  X :: 32 bytes, ChaCha20 encrypted X25519 ephemeral key, little endian
          key: Bob's intro key
          n: 1
          data: 48 bytes (bytes 16-31 of the header, followed by encrypted X)

البيانات غير المشفرة (علامة مصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                   X                   |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |     see below for allowed blocks      |
  +----+----+----+----+----+----+----+----+


  Destination Connection ID :: Randomly generated by Alice

  id :: 1 byte, the network ID (currently 2, except for test networks)

  ver :: 2

  type :: 0

  flag :: 1 byte, unused, set to 0 for future compatibility

  Packet Number :: Random 4 byte number generated by Alice, ignored

  Source Connection ID :: Randomly generated by Alice,
                          must not be equal to Destination Connection ID

  Token :: 0 if not previously received from Bob

  X :: 32 bytes, X25519 ephemeral key, little endian

Payload

• كتلة التاريخ والوقت
• كتلة الخيارات (اختيارية)
• كتلة طلب علامة التتابع (اختيارية)
• كتلة الحشو (اختيارية)

الحد الأدنى لحجم البيانات هو 8 بايت. نظراً لأن كتلة DateTime تتكون من 7 بايت فقط، يجب أن تكون هناك كتلة أخرى واحدة على الأقل.

Notes

• القيمة الفريدة X في كتلة ChaCha20 الأولية تضمن أن النص المشفر مختلف لكل جلسة.

• لتوفير مقاومة التحقق، يجب على Bob ألا يرسل رسالة Retry ردًا على رسالة Session Request ما لم تكن حقول نوع الرسالة وإصدار البروتوكول ومعرف الشبكة في رسالة Session Request صحيحة.

• يجب على Bob رفض الاتصالات حيث تكون قيمة الطابع الزمني بعيدة جداً عن الوقت الحالي. أطلق على أقصى فرق زمني “D”. يجب على Bob الحفاظ على ذاكرة تخزين مؤقت محلية للقيم المستخدمة سابقاً في المصافحة ورفض المكررات، لمنع هجمات إعادة التشغيل. يجب أن تكون للقيم في الذاكرة المؤقتة مدة حياة لا تقل عن 2*D. قيم الذاكرة المؤقتة تعتمد على التنفيذ، ومع ذلك يمكن استخدام قيمة X ذات الـ 32 بايت (أو مكافئها المشفر). الرفض يتم بإرسال رسالة Retry تحتوي على رمز مميز صفري وكتلة إنهاء.

• مفاتيح Diffie-Hellman المؤقتة يجب ألا تُستخدم مرة أخرى أبداً، لمنع الهجمات التشفيرية، وإعادة الاستخدام سيتم رفضها كهجوم إعادة تشغيل.

• يجب أن تكون خيارات “KE” و “auth” متوافقة، أي يجب أن يكون المفتاح السري المشترك K بالحجم المناسب. إذا تمت إضافة المزيد من خيارات “auth”، فقد يؤدي هذا إلى تغيير ضمني لمعنى علامة “KE” لاستخدام KDF مختلف أو حجم اقتطاع مختلف.

• يجب على Bob التحقق من أن ephemeral key الخاص بـ Alice هو نقطة صالحة على المنحنى هنا.

• يجب أن يكون الـ Padding محدود بكمية معقولة. قد يرفض Bob الاتصالات التي تحتوي على padding مفرط. سيحدد Bob خيارات الـ padding الخاصة به في Session Created. إرشادات الحد الأدنى/الأقصى TBD. حجم عشوائي من 0 إلى 31 بايت كحد أدنى؟ (التوزيع سيتم تحديده، انظر الملحق A.) TODO ما لم يتم فرض حد أدنى لحجم الحزمة من أجل PMTU.

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

• قد يُرسل Bob رسالة Retry تحتوي على رمز مميز صفري وكتلة Termination مع رمز سبب انحراف الساعة إذا كانت الطابع الزمني في كتلة DateTime منحرفة جداً.

• التخفيف من هجمات رفض الخدمة: DH عملية مكلفة نسبياً. كما هو الحال مع بروتوكول NTCP السابق، يجب على أجهزة router اتخاذ جميع التدابير اللازمة لمنع استنزاف المعالج أو الاتصالات. ضع حدود على الحد الأقصى للاتصالات النشطة والحد الأقصى لإعدادات الاتصال قيد التقدم. فرض مهلات زمنية للقراءة (لكل قراءة وإجمالية لـ “slowloris”). حد الاتصالات المتكررة أو المتزامنة من نفس المصدر. حافظ على قوائم سوداء للمصادر التي تفشل بشكل متكرر. لا تستجب لفشل AEAD. بدلاً من ذلك، استجب برسالة Retry قبل عملية DH والتحقق من صحة AEAD.

• حقل “ver”: بروتوكول Noise الشامل والإضافات وبروتوكول SSU2 بما في ذلك مواصفات الحمولة، مما يشير إلى SSU2. قد يُستخدم هذا الحقل للإشارة إلى دعم التغييرات المستقبلية.

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

• يجب على Bob إسقاط الرسالة إذا كان Source Connection ID يساوي Destination Connection ID.

KDF for Session Created and Session Confirmed part 1

// take h saved from Session Request KDF
  // MixHash(ciphertext)
  h = SHA256(h || encrypted Noise payload from Session Request)

  // MixHash(header)
  h = SHA256(h || header)

  This is the "e" message pattern:

  // Bob's X25519 ephemeral keys
  besk = GENERATE_PRIVATE()
  bepk = DERIVE_PUBLIC(besk)

  // h is from KDF for Session Request
  // Bob ephemeral key Y
  // MixHash(bepk)
  h = SHA256(h || bepk);

  // h is used as the associated data for the AEAD in Session Created
  // Retain the Hash h for the Session Confirmed KDF

  End of "e" message pattern.

  This is the "ee" message pattern:

  // MixKey(DH())
  //[chainKey, k] = MixKey(sharedSecret)
  sharedSecret = DH(aesk, bepk) = DH(besk, aepk)
  keydata = HKDF(chainKey, sharedSecret, "", 64)
  chainKey = keydata[0:31]

  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, payload, ad)

  // retain the chaining key ck for Session Confirmed KDF

  End of "ee" message pattern.

  // Header encryption keys for this message
  // bik = Bob's intro key
  k_header_1 = bik
  k_header_2: See Session Request KDF above

  // Header protection keys for next message (Session Confirmed)
  k_header_1 = bik
  k_header_2 = HKDF(chainKey, ZEROLEN, "SessionConfirmed", 32)

ترحيل الاتصال

يرسل Bob إلى Alice، استجابةً لرسالة Session Request. تستجيب Alice برسالة Session Confirmed. الحجم: 80 + حجم الحمولة. الحد الأدنى للحجم: 88

محتوى Noise: مفتاح Bob المؤقت Y حمولة Noise: DateTime والعنوان وكتل أخرى الحد الأقصى لحجم الحمولة: MTU - 108 (IPv4) أو MTU - 128 (IPv6). للـ MTU 1280: الحد الأقصى للحمولة هو 1172 (IPv4) أو 1152 (IPv6). للـ MTU 1500: الحد الأقصى للحمولة هو 1392 (IPv4) أو 1372 (IPv6).

خصائص أمان الحمولة:

XK(s, rs):           Authentication   Confidentiality
    <- e, ee                  2                1

    Authentication: 2.
    Sender authentication resistant to key-compromise impersonation (KCI).
    The sender authentication is based on an ephemeral-static DH ("es" or "se")
    between the sender's static key pair and the recipient's ephemeral key pair.
    Assuming the corresponding private keys are secure, this authentication cannot be forged.

    Confidentiality: 1.
    Encryption to an ephemeral recipient.
    This payload has forward secrecy, since encryption involves an ephemeral-ephemeral DH ("ee").
    However, the sender has not authenticated the recipient,
    so this payload might be sent to any party, including an active attacker.


    "e": Bob generates a new ephemeral key pair and stores it in the e variable,
    writes the ephemeral public key as cleartext into the message buffer,
    and hashes the public key along with the old h to derive a new h.

    "ee": A DH is performed between the Bob's ephemeral key pair and the Alice's ephemeral key pair.
    The result is hashed along with the old ck to derive a new ck and k, and n is set to zero.

قيمة Y مشفرة لضمان عدم القدرة على التمييز وفرادة الحمولة، وهما إجراءان ضروريان لمواجهة فحص الحزم العميق. نحن نستخدم تشفير ChaCha20 لتحقيق ذلك، بدلاً من البدائل الأكثر تعقيداً وبطئاً مثل elligator2. التشفير غير المتماثل لمفتاح router العام الخاص بـ Alice سيكون بطيئاً جداً. يستخدم تشفير ChaCha20 مفتاح intro الخاص بـ Bob، كما هو منشور في قاعدة بيانات الشبكة.

تشفير ChaCha20 هو لمقاومة DPI فقط. أي طرف يعرف مفتاح intro الخاص بـ Bob، والذي يتم نشره في قاعدة بيانات الشبكة، والتقط أول 32 بايت من Session Request، قد يفك تشفير قيمة Y في هذه الرسالة.

المحتويات الخام:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key and     +
  | derived key, see Header Encryption KDF|
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with derived key n=0       +
  |  See Header Encryption KDF            |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       Y, ChaCha20 encrypted           +
  |       with derived key n=0            |
  +              (32 bytes)               +
  |       See Header Encryption KDF       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 data                       |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in KDF for Session Created +
  |  n = 0; see KDF for associated data   |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

  Y :: 32 bytes, ChaCha20 encrypted X25519 ephemeral key, little endian
          key: Bob's intro key
          n: 1
          data: 48 bytes (bytes 16-31 of the header, followed by encrypted Y)

البيانات غير المشفرة (علامة مصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |      see below for allowed blocks     |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: The Source Connection ID
                               received from Alice in Session Request

  id :: 1 byte, the network ID (currently 2, except for test networks)

  ver :: 2

  type :: 0

  flag :: 1 byte, unused, set to 0 for future compatibility

  Packet Number :: Random 4 byte number generated by Bob, ignored

  Source Connection ID :: The Destination Connection ID
                          received from Alice in Session Request

  Token :: 0 (unused)

  Y :: 32 bytes, X25519 ephemeral key, little endian

Payload

• كتلة DateTime
• كتلة Address
• كتلة Relay Tag (اختيارية)
• كتلة New Token (اختيارية)
• كتلة First Packet Number (اختيارية)
• كتلة Options (اختيارية)
• كتلة Termination (غير مستحسنة، يُرسل في رسالة إعادة محاولة بدلاً من ذلك)
• كتلة Padding (اختيارية)

الحد الأدنى لحجم البيانات المفيدة هو 8 بايت. نظراً لأن كتل DateTime وAddress يبلغ مجموعها أكثر من ذلك، فإن المتطلب يتم تلبيته بهاتين الكتلتين فقط.

Notes

• يجب على Alice التحقق من أن مفتاح Bob المؤقت هو نقطة صالحة على المنحنى هنا.

• يجب أن يكون الحشو محدودًا بكمية معقولة. قد ترفض Alice الاتصالات التي تحتوي على حشو مفرط. ستحدد Alice خيارات الحشو الخاصة بها في Session Confirmed. إرشادات الحد الأدنى/الأقصى TBD. حجم عشوائي من 0 إلى 31 بايت كحد أدنى؟ (التوزيع سيتم تحديده، انظر الملحق A.) TODO UNLESS يتم فرض حد أدنى لحجم الحزمة لـ PMTU.

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

• يجب على Alice رفض الاتصالات حيث تكون قيمة الوقت بعيدة جداً عن الوقت الحالي. لنسمِ الحد الأقصى لفرق الوقت “D”. يجب على Alice الاحتفاظ بذاكرة تخزين مؤقت محلية لقيم المصافحة المستخدمة سابقاً ورفض المكررات، لمنع هجمات إعادة التشغيل. يجب أن تكون للقيم في ذاكرة التخزين المؤقت مدة حياة لا تقل عن 2*D. قيم ذاكرة التخزين المؤقت تعتمد على التنفيذ، ومع ذلك يمكن استخدام قيمة Y بحجم 32 بايت (أو ما يعادلها المشفر).

• يجب على Alice إسقاط الرسالة إذا لم يتطابق IP المصدر والمنفذ مع IP الوجهة والمنفذ الخاص بـ Session Request.

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

• يرسل Bob كتلة علامة الترحيل (relay tag block) إذا طلبتها Alice في طلب الجلسة (Session Request).

Issues

• هل نضمّن خيارات الحشو (padding) الدنيا/العليا هنا؟

KDF for Session Confirmed part 1, using Session Created KDF

// take h saved from Session Created KDF
  // MixHash(ciphertext)
  h = SHA256(h || encrypted Noise payload from Session Created)

  // MixHash(header)
  h = SHA256(h || header)
  // h is used as the associated data for the AEAD in Session Confirmed part 1, below

  This is the "s" message pattern:

  // Alice's X25519 static keys
  ask = GENERATE_PRIVATE()
  apk = DERIVE_PUBLIC(ask)

  // AEAD parameters
  // k is from Session Request
  n = 1
  ad = h
  ciphertext = ENCRYPT(k, n++, apk, ad)

  // MixHash(ciphertext)
  h = SHA256(h || ciphertext);

  // h is used as the associated data for the AEAD in Session Confirmed part 2

  End of "s" message pattern.

  // Header encryption keys for this message
  See Session Confirmed part 2 below

KDF for Session Confirmed part 2

This is the "se" message pattern:

  // DH(ask, bepk) == DH(besk, apk)
  sharedSecret = DH(ask, bepk) = DH(besk, apk)

  // MixKey(DH())
  //[chainKey, k] = MixKey(sharedSecret)
  keydata = HKDF(chainKey, sharedSecret, "", 64)
  chainKey = keydata[0:31]

  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, payload, ad)

  // h from Session Confirmed part 1 is used as the associated data for the AEAD in Session Confirmed part 2
  // MixHash(ciphertext)
  h = SHA256(h || ciphertext);

  // retain the chaining key ck for the data phase KDF
  // retain the hash h for the data phase KDF

  End of "se" message pattern.

  // Header encryption keys for this message
  // bik = Bob's intro key
  k_header_1 = bik
  k_header_2: See Session Created KDF above

  // Header protection keys for data phase
  See data phase KDF below

SessionConfirmed (Type 2)

Alice ترسل إلى Bob، استجابةً لرسالة Session Created. Bob يجيب فوراً برسالة Data تحتوي على كتلة ACK. الحجم: 80 + حجم payload. الحد الأدنى للحجم: حوالي 500 (الحد الأدنى لحجم كتلة router info حوالي 420 بايت)

محتوى Noise: المفتاح الثابت لـ Alice جزء حمولة Noise 1: لا شيء جزء حمولة Noise 2: RouterInfo الخاص بـ Alice، وكتل أخرى الحد الأقصى لحجم الحمولة: MTU - 108 (IPv4) أو MTU - 128 (IPv6). لـ MTU بقيمة 1280: الحد الأقصى للحمولة هو 1172 (IPv4) أو 1152 (IPv6). لـ MTU بقيمة 1500: الحد الأقصى للحمولة هو 1392 (IPv4) أو 1372 (IPv6).

خصائص أمان الحمولة:

XK(s, rs):           Authentication   Confidentiality
    -> s, se                  2                5

    Authentication: 2.
    Sender authentication resistant to key-compromise impersonation (KCI).  The
    sender authentication is based on an ephemeral-static DH ("es" or "se")
    between the sender's static key pair and the recipient's ephemeral key
    pair.  Assuming the corresponding private keys are secure, this
    authentication cannot be forged.

    Confidentiality: 5.
    Encryption to a known recipient, strong forward secrecy.  This payload is
    encrypted based on an ephemeral-ephemeral DH as well as an ephemeral-static
    DH with the recipient's static key pair.  Assuming the ephemeral private
    keys are secure, and the recipient is not being actively impersonated by an
    attacker that has stolen its static private key, this payload cannot be
    decrypted.

    "s": Alice writes her static public key from the s variable into the
    message buffer, encrypting it, and hashes the output along with the old h
    to derive a new h.

    "se": A DH is performed between the Alice's static key pair and the Bob's
    ephemeral key pair.  The result is hashed along with the old ck to derive a
    new ck and k, and n is set to zero.

يحتوي هذا على إطارين من ChaChaPoly. الأول هو المفتاح العام الثابت المُشفر لأليس. الثاني هو حمولة Noise: RouterInfo المُشفر لأليس، والخيارات الاختيارية، والحشو الاختياري. يستخدمان مفاتيح مختلفة، لأن دالة MixKey() يتم استدعاؤها بينهما.

المحتويات الخام:

+----+----+----+----+----+----+----+----+
  |  Short Header 16 bytes, ChaCha20      |
  +  encrypted with Bob intro key and     +
  | derived key, see Header Encryption KDF|
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 frame (32 bytes)           |
  +   Encrypted and authenticated data    +
  +   Alice static key S                  +
  | k defined in KDF for Session Created  |
  +     n = 1                             +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  + Length varies (remainder of packet)   +
  |                                       |
  +   ChaChaPoly frame                    +
  |   Encrypted and authenticated         |
  +   see below for allowed blocks        +
  |                                       |
  +     k defined in KDF for              +
  |     Session Confirmed part 2          |
  +     n = 0                             +
  |     see KDF for associated data       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

  S :: 32 bytes, ChaChaPoly encrypted Alice's X25519 static key, little endian
       inside 48 byte ChaChaPoly frame

البيانات غير المشفرة (علامات المصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type|frag|  flags  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |              S                        |
  +       Alice static key                +
  |          (32 bytes)                   |
  +                                       +
  |                                       |
  +                                       +
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |        Noise Payload                  |
  +        (length varies)                +
  |        see below for allowed blocks   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: As sent in Session Request,
                               or one received in Session Confirmed?

  Packet Number :: 0 always, for all fragments, even if retransmitted

  type :: 2

  frag :: 1 byte fragment info:
         bit order: 76543210 (bit 7 is MSB)
         bits 7-4: fragment number 0-14, big endian
         bits 3-0: total fragments 1-15, big endian

  flags :: 2 bytes, unused, set to 0 for future compatibility

  S :: 32 bytes, Alice's X25519 static key, little endian

Payload

• كتلة RouterInfo (يجب أن تكون الكتلة الأولى)
• كتلة الخيارات (اختيارية)
• كتلة New Token (اختيارية)
• كتلة Relay Request (اختيارية)
• كتلة Peer Test (اختيارية)
• كتلة First Packet Number (اختيارية)
• كتل I2NP أو First Fragment أو Follow-on Fragment (اختيارية، لكن ربما لا توجد مساحة)
• كتلة الحشو (اختيارية)

الحد الأدنى لحجم البيانات المفيدة هو 8 بايت. وحيث أن كتلة RouterInfo ستكون أكبر من ذلك بكثير، فإن المتطلب يتم الوفاء به بهذه الكتلة فقط.

Notes

• يجب على Bob أن يقوم بالتحقق المعتاد من Router Info. تأكد من أن نوع التوقيع مدعوم، تحقق من التوقيع، تحقق من أن الطابع الزمني ضمن الحدود المقبولة، وأي فحوصات أخرى ضرورية. انظر أدناه للملاحظات حول التعامل مع Router Infos المجزأة.

• يجب على Bob التحقق من أن المفتاح الثابت لـ Alice المستلم في الإطار الأول يطابق المفتاح الثابت في Router Info. يجب على Bob أولاً البحث في Router Info عن عنوان NTCP أو SSU2 Router Address مع خيار إصدار (v) مطابق. انظر أقسام Published Router Info و Unpublished Router Info أدناه. انظر أدناه للملاحظات حول التعامل مع Router Infos المجزأة.

• إذا كان لدى Bob نسخة أقدم من RouterInfo الخاص بـ Alice في netDb الخاص به، تحقق من أن الـ static key في معلومات الـ router هو نفسه في كليهما، إن وُجد، وإذا كانت النسخة الأقدم أقل من XXX قدماً (انظر وقت دوران المفتاح أدناه)

• يجب على Bob التحقق من أن المفتاح الثابت لـ Alice هو نقطة صالحة على المنحنى هنا.

• يجب تضمين الخيارات، لتحديد معاملات الحشو.

• في حالة حدوث أي خطأ، بما في ذلك فشل التحقق من AEAD أو RI أو DH أو الطابع الزمني أو المفتاح، يجب على Bob إيقاف معالجة الرسائل الإضافية وإغلاق الاتصال دون الرد.

• محتوى إطار الجزء الثاني من الرسالة 3: تنسيق هذا الإطار هو نفس تنسيق إطارات مرحلة البيانات، باستثناء أن طول الإطار يتم إرساله بواسطة Alice في Session Request. انظر أدناه لتنسيق إطار مرحلة البيانات. يجب أن يحتوي الإطار على 1 إلى 4 كتل بالترتيب التالي:

  1. كتلة Router Info الخاصة بـ Alice (مطلوبة)
  2. كتلة Options (اختيارية)
  3. كتل I2NP (اختيارية)
  4. كتلة Padding (اختيارية) يجب ألا يحتوي هذا الإطار أبداً على أي نوع آخر من الكتل. TODO: ماذا عن relay وpeer test؟

• كتلة الحشو للجزء الثاني من الرسالة 3 مُوصى بها.

• قد لا تتوفر مساحة، أو قد تتوفر مساحة صغيرة فقط، لكتل I2NP، اعتماداً على MTU وحجم Router Info. لا تتضمن كتل I2NP إذا كان Router Info مجزأ. قد يكون أبسط تنفيذ هو عدم تضمين كتل I2NP أبداً في رسالة Session Confirmed، وإرسال جميع كتل I2NP في رسائل Data اللاحقة. راجع قسم كتلة Router Info أدناه لمعرفة الحد الأقصى لحجم الكتلة.

Session Confirmed Fragmentation

يجب أن تحتوي رسالة Session Confirmed على Router Info الموقعة بالكامل من Alice حتى يتمكن Bob من إجراء عدة فحوصات مطلوبة:

• المفتاح الثابت “s” في RI يطابق المفتاح الثابت في handshake
• مفتاح التعريف “i” في RI يجب استخراجه وأن يكون صالحاً، ليتم استخدامه في مرحلة البيانات
• توقيع RI صالح

لسوء الحظ، قد تتجاوز معلومات الموجه Router Info، حتى عند ضغطها بـ gzip في كتلة RI، حجم MTU. لذلك، قد يتم تجزئة Session Confirmed عبر حزمتين أو أكثر. هذه هي الحالة الوحيدة في بروتوكول SSU2 حيث يتم تجزئة حمولة محمية بـ AEAD عبر حزمتين أو أكثر.

يتم بناء الرؤوس لكل حزمة كما يلي:

• جميع الرؤوس هي رؤوس قصيرة بنفس رقم الحزمة 0
• جميع الرؤوس تحتوي على حقل “frag”، مع رقم الجزء والعدد الإجمالي للأجزاء
• الرأس غير المشفر للجزء 0 هو البيانات المرتبطة (AD) لرسالة “jumbo”
• كل رأس يتم تشفيره باستخدام آخر 24 بايت من البيانات في تلك الحزمة

قم ببناء سلسلة الحزم كما يلي:

• إنشاء كتلة RI واحدة (الجزء 0 من 1 في حقل frag لكتلة RI). نحن لا نستخدم تجزئة كتلة RI، كانت تلك لطريقة بديلة لحل نفس المشكلة.
• إنشاء حمولة “jumbo” مع كتلة RI وأي كتل أخرى ليتم تضمينها
• حساب إجمالي حجم البيانات (لا يشمل الرأس)، وهو حجم الحمولة + 64 بايت للمفتاح الثابت واثنين من MACs
• حساب المساحة المتاحة في كل حزمة، والتي تساوي MTU ناقص رأس IP (20 أو 40)، ناقص رأس UDP (8)، ناقص رأس SSU2 القصير (16). إجمالي الأعباء الإضافية لكل حزمة هو 44 (IPv4) أو 64 (IPv6).
• حساب عدد الحزم.
• حساب حجم البيانات في الحزمة الأخيرة. يجب أن يكون أكبر من أو يساوي 24 بايت، بحيث يعمل تشفير الرأس. إذا كان صغيراً جداً، إما إضافة كتلة حشو، أو زيادة حجم كتلة الحشو إن وجدت بالفعل، أو تقليل حجم إحدى الحزم الأخرى بحيث تكون الحزمة الأخيرة كبيرة بما فيه الكفاية.
• إنشاء الرأس غير المشفر للحزمة الأولى، مع العدد الإجمالي للأجزاء في حقل frag، وتشفير الحمولة “jumbo” باستخدام Noise، مع استخدام الرأس كـ AD، كالمعتاد.
• تقسيم الحزمة jumbo المشفرة إلى أجزاء
• إضافة رأس غير مشفر لكل جزء 1-n
• تشفير الرأس لكل جزء 0-n. كل رأس يستخدم نفس k_header_1 و k_header_2 كما هو معرّف أعلاه في Session Confirmed KDF.
• إرسال جميع الأجزاء

عملية إعادة التجميع:

عندما يستقبل Bob أي رسالة Session Confirmed، فإنه يفك تشفير الرأس، ويفحص حقل frag، ويحدد أن Session Confirmed مجزأة. لا يقوم (ولا يستطيع) بفك تشفير الرسالة حتى يتم استقبال جميع الأجزاء وإعادة تجميعها.

• احتفظ بالعنوان الخاص بالجزء 0، حيث يتم استخدامه كـ Noise AD
• تجاهل العناوين الخاصة بالأجزاء الأخرى قبل إعادة التجميع
• أعد تجميع الحمولة الـ “jumbo”، مع العنوان الخاص بالجزء 0 كـ AD، وفك التشفير باستخدام Noise
• تحقق من كتلة الـ RI كالمعتاد
• انتقل إلى مرحلة البيانات وأرسل ACK 0، كالمعتاد

لا توجد آلية لـ Bob لإرسال إقرار استلام للأجزاء الفردية. عندما يستلم Bob جميع الأجزاء، ويعيد تجميعها، ويفك تشفيرها، ويتحقق من صحة المحتويات، يقوم Bob بعملية split() كالمعتاد، ويدخل مرحلة البيانات، ويرسل ACK لرقم الحزمة 0.

إذا لم تتلق Alice إقرار استلام (ACK) للحزمة رقم 0، يجب عليها إعادة إرسال جميع حزم تأكيد الجلسة كما هي.

أمثلة:

بالنسبة لـ 1500 MTU عبر IPv6، أقصى حمولة هي 1372، وإضافة كتلة RI هي 5، وأقصى حجم لبيانات RI (المضغوطة بـ gzip) هو 1367 (بافتراض عدم وجود كتل أخرى). مع حزمتين، إضافة الحزمة الثانية هي 64، لذا يمكنها حمل 1436 بايت إضافية من الحمولة. إذن حزمتان كافيتان لـ RI مضغوط يصل إلى 2803 بايت.

أكبر RI مضغوط شوهد في الشبكة الحالية يبلغ حوالي 1400 بايت؛ لذلك، في الممارسة العملية، يجب أن يكون جزأين كافيين، حتى مع الحد الأدنى للـ MTU البالغ 1280. يسمح البروتوكول بحد أقصى 15 جزءًا.

تحليل الأمان:

سلامة وأمان Session Confirmed المجزأة هي نفسها للغير مجزأة. أي تغيير في أي جزء سيؤدي إلى فشل Noise AEAD بعد إعادة التجميع. رؤوس الأجزاء بعد الجزء 0 تُستخدم فقط لتحديد الجزء. حتى لو كان لدى مهاجم على المسار مفتاح k_header_2 المستخدم لتشفير الرأس (غير محتمل، مُشتق من المصافحة)، فإن هذا لن يسمح للمهاجم بتبديل جزء صالح.

KDF for data phase

مرحلة البيانات تستخدم الرأس للبيانات المرتبطة.

تقوم KDF بتوليد مفتاحين للتشفير k_ab و k_ba من مفتاح التسلسل ck، باستخدام HMAC-SHA256(key, data) كما هو محدد في RFC 2104. هذه هي دالة split()، تماماً كما هي محددة في مواصفات Noise.

// split()
  // chainKey = from handshake phase
  keydata = HKDF(chainKey, ZEROLEN, "", 64)
  k_ab = keydata[0:31]
  k_ba = keydata[32:63]

  // key is k_ab for Alice to Bob
  // key is k_ba for Bob to Alice

  keydata = HKDF(key, ZEROLEN, "HKDFSSU2DataKeys", 64)
  k_data = keydata[0:31]
  k_header_2 = keydata[32:63]


  // AEAD parameters
  k = k_data
  n = 4 byte packet number from header
  ad = 16 byte header, before header encryption
  ciphertext = ENCRYPT(k, n, payload, ad)

  // Header encryption keys for data phase
  // aik = Alice's intro key
  // bik = Bob's intro key
  k_header_1 = Receiver's intro key (aik or bik)
  k_header_2: from above

Data Message (Type 6)

حمولة Noise: جميع أنواع الكتل مسموحة. الحد الأقصى لحجم الحمولة: MTU - 60 (IPv4) أو MTU - 80 (IPv6). لـ MTU 1500: الحد الأقصى للحمولة هو 1440 (IPv4) أو 1420 (IPv6).

بدءاً من الجزء الثاني من Session Confirmed، تكون جميع الرسائل داخل حمولة ChaChaPoly مُصادق عليها ومُشفرة. جميع الحشو موجود داخل الرسالة. داخل الحمولة يوجد تنسيق قياسي مع صفر أو أكثر من “الكتل”. كل كتلة تحتوي على نوع من بايت واحد وطول من بايتين. الأنواع تشمل التاريخ/الوقت، ورسالة I2NP، والخيارات، والإنهاء، والحشو.

ملاحظة: يمكن لـ Bob، ولكنه غير مطالب، بإرسال RouterInfo الخاص به إلى Alice كأول رسالة له إلى Alice في مرحلة البيانات.

خصائص أمان الحمولة:

XK(s, rs):           Authentication   Confidentiality
    <-                        2                5
    ->                        2                5

    Authentication: 2.
    Sender authentication resistant to key-compromise impersonation (KCI).
    The sender authentication is based on an ephemeral-static DH ("es" or "se")
    between the sender's static key pair and the recipient's ephemeral key pair.
    Assuming the corresponding private keys are secure, this authentication cannot be forged.

    Confidentiality: 5.
    Encryption to a known recipient, strong forward secrecy.
    This payload is encrypted based on an ephemeral-ephemeral DH as well as
    an ephemeral-static DH with the recipient's static key pair.
    Assuming the ephemeral private keys are secure, and the recipient is not being actively impersonated
    by an attacker that has stolen its static private key, this payload cannot be decrypted.

Notes

• يجب على الـ router إسقاط الرسالة التي تحتوي على خطأ AEAD.

+----+----+----+----+----+----+----+----+
  |  Short Header 16 bytes, ChaCha20      |
  +  encrypted with intro key and         +
  |  derived key, see Data Phase KDF      |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 data                       |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in Data Phase KDF          +
  |  n = packet number from header        |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

البيانات غير المشفرة (علامة المصادقة Poly1305 غير مُظهرة):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type|    flags     |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |                                       |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: As specified in session setup

  Packet Number :: 4 byte big endian integer

  type :: 6

  flags :: 3 bytes, unused, set to 0 for future compatibility

Notes

• الحد الأدنى لحجم الحمولة هو 8 بايت. سيتم الوفاء بهذا المتطلب بواسطة أي كتلة ACK أو I2NP أو First Fragment أو Follow-on Fragment. إذا لم يتم الوفاء بالمتطلب، يجب تضمين كتلة Padding.

• يجب استخدام كل رقم حزمة مرة واحدة فقط. عند إعادة إرسال رسائل I2NP أو الأجزاء، يجب استخدام رقم حزمة جديد.

KDF for Peer Test

// AEAD parameters
  // bik = Bob's intro key
  k = bik
  n = 4 byte packet number from header
  ad = 32 byte header, before header encryption
  ciphertext = ENCRYPT(k, n, payload, ad)

  // Header encryption keys for this message
  k_header_1 = bik
  k_header_2 = bik

Peer Test (Type 7)

يرسل Charlie إلى Alice، وترسل Alice إلى Charlie، لمراحل Peer Test 5-7 فقط. يجب إرسال مراحل Peer Test 1-4 داخل الجلسة باستخدام كتلة Peer Test في رسالة Data. راجع قسمي Peer Test Block وعملية Peer Test أدناه للمزيد من المعلومات.

الحجم: 48 + حجم البيانات المفيدة.

حمولة Noise: انظر أدناه.

المحتويات الخام:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Alice or Charlie      +
  |  intro key                            |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Alice or Charlie      +
  |  intro key                            |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data             |
  +          (length varies)              +
  |                                       |
  +  see KDF for key and n                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

البيانات غير المشفرة (علامة المصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |    ChaCha20 payload (block data)      |
  +          (length varies)              +
  |    see below for allowed blocks       |
  +----+----+----+----+----+----+----+----+


  Destination Connection ID :: See below

  type :: 7

  ver :: 2

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Packet Number :: Random number generated by Alice or Charlie

  Source Connection ID :: See below

  Token :: Randomly generated by Alice or Charlie, ignored

عنوان طويل

• كتلة DateTime
• كتلة Address (مطلوبة للرسائل 6 و 7، انظر الملاحظة أدناه)
• كتلة Peer Test
• كتلة Padding (اختيارية)

الحد الأدنى لحجم البيانات المفيدة هو 8 بايت. نظرًا لأن كتلة Peer Test يبلغ مجموعها أكثر من ذلك، فإن المتطلب يتم الوفاء به بهذه الكتلة فقط.

في الرسائل 5 و 7، قد يكون بلوك Peer Test مطابقاً للبلوك من الرسائل داخل الجلسة 3 و 4، والذي يحتوي على الاتفاقية الموقعة من قبل Charlie، أو قد يتم إعادة توليده. التوقيع اختياري.

في الرسالة 6، قد يكون كتلة اختبار النظير (Peer Test block) مطابقة للكتلة من الرسائل داخل الجلسة 1 و 2، والتي تحتوي على الطلب الموقع من قبل أليس، أو قد يتم إعادة إنتاجها. التوقيع اختياري.

معرفات الاتصال: يتم اشتقاق معرفي الاتصال من test nonce. للرسائل 5 و 7 المرسلة من Charlie إلى Alice، يكون Destination Connection ID عبارة عن نسختين من test nonce بحجم 4 بايت big-endian، أي ((nonce « 32) | nonce). Source Connection ID هو عكس Destination Connection ID، أي ~((nonce « 32) | nonce). للرسالة 6 المرسلة من Alice إلى Charlie، يتم تبديل معرفي الاتصال.

محتويات كتلة العنوان:

• في الرسالة 5: غير مطلوب.
• في الرسالة 6: عنوان IP ومنفذ Charlie كما تم اختيارهما من RI الخاص بـ Charlie.
• في الرسالة 7: عنوان IP ومنفذ Alice الفعليان اللذان تم استقبال الرسالة 6 منهما.

KDF for Retry

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

// AEAD parameters
  // bik = Bob's intro key
  k = bik
  n = 4 byte packet number from header
  ad = 32 byte header, before header encryption
  ciphertext = ENCRYPT(k, n, payload, ad)

  // Header encryption keys for this message
  k_header_1 = bik
  k_header_2 = bik

Retry (Type 9)

يرسل Bob إلى Alice، كاستجابة لرسالة Session Request أو Token Request. تستجيب Alice برسالة Session Request جديدة. الحجم: 48 + حجم البيانات.

يعمل أيضاً كرسالة إنهاء (أي، “لا تعيد المحاولة”) إذا تم تضمين كتلة إنهاء.

Noise payload: انظر أدناه.

المحتويات الخام:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key         +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Bob intro key         +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data             |
  +          (length varies)              +
  |                                       |
  +  see KDF for key and n                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

البيانات غير المشفرة (علامة مصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |    ChaCha20 payload (block data)      |
  +          (length varies)              +
  |    see below for allowed blocks       |
  +----+----+----+----+----+----+----+----+


  Destination Connection ID :: The Source Connection ID
                               received from Alice in Token Request
                               or Session Request

  Packet Number :: Random number generated by Bob

  type :: 9

  ver :: 2

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: The Destination Connection ID
                          received from Alice in Token Request
                          or Session Request

  Token :: 8 byte unsigned integer, randomly generated by Bob, nonzero,
           or zero if session is rejected and a termination block is included

رأس قصير

• كتلة DateTime
• كتلة العنوان
• كتلة الخيارات (اختيارية)
• كتلة الإنهاء (اختيارية، إذا تم رفض الجلسة)
• كتلة الحشو (اختيارية)

الحد الأدنى لحجم الحمولة هو 8 بايت. نظراً لأن كتل DateTime و Address يبلغ مجموعها أكثر من ذلك، فإن المتطلب يتم تلبيته بهاتين الكتلتين فقط.

ترقيم معرف الاتصال

• لتوفير مقاومة التحقيق، يجب على router ألا يرسل رسالة Retry كاستجابة لرسالة Session Request أو Token Request ما لم تكن حقول نوع الرسالة وإصدار البروتوكول ومعرف الشبكة في رسالة Request صحيحة.

• لتحديد حجم أي هجوم تضخيم يمكن تنفيذه باستخدام عناوين مصدر مزيفة، يجب ألا تحتوي رسالة Retry على كميات كبيرة من الحشو. يُوصى بأن تكون رسالة Retry لا تزيد عن ثلاثة أضعاف حجم الرسالة التي تستجيب لها. بدلاً من ذلك، استخدم طريقة بسيطة مثل إضافة كمية عشوائية من الحشو في النطاق 1-64 بايت.

KDF for Token Request

يجب أن تكون هذه الرسالة سريعة التوليد، باستخدام التشفير المتماثل فقط.

// AEAD parameters
  // bik = Bob's intro key
  k = bik
  n = 4 byte packet number from header
  ad = 32 byte header, before header encryption
  ciphertext = ENCRYPT(k, n, payload, ad)

  // Header encryption keys for this message
  k_header_1 = bik
  k_header_2 = bik

Token Request (Type 10)

أليس ترسل إلى بوب. بوب يجيب برسالة Retry. الحجم: 48 + حجم الحمولة.

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

الحمولة الصوتية: انظر أدناه.

المحتويات الخام:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key         +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Bob intro key         +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data             |
  +          (length varies)              +
  |                                       |
  +  see KDF for key and n                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

البيانات غير المشفرة (علامة المصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |    ChaCha20 payload (block data)      |
  +          (length varies)              +
  |    see below for allowed blocks       |
  +----+----+----+----+----+----+----+----+


  Destination Connection ID :: Randomly generated by Alice

  Packet Number :: Random number generated by Alice

  type :: 10

  ver :: 2

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: Randomly generated by Alice,
                          must not be equal to Destination Connection ID

  Token :: zero

ترقيم الحزم

• كتلة DateTime
• كتلة Padding

الحد الأدنى لحجم الحمولة هو 8 بايت.

ربط الرأسية

• لتوفير مقاومة الاستطلاع، يجب على الـ router ألا يرسل رسالة Retry كرد على رسالة Token Request ما لم تكن حقول نوع الرسالة وإصدار البروتوكول ومعرف الشبكة في رسالة Token Request صحيحة.

• هذه ليست رسالة Noise قياسية وليست جزءًا من عملية المصافحة. وهي غير مرتبطة برسالة طلب الجلسة إلا من خلال معرفات الاتصال.

• في معظم الأخطاء، بما في ذلك AEAD، أو إعادة التشغيل الظاهرة يجب على Bob إيقاف معالجة الرسائل الإضافية و إسقاط الرسالة دون الرد.

• يجب على Bob رفض الاتصالات التي تكون فيها قيمة الطابع الزمني بعيدة جداً عن الوقت الحالي. أطلق على أقصى فرق زمني اسم “D”. يجب على Bob الاحتفاظ بذاكرة تخزين مؤقت محلية للقيم المستخدمة سابقاً في handshake ورفض القيم المكررة، لمنع هجمات replay. يجب أن تكون للقيم في ذاكرة التخزين المؤقت مدة حياة لا تقل عن 2*D. قيم ذاكرة التخزين المؤقت تعتمد على التنفيذ، ومع ذلك يمكن استخدام قيمة X ذات الـ 32 بايت (أو ما يعادلها مشفراً).

• يجوز لـ Bob إرسال رسالة Retry تحتوي على token صفري وكتلة Termination مع رمز سبب انحراف الساعة إذا كانت الطابع الزمني في كتلة DateTime منحرفاً جداً.

• الحد الأدنى للحجم: TBD، نفس القواعد كما هو الحال بالنسبة لـ Session Created؟

KDF for Hole Punch

يجب أن تكون هذه الرسالة سريعة في التوليد، باستخدام التشفير المتماثل فقط.

// AEAD parameters
  // aik = Alice's intro key
  k = aik
  n = 4 byte packet number from header
  ad = 32 byte header, before header encryption
  ciphertext = ENCRYPT(k, n, payload, ad)

  // Header encryption keys for this message
  k_header_1 = aik
  k_header_2 = aik

Hole Punch (Type 11)

تشارلي يرسل إلى أليس، كاستجابة لـ Relay Intro المستلم من بوب. أليس ترد بـ Session Request جديد. الحجم: 48 + حجم الحمولة.

حمولة Noise: انظر أدناه.

المحتويات الخام:

+----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Alice intro key       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Alice intro key       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data             |
  +          (length varies)              +
  |                                       |
  +  see KDF for key and n                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

البيانات غير المشفرة (علامة مصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |    ChaCha20 payload (block data)      |
  +          (length varies)              +
  |    see below for allowed blocks       |
  +----+----+----+----+----+----+----+----+


  Destination Connection ID :: See below

  Packet Number :: Random number generated by Charlie

  type :: 11

  ver :: 2

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: See below

  Token :: 8 byte unsigned integer, randomly generated by Charlie, nonzero.

تشفير العنوان

• كتلة DateTime
• كتلة Address
• كتلة Relay Response
• كتلة Padding (اختيارية)

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

معرفات الاتصال: يتم اشتقاق معرفي الاتصال من الـ relay nonce. معرف اتصال الوجهة هو نسختان من الـ 4-byte big-endian relay nonce، أي ((nonce « 32) | nonce). معرف اتصال المصدر هو عكس معرف اتصال الوجهة، أي ~((nonce « 32) | nonce).

يجب على Alice تجاهل الرمز المميز في الرأس. الرمز المميز الذي سيتم استخدامه في طلب الجلسة موجود في كتلة استجابة التتابع.

Noise Payload

كل حمولة Noise تحتوي على صفر أو أكثر من “الكتل”.

يستخدم هذا نفس تنسيق الكتل كما هو محدد في مواصفات NTCP2 و ECIES. أنواع الكتل الفردية محددة بشكل مختلف. المصطلح المكافئ في QUIC RFC 9000 هو “frames”.

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

اعتبارات الأمان

يوجد كتلة واحدة أو أكثر في الحمولة المشفرة. الكتلة هي تنسيق بسيط من نوع Tag-Length-Value (TLV). كل كتلة تحتوي على معرف من بايت واحد، وطول من بايتين، وصفر أو أكثر من بايتات البيانات. هذا التنسيق مطابق لذلك الموجود في NTCP2 و ECIES، لكن تعريفات الكتل مختلفة.

للقابلية للتوسع، يجب على المستقبِلات تجاهل الكتل ذات المعرفات غير المعروفة، والتعامل معها كحشو.

(علامة مصادقة Poly1305 غير معروضة):

+----+----+----+----+----+----+----+----+
  |blk |  size   |       data             |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  |blk |  size   |       data             |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  ~               .   .   .               ~

  blk :: 1 byte, see below
  size :: 2 bytes, big endian, size of data to follow, 0 - TBD
  data :: the data

تستخدم تشفير الرأس آخر 24 بايت من الحزمة كـ IV للعمليتين ChaCha20. نظرًا لأن جميع الحزم تنتهي بـ MAC بحجم 16 بايت، فإن هذا يتطلب أن تكون جميع حمولات الحزم بحد أدنى 8 بايت. إذا لم تفِ الحمولة بهذا المتطلب بطريقة أخرى، فيجب تضمين كتلة Padding.

يختلف الحد الأقصى لحمولة ChaChaPoly بناءً على نوع الرسالة و MTU ونوع عنوان IPv4 أو IPv6. الحد الأقصى للحمولة هو MTU - 60 لـ IPv4 و MTU - 80 لـ IPv6. الحد الأقصى لبيانات الحمولة هو MTU - 63 لـ IPv4 و MTU - 83 لـ IPv6. الحد الأعلى هو حوالي 1440 بايت لـ IPv4، 1500 MTU، رسالة البيانات. الحد الأقصى لحجم الكتلة الإجمالي هو الحد الأقصى لحجم الحمولة. الحد الأقصى لحجم الكتلة الواحدة هو الحد الأقصى لحجم الكتلة الإجمالي. نوع الكتلة هو 1 بايت. طول الكتلة هو 2 بايت. الحد الأقصى لحجم بيانات الكتلة الواحدة هو الحد الأقصى لحجم الكتلة الواحدة ناقص 3.

ملاحظات:

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

• يجب على التطبيقات تجاهل أنواع الكتل غير المعروفة من أجل التوافق المستقبلي.

أنواع الكتل:

Block Ordering Rules

في الجلسة المؤكدة، يجب أن تكون معلومات الراوتر (Router Info) هي الكتلة الأولى.

في جميع الرسائل الأخرى، الترتيب غير محدد، باستثناء المتطلبات التالية: Padding، إذا كان موجوداً، يجب أن يكون الكتلة الأخيرة. Termination، إذا كان موجوداً، يجب أن يكون الكتلة الأخيرة باستثناء Padding. عدة كتل Padding غير مسموحة في حمولة واحدة.

Block Specifications

تشفير الترويسة KDF

لمزامنة الوقت:

+----+----+----+----+----+----+----+
  | 0  |    4    |     timestamp     |
  +----+----+----+----+----+----+----+

  blk :: 0
  size :: 2 bytes, big endian, value = 4
  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106

ملاحظات:

• على عكس SSU 1، لا يوجد طابع زمني في رأس الحزمة لمرحلة البيانات في SSU 2.
• يجب على التطبيقات إرسال كتل DateTime بشكل دوري في مرحلة البيانات.
• يجب على التطبيقات التقريب إلى أقرب ثانية لمنع انحياز الساعة في الشبكة.

التحقق من صحة الرأسية

تمرير الخيارات المحدثة. تتضمن الخيارات: الحد الأدنى والأقصى للحشو.

كتلة الخيارات ستكون بطول متغير.

+----+----+----+----+----+----+----+----+
  | 1  |  size   |tmin|tmax|rmin|rmax|tdmy|
  +----+----+----+----+----+----+----+----+
  |tdmy|  rdmy   |  tdelay |  rdelay |    |
  ~----+----+----+----+----+----+----+    ~
  |              more_options             |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 1
  size :: 2 bytes, big endian, size of options to follow, 12 bytes minimum

  tmin, tmax, rmin, rmax :: requested padding limits
      tmin and rmin are for desired resistance to traffic analysis.
      tmax and rmax are for bandwidth limits.
      tmin and tmax are the transmit limits for the router sending this options block.
      rmin and rmax are the receive limits for the router sending this options block.
      Each is a 4.4 fixed-point float representing 0 to 15.9375
      (or think of it as an unsigned 8-bit integer divided by 16.0).
      This is the ratio of padding to data. Examples:
      Value of 0x00 means no padding
      Value of 0x01 means add 6 percent padding
      Value of 0x10 means add 100 percent padding
      Value of 0x80 means add 800 percent (8x) padding
      Alice and Bob will negotiate the minimum and maximum in each direction.
      These are guidelines, there is no enforcement.
      Sender should honor receiver's maximum.
      Sender may or may not honor receiver's minimum, within bandwidth constraints.

  tdmy: Max dummy traffic willing to send, 2 bytes big endian, bytes/sec average
  rdmy: Requested dummy traffic, 2 bytes big endian, bytes/sec average
  tdelay: Max intra-message delay willing to insert, 2 bytes big endian, msec average
  rdelay: Requested intra-message delay, 2 bytes big endian, msec average

  Padding distribution specified as additional parameters?
  Random delay specified as additional parameters?

  more_options :: Format TBD

مشاكل الخيارات:

• تفاوض الخيارات لم يتم تحديده بعد.

RouterInfo

مرر RouterInfo الخاص بأليس إلى بوب. يُستخدم فقط في الحمولة الخاصة بالجزء الثاني من Session Confirmed. لا يجب استخدامه في مرحلة البيانات؛ استخدم رسالة I2NP DatabaseStore بدلاً من ذلك.

الحد الأدنى للحجم: حوالي 420 بايت، إلا إذا كانت هوية الـ router والتوقيع في معلومات الـ router قابلة للضغط، وهو أمر غير محتمل.

ملاحظة: كتلة Router Info لا يتم تجزئتها أبداً. حقل frag دائماً 0/1. راجع قسم Session Confirmed Fragmentation أعلاه لمزيد من المعلومات.

+----+----+----+----+----+----+----+----+
  | 2  |  size   |flag|frag|              |
  +----+----+----+----+----+              +
  |                                       |
  +       Router Info fragment            +
  | (Alice RI in Session Confirmed)       |
  + (Alice, Bob, or third-party           +
  |  RI in data phase)                    |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 2
  size :: 2 bytes, big endian, 2 + fragment size
  flag :: 1 byte flags
         bit order: 76543210 (bit 7 is MSB)
         bit 0: 0 for local store, 1 for flood request
         bit 1: 0 for uncompressed, 1 for gzip compressed
         bits 7-2: Unused, set to 0 for future compatibility
  frag :: 1 byte fragment info:
         bit order: 76543210 (bit 7 is MSB)
         bits 7-4: fragment number, always 0
         bits 3-0: total fragments, always 1, big endian

  routerinfo :: Alice's or Bob's RouterInfo

ملاحظات:

• معلومات Router مضغوطة اختيارياً باستخدام gzip، كما هو مُشار إليه بواسطة بت العلامة 1. هذا يختلف عن NTCP2، حيث لا يتم ضغطها أبداً، وعن رسالة DatabaseStore، حيث يتم ضغطها دائماً. الضغط اختياري لأنه عادة ما يكون ذا فائدة قليلة لمعلومات Router الصغيرة، حيث يوجد محتوى قابل للضغط قليل، لكنه مفيد جداً لمعلومات Router الكبيرة التي تحتوي على عدة عناوين Router قابلة للضغط. يُنصح بالضغط إذا كان يسمح لمعلومات Router بأن تتسع في حزمة Session Confirmed واحدة دون تجزئة.

• الحد الأقصى لحجم الجزء الأول أو الوحيد في رسالة Session Confirmed: MTU - 113 لـ IPv4 أو MTU - 133 لـ IPv6. بافتراض MTU افتراضي 1500 بايت، وعدم وجود كتل أخرى في الرسالة، 1387 لـ IPv4 أو 1367 لـ IPv6. 97% من معلومات router الحالية أصغر من 1367 بدون ضغط gzip. 99.9% من معلومات router الحالية أصغر من 1367 عند ضغطها بـ gzip. بافتراض الحد الأدنى لـ MTU 1280 بايت، وعدم وجود كتل أخرى في الرسالة، 1167 لـ IPv4 أو 1147 لـ IPv6. 94% من معلومات router الحالية أصغر من 1147 بدون ضغط gzip. 97% من معلومات router الحالية أصغر من 1147 عند ضغطها بـ gzip.

• بايت التجزئة (frag byte) غير مستخدم الآن، كتلة معلومات الموجه (Router Info block) لا يتم تجزئتها أبداً. يجب تعيين بايت التجزئة إلى الجزء 0، إجمالي الأجزاء 1. راجع قسم تجزئة الجلسة المؤكدة (Session Confirmed Fragmentation) أعلاه لمزيد من المعلومات.

• يجب عدم طلب الـ Flooding إلا إذا كانت هناك RouterAddresses منشورة في الـ RouterInfo. يجب على الـ router المستقبل عدم إجراء flood للـ RouterInfo إلا إذا كانت تحتوي على RouterAddresses منشورة.

• هذا البروتوكول لا يوفر إقرارًا بأن RouterInfo تم تخزينها أو إغراقها. إذا كان الإقرار مرغوبًا، وكان المستقبل floodfill، يجب على المرسل بدلاً من ذلك إرسال I2NP DatabaseStoreMessage قياسية مع reply token.

I2NP Message

رسالة I2NP كاملة مع رأسية معدلة.

يستخدم هذا نفس الـ 9 بايت لرأسية I2NP كما في NTCP2 (النوع، معرف الرسالة، انتهاء الصلاحية المختصر).

+----+----+----+----+----+----+----+----+
  | 3  |  size   |type|    msg id         |
  +----+----+----+----+----+----+----+----+
  |   short exp       |     message       |
  +----+----+----+----+                   +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 3
  size :: 2 bytes, big endian, size of type + msg id + exp + message to follow
          I2NP message body size is (size - 9).
  type :: 1 byte, I2NP msg type, see I2NP spec
  msg id :: 4 bytes, big endian, I2NP message ID
  short exp :: 4 bytes, big endian, I2NP message expiration, Unix timestamp, unsigned seconds.
               Wraps around in 2106
  message :: I2NP message body

ملاحظات:

• هذا هو نفس تنسيق رأس I2NP المكون من 9 بايت المستخدم في NTCP2.

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

• الحد الأقصى للحجم بما في ذلك رأس I2NP بحجم 9 بايت هو MTU - 63 لـ IPv4 و MTU - 83 لـ IPv6.

ChaCha20/Poly1305

الجزء الأول (الجزء #0) من رسالة I2NP مع عنوان معدّل.

يستخدم هذا نفس الـ 9 بايتات لرأس I2NP كما في NTCP2 (النوع، معرف الرسالة، انتهاء الصلاحية القصير).

العدد الإجمالي للشظايا غير محدد.

+----+----+----+----+----+----+----+----+
  | 4  |  size   |type|    msg id         |
  +----+----+----+----+----+----+----+----+
  |   short exp       |                   |
  +----+----+----+----+                   +
  |          partial message              |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 4
  size :: 2 bytes, big endian, size of data to follow
          Fragment size is (size - 9).
  type :: 1 byte, I2NP msg type, see I2NP spec
  msg id :: 4 bytes, big endian, I2NP message ID
  short exp :: 4 bytes, big endian, I2NP message expiration, Unix timestamp, unsigned seconds.
               Wraps around in 2106
  message :: Partial I2NP message body, bytes 0 - (size - 10)

ملاحظات:

• هذا هو نفس تنسيق رأس I2NP المكون من 9 بايت المستخدم في NTCP2.

• هذا بالضبط نفس تنسيق كتلة رسالة I2NP، ولكن نوع الكتلة يشير إلى أن هذه هي الجزء الأول من الرسالة.

• يجب أن يكون طول الرسالة الجزئية أكبر من الصفر.

• كما هو الحال في SSU 1، يُوصى بإرسال الجزء الأخير أولاً، حتى يتمكن المستقبل من معرفة العدد الإجمالي للأجزاء ويمكنه تخصيص مخازن الاستقبال بكفاءة.

• الحد الأقصى للحجم بما في ذلك عنوان I2NP بحجم 9 بايت هو MTU - 63 لـ IPv4 و MTU - 83 لـ IPv6.

ملاحظات

جزء إضافي (رقم الجزء أكبر من الصفر) من رسالة I2NP.

+----+----+----+----+----+----+----+----+
  | 5  |  size   |frag|    msg id         |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |          partial message              |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 5
  size :: 2 bytes, big endian, size of data to follow
          Fragment size is (size - 5).
  frag :: Fragment info:
          Bit order: 76543210 (bit 7 is MSB)
          bits 7-1: fragment number 1 - 127 (0 not allowed)
          bit 0: isLast (1 = true)
  msg id :: 4 bytes, big endian, I2NP message ID
  message :: Partial I2NP message body

ملاحظات:

• يجب أن يكون طول الرسالة الجزئية أكبر من الصفر.

• كما هو الحال في SSU 1، يُوصى بإرسال الجزء الأخير أولاً، حتى يتمكن المستقبِل من معرفة العدد الإجمالي للأجزاء ويمكنه تخصيص buffers الاستقبال بكفاءة.

• كما هو الحال في SSU 1، الحد الأقصى لرقم الجزء هو 127، لكن الحد العملي هو 63 أو أقل. قد تحد التطبيقات من الحد الأقصى إلى ما هو عملي لحجم رسالة I2NP الأقصى حوالي 64 كيلوبايت، والذي يعادل حوالي 55 جزء مع حد أدنى للـ MTU يبلغ 1280. انظر قسم Max I2NP Message Size أدناه.

• الحد الأقصى لحجم الرسالة الجزئية (لا يشمل frag ومعرف الرسالة) هو MTU - 68 لـ IPv4 و MTU - 88 لـ IPv6.

معالجة أخطاء AEAD

قطع الاتصال. يجب أن تكون هذه آخر كتلة غير مبطنة في الحمولة.

+----+----+----+----+----+----+----+----+
  | 6  |  size   |    valid data packets  |
  +----+----+----+----+----+----+----+----+
      received   | rsn|     addl data     |
  +----+----+----+----+                   +
  ~               .   .   .               ~
  +----+----+----+----+----+----+----+----+

  blk :: 6
  size :: 2 bytes, big endian, value = 9 or more
  valid data packets received :: The number of valid packets received
                                (current receive nonce value)
                                0 if error occurs in handshake phase
                                8 bytes, big endian
  rsn :: reason, 1 byte:
         0: normal close or unspecified
         1: termination received
         2: idle timeout
         3: router shutdown
         4: data phase AEAD failure
         5: incompatible options
         6: incompatible signature type
         7: clock skew
         8: padding violation
         9: AEAD framing error
         10: payload format error
         11: Session Request error
         12: Session Created error
         13: Session Confirmed error
         14: Timeout
         15: RI signature verification fail
         16: s parameter missing, invalid, or mismatched in RouterInfo
         17: banned
         18: bad token
         19: connection limits
         20: incompatible version
         21: wrong net ID
         22: replaced by new session
  addl data :: optional, 0 or more bytes, for future expansion, debugging,
               or reason text.
               Format unspecified and may vary based on reason code.

ملاحظات:

• ليست كل الأسباب قد تُستخدم فعلياً، وهذا يعتمد على التنفيذ. معظم الإخفاقات ستؤدي عموماً إلى إسقاط الرسالة، وليس إلى الإنهاء. راجع الملاحظات في أقسام رسائل handshake أعلاه. الأسباب الإضافية المُدرجة هي للتوافق والتسجيل وتصحيح الأخطاء، أو في حالة تغيير السياسة.
• يُنصح بتضمين كتلة ACK مع كتلة الإنهاء.
• في مرحلة البيانات، لأي سبب آخر غير “تم استلام الإنهاء”، يجب على النظير الرد بكتلة إنهاء مع السبب “تم استلام الإنهاء”.

RelayRequest

يُرسل في رسالة Data داخل الجلسة، من Alice إلى Bob. راجع قسم عملية التتابع أدناه.

+----+----+----+----+----+----+----+----+
  |  7 |  size   |flag|       nonce       |
  +----+----+----+----+----+----+----+----+
  |     relay tag     |     timestamp     |
  +----+----+----+----+----+----+----+----+
  | ver| asz|AlicePort|  Alice IP address |
  +----+----+----+----+----+----+----+----+
  |              signature                |
  +            length varies              +
  |         64 bytes for Ed25519          |
  ~                                       ~
  |                 . . .                 |
  +----+----+----+----+----+----+----+----+

  blk :: 7
  size :: 2 bytes, big endian, size of data to follow
  flag :: 1 byte flags, Unused, set to 0 for future compatibility

  The data below here is covered
  by the signature, and Bob forwards it unmodified.

  nonce :: 4 bytes, randomly generated by Alice
  relay tag :: 4 bytes, the itag from Charlie's RI
  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106
  ver ::  1 byte SSU version to be used for the introduction:
         1: SSU 1
         2: SSU 2
  asz :: 1 byte endpoint (port + IP) size (6 or 18)
  AlicePort :: 2 byte Alice's port number, big endian
  Alice IP :: (asz - 2) byte representation of Alice's IP address,
              network byte order
  signature :: length varies, 64 bytes for Ed25519.
               Signature of prologue, Bob's hash,
               and signed data above, as signed by
               Alice.

ملاحظات:

• يتم دائماً تضمين عنوان IP (على عكس SSU 1) وقد يختلف عن IP المستخدم للجلسة.

التوقيع:

أليس توقع الطلب وتدرجه في هذا البلوك؛ بوب يعيد توجيهه في بلوك Relay Intro إلى تشارلي. خوارزمية التوقيع: وقع البيانات التالية بمفتاح التوقيع الخاص بـ router أليس:

• prologue: 16 بايت “RelayRequestData”، غير منتهية بـ null (غير مضمنة في الرسالة)
• bhash: hash router بوب بحجم 32 بايت (غير مضمن في الرسالة)
• chash: hash router تشارلي بحجم 32 بايت (غير مضمن في الرسالة)
• nonce: nonce بحجم 4 بايت
• relay tag: relay tag بحجم 4 بايت
• timestamp: طابع زمني بحجم 4 بايت (بالثواني)
• ver: إصدار SSU بحجم 1 بايت
• asz: حجم endpoint (المنفذ + IP) بحجم 1 بايت (6 أو 18)
• AlicePort: رقم منفذ أليس بحجم 2 بايت
• Alice IP: عنوان IP أليس بحجم (asz - 2) بايت

KDF للـ ChainKey الأولي

يُرسل في رسالة Data أثناء الجلسة، من Charlie إلى Bob أو من Bob إلى Alice، وأيضاً في رسالة Hole Punch من Charlie إلى Alice. انظر قسم عملية التتابع أدناه.

+----+----+----+----+----+----+----+----+
  |  8 |  size   |flag|code|    nonce
  +----+----+----+----+----+----+----+----+
       |     timestamp     | ver| csz|Char
  +----+----+----+----+----+----+----+----+
   Port|   Charlie IP addr |              |
  +----+----+----+----+----+              +
  |              signature                |
  +            length varies              +
  |         64 bytes for Ed25519          |
  ~                                       ~
  |                 . . .                 |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+

  blk :: 8
  size :: 2 bytes, 6
  flag :: 1 byte flags, Unused, set to 0 for future compatibility
  code :: 1 byte status code:
         0: accept
         1: rejected by Bob, reason unspecified
         2: rejected by Bob, Charlie is banned
         3: rejected by Bob, limit exceeded
         4: rejected by Bob, signature failure
         5: rejected by Bob, relay tag not found
         6: rejected by Bob, Alice RI not found
         7-63: other rejected by Bob codes TBD
         64: rejected by Charlie, reason unspecified
         65: rejected by Charlie, unsupported address
         66: rejected by Charlie, limit exceeded
         67: rejected by Charlie, signature failure
         68: rejected by Charlie, Alice is already connected
         69: rejected by Charlie, Alice is banned
         70: rejected by Charlie, Alice is unknown
         71-127: other rejected by Charlie codes TBD
         128: reject, source and reason unspecified
         129-255: other reject codes TBD

  The data below is covered by the signature if the code is 0 (accept).
  Bob forwards it unmodified.

  nonce :: 4 bytes, as received from Bob or Alice

  The data below is present only if the code is 0 (accept).

  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106
  ver ::  1 byte SSU version to be used for the introduction:
         1: SSU 1
         2: SSU 2
  csz :: 1 byte endpoint (port + IP) size (0 or 6 or 18)
         may be 0 for some rejection codes
  CharliePort :: 2 byte Charlie's port number, big endian
                 not present if csz is 0
  Charlie IP :: (csz - 2) byte representation of Charlie's IP address,
                network byte order
                not present if csz is 0
  signature :: length varies, 64 bytes for Ed25519.
               Signature of prologue, Bob's hash,
               and signed data above, as signed by
               Charlie.
               Not present if rejected by Bob.
  token :: Token generated by Charlie for Alice to use
           in the Session Request.
           Only present if code is 0 (accept)

ملاحظات:

يجب على Alice استخدام الرمز المميز فوراً في طلب الجلسة.

التوقيع:

إذا وافق Charlie (رمز الاستجابة 0) أو رفض (رمز الاستجابة 64 أو أعلى)، يقوم Charlie بتوقيع الاستجابة وتضمينها في هذه الكتلة؛ يقوم Bob بإعادة توجيهها في كتلة Relay Response إلى Alice. خوارزمية التوقيع: وقع البيانات التالية بمفتاح توقيع router الخاص بـ Charlie:

• prologue: 16 بايت “RelayAgreementOK”، غير منتهية بـ null (غير مُدرجة في الرسالة)
• bhash: hash الموجه الخاص بـ Bob بحجم 32 بايت (غير مُدرج في الرسالة)
• nonce: nonce بحجم 4 بايت
• timestamp: timestamp بحجم 4 بايت (بالثواني)
• ver: إصدار SSU بحجم 1 بايت
• csz: حجم النقطة الطرفية (منفذ + IP) بحجم 1 بايت (0 أو 6 أو 18)
• CharliePort: رقم منفذ Charlie بحجم 2 بايت (غير موجود إذا كان csz يساوي 0)
• Charlie IP: عنوان IP الخاص بـ Charlie بحجم (csz - 2) بايت (غير موجود إذا كان csz يساوي 0)

إذا رفض Bob (رمز الاستجابة 1-63)، يقوم Bob بتوقيع الاستجابة وتضمينها في هذا البلوك. خوارزمية التوقيع: وقع البيانات التالية بمفتاح التوقيع الخاص بـ router الخاص بـ Bob:

• prologue: 16 بايت “RelayAgreementOK”، غير منتهية بـ null (غير مضمنة في الرسالة)
• bhash: هاش router الخاص بـ Bob بحجم 32 بايت (غير مضمن في الرسالة)
• nonce: nonce بحجم 4 بايت
• timestamp: طابع زمني بحجم 4 بايت (بالثواني)
• ver: إصدار SSU بحجم 1 بايت
• csz: 1 بايت = 0

دالة اشتقاق المفاتيح لطلب الجلسة

يتم إرسالها في رسالة Data داخل الجلسة، من Bob إلى Charlie. انظر قسم عملية التتابع أدناه.

يجب أن يسبقه كتلة RouterInfo، أو كتلة رسالة I2NP DatabaseStore (أو جزء)، تحتوي على Router Info الخاص بـ Alice، إما في نفس الحمولة (إذا كان هناك مساحة)، أو في رسالة سابقة.

+----+----+----+----+----+----+----+----+
  |  9 |  size   |flag|                   |
  +----+----+----+----+                   +
  |                                       |
  +                                       +
  |         Alice Router Hash             |
  +             32 bytes                  +
  |                                       |
  +                   +----+----+----+----+
  |                   |      nonce        |
  +----+----+----+----+----+----+----+----+
  |     relay tag     |     timestamp     |
  +----+----+----+----+----+----+----+----+
  | ver| asz|AlicePort|  Alice IP address |
  +----+----+----+----+----+----+----+----+
  |              signature                |
  +            length varies              +
  |         64 bytes for Ed25519          |
  ~                                       ~
  |                 . . .                 |
  +----+----+----+----+----+----+----+----+

  blk :: 9
  size :: 2 bytes, big endian, size of data to follow
  flag :: 1 byte flags, Unused, set to 0 for future compatibility
  hash :: Alice's 32-byte router hash,

  The data below here is covered
  by the signature, as received from Alice in the Relay Request,
  and Bob forwards it unmodified.

  nonce :: 4 bytes, as received from Alice
  relay tag :: 4 bytes, the itag from Charlie's RI
  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106
  ver ::  1 byte SSU version to be used for the introduction:
         1: SSU 1
         2: SSU 2
  asz :: 1 byte endpoint (port + IP) size (6 or 18)
  AlicePort :: 2 byte Alice's port number, big endian
  Alice IP :: (asz - 2) byte representation of Alice's IP address,
              network byte order
  signature :: length varies, 64 bytes for Ed25519.
               Signature of prologue, Bob's hash,
               and signed data above, as signed by
               Alice.

ملاحظات:

• بالنسبة لـ IPv4، عنوان IP الخاص بـ Alice يكون دائماً 4 بايت، لأن Alice تحاول الاتصال بـ Charlie عبر IPv4. IPv6 مدعوم، وقد يكون عنوان IP الخاص بـ Alice 16 بايت.

• بالنسبة لـ IPv4، يجب إرسال هذه الرسالة عبر اتصال IPv4 مُنشأ مسبقاً، حيث أن هذه هي الطريقة الوحيدة التي يعرف بها Bob عنوان IPv4 الخاص بـ Charlie ليعيده إلى Alice في RelayResponse_. IPv6 مدعوم، ويمكن إرسال هذه الرسالة عبر اتصال IPv6 مُنشأ مسبقاً.

• أي عنوان SSU منشور مع introducers يجب أن يحتوي على “4” أو “6” في خيار “caps”.

التوقيع:

أليس توقع الطلب وبوب يعيد توجيهه في هذه الكتلة إلى تشارلي. خوارزمية التحقق: تحقق من البيانات التالية باستخدام مفتاح التوقيع الخاص بـ router أليس:

• prologue: 16 بايت “RelayRequestData”، غير منتهية بقيمة null (غير مضمنة في الرسالة)
• bhash: hash الـ router الخاص بـ Bob بحجم 32 بايت (غير مضمن في الرسالة)
• chash: hash الـ router الخاص بـ Charlie بحجم 32 بايت (غير مضمن في الرسالة)
• nonce: nonce بحجم 4 بايت
• relay tag: علامة relay بحجم 4 بايت
• timestamp: طابع زمني بحجم 4 بايت (بالثواني)
• ver: إصدار SSU بحجم 1 بايت
• asz: حجم نقطة النهاية (المنفذ + IP) بحجم 1 بايت (6 أو 18)
• AlicePort: رقم منفذ Alice بحجم 2 بايت
• Alice IP: عنوان IP الخاص بـ Alice بحجم (asz - 2) بايت

PeerTest

يتم إرساله إما في رسالة Data داخل الجلسة، أو رسالة Peer Test خارج الجلسة. انظر قسم عملية Peer Test أدناه.

بالنسبة للرسالة 2، يجب أن تكون مسبوقة بكتلة RouterInfo، أو كتلة رسالة I2NP DatabaseStore (أو جزء منها)، تحتوي على Router Info الخاص بـ Alice، إما في نفس الحمولة (إذا كان هناك مساحة)، أو في رسالة سابقة.

بالنسبة للرسالة 4، إذا تم قبول الـ relay (رمز السبب 0)، يجب أن تكون مسبوقة بكتلة RouterInfo، أو كتلة رسالة I2NP DatabaseStore (أو جزء منها)، تحتوي على Router Info الخاص بـ Charlie، إما في نفس الـ payload (إذا كان هناك مساحة)، أو في رسالة سابقة.

+----+----+----+----+----+----+----+----+
  | 10 |  size   | msg|code|flag|         |
  +----+----+----+----+----+----+         +
  | Alice router hash (message 2 only)    |
  +             or                        +
  | Charlie router hash (message 4 only)  |
  + or all zeros if rejected by Bob       +
  | Not present in messages 1,3,5,6,7     |
  +                             +----+----+
  |                             | ver|
  +----+----+----+----+----+----+----+----+
     nonce       |     timestamp     | asz|
  +----+----+----+----+----+----+----+----+
  |AlicePort|  Alice IP address |         |
  +----+----+----+----+----+----+         +
  |              signature                |
  +            length varies              +
  |         64 bytes for Ed25519          |
  ~                                       ~
  |                 . . .                 |
  +----+----+----+----+----+----+----+----+

  blk :: 10
  size :: 2 bytes, big endian, size of data to follow
  msg :: 1 byte message number 1-7
  code :: 1 byte status code:
         0: accept
         1: rejected by Bob, reason unspecified
         2: rejected by Bob, no Charlie available
         3: rejected by Bob, limit exceeded
         4: rejected by Bob, signature failure
         5: rejected by Bob, address unsupported
         6-63: other rejected by Bob codes TBD
         64: rejected by Charlie, reason unspecified
         65: rejected by Charlie, unsupported address
         66: rejected by Charlie, limit exceeded
         67: rejected by Charlie, signature failure
         68: rejected by Charlie, Alice is already connected
         69: rejected by Charlie, Alice is banned
         70: rejected by Charlie, Alice is unknown
         70-127: other rejected by Charlie codes TBD
         128: reject, source and reason unspecified
         129-255: other reject codes TBD
         reject codes only allowed in messages 3 and 4
  flag :: 1 byte flags, Unused, set to 0 for future compatibility
  hash :: Alice's or Charlie's 32-byte router hash,
          only present in messages 2 and 4.
          All zeros (fake hash) in message 4 if rejected by Bob.

  For messages 1-4, the data below here is covered
  by the signature, if present, and Bob forwards it unmodified.

  ver :: 1 byte SSU version:
         1: SSU 1 (not supported)
         2: SSU 2 (required)
  nonce :: 4 byte test nonce, big endian
  timestamp :: Unix timestamp, unsigned seconds.
               Wraps around in 2106
  asz :: 1 byte endpoint (port + IP) size (6 or 18)
  AlicePort :: 2 byte Alice's port number, big endian
  Alice IP :: (asz - 2) byte representation of Alice's IP address,
              network byte order
  signature :: length varies, 64 bytes for Ed25519.
               Signature of prologue, Bob's hash,
               and signed data above, as signed by
               Alice or Charlie.
               Only present for messages 1-4.
               Optional in message 5-7.

ملاحظات:

• على عكس SSU 1، يجب أن تتضمن الرسالة 1 عنوان IP ومنفذ Alice.

• يتم دعم اختبار عناويين IPv6، وقد تتم الاتصالات بين Alice-Bob وAlice-Charlie عبر IPv6، إذا أشار Bob وCharlie إلى الدعم بقدرة ‘B’ في عنوان IPv6 المنشور الخاص بهم. راجع Proposal 126 للتفاصيل.

تُرسل Alice الطلب إلى Bob باستخدام جلسة موجودة عبر النقل (IPv4 أو IPv6) التي تريد اختبارها. عندما يتلقى Bob طلباً من Alice عبر IPv4، يجب على Bob أن يختار Charlie يُعلن عن عنوان IPv4. عندما يتلقى Bob طلباً من Alice عبر IPv6، يجب على Bob أن يختار Charlie يُعلن عن عنوان IPv6. التواصل الفعلي بين Bob وCharlie قد يكون عبر IPv4 أو IPv6 (أي مستقل عن نوع عنوان Alice).

• الرسائل 1-4 يجب أن تكون محتواة في رسالة Data في جلسة موجودة.

• يجب على Bob إرسال RI الخاص بـ Alice إلى Charlie قبل إرسال الرسالة 2.

• يجب على Bob إرسال RI الخاص بـ Charlie إلى Alice قبل إرسال الرسالة 4، إذا تم القبول (رمز السبب 0).

• الرسائل 5-7 يجب أن تكون محتواة في رسالة Peer Test خارج الجلسة.

• الرسائل 5 و 7 قد تحتوي على نفس البيانات الموقعة المرسلة في الرسائل 3 و 4، أو قد يتم إعادة توليدها مع timestamp جديد. التوقيع اختياري.

• الرسالة 6 قد تحتوي على نفس البيانات الموقعة المرسلة في الرسالتين 1 و 2، أو قد يتم إعادة إنشاؤها بطابع زمني جديد. التوقيع اختياري.

التوقيعات:

أليس توقع الطلب وتضمنه في الرسالة 1؛ بوب يعيد توجيهه في الرسالة 2 إلى تشارلي. تشارلي يوقع الرد ويضمنه في الرسالة 3؛ بوب يعيد توجيهه في الرسالة 4 إلى أليس. خوارزمية التوقيع: وقع أو تحقق من البيانات التالية باستخدام مفتاح التوقيع الخاص بأليس أو تشارلي:

• prologue: 16 بايت “PeerTestValidate”، غير منتهية بقيمة null (غير مُضمنة في الرسالة)
• bhash: router hash الخاص بـ Bob بحجم 32 بايت (غير مُضمن في الرسالة)
• ahash: router hash الخاص بـ Alice بحجم 32 بايت (يُستخدم فقط في التوقيع للرسالتين 3 و 4؛ غير مُضمن في الرسالة 3 أو 4)
• ver: 1 بايت إصدار SSU
• nonce: 4 بايت test nonce
• timestamp: 4 بايت الطابع الزمني (بالثواني)
• asz: 1 بايت حجم endpoint (المنفذ + IP) (6 أو 18)
• AlicePort: 2 بايت رقم منفذ Alice
• Alice IP: (asz - 2) بايت عنوان Alice IP

الحمولة

مهام TODO فقط في حالة تدوير المفاتيح

+----+----+----+----+----+----+----+----+
  | 11 |  size   |      TBD               |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 11
  size :: 2 bytes, big endian, size of data to follow

ملاحظات

4 بايت ack through، متبوعة بعدد ack وصفر أو أكثر من نطاقات nack/ack.

هذا التصميم مُقتبس ومُبسط من QUIC. أهداف التصميم كما يلي:

• نريد ترميز “bitfield” بكفاءة، وهو تسلسل من البتات يمثل الحزم المؤكدة.
• الـ bitfield يحتوي في الغالب على 1’s. كل من الـ 1’s والـ 0’s تأتي عموماً في “كتل” متتالية.
• مقدار المساحة المتاحة في الحزمة للتأكيدات متغير.
• البت الأكثر أهمية هو الأعلى رقماً. البتات ذات الأرقام الأقل أقل أهمية. تحت مسافة معينة من أعلى بت، سيتم “نسيان” البتات الأقدم ولن يتم إرسالها مرة أخرى.

الترميز المحدد أدناه يحقق أهداف التصميم هذه، من خلال إرسال رقم أعلى بت مضبوط على 1، مع بتات إضافية متتالية أقل من ذلك والتي مضبوطة أيضاً على 1. بعد ذلك، إذا كان هناك مساحة، واحد أو أكثر من “النطاقات” التي تحدد عدد البتات المتتالية 0 والبتات المتتالية 1 الأقل من ذلك. انظر QUIC RFC 9000 القسم 13.2.3 للمزيد من المعلومات الأساسية.

+----+----+----+----+----+----+----+----+
  | 12 |  size   |    Ack Through    |acnt|
  +----+----+----+----+----+----+----+----+
  |  range  |  range  |     .   .   .     |
  +----+----+----+----+                   +
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 12
  size :: 2 bytes, big endian, size of data to follow,
          5 minimum
  ack through :: highest packet number acked
  acnt :: number of acks lower than ack through also acked,
          0-255
  range :: If present,
           1 byte nack count followed by 1 byte ack count,
           0-255 each

أمثلة:

نريد إرسال ACK للحزمة 10 فقط:

• Ack Through: 10
• acnt: 0
• لا توجد نطاقات مضمنة

نريد إرسال ACK للحزم 8-10 فقط:

• Ack Through: 10
• acnt: 2
• لا توجد نطاقات مضمنة

نريد إرسال ACK للرسائل 10 9 8 6 5 2 1 0، وإرسال NACK للرسائل 7 4 3. ترميز كتلة ACK هو:

• Ack Through: 10
• acnt: 2 (ack 9 8)
• range: 1 2 (nack 7, ack 6 5)
• range: 2 3 (nack 4 3, ack 2 1 0)

ملاحظات:

• قد لا تكون النطاقات موجودة. العدد الأقصى للنطاقات غير محدد، قد يكون بقدر ما يمكن أن يتسع له الحزمة.
• Range nack قد يكون صفراً إذا كان الـ acking لأكثر من 255 حزمة متتالية.
• Range ack قد يكون صفراً إذا كان الـ nacking لأكثر من 255 حزمة متتالية.
• Range nack وrange ack قد لا يكونان كلاهما صفراً.
• بعد النطاق الأخير، لا تكون الحزم مُـ acked ولا مُـ nacked. طول الـ ack block وكيفية التعامل مع الـ acks/nacks القديمة يعود لمُرسل الـ ack block. انظر أقسام الـ ack أدناه للنقاش.
• يجب أن يكون الـ ack through هو أعلى رقم حزمة مُستلمة، وأي حزم أعلى لم يتم استلامها. ومع ذلك، في حالات محدودة، قد يكون أقل، مثل الـ acking لحزمة واحدة “تملأ ثغرة”، أو تطبيق مبسط لا يحتفظ بحالة جميع الحزم المُستلمة. فوق أعلى حزمة مُستلمة، لا تكون الحزم مُـ acked ولا مُـ nacked، ولكن بعد عدة ack blocks، قد يكون من المناسب الدخول في وضع إعادة الإرسال السريع.
• هذا التنسيق هو نسخة مبسطة من ذلك الموجود في QUIC. مُصمم لترميز عدد كبير من الـ ACKs بكفاءة، مع دفعات من الـ NACKs.
• تُستخدم ACK blocks لإقرار حزم مرحلة البيانات. يجب تضمينها فقط لحزم مرحلة البيانات داخل الجلسة.

Address

2 بايت للمنفذ و 4 أو 16 بايت لعنوان IP. عنوان Alice، يُرسل إلى Alice من قِبل Bob، أو عنوان Bob، يُرسل إلى Bob من قِبل Alice.

+----+----+----+----+----+----+----+----+
  | 13 | 6 or 18 |   Port  | IP Address    
  +----+----+----+----+----+----+----+----+
       |
  +----+

  blk :: 13
  size :: 2 bytes, big endian, 6 or 18
  port :: 2 bytes, big endian
  ip :: 4 byte IPv4 or 16 byte IPv6 address,
        big endian (network byte order)

Relay Tag Request

قد ترسل Alice هذا في رسالة Session Request أو Session Confirmed أو Data. غير مدعوم في رسالة Session Created، حيث أن Bob لا يملك RI الخاص بـ Alice بعد، ولا يعرف ما إذا كانت Alice تدعم التتابع. أيضاً، إذا كان Bob يحصل على اتصال وارد، فربما لا يحتاج إلى introducers (باستثناء ربما للنوع الآخر ipv4/ipv6).

عند الإرسال في طلب الجلسة (Session Request)، قد يستجيب Bob برقم تمييز الترحيل (Relay Tag) في رسالة إنشاء الجلسة (Session Created)، أو قد يختار الانتظار حتى استقبال RouterInfo الخاص بـ Alice في تأكيد الجلسة (Session Confirmed) للتحقق من هوية Alice قبل الاستجابة في رسالة البيانات (Data message). إذا لم يرغب Bob في الترحيل لـ Alice، فإنه لا يرسل كتلة رقم تمييز الترحيل (Relay Tag block).

+----+----+----+
  | 15 |    0    |
  +----+----+----+

  blk :: 15
  size :: 2 bytes, big endian, value = 0

الحمولة

قد يرسل Bob هذا في رسالة Session Confirmed أو Data، كاستجابة لطلب Relay Tag Request من Alice.

عندما يتم إرسال طلب Relay Tag في Session Request، قد يستجيب Bob بـ Relay Tag في رسالة Session Created، أو قد يختار الانتظار حتى يستقبل RouterInfo الخاص بـ Alice في Session Confirmed للتحقق من هوية Alice قبل الاستجابة في رسالة Data. إذا كان Bob لا يرغب في القيام بالترحيل لـ Alice، فإنه لا يرسل كتلة Relay Tag.

+----+----+----+----+----+----+----+
  | 16 |    4    |    relay tag      |
  +----+----+----+----+----+----+----+

  blk :: 16
  size :: 2 bytes, big endian, value = 4
  relay tag :: 4 bytes, big endian, nonzero

ملاحظات

للاتصال اللاحق. يتم تضمينه عمومًا في رسائل Session Created و Session Confirmed. قد يتم إرساله مرة أخرى أيضًا في رسالة Data لجلسة طويلة المدى إذا انتهت صلاحية الرمز المميز السابق.

+----+----+----+----+----+----+----+----+
  | 17 |   12    |     expires       |
  +----+----+----+----+----+----+----+----+
                  token              |
  +----+----+----+----+----+----+----+

  blk :: 17
  size :: 2 bytes, big endian, value = 12
  expires :: Unix timestamp, unsigned seconds.
             Wraps around in 2106
  token :: 8 bytes, big endian

المشاكل

ping مع بيانات عشوائية ليتم إرجاعها في Path Response، يُستخدم كـ keep-alive أو للتحقق من صحة تغيير IP/Port.

+----+----+----+----+----+----+----+----+
  | 18 |  size   |    Arbitrary Data      |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 18
  size :: 2 bytes, big endian, size of data to follow
  data :: Arbitrary data to be returned in a Path Response
          length as selected by sender

ملاحظات:

يُنصح بحد أدنى لحجم البيانات يبلغ 8 بايت، يحتوي على بيانات عشوائية، ولكن ذلك ليس مطلوباً.

Path Response

رد Pong مع البيانات المستلمة في Path Challenge، كرد على Path Challenge، يُستخدم كـ keep-alive أو للتحقق من تغيير IP/Port.

+----+----+----+----+----+----+----+----+
  | 19 |  size   |                        |
  +----+----+----+                        +
  |    Data received in Path Challenge    |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 19
  size :: 2 bytes, big endian, size of data to follow
  data :: As received in a Path Challenge

First Packet Number

يتم تضمينها اختياريًا في المصافحة في كل اتجاه، لتحديد رقم الحزمة الأولى التي سيتم إرسالها. هذا يوفر أمانًا أكثر لتشفير الرأس، مشابه لـ TCP.

غير محدد بالكامل، غير مدعوم حالياً.

+----+----+----+----+----+----+----+
  | 20 |  size   |  First pkt number |
  +----+----+----+----+----+----+----+

  blk :: 20
  size :: 4
  pkt num :: The first packet number to be sent in the data phase

Congestion

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

هذا يحافظ على أي معلومات ازدحام خارج كتل I2NP والـ First Fragment والـ Followon Fragment والـ ACK عالية الاستخدام، حيث لا توجد مساحة مخصصة للأعلام. بينما توجد ثلاثة بايتات من الأعلام غير المستخدمة في رأس حزمة Data، فإن ذلك يوفر أيضاً مساحة محدودة للقابلية للتوسع، وحماية تشفير أضعف.

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

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

يجب أن يكون هذا البلوك على الأرجح آخر بلوك غير مُحشو في الحمولة.

+----+----+----+----+
  | 21 |  size   |flag|
  +----+----+----+----+

  blk :: 21
  size :: 1 (or more if extended)
  flag :: 1 byte flags
         bit order: 76543210 (bit 7 is MSB)
         bit 0: 1 to request immediate ack
         bit 1: 1 for explicit congestion notification (ECN)
         bits 7-2: Unused, set to 0 for future compatibility

الحمولة

هذا للحشو داخل حمولات AEAD. الحشو لجميع الرسائل موجود داخل حمولات AEAD.

يجب أن يلتزم الحشو تقريباً بالمعاملات المتفاوض عليها. أرسل Bob معاملات tx/rx الدنيا/العليا المطلوبة في Session Created. أرسلت Alice معاملات tx/rx الدنيا/العليا المطلوبة في Session Confirmed. قد يتم إرسال خيارات محدثة أثناء مرحلة البيانات. راجع معلومات كتلة الخيارات أعلاه.

إذا كان موجوداً، يجب أن يكون هذا آخر block في الـ payload.

+----+----+----+----+----+----+----+----+
  |254 |  size   |      padding           |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 254
  size :: 2 bytes, big endian, size of padding to follow
  padding :: random data

ملاحظات:

• الحجم = 0 مسموح.

• استراتيجيات الحشو لم تُحدد بعد.

• الحد الأدنى للحشو لم يُحدد بعد.

• الحمولات التي تحتوي على حشو فقط مسموحة.

• إعدادات الحشو الافتراضية لم تُحدد بعد.

• راجع كتلة الخيارات لتفاوض معاملات الحشو

• راجع كتلة الخيارات لمعاملات الحد الأدنى/الأقصى للحشو

• لا تتجاوز الـ MTU. إذا كان المزيد من الحشو ضرورياً، أرسل رسائل متعددة.

• استجابة الـ router عند انتهاك الحشو المتفاوض عليه تعتمد على التنفيذ.

• طول الحشو إما أن يتم تحديده على أساس كل رسالة على حدة وتقديرات توزيع الطول، أو يجب إضافة تأخيرات عشوائية. هذه التدابير المضادة يجب أن تُدرج لمقاومة DPI، حيث أن أحجام الرسائل ستكشف خلاف ذلك أن حركة مرور I2P يتم نقلها بواسطة بروتوكول النقل. مخطط الحشو الدقيق هو مجال للعمل المستقبلي، الملحق A من NTCP2 يوفر مزيداً من المعلومات حول هذا الموضوع.

Replay Prevention

SSU2 مصمم لتقليل تأثير الرسائل المعاد تشغيلها من قبل المهاجم.

رسائل Token Request و Retry و Session Request و Session Created و Hole Punch و out-of-session Peer Test يجب أن تحتوي على كتل DateTime.

يقوم كل من Alice و Bob بالتحقق من أن وقت هذه الرسائل يقع ضمن انحراف زمني صالح (الموصى به +/- دقيقتان). من أجل “مقاومة التحسس”، يجب على Bob عدم الرد على رسائل Token Request أو Session Request إذا كان الانحراف الزمني غير صالح، حيث قد تكون هذه الرسائل عبارة عن هجوم إعادة تشغيل أو تحسس.

قد يختار Bob رفض رسائل Token Request و Retry المكررة، حتى لو كان الانحراف صحيحًا، عبر مرشح Bloom أو آلية أخرى. ومع ذلك، فإن حجم وتكلفة المعالج للرد على هذه الرسائل منخفضة. في أسوأ الأحوال، قد تؤدي رسالة Token Request معادة التشغيل إلى إلغاء صحة رمز مميز تم إرساله مسبقًا.

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

رسائل Session Created وSession Confirmed المكررة لن تتم مصادقتها لأن حالة مصافحة Noise لن تكون في الحالة الصحيحة لفك تشفيرها. في أسوأ الحالات، قد يعيد النظير إرسال Session Confirmed استجابة لما يبدو أنه Session Created مكرر.

رسائل Hole Punch وPeer Test المُعاد تشغيلها يجب أن يكون لها تأثير قليل أو معدوم.

يجب على أجهزة router استخدام رقم حزمة رسالة البيانات لاكتشاف وإسقاط رسائل مرحلة البيانات المكررة. يجب استخدام كل رقم حزمة مرة واحدة فقط. يجب تجاهل الرسائل المُعاد تشغيلها.

Handshake Retransmission

Session Request

إذا لم تتلق Alice أي Session Created أو Retry:

حافظ على نفس معرفات المصدر والاتصال، والمفتاح المؤقت، ورقم الحزمة 0. أو، احتفظ فقط وأعد إرسال نفس الحزمة المشفرة. يجب عدم زيادة رقم الحزمة، لأن ذلك سيغير قيمة الهاش المتسلسل المستخدمة لتشفير رسالة Session Created.

فترات الإعادة الإرسال الموصى بها: 1.25، 2.5، و 5 ثوانٍ (1.25، 3.75، و 8.75 ثانية بعد الإرسال الأول). المهلة الزمنية الموصى بها: 15 ثانية إجمالي

Session Created

إذا لم يتلق Bob أي Session Confirmed:

احتفظ بنفس معرفات المصدر والاتصال، والمفتاح المؤقت، ورقم الحزمة 0. أو، احتفظ فقط بالحزمة المشفرة. يجب عدم زيادة رقم الحزمة، لأن ذلك سيغير قيمة الـ hash المتسلسلة المستخدمة لتشفير رسالة Session Confirmed.

فترات إعادة الإرسال الموصى بها: 1، 2، و 4 ثوانٍ (1، 3، و 7 ثوانٍ بعد الإرسال الأول). المهلة الزمنية الموصى بها: 12 ثانية إجمالي

Session Confirmed

في SSU 1، أليس لا تنتقل إلى مرحلة البيانات حتى يتم استقبال أول حزمة بيانات من بوب. هذا يجعل SSU 1 إعداد ذو رحلتين ذهاباً وإياباً.

بالنسبة لـ SSU 2، فترات إعادة الإرسال المُوصى بها لـ Session Confirmed: 1.25 و 2.5 و 5 ثوانٍ (1.25 و 3.75 و 8.75 ثانية بعد الإرسال الأول).

هناك عدة بدائل. جميعها 1 RTT:

1. تفترض Alice أن Session Confirmed تم استلامه، ترسل رسائل البيانات فوراً، ولا تعيد إرسال Session Confirmed أبداً. حزم البيانات المستلمة خارج الترتيب (قبل Session Confirmed) ستكون غير قابلة للفك، ولكن سيتم إعادة إرسالها. إذا فُقد Session Confirmed، فإن جميع رسائل البيانات المُرسلة سيتم إسقاطها.

2. كما في 1)، أرسل رسائل البيانات فوراً، ولكن أعد إرسال Session Confirmed أيضاً حتى يتم استلام رسالة بيانات.

3. يمكننا استخدام IK بدلاً من XK، حيث أنه يحتوي على رسالتين فقط في المصافحة، لكنه يستخدم DH إضافي (4 بدلاً من 3).

التنفيذ الموصى به هو الخيار 2). يجب على Alice الاحتفاظ بالمعلومات المطلوبة لإعادة إرسال رسالة Session Confirmed. يجب على Alice أيضاً إعادة إرسال جميع رسائل Data بعد إعادة إرسال رسالة Session Confirmed.

عند إعادة إرسال Session Confirmed، حافظ على نفس معرفات المصدر والاتصال، والمفتاح المؤقت، ورقم الحزمة 1. أو، احتفظ فقط بالحزمة المشفرة. يجب عدم زيادة رقم الحزمة، لأن ذلك سيغير قيمة hash المتسلسلة التي تعتبر مدخلاً لدالة split().

قد يحتفظ Bob (في طابور) برسائل البيانات المستلمة قبل رسالة Session Confirmed. لا تكون مفاتيح حماية الرأس ولا مفاتيح فك التشفير متاحة قبل استلام رسالة Session Confirmed، لذا لا يعرف Bob أنها رسائل بيانات، ولكن يمكن افتراض ذلك. بعد استلام رسالة Session Confirmed، يصبح Bob قادراً على فك تشفير ومعالجة رسائل البيانات المجمعة في الطابور. إذا كان هذا معقداً جداً، فقد يتجاهل Bob رسائل البيانات غير القابلة لفك التشفير، حيث أن Alice ستعيد إرسالها.

ملاحظة: إذا فُقدت حزم session confirmed، فإن Bob سيعيد إرسال session created. لن يكون رأس session created قابلاً لفك التشفير باستخدام intro key الخاص بـ Alice، حيث أنه مُعيَّن بـ intro key الخاص بـ Bob (إلا إذا تم تنفيذ فك التشفير الاحتياطي باستخدام intro key الخاص بـ Bob). قد يعيد Bob إرسال حزم session confirmed فوراً إذا لم تكن مؤكدة من قبل، وتم استقبال حزمة غير قابلة لفك التشفير.

Token Request

إذا لم تتلق Alice أي Retry:

حافظ على نفس معرفات المصدر والاتصال. قد ينشئ التنفيذ رقم حزمة عشوائي جديد ويشفر حزمة جديدة؛ أو قد يعيد استخدام نفس رقم الحزمة أو مجرد الاحتفاظ بإعادة إرسال نفس الحزمة المشفرة. يجب عدم زيادة رقم الحزمة، لأن ذلك سيغير قيمة الـ hash المتسلسل المستخدمة لتشفير رسالة Session Created.

الفترات الزمنية الموصى بها لإعادة الإرسال: 3 و 6 ثوانِ (3 و 9 ثوانِ بعد الإرسال الأول). المهلة الزمنية الموصى بها: 15 ثانية إجمالاً

Retry

إذا لم يستقبل Bob أي Session Request:

رسالة إعادة المحاولة لا يتم إعادة إرسالها عند انتهاء المهلة الزمنية، وذلك لتقليل تأثيرات عناوين المصدر المُزيفة.

ومع ذلك، قد يتم إعادة إرسال رسالة Retry استجابةً لتلقي رسالة Session Request متكررة تحتوي على token الأصلي (غير صالح)، أو استجابةً لرسالة Token Request متكررة. في كلتا الحالتين، هذا يشير إلى أن رسالة Retry قد فُقدت.

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

إذا تم إعادة إرسال رسالة Retry: احتفظ بنفس معرفات المصدر والاتصال والرمز المميز. قد ينشئ التنفيذ رقم حزمة عشوائي جديد ويشفر حزمة جديدة؛ أو قد يعيد استخدام نفس رقم الحزمة أو يحتفظ فقط بإعادة إرسال نفس الحزمة المشفرة.

Total Timeout

المهلة الزمنية الإجمالية الموصى بها للمصافحة هي 20 ثانية.

Duplicates and Error Handling

يجب اكتشاف المكررات من رسائل Noise handshake الثلاث Session Request و Session Created و Session Confirmed قبل MixHash() الخاص بالعنوان. بينما ستفشل معالجة Noise AEAD على الأرجح بعد ذلك، فإن hash الخاص بالـ handshake سيكون قد تم إتلافه بالفعل.

إذا تم إفساد أي من الرسائل الثلاث وفشل في AEAD، فلن يمكن استرداد المصافحة لاحقاً حتى مع إعادة الإرسال، لأن MixHash() تم استدعاؤها بالفعل على الرسالة المفسدة.

Tokens

الـ Token في رأس Session Request يُستخدم للتخفيف من هجمات DoS، لمنع انتحال عنوان المصدر، وكمقاومة لهجمات إعادة التشغيل.

إذا لم يقبل Bob الرمز المميز في رسالة Session Request، فإن Bob لا يقوم بفك تشفير الرسالة، حيث أنها تتطلب عملية DH مكلفة. يقوم Bob ببساطة بإرسال رسالة Retry مع رمز مميز جديد.

إذا تم استلام رسالة Session Request لاحقة بهذا الرمز المميز، يقوم Bob بفك تشفير تلك الرسالة والمتابعة مع عملية المصافحة.

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

قد يتم استخدام الرموز المميزة مرة واحدة فقط. يجب استخدام الرمز المميز المرسل من Bob إلى Alice في رسالة Retry فورًا، وينتهي صلاحيته خلال ثوانٍ قليلة. قد يتم استخدام الرمز المميز المرسل في كتلة New Token في جلسة مُنشأة في اتصال لاحق، وينتهي صلاحيته في الوقت المحدد في تلك الكتلة. يحدد المرسل انتهاء الصلاحية؛ القيم الموصى بها هي ساعة واحدة كحد أدنى، وعدة ساعات كحد أقصى.

إذا تغير عنوان IP أو المنفذ الخاص بـ router، فيجب عليه حذف جميع الرموز المميزة المحفوظة (الواردة والصادرة) للعنوان IP أو المنفذ القديم، حيث أنها لم تعد صالحة. قد يتم الاحتفاظ بالرموز المميزة عبر إعادة تشغيل router بشكل اختياري، حسب التنفيذ. قبول الرمز المميز غير المنتهي الصلاحية غير مضمون؛ إذا نسي Bob أو حذف رموزه المميزة المحفوظة، فسوف يرسل Retry إلى Alice. قد يختار router تحديد تخزين الرموز المميزة، وإزالة أقدم الرموز المميزة المخزنة حتى لو لم تنته صلاحيتها.

يمكن إرسال كتل Token الجديدة من Alice إلى Bob أو من Bob إلى Alice. عادة ما يتم إرسالها مرة واحدة، أثناء إنشاء الجلسة أو بعدها بوقت قصير. يمكن إعادة إرسال الرمز المميز قبل أو بعد انتهاء الصلاحية مع وقت انتهاء صلاحية جديد، أو يمكن إرسال رمز مميز جديد. يجب أن تفترض أجهزة router أن آخر رمز مميز تم استلامه فقط هو الصالح؛ لا يوجد متطلب لتخزين عدة رموز مميزة واردة أو صادرة لنفس IP/port.

الرمز المميز مرتبط بمزيج عنوان IP/المنفذ المصدر وعنوان IP/المنفذ الوجهة. الرمز المميز المُستلم عبر IPv4 لا يمكن استخدامه لـ IPv6 والعكس صحيح.

إذا انتقل أي من الأقران (peers) إلى IP أو منفذ جديد أثناء الجلسة (انظر قسم Connection Migration)، فإن أي رموز (tokens) تم تبادلها مسبقاً تصبح غير صالحة، ويجب تبادل رموز جديدة.

يمكن للتطبيقات، وليس مطلوباً منها، حفظ الرموز المميزة (tokens) على القرص وإعادة تحميلها عند إعادة التشغيل. إذا تم الاحتفاظ بها، يجب على التطبيق التأكد من أن عنوان IP والمنفذ لم يتغيرا منذ الإغلاق قبل إعادة تحميلها.

I2NP Message Fragmentation

الاختلافات عن SSU 1

ملاحظة: كما هو الحال في SSU 1، الجزء الأولي لا يحتوي على معلومات حول العدد الإجمالي للأجزاء أو الطول الإجمالي. الأجزاء التالية لا تحتوي على معلومات حول إزاحتها. هذا يوفر للمرسل مرونة التجزئة “أثناء التشغيل” بناءً على المساحة المتاحة في الحزمة. (Java I2P لا يقوم بذلك؛ فهو يقوم “بالتجزئة المسبقة” قبل إرسال الجزء الأول) ومع ذلك، فإن هذا يُحمّل المستقبل عبء تخزين الأجزاء المستلمة خارج الترتيب وتأخير إعادة التجميع حتى يتم استلام جميع الأجزاء.

كما هو الحال في SSU 1، يجب أن تحافظ أي إعادة إرسال للأجزاء على طول (والإزاحة الضمنية) للإرسال السابق للجزء.

SSU 2 يفصل الحالات الثلاث (الرسالة الكاملة، والجزء الأولي، والجزء التالي) إلى ثلاثة أنواع كتل مختلفة، لتحسين كفاءة المعالجة.

I2NP Message Duplication

هذا البروتوكول لا يمنع تماماً التسليم المكرر لرسائل I2NP. المكررات على مستوى IP أو هجمات الإعادة سيتم اكتشافها في طبقة SSU2، لأن كل رقم حزمة يمكن استخدامه مرة واحدة فقط.

عندما يتم إعادة إرسال رسائل I2NP أو أجزاؤها في حزم جديدة، فإن هذا غير قابل للكشف على مستوى طبقة SSU2. يجب على الـ router فرض انتهاء صلاحية I2NP (سواء كانت قديمة جداً أو بعيدة جداً في المستقبل) واستخدام مرشح Bloom أو آلية أخرى مبنية على معرف رسالة I2NP.

قد يستخدم الـ router، أو في تطبيق SSU2، آليات إضافية لاكتشاف التكرارات. على سبيل المثال، يمكن لـ SSU2 الاحتفاظ بذاكرة تخزين مؤقت لمعرفات الرسائل المستلمة مؤخراً. هذا يعتمد على التطبيق.

Congestion Control

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

حزم البيانات التي تحتوي على ACK فقط يجب ألا تُحسب ضمن البايتات أو الحزم قيد الإرسال وهي غير مُتحكم بها من ناحية الازدحام. وعلى عكس TCP، يمكن لـ SSU2 اكتشاف فقدان هذه الحزم وقد تُستخدم هذه المعلومات لتعديل حالة الازدحام. ومع ذلك، لا تحدد هذه الوثيقة آلية للقيام بذلك.

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

• اختبار النظير
• طلب الترحيل/التعريف/الاستجابة
• تحدي/استجابة المسار

يُوصى بأن يعتمد التحكم في الازدحام على عدد البايتات وليس عدد الحزم، باتباع التوجيهات الواردة في TCP RFCs و QUIC RFC 9002. قد يكون حد إضافي لعدد الحزم مفيداً أيضاً لمنع فيض المخزن المؤقت في النواة أو في الصناديق الوسطية، اعتماداً على التنفيذ، رغم أن هذا قد يضيف تعقيداً كبيراً. إذا كان الإخراج للحزم لكل جلسة و/أو المجموع محدوداً بعرض النطاق الترددي و/أو منظماً، فقد يقلل هذا من الحاجة لتحديد عدد الحزم.

Packet Numbers

في SSU 1، احتوت ACKs و NACKs على أرقام رسائل I2NP وأقنعة البت للشظايا. تتبعت المُرسِلات حالة ACK للرسائل الصادرة (وشظاياها) وأعادت إرسال الشظايا حسب الحاجة.

في SSU 2، تحتوي رسائل ACK و NACK على أرقام الحزم. يجب على المُرسِلات الاحتفاظ ببنية بيانات تحتوي على ربط بين أرقام الحزم ومحتوياتها. عندما يتم إرسال ACK أو NACK لحزمة معينة، يجب على المُرسِل تحديد رسائل I2NP والأجزاء التي كانت في تلك الحزمة، لاتخاذ قرار حول ما يجب إعادة إرساله.

Session Confirmed ACK

يرسل Bob رسالة ACK للحزمة 0، والتي تؤكد استلام رسالة Session Confirmed وتسمح لـ Alice بالانتقال إلى مرحلة البيانات، والتخلص من رسالة Session Confirmed الكبيرة المحفوظة لإعادة الإرسال المحتملة. هذا يحل محل DeliveryStatusMessage التي يرسلها Bob في SSU 1.

يجب على Bob إرسال ACK في أقرب وقت ممكن بعد استلام رسالة Session Confirmed. التأخير الطفيف (لا يزيد عن 50 مللي ثانية) مقبول، حيث أنه يجب وصول رسالة Data واحدة على الأقل بعد رسالة Session Confirmed مباشرة تقريباً، بحيث يمكن لـ ACK تأكيد استلام كل من رسالة Session Confirmed ورسالة Data. هذا سيمنع Bob من الاضطرار لإعادة إرسال رسالة Session Confirmed.

Generating ACKs

التعريف: الحزم المحفزة للإقرار: الحزم التي تحتوي على كتل محفزة للإقرار تستدعي ACK من المستقبل خلال أقصى تأخير إقرار وتُسمى الحزم المحفزة للإقرار.

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

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

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

حزم البيانات داخل الجلسة التي تحتوي على أي كتلة باستثناء ما يلي تتطلب إقرار الاستلام:

• كتلة ACK
• كتلة العنوان
• كتلة DateTime
• كتلة الحشو
• كتلة الإنهاء
• أي كتل في نفس الحزمة مع كتلة الإنهاء
• أخرى؟

الحزم التي تحتوي على كتلة Termination مع سبب غير “termination received” يتم الإقرار بها بحزمة تحتوي على كتلة Termination مع “termination received”.

الحزم خارج الجلسة، بما في ذلك رسائل المصافحة ورسائل اختبار النظير 5-7، لها آليات إقرار خاصة بها. انظر أدناه.

Handshake ACKs

هذه حالات خاصة:

• طلب الرمز المميز (Token Request) مؤكد ضمنياً بواسطة إعادة المحاولة (Retry)
• طلب الجلسة (Session Request) مؤكد ضمنياً بواسطة إنشاء الجلسة (Session Created) أو إعادة المحاولة (Retry)
• إعادة المحاولة (Retry) مؤكدة ضمنياً بواسطة طلب الجلسة (Session Request)
• إنشاء الجلسة (Session Created) مؤكد ضمنياً بواسطة تأكيد الجلسة (Session Confirmed)
• تأكيد الجلسة (Session Confirmed) يجب تأكيده فوراً

Sending ACK Blocks

تُستخدم كتل ACK لتأكيد استلام حزم مرحلة البيانات. يجب تضمينها فقط لحزم مرحلة البيانات داخل الجلسة.

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

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

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

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

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

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

من أجل المساعدة في اكتشاف الفقدان لدى المرسل، يجب على endpoint أن ينشئ ويرسل كتلة ACK دون تأخير عندما يستقبل حزمة ack-eliciting في أي من هذه الحالات:

• عندما تحتوي الحزمة المستلمة على رقم حزمة أقل من حزمة أخرى مثيرة للإقرار تم استلامها

• عندما تحتوي الحزمة على رقم حزمة أكبر من أعلى رقم حزمة محفزة للإقرار تم استلامها وهناك حزم مفقودة بين تلك الحزمة وهذه الحزمة.

• عندما يتم تعيين علامة ack-immediate في رأس الحزمة

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

ACK Frequency

يحدد المستقبل عدد مرات إرسال الإقرارات استجابةً للحزم المحفزة للإقرار. يتضمن هذا التحديد مقايضة.

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

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

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

قد يقوم المستقبل بمعالجة عدة حزم متاحة قبل تحديد ما إذا كان سيرسل كتلة ACK كاستجابة. بشكل عام، يجب ألا يؤخر المستقبل إرسال ACK لأكثر من RTT / 6، أو 150 مللي ثانية كحد أقصى.

راية ack-immediate في رأس حزمة البيانات هي طلب من المستقبِل لإرسال إقرار استلام بعد وقت قصير من الاستقبال، على الأرجح خلال بضعة مللي ثانية. بشكل عام، يجب على المستقبِل ألا يؤخر الـ ACK الفوري لأكثر من RTT / 16، أو 5 مللي ثانية كحد أقصى.

Immediate ACK Flag

المستقبِل لا يعرف حجم نافذة الإرسال الخاصة بالمرسِل، وبالتالي لا يعرف كم من الوقت يجب أن يؤخر قبل إرسال ACK. علم الـ ACK الفوري في رأس حزمة البيانات هو طريقة مهمة للحفاظ على أقصى معدل إنتاجية من خلال تقليل الـ RTT الفعال. علم الـ ACK الفوري هو البايت 13 في الرأس، البت 0، أي (header[13] & 0x01). عندما يتم تعيينه، يُطلب ACK فوري. راجع قسم الرأس القصير أعلاه للتفاصيل.

هناك عدة استراتيجيات محتملة يمكن للمرسل استخدامها لتحديد متى يتم تعيين علامة immediate-ack:

• يتم تعيينها مرة واحدة كل N حزمة، لقيمة N صغيرة
• يتم تعيينها في آخر حزمة في دفعة من الحزم
• يتم تعيينها عندما تكون نافذة الإرسال ممتلئة تقريباً، على سبيل المثال أكثر من 2/3 ممتلئة
• يتم تعيينها على جميع الحزم التي تحتوي على أجزاء معاد إرسالها

يجب أن تكون علامات ACK الفورية ضرورية فقط على حزم البيانات التي تحتوي على رسائل I2NP أو أجزاء الرسائل.

ACK Block Size

عندما يتم إرسال كتلة ACK، يتم تضمين نطاق واحد أو أكثر من الحزم المؤكدة. إن تضمين إقرارات الاستلام للحزم الأقدم يقلل من فرصة إعادة الإرسال الزائف الناجم عن فقدان كتل ACK المرسلة سابقاً، مقابل تكلفة كتل ACK أكبر حجماً.

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

يحدد المستقبِل عدد نطاقات ACK التي يتذكرها ويرسلها في كتل ACK، وذلك لتحديد حجم كتل ACK وتجنب استنزاف الموارد. بعد تلقي إقرارات لكتلة ACK، يجب على المستقبِل التوقف عن تتبع نطاقات ACK المُقر بها. يمكن للمرسلين توقع إقرارات لمعظم الحزم، لكن هذا البروتوكول لا يضمن تلقي إقرار لكل حزمة يعالجها المستقبِل.

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

يجب على المستقبل الاحتفاظ بنطاق ACK ما لم يتمكن من ضمان أنه لن يقبل لاحقاً حزم بأرقام في ذلك النطاق. الحفاظ على رقم حزمة أدنى يزيد مع تجاهل النطاقات هو إحدى الطرق لتحقيق ذلك بأقل حالة ممكنة.

يمكن للمستقبلات تجاهل جميع نطاقات ACK، لكن يجب عليها الاحتفاظ بأكبر رقم حزمة تمت معالجتها بنجاح، حيث يُستخدم ذلك لاستعادة أرقام الحزم من الحزم اللاحقة.

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

Limiting Ranges by Tracking ACK Blocks

عندما يتم إرسال حزمة تحتوي على كتلة ACK، يمكن حفظ حقل Ack Through في تلك الكتلة. عندما يتم تأكيد حزمة تحتوي على كتلة ACK، يمكن للمستقبل التوقف عن تأكيد الحزم الأقل من أو المساوية لحقل Ack Through في كتلة ACK المُرسلة.

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

في الحالات التي لا تحدث فيها خسارة كتلة ACK، تسمح هذه الخوارزمية بحد أدنى من 1 RTT من إعادة الترتيب. في الحالات التي تحدث فيها خسارة كتلة ACK وإعادة الترتيب، لا يضمن هذا النهج أن كل إقرار يتم رؤيته من قبل المرسل قبل أن لا يعد مضمناً في كتلة ACK. قد يتم استقبال الحزم خارج الترتيب، وقد تضيع جميع كتل ACK اللاحقة التي تحتويها. في هذه الحالة، قد تتسبب خوارزمية استرداد الفقدان في إعادة إرسال زائفة، لكن المرسل سيستمر في إحراز تقدم للأمام.

Congestion

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

Retransmission

يجب على المرسل عدم الاحتفاظ بالمحتوى الكامل للرسالة، ليتم إعادة إرسالها بشكل مطابق (باستثناء رسائل handshake، انظر أعلاه). يجب على المرسل تجميع الرسائل التي تحتوي على معلومات محدثة (ACKs، NACKs، والبيانات غير المؤكدة) في كل مرة يرسل فيها رسالة. يجب على المرسل تجنب إعادة إرسال المعلومات من الرسائل بمجرد تأكيدها. يشمل هذا الرسائل التي يتم تأكيدها بعد إعلانها مفقودة، والتي يمكن أن تحدث في وجود إعادة ترتيب الشبكة.

Window

سيتم تحديده لاحقاً. يمكن العثور على إرشادات عامة في RFC 9002.

Connection Migration

قد يتغير عنوان IP أو المنفذ الخاص بالنظير أثناء مدة الجلسة. قد يحدث تغيير IP بسبب دوران العنوان المؤقت لـ IPv6، أو تغيير IP الدوري المدفوع من قبل مزود خدمة الإنترنت، أو عميل محمول ينتقل بين عناوين IP الخاصة بـ WiFi والشبكة الخلوية، أو تغييرات أخرى في الشبكة المحلية. قد يحدث تغيير المنفذ بسبب إعادة ربط NAT بعد انتهاء مهلة الربط السابق.

قد يبدو أن عنوان IP أو منفذ النظير يتغير بسبب هجمات مختلفة على المسار وخارج المسار، بما في ذلك تعديل أو حقن الحزم.

ترحيل الاتصال هو العملية التي يتم من خلالها التحقق من نقطة نهاية مصدر جديدة (IP+منفذ)، مع منع التغييرات غير المتحقق منها. هذه العملية هي نسخة مبسطة من تلك المحددة في QUIC RFC 9000. هذه العملية محددة فقط لمرحلة البيانات في الجلسة. الترحيل غير مسموح أثناء المصافحة. يجب التحقق من أن جميع حزم المصافحة مرسلة من نفس عنوان IP والمنفذ كما في الحزم المرسلة والمستقبلة سابقاً. بمعنى آخر، يجب أن يكون عنوان IP والمنفذ الخاص بالند ثابتين أثناء المصافحة.

Threat Model

(مقتبس من QUIC RFC 9000)

ملاحظات

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

تأكيد الجلسة والتجزئة

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

Off-Path Packet Forwarding

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

Privacy Implications

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

Initiating Path Validation

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

بالإضافة إلى ذلك، يجب على العقدة التحقق من أن عنوان IP والمنفذ الجديدين صالحان وفقاً لقواعد التحقق المحلية (غير محظورين، وليسا منافذ غير قانونية، إلخ). العقد غير مُطالبة بدعم الانتقال بين IPv4 و IPv6، وقد تتعامل مع عنوان IP جديد في عائلة العناوين الأخرى على أنه غير صالح، نظراً لأن هذا السلوك غير متوقع وقد يضيف تعقيداً كبيراً في التنفيذ. عند استقبال حزمة من عنوان IP/منفذ غير صالح، قد يقوم التطبيق ببساطة بإسقاطها، أو قد يبدأ عملية التحقق من المسار مع عنوان IP/المنفذ القديم.

عند دخول مرحلة التحقق من صحة المسار، اتبع الخطوات التالية:

• بدء مؤقت انتهاء صلاحية التحقق من المسار لعدة ثوان، أو عدة مرات من RTO الحالي (سيتم تحديده)
• تقليل نافذة الازدحام إلى الحد الأدنى
• تقليل PMTU إلى الحد الأدنى (1280)
• إرسال حزمة بيانات تحتوي على كتلة Path Challenge، وكتلة Address (تحتوي على IP/المنفذ الجديد)، وعادة، كتلة ACK، إلى IP والمنفذ الجديدين. تستخدم هذه الحزمة نفس معرف الاتصال ومفاتيح التشفير الخاصة بالجلسة الحالية. يجب أن تحتوي بيانات كتلة Path Challenge على إنتروبيا كافية (8 بايت على الأقل) بحيث لا يمكن انتحالها.
• اختيارياً، إرسال Path Challenge أيضاً إلى IP/المنفذ القديم، ببيانات كتلة مختلفة. انظر أدناه.
• بدء مؤقت انتهاء صلاحية Path Response بناءً على RTO الحالي (عادة RTT + مضاعف RTTdev)

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

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

إذا تم استلام Path Response، يحتوي على البيانات المطابقة المرسلة في Path Challenge، فإن Path Validation قد نجح. عنوان IP المصدر/المنفذ الخاص برسالة Path Response غير مطلوب أن يكون نفس العنوان الذي تم إرسال Path Challenge إليه.

إذا لم يتم استقبال Path Response قبل انتهاء صلاحية مؤقت Path Response، أرسل Path Challenge آخر وضاعف مؤقت Path Response.

إذا لم يتم استقبال Path Response قبل انتهاء صلاحية مؤقت Path Validation، فإن Path Validation قد فشل.

Message Contents

يجب أن تحتوي رسائل البيانات على الكتل التالية. الترتيب غير محدد باستثناء أن Padding يجب أن يكون الأخير:

• كتلة التحقق من المسار أو كتلة استجابة المسار. يحتوي التحقق من المسار على بيانات معتمة، يُوصى بحد أدنى 8 بايت. تحتوي استجابة المسار على البيانات من التحقق من المسار.
• كتلة العنوان التي تحتوي على عنوان IP الظاهر للمستقبل
• كتلة التاريخ والوقت
• كتلة ACK
• كتلة الحشو

لا يُنصح بتضمين أي كتل أخرى (على سبيل المثال، I2NP) في الرسالة.

يُسمح بتضمين كتلة Path Validation في الرسالة التي تحتوي على Path Response، لبدء التحقق في الاتجاه الآخر.

كتل Path Challenge و Path Response تستدعي ACK. سيتم إرسال ACK لـ Path Challenge عبر رسالة Data تحتوي على كتل Path Response و ACK. يجب إرسال ACK لـ Path Response عبر رسالة Data تحتوي على كتلة ACK.

Routing during Path Validation

مواصفات QUIC غير واضحة حول مكان إرسال حزم البيانات أثناء التحقق من المسار - إلى عنوان IP/المنفذ القديم أم الجديد؟ هناك توازن يجب تحقيقه بين الاستجابة السريعة لتغييرات عنوان IP/المنفذ، وعدم إرسال حركة البيانات إلى عناوين مزيفة. كما يجب عدم السماح للحزم المزيفة بالتأثير بشكل كبير على جلسة موجودة. من المرجح أن تكون التغييرات في المنفذ فقط ناتجة عن إعادة ربط NAT بعد فترة خمول؛ يمكن أن تحدث تغييرات عنوان IP أثناء مراحل حركة البيانات العالية في اتجاه واحد أو كلا الاتجاهين.

الاستراتيجيات خاضعة للبحث والتحسين. تشمل الإمكانيات:

• عدم إرسال حزم البيانات إلى العنوان/المنفذ الجديد حتى يتم التحقق منه
• الاستمرار في إرسال حزم البيانات إلى العنوان/المنفذ القديم حتى يتم التحقق من العنوان/المنفذ الجديد
• إعادة التحقق من العنوان/المنفذ القديم في نفس الوقت
• عدم إرسال أي بيانات حتى يتم التحقق من العنوان/المنفذ القديم أو الجديد
• استراتيجيات مختلفة لتغيير المنفذ فقط عن تغيير العنوان
• استراتيجيات مختلفة لتغيير IPv6 في نفس /32، والذي يحدث غالباً بسبب دوران العناوين المؤقتة

Responding to Path Challenge

عند استقبال Path Challenge، يجب على النظير الرد بحزمة بيانات تحتوي على Path Response، مع البيانات من Path Challenge. TODO ربما؟؟؟: يجب إرسال Path Response إلى عنوان IP/المنفذ الذي تم استقبال Path Challenge منه. هذا ليس بالضرورة عنوان IP/المنفذ الذي تم تأسيسه مسبقاً للنظير. هذا يضمن أن التحقق من المسار بواسطة النظير ينجح فقط إذا كان المسار يعمل في كلا الاتجاهين. انظر قسم التحقق بعد التغيير المحلي أدناه.

ما لم يكن IP/port مختلفًا عن IP/port المعروف مسبقًا للنظير، تعامل مع Path Challenge كـ ping بسيط، واستجب دون قيد أو شرط بـ Path Response. لا يحتفظ المستقبل بأي حالة أو يغيرها بناءً على Path Challenge مستلم. إذا كان IP/port مختلفًا، يجب على النظير التحقق من أن IP والمنفذ الجديدين صالحان وفقًا لقواعد التحقق المحلية (غير محجوبين، ليسا منافذ غير قانونية، إلخ). النظراء غير مطالبين بدعم الاستجابات عبر عائلات العناوين المختلفة بين IPv4 و IPv6، وقد يعتبرون IP جديد في عائلة العناوين الأخرى غير صالح، حيث أن هذا ليس سلوكًا متوقعًا.

ما لم تكن مقيدة بواسطة التحكم في الازدحام، يجب إرسال Path Response على الفور. يجب على التطبيقات اتخاذ تدابير لتقييد معدل Path Responses أو النطاق الترددي المستخدم إذا لزم الأمر.

كتلة Path Challenge عادة ما تكون مصحوبة بكتلة Address في نفس الرسالة. إذا كانت كتلة العنوان تحتوي على IP/port جديد، فقد يقوم النظير بالتحقق من صحة ذلك IP/port وبدء اختبار النظير لذلك IP/port الجديد، مع نظير الجلسة أو أي نظير آخر. إذا كان النظير يعتقد أنه محمي بجدار ناري، وتغير المنفذ فقط، فإن هذا التغيير يحدث على الأرجح بسبب إعادة ربط NAT، وربما لا يكون اختبار النظير الإضافي مطلوباً.

Successful Path Validation

عند التحقق بنجاح من صحة المسار، يتم ترحيل الاتصال بالكامل إلى IP/port الجديد. عند النجاح:

• الخروج من مرحلة التحقق من المسار
• يتم إرسال جميع الحزم إلى عنوان IP والمنفذ الجديدين.
• يتم إزالة القيود على نافذة الازدحام وPMTU، ويُسمح لها بالزيادة. لا تقم ببساطة باستعادتها إلى القيم القديمة، حيث قد يكون للمسار الجديد خصائص مختلفة.
• إذا تغير عنوان IP، قم بتعيين RTT وRTO المحسوبين إلى القيم الأولية. نظراً لأن التغييرات في المنفذ فقط عادة ما تكون نتيجة لإعادة ربط NAT أو نشاط middlebox آخر، قد يحتفظ النظير بدلاً من ذلك بحالة التحكم في الازدحام وتقدير زمن الرحلة ذهاباً وإياباً في تلك الحالات بدلاً من العودة إلى القيم الأولية.
• حذف (إبطال) أي رموز مميزة تم إرسالها أو استقبالها للعنوان IP/المنفذ القديم (اختياري)
• إرسال كتلة رمز مميز جديدة للعنوان IP/المنفذ الجديد (اختياري)

Cancelling Path Validation

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

عند إلغاء التحقق من المسار:

• الخروج من مرحلة التحقق من المسار
• يتم إرسال جميع الحزم إلى عنوان IP والمنفذ القديم.
• يتم إزالة القيود على نافذة الازدحام و PMTU، ويُسمح لها بالزيادة، أو، اختيارياً، استعادة القيم السابقة
• إعادة إرسال أي حزم بيانات تم إرسالها سابقاً إلى عنوان IP/المنفذ الجديد إلى عنوان IP/المنفذ القديم.

Failed Path Validation

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

عند فشل التحقق من المسار:

• اخرج من مرحلة التحقق من المسار
• يتم إرسال جميع الحزم إلى عنوان IP والمنفذ القديم.
• يتم إزالة القيود على نافذة الازدحام و PMTU، ويُسمح لها بالزيادة.
• اختياريًا، ابدأ التحقق من المسار على عنوان IP والمنفذ القديم. إذا فشل، أنهِ الجلسة.
• خلاف ذلك، اتبع قواعد انتهاء وإنهاء الجلسة القياسية.
• أعد إرسال أي حزم بيانات تم إرسالها سابقًا إلى عنوان IP/المنفذ الجديد إلى عنوان IP/المنفذ القديم.

Validation After Local Change

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

عند استلام تحدي مسار من نظير قام بتغيير عنوان IP أو المنفذ الخاص به، يجب على النظير الآخر أن يبدأ تحدي مسار في الاتجاه الآخر.

أمان التتابع

قد يتم استخدام كتل Path Validation و Path Response في أي وقت كحزم Ping/Pong. استقبال كتلة Path Validation لا يغير أي حالة لدى المستقبل، إلا إذا تم استقباله من IP/port مختلف.

Multiple Sessions

يجب ألا يقوم الأقران بإنشاء جلسات متعددة مع نفس القرين، سواء كان SSU 1 أو 2، أو بنفس عناوين IP أو عناوين مختلفة. ومع ذلك، قد يحدث هذا، إما بسبب أخطاء، أو فقدان رسالة إنهاء جلسة سابقة، أو في حالة تسابق حيث لم تصل رسالة الإنهاء بعد.

إذا كان لدى Bob جلسة موجودة مع Alice، عندما يتلقى Bob رسالة Session Confirmed من Alice، مما يكمل المصافحة وينشئ جلسة جديدة، يجب على Bob أن:

• ترحيل أي رسائل I2NP صادرة غير مرسلة أو غير مؤكدة من الجلسة القديمة إلى الجديدة
• إرسال إنهاء برمز السبب 22 على الجلسة القديمة
• إزالة الجلسة القديمة واستبدالها بالجديدة

Session Termination

أمان اختبار النظراء

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

أهداف تصميم الترحيل واختبار النظراء

الجلسات في مرحلة البيانات يتم إنهاؤها عن طريق إرسال رسالة بيانات تتضمن كتلة Termination. يجب أن تتضمن هذه الرسالة أيضاً كتلة ACK. قد تتضمن، إذا كانت الجلسة قد استمرت لفترة كافية بحيث أن رمزاً مُرسلاً مسبقاً قد انتهت صلاحيته أو على وشك انتهاء الصلاحية، كتلة New Token. هذه الرسالة لا تتطلب إقراراً. عند استقبال كتلة Termination بأي سبب عدا “Termination Received”، يستجيب النظير برسالة بيانات تحتوي على كتلة Termination مع السبب “Termination Received”.

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

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

بعد استلام كتلة إنهاء مع السبب “تم استلام الإنهاء”، قد تخرج الجلسة من مرحلة الإغلاق.

Cleanup

عند أي إنهاء طبيعي أو غير طبيعي، يجب على الـ routers أن تمحو أي بيانات مؤقتة في الذاكرة، بما في ذلك مفاتيح المصافحة المؤقتة ومفاتيح التشفير المتماثل والمعلومات ذات الصلة.

MTU

المتطلبات تختلف، بناءً على ما إذا كان العنوان المنشور مشتركًا مع SSU 1. الحد الأدنى الحالي لـ SSU 1 IPv4 هو 620، وهو صغير جداً بالتأكيد.

الحد الأدنى لـ SSU2 MTU هو 1280 لكل من IPv4 و IPv6، وهو نفس ما هو محدد في RFC 9000. انظر أدناه. من خلال زيادة الحد الأدنى لـ MTU، ستتناسب رسائل tunnel بحجم 1 كيلوبايت ورسائل tunnel build القصيرة في datagram واحد، مما يقلل بشكل كبير من مقدار التجزئة المعتاد. هذا يسمح أيضاً بزيادة الحد الأقصى لحجم رسائل I2NP. رسائل البث المباشر بحجم 1820 بايت يجب أن تتناسب في datagram اثنين.

يجب على الـ router ألا يُفعّل SSU2 أو ينشر عنوان SSU2 إلا إذا كان MTU لذلك العنوان 1280 على الأقل.

يجب على أجهزة router أن تنشر MTU غير افتراضي في كل عنوان router خاص بـ SSU أو SSU2.

الملخص

عنوان مشترك مع SSU 1، يجب اتباع قواعد SSU 1. IPv4: الافتراضي والحد الأقصى هو 1484. الحد الأدنى هو 1292. (IPv4 MTU + 4) يجب أن يكون مضاعفاً للعدد 16. IPv6: يجب أن يكون منشوراً، الحد الأدنى هو 1280 والحد الأقصى هو 1488. IPv6 MTU يجب أن يكون مضاعفاً للعدد 16.

ضمانات التسليم

IPv4: الافتراضي والحد الأقصى هو 1500. الحد الأدنى هو 1280. IPv6: الافتراضي والحد الأقصى هو 1500. الحد الأدنى هو 1280. لا توجد قواعد مضاعفات الـ 16، ولكن يُفضل أن يكون مضاعفاً للعدد 2 على الأقل.

إطار عمل بروتوكول Noise

بالنسبة لـ SSU 1، يقوم Java I2P الحالي بإجراء اكتشاف PMTU عن طريق البدء بحزم صغيرة وزيادة الحجم تدريجياً، أو الزيادة بناءً على حجم الحزمة المستقبلة. هذا الأمر بدائي ويقلل بشكل كبير من الكفاءة. استمرار هذه الميزة في SSU 2 لم يتم تحديده بعد.

تشير الدراسات الحديثة PMTU إلى أن الحد الأدنى لـ IPv4 البالغ 1200 أو أكثر سيعمل لأكثر من 99% من الاتصالات. يتطلب QUIC RFC 9000 حد أدنى لحجم حزمة IP يبلغ 1280 بايت.

اقتبس من RFC 9000:

الحد الأقصى لحجم الـ datagram يُعرَّف بأنه أكبر حجم لحمولة UDP يمكن إرسالها عبر مسار الشبكة باستخدام datagram UDP واحد. يجب عدم استخدام QUIC إذا كان مسار الشبكة لا يدعم حدًا أقصى لحجم الـ datagram يبلغ 1200 بايت على الأقل.

يفترض QUIC حدًا أدنى لحجم حزمة IP يبلغ 1280 بايت على الأقل. هذا هو الحد الأدنى لحجم IPv6 [IPv6] وهو مدعوم أيضًا من قبل معظم شبكات IPv4 الحديثة. بافتراض الحد الأدنى لحجم رأس IP البالغ 40 بايت لـ IPv6 و20 بايت لـ IPv4 وحجم رأس UDP البالغ 8 بايت، ينتج عن ذلك حد أقصى لحجم البيانات المرسلة يبلغ 1232 بايت لـ IPv6 و1252 بايت لـ IPv4. وبالتالي، من المتوقع أن تكون شبكات IPv4 الحديثة وجميع مسارات شبكة IPv6 قادرة على دعم QUIC.

ملاحظة: هذا المتطلب لدعم حمولة UDP بحجم 1200 بايت يحد من المساحة المتاحة لرؤوس امتداد IPv6 إلى 32 بايت أو خيارات IPv4 إلى 52 بايت إذا كان المسار يدعم فقط الحد الأدنى لـ MTU في IPv6 البالغ 1280 بايت. هذا يؤثر على الحزم الأولية والتحقق من صحة المسار.

نهاية الاقتباس

إضافات إلى الإطار

QUIC يتطلب أن تكون حزم البيانات الأولية (Initial datagrams) في كلا الاتجاهين بحجم 1200 بايت على الأقل، لمنع هجمات التضخيم وضمان أن PMTU يدعم ذلك في كلا الاتجاهين.

يمكننا أن نطلب هذا لـ Session Request و Session Created، بتكلفة كبيرة في النطاق الترددي. ربما يمكننا القيام بذلك فقط إذا لم يكن لدينا token، أو بعد استلام رسالة Retry. سيتم تحديد ذلك لاحقاً

يتطلب QUIC ألا يرسل Bob أكثر من ثلاثة أضعاف كمية البيانات المستلمة حتى يتم التحقق من صحة عنوان العميل. يلبي SSU2 هذا المتطلب بطبيعته، لأن رسالة Retry تقريباً بنفس حجم رسالة Token Request، وهي أصغر من رسالة Session Request. أيضاً، يتم إرسال رسالة Retry مرة واحدة فقط.

تقدير الأعباء الإضافية للمعالجة

يتطلب QUIC أن تكون الرسائل التي تحتوي على كتل PATH_CHALLENGE أو PATH_RESPONSE بحجم 1200 بايت على الأقل، لمنع هجمات التضخيم وضمان أن PMTU يدعم ذلك في كلا الاتجاهين.

يمكننا أن نطلب هذا أيضًا، ولكن بتكلفة كبيرة في عرض النطاق الترددي. ومع ذلك، هذه الحالات يجب أن تكون نادرة. TBD

Max I2NP Message Size

IPv4: لا يُفترض تجزئة IP. رأس IP + datagram هو 28 بايت. هذا يفترض عدم وجود خيارات IPv4. الحد الأقصى لحجم الرسالة هو MTU - 28. رأس مرحلة البيانات هو 16 بايت و MAC هو 16 بايت، بإجمالي 32 بايت. حجم الحمولة هو MTU - 60. الحد الأقصى لحمولة مرحلة البيانات هو 1440 لحد أقصى 1500 MTU. الحد الأقصى لحمولة مرحلة البيانات هو 1220 لحد أدنى 1280 MTU.

IPv6: لا يُسمح بتجزئة IP. رأس IP + datagram هو 48 بايت. هذا يفترض عدم وجود رؤوس امتداد IPv6. الحد الأقصى لحجم الرسالة هو MTU - 48. رأس مرحلة البيانات هو 16 بايت و MAC هو 16 بايت، بإجمالي 32 بايت. حجم الحمولة هو MTU - 80. الحد الأقصى لحمولة مرحلة البيانات هو 1420 لحد أقصى MTU يبلغ 1500. الحد الأقصى لحمولة مرحلة البيانات هو 1200 لحد أدنى MTU يبلغ 1280.

في SSU 1، كانت الإرشادات تنص على حد أقصى صارم يبلغ حوالي 32 كيلوبايت لرسالة I2NP بناءً على 64 جزء كحد أقصى و 620 كحد أدنى لـ MTU. بسبب الحمولة الإضافية لـ LeaseSets المجمعة ومفاتيح الجلسة، كان الحد العملي على مستوى التطبيق أقل بحوالي 6 كيلوبايت، أو حوالي 26 كيلوبايت. يسمح بروتوكول SSU 1 بـ 128 جزء ولكن التطبيقات الحالية تحدده بـ 64 جزء.

من خلال رفع الحد الأدنى لـ MTU إلى 1280، مع حمولة مرحلة البيانات تبلغ تقريباً 1200، فإن رسالة SSU 2 بحجم حوالي 76 كيلوبايت ممكنة في 64 جزء و152 كيلوبايت في 128 جزء. هذا يسمح بسهولة بحد أقصى 64 كيلوبايت.

بسبب التجزئة في الأنفاق، والتجزئة في SSU 2، تزداد احتمالية فقدان الرسائل بشكل تصاعدي مع حجم الرسالة. نواصل التوصية بحد عملي يبلغ حوالي 10 كيلوبايت على طبقة التطبيق لـ I2NP datagrams.

Peer Test Process

راجع أمان Peer Test أعلاه للحصول على تحليل لـ SSU1 Peer Test والأهداف الخاصة بـ SSU2 Peer Test.

Alice                     Bob                  Charlie
1. PeerTest ------------------->
                              Alice RI ------------------->
2.                          PeerTest ------------------->
3.                             <------------------ PeerTest
          <---------------- Charlie RI
4.      <------------------ PeerTest

5.      <----------------------------------------- PeerTest
6. PeerTest ----------------------------------------->
7.      <----------------------------------------- PeerTest

عندما يرفض Bob:

Alice                     Bob                  Charlie
1. PeerTest ------------------->
4.      <------------------ PeerTest (reject)

عندما يتم الرفض من قبل Charlie:

Alice                     Bob                  Charlie
1. PeerTest ------------------->
                              Alice RI ------------------->
2.                          PeerTest ------------------->
3.                             <------------------ PeerTest (reject)
                        (optional: Bob could try another Charlie here)
4.      <------------------ PeerTest (reject)

ملاحظة: قد يتم إرسال RI إما كرسائل I2NP Database Store في كتل I2NP، أو ككتل RI (إذا كانت صغيرة بما فيه الكفاية). قد تكون هذه موجودة في نفس الحزم مثل كتل peer test، إذا كانت صغيرة بما فيه الكفاية.

الرسائل 1-4 هي داخل الجلسة باستخدام كتل Peer Test في رسالة Data. الرسائل 5-7 هي خارج الجلسة باستخدام كتل Peer Test في رسالة Peer Test.

ملاحظة: كما هو الحال في SSU 1، قد تصل الرسائل 4 و 5 بأي ترتيب. قد لا يتم استقبال الرسالة 5 و/أو 7 على الإطلاق إذا كانت Alice محجوبة بجدار حماية. عندما تصل الرسالة 5 قبل الرسالة 4، لا تستطيع Alice إرسال الرسالة 6 فوراً، لأنها لا تملك بعد مفتاح تعريف Charlie لتشفير الرأس. عندما تصل الرسالة 4 قبل الرسالة 5، يجب على Alice عدم إرسال الرسالة 6 فوراً، لأنها يجب أن تنتظر لترى إذا كانت الرسالة 5 ستصل دون فتح جدار الحماية بالرسالة 6.

Versions

اختبار الأقران عبر الإصدارات المختلفة غير مدعوم. التركيبة الوحيدة المسموحة للإصدارات هي عندما تكون جميع الأقران من الإصدار 2.

إنشاء الجلسة

الرسائل 1-4 هي داخل الجلسة ومشمولة بعمليات الإقرار وإعادة الإرسال لمرحلة البيانات. كتل Peer Test تستدعي الإقرار.

الرسائل 5-7 قد يُعاد إرسالها، دون تغيير.

رأس الحزمة

كما في SSU 1، اختبار عناوين IPv6 مدعوم، وقد تكون اتصالات Alice-Bob و Alice-Charlie عبر IPv6، إذا أشار Bob و Charlie للدعم بقدرة ‘B’ في عنوان IPv6 المنشور الخاص بهما. راجع Proposal 126 للتفاصيل.

كما هو الحال في SSU 1 قبل الإصدار 0.9.50، ترسل Alice الطلب إلى Bob باستخدام جلسة موجودة عبر النقل (IPv4 أو IPv6) التي ترغب في اختبارها. عندما يتلقى Bob طلباً من Alice عبر IPv4، يجب على Bob أن يختار Charlie يعلن عن عنوان IPv4. عندما يتلقى Bob طلباً من Alice عبر IPv6، يجب على Bob أن يختار Charlie يعلن عن عنوان IPv6. قد يكون التواصل الفعلي بين Bob وCharlie عبر IPv4 أو IPv6 (أي مستقلاً عن نوع عنوان Alice). هذا ليس سلوك SSU 1 اعتباراً من الإصدار 0.9.50، حيث يُسمح بطلبات IPv4/v6 المختلطة.

Processing by Bob

على عكس SSU 1، تحدد أليس عنوان IP والمنفذ المطلوبين للاختبار في الرسالة 1. يجب على بوب التحقق من صحة عنوان IP والمنفذ هذين، ورفضهما برمز 5 إذا كانا غير صالحين. التحقق الموصى به لعنوان IP هو أنه، بالنسبة لـ IPv4، يطابق عنوان IP الخاص بأليس، وبالنسبة لـ IPv6، على الأقل أول 8 بايتات من عنوان IP تتطابق. يجب أن يرفض التحقق من صحة المنفذ المنافذ المميزة والمنافذ الخاصة بالبروتوكولات المعروفة.

Relay Process

راجع أمان التتابع أعلاه للحصول على تحليل لـ SSU1 Relay وأهداف SSU2 Relay.

Alice                         Bob                  Charlie
     lookup Bob RI

     SessionRequest -------------------->
          <------------  SessionCreated
     SessionConfirmed  ----------------->

1. RelayRequest ---------------------->
                                           Alice RI  ------------>
2.                                       RelayIntro ----------->
3.                                  <-------------- RelayResponse
4.      <-------------- RelayResponse

5.      <-------------------------------------------- HolePunch
6. SessionRequest -------------------------------------------->
7.      <-------------------------------------------- SessionCreated
8. SessionConfirmed ------------------------------------------>

عند الرفض من قبل Bob:

Alice                         Bob                  Charlie
     lookup Bob RI

     SessionRequest -------------------->
          <------------  SessionCreated
     SessionConfirmed  ----------------->

1. RelayRequest ---------------------->
4.      <-------------- RelayResponse

عند الرفض من قِبل Charlie:

Alice                         Bob                  Charlie
     lookup Bob RI

     SessionRequest -------------------->
          <------------  SessionCreated
     SessionConfirmed  ----------------->

1. RelayRequest ---------------------->
                                           Alice RI  ------------>
2.                                       RelayIntro ----------->
3.                                  <-------------- RelayResponse
4.      <-------------- RelayResponse

ملاحظة: قد يتم إرسال RI إما كرسائل I2NP Database Store في كتل I2NP، أو ككتل RI (إذا كانت صغيرة بما فيه الكفاية). قد تكون هذه موجودة في نفس الحزم مثل كتل الـ relay، إذا كانت صغيرة بما فيه الكفاية.

في SSU 1، تحتوي معلومات router الخاصة بـ Charlie على عنوان IP والمنفذ ومفتاح intro وعلامة relay وتاريخ انتهاء صلاحية كل introducer.

في SSU 2، تحتوي معلومات router الخاصة بـ Charlie على router hash و relay tag وتاريخ انتهاء صلاحية كل introducer.

يجب على Alice تقليل عدد الرحلات ذهاباً وإياباً المطلوبة عن طريق اختيار introducer (Bob) أولاً لديها اتصال معه بالفعل. ثانياً، إذا لم يوجد أي منهم، تختار introducer لديها معلومات router الخاصة به بالفعل.

يجب أيضاً دعم التتابع عبر الإصدارات إذا أمكن ذلك. سيسهل هذا الانتقال التدريجي من SSU 1 إلى SSU 2. مجموعات الإصدارات المسموحة هي (TODO):

Retransmissions

طلب Relay Request وتقديم Relay Intro واستجابة Relay Response جميعها داخل الجلسة ومغطاة بواسطة عمليات ACK لمرحلة البيانات وإعادة الإرسال. كتل Relay Request وRelay Intro وRelay Response تستدعي الإقرار.

قد يتم إعادة إرسال hole punch، كما هو الحال في SSU 1.

IPv4/v6

جميع ميزات تتابع SSU 1 مدعومة، بما في ذلك تلك الموثقة في الاقتراح 158 والمدعومة اعتبارًا من الإصدار 0.9.50. مقدمات IPv4 و IPv6 مدعومة. يمكن إرسال طلب التتابع عبر جلسة IPv4 لمقدمة IPv6، ويمكن إرسال طلب التتابع عبر جلسة IPv6 لمقدمة IPv4.

Processing by Alice

فيما يلي الاختلافات عن SSU 1 والتوصيات لتنفيذ SSU 2.

ملاحظات

في SSU 1، تكون عملية التقديم غير مكلفة نسبياً، وتقوم Alice عادة بإرسال Relay Requests إلى جميع المُقدِّمين. في SSU 2، تكون عملية التقديم أكثر تكلفة، حيث يجب أولاً إنشاء اتصال مع المُقدِّم. لتقليل زمن التأخير والعبء الإضافي للتقديم، فإن خطوات المعالجة الموصى بها هي كما يلي:

• تجاهل أي introducers منتهية الصلاحية بناءً على قيمة iexp في العنوان
• إذا كان هناك اتصال SSU2 مُنشأ بالفعل مع واحد أو أكثر من introducers، اختر واحداً وأرسل Relay Request إلى ذلك introducer فقط.
• وإلا، إذا كان Router Info معروفاً محلياً لواحد أو أكثر من introducers، اختر واحداً واتصل بذلك introducer فقط.
• وإلا، ابحث عن Router Infos لجميع introducers، اتصل بـ introducer الذي يتم استلام Router Info الخاص به أولاً.

ملاحظات

في كل من SSU 1 و SSU 2، قد يتم استقبال Relay Response و Hole Punch بأي ترتيب، أو قد لا يتم استقبالهما على الإطلاق.

في SSU 1، تستقبل Alice عادةً Relay Response (1 RTT) قبل Hole Punch (1 1/2 RTT). قد لا يكون هذا موثقاً جيداً في تلك المواصفات، لكن يجب على Alice استقبال Relay Response من Bob قبل المتابعة، لتلقي عنوان IP الخاص بـ Charlie. إذا تم استقبال Hole Punch أولاً، فلن تتعرف عليه Alice، لأنه لا يحتوي على بيانات وعنوان IP المصدر غير معروف. بعد استقبال Relay Response، يجب على Alice انتظار إما استقبال Hole Punch من Charlie، أو تأخير قصير (يُنصح بـ 500 مللي ثانية) قبل بدء المصافحة مع Charlie.

في SSU 2، ستتلقى Alice عادةً رسالة Hole Punch (1 1/2 RTT) قبل Relay Response (2 RTT). رسالة SSU 2 Hole Punch أسهل في المعالجة من SSU 1، لأنها رسالة كاملة مع معرفات اتصال محددة (مشتقة من relay nonce) ومحتويات تتضمن عنوان IP الخاص بـ Charlie. رسالة Relay Response (رسالة البيانات) ورسالة Hole Punch تحتويان على نفس كتلة Relay Response الموقعة. لذلك، قد تبدأ Alice المصافحة مع Charlie بعد تلقي رسالة Hole Punch من Charlie، أو تلقي Relay Response من Bob.

التحقق من توقيع Hole Punch يتضمن router hash الخاص بـ introducer (Bob). إذا تم إرسال Relay Requests إلى أكثر من introducer واحد، فهناك عدة خيارات للتحقق من صحة التوقيع:

• جرب كل hash تم إرسال طلب إليه
• استخدم nonces مختلفة لكل introducer، واستخدم ذلك لتحديد أي introducer كان هذا الـ Hole Punch ردًا عليه
• لا تعيد التحقق من التوقيع إذا كان المحتوى مطابقًا لذلك الموجود في الـ Relay Response، إذا تم استلامه مسبقًا
• لا تتحقق من التوقيع على الإطلاق

إذا كان تشارلي خلف NAT متماثل، فقد لا يكون المنفذ المُبلغ عنه في Relay Response و Hole Punch دقيقاً. لذلك، يجب على أليس فحص منفذ مصدر UDP لرسالة Hole Punch، واستخدام ذلك إذا كان مختلفاً عن المنفذ المُبلغ عنه.

Tag Requests by Bob

في SSU 1، كان بإمكان Alice فقط طلب علامة (tag)، في طلب الجلسة (Session Request). لم يكن بإمكان Bob أبداً طلب علامة، ولم يكن بإمكان Alice التوسط لـ Bob.

في SSU2، تطلب Alice عادةً علامة في طلب الجلسة (Session Request)، لكن يمكن لكل من Alice أو Bob أيضاً طلب علامة في مرحلة البيانات. عادةً لا يكون Bob محجوباً بجدار حماية بعد تلقي طلب وارد، لكن يمكن أن يكون كذلك بعد relay، أو قد تتغير حالة Bob، أو قد يطلب introducer لنوع العنوان الآخر (IPv4/v6). لذلك، في SSU2، من الممكن أن يكون كل من Alice و Bob في نفس الوقت relays للطرف الآخر.

Published Router Info

Address Properties

قد يتم نشر خصائص العناوين التالية، دون تغيير من SSU 1، بما في ذلك التغييرات في Proposal 158 المدعومة اعتباراً من API 0.9.50:

• caps: قدرات [B,C,4,6]

• host: IP (IPv4 أو IPv6). عناوين IPv6 المختصرة (مع “::”) مسموحة. قد تكون موجودة أو غير موجودة في حالة وجود جدار حماية. أسماء المضيفات غير مسموحة.

• iexp[0-2]: انتهاء صلاحية هذا المُقدِّم. أرقام ASCII، بالثواني منذ بداية العهد. موجود فقط إذا كان محمياً بجدار حماية، والمُقدِّمون مطلوبون. اختياري (حتى لو كانت خصائص أخرى لهذا المُقدِّم موجودة).

• ihost[0-2]: عنوان IP الخاص بالـ Introducer (IPv4 أو IPv6). العنوان المختصر IPv6 (مع “::”) مسموح. موجود فقط إذا كان محمياً بجدار حماية، والـ introducers مطلوبة. أسماء المضيفين غير مسموحة. عنوان SSU فقط.

• ikey[0-2]: مفتاح التقديم Base 64 الخاص بالـ Introducer. يكون موجوداً فقط إذا كان محمياً بجدار الحماية، وكانت الـ introducers مطلوبة. عنوان SSU فقط.

• iport[0-2]: منفذ المُقدم (Introducer’s port) 1024 - 65535. متوفر فقط إذا كان خلف جدار حماية، والمُقدمون مطلوبون. عنوان SSU فقط.

• itag[0-2]: علامة المُقدِّم 1 - (2**32 - 1) أرقام ASCII. موجودة فقط إذا كان محمياً بجدار حماية، ومطلوب وجود مُقدِّمين.

• key: مفتاح التعريف Base 64.

• mtu: اختياري. راجع قسم MTU أعلاه.

• port: 1024 - 65535 قد يكون موجودًا أو غير موجود في حالة وجود جدار حماية.

Published Addresses

عنوان الـ RouterAddress المنشور (جزء من RouterInfo) سيحتوي على معرف بروتوكول إما “SSU” أو “SSU2”.

يجب أن يحتوي RouterAddress على ثلاثة خيارات للإشارة إلى دعم SSU2:

• s=(Base64 key) مفتاح Noise الثابت العام الحالي (s) لهذا RouterAddress. مُرمز بـ Base 64 باستخدام أبجدية I2P القياسية لـ Base 64. 32 بايت في النظام الثنائي، 44 بايت كـ Base 64 مُرمز، مفتاح X25519 عام بترتيب البايت الأصغر أولاً.

• i=(Base64 key) مفتاح التقديم الحالي لتشفير الرؤوس لعنوان router هذا. مُرمز بـ Base 64 باستخدام أبجدية I2P Base 64 القياسية. 32 بايت في النظام الثنائي، 44 بايت مُرمز بـ Base 64، مفتاح ChaCha20 بترتيب البايت الكبير.

• v=2 النسخة الحالية (2). عند النشر كـ “SSU”، يُضمن الدعم الإضافي للنسخة 1. الدعم للنسخ المستقبلية سيكون بقيم مفصولة بفواصل، مثل v=2,3 يجب على التنفيذ التحقق من التوافق، بما في ذلك النسخ المتعددة إذا كانت الفاصلة موجودة. النسخ المفصولة بفواصل يجب أن تكون مرتبة ترتيباً رقمياً.

يجب على أليس التحقق من وجود وصحة الخيارات الثلاثة جميعها قبل الاتصال باستخدام بروتوكول SSU2.

عند النشر كـ “SSU” مع خيارات “s” و “i” و “v”، ومع خيارات “host” و “port”، يجب على الـ router قبول الاتصالات الواردة على ذلك المضيف والمنفذ لكل من بروتوكولي SSU و SSU2، واكتشاف إصدار البروتوكول تلقائياً.

عند النشر كـ “SSU2” مع خيارات “s” و “i” و “v”، ومع خيارات “host” و “port”، يقبل الموجه الاتصالات الواردة على ذلك المضيف والمنفذ لبروتوكول SSU2 فقط.

إذا كان router يدعم كلاً من اتصالات SSU1 و SSU2 ولكن لا ينفذ الكشف التلقائي للإصدار للاتصالات الواردة، فيجب عليه الإعلان عن عناوين “SSU” و “SSU2” كليهما، وتضمين خيارات SSU2 في عنوان “SSU2” فقط. يجب على الـ router تعيين قيمة تكلفة أقل (أولوية أعلى) في عنوان “SSU2” من عنوان “SSU”، بحيث يكون SSU2 مفضلاً.

إذا تم نشر عدة RouterAddresses من نوع SSU2 (سواء كـ “SSU” أو “SSU2”) في نفس RouterInfo (لعناوين IP أو منافذ إضافية)، فيجب أن تحتوي جميع العناوين التي تحدد نفس المنفذ على خيارات وقيم SSU2 متطابقة. على وجه الخصوص، يجب أن تحتوي جميعها على نفس المفتاح الثابت “s” ومفتاح التقديم “i”.

Introducers

عند النشر كـ SSU أو SSU2 مع المُقدِّمين، تكون الخيارات التالية متاحة:

• ih[0-2]=(Base64 hash) hash الخاص بـ router للمقدم. مُرمز بـ Base 64 باستخدام أبجدية I2P القياسية لـ Base 64. 32 بايت في النظام الثنائي، 44 بايت كما هو مُرمز بـ Base 64

• iexp[0-2]: انتهاء صلاحية هذا المُقدِّم (introducer). لم يتغير عن SSU 1.

• itag[0-2]: علامة المُقدِّم 1 - (2**32 - 1) غير مُتغيرة من SSU 1.

الخيارات التالية مخصصة لـ SSU فقط ولا تُستخدم مع SSU2. في SSU2، تحصل Alice على هذه المعلومات من RI الخاص بـ Charlie بدلاً من ذلك.

• ihost[0-2]
• ikey[0-2]
• itag[0-2]

يجب على الـ router عدم نشر المضيف أو المنفذ في العنوان عند نشر المقدمين. يجب على الـ router نشر caps 4 و/أو 6 في العنوان عند نشر المقدمين للإشارة إلى دعم IPv4 و/أو IPv6. هذا مماثل للممارسة الحالية لعناوين SSU 1 الحديثة.

ملاحظة: إذا تم النشر كـ SSU، وكان هناك خليط من مُعرِّفي SSU 1 و SSU2، يجب أن يكون مُعرِّفو SSU 1 في الفهارس المنخفضة ومُعرِّفو SSU2 في الفهارس العليا، للتوافق مع أجهزة router الأقدم.

Unpublished SSU2 Address

إذا لم تنشر Alice عنوان SSU2 الخاص بها (كـ “SSU” أو “SSU2”) للاتصالات الواردة، فيجب عليها نشر عنوان router “SSU2” يحتوي فقط على مفتاحها الثابت وإصدار SSU2، بحيث يمكن لـ Bob التحقق من صحة المفتاح بعد استلام RouterInfo الخاص بـ Alice في الجزء الثاني من Session Confirmed.

• s=(Base64 key) كما هو محدد أعلاه للعناوين المنشورة.

• i=(Base64 key) كما هو محدد أعلاه للعناوين المنشورة.

• v=2 كما هو محدد أعلاه للعناوين المنشورة.

عنوان router هذا لن يحتوي على خيارات “host” أو “port”، حيث أن هذه غير مطلوبة لاتصالات SSU2 الصادرة. التكلفة المنشورة لهذا العنوان لا تهم بشكل صارم، حيث أنها للاتصالات الواردة فقط؛ ومع ذلك، قد يكون من المفيد للموجهات الأخرى إذا تم تعيين التكلفة أعلى (أولوية أقل) من العناوين الأخرى. القيمة المقترحة هي 14.

يمكن لـ Alice أيضًا أن تضيف ببساطة الخيارات “i” و “s” و “v” إلى عنوان “SSU” منشور موجود.

سلامة الحزم

استخدام نفس المفاتيح الثابتة لـ NTCP2 و SSU2 مسموح، ولكن غير مستحسن.

بسبب التخزين المؤقت لـ RouterInfos، يجب على الـ routers عدم تدوير المفتاح العام الثابت أو الـ IV أثناء تشغيل الـ router، سواء كان في عنوان منشور أم لا. يجب على الـ routers تخزين هذا المفتاح والـ IV بشكل دائم لإعادة الاستخدام بعد إعادة التشغيل الفورية، حتى تستمر الاتصالات الواردة في العمل، ولا تُكشف أوقات إعادة التشغيل. يجب على الـ routers تخزين أو تحديد وقت آخر إيقاف تشغيل بشكل دائم، بحيث يمكن حساب فترة التوقف السابقة عند بدء التشغيل.

مع مراعاة المخاوف حول كشف أوقات إعادة التشغيل، قد تقوم أجهزة router بتدوير هذا المفتاح أو IV عند بدء التشغيل إذا كان الـ router متوقفاً مسبقاً لفترة من الوقت (عدة أيام على الأقل).

إذا كان الـ router يحتوي على أي RouterAddresses منشورة من نوع SSU2 (كـ SSU أو SSU2)، فإن الحد الأدنى لفترة التوقف قبل التدوير يجب أن يكون أطول بكثير، على سبيل المثال شهر واحد، إلا إذا تغير عنوان IP المحلي أو قام الـ router بعملية “rekeys”.

إذا كان لدى الموجه أي عناوين SSU RouterAddresses منشورة، ولكن ليس SSU2 (كـ SSU أو SSU2)، يجب أن يكون الحد الأدنى لوقت التوقف قبل التدوير أطول، على سبيل المثال يوم واحد، ما لم يتغير عنوان IP المحلي أو يقوم الموجه بـ “rekeys”. هذا ينطبق حتى لو كان عنوان SSU المنشور يحتوي على introducers.

إذا لم يكن لدى الـ router أي RouterAddresses منشورة (SSU أو SSU2 أو SSU)، فقد يكون الحد الأدنى لوقت التوقف قبل التناوب قصيرًا يصل إلى ساعتين، حتى لو تغير عنوان IP، إلا إذا قام الـ router بـ “rekeys”.

إذا قام الـ router بـ “rekeys” إلى Router Hash مختلف، فيجب عليه إنشاء noise key جديد وmtro key أيضاً.

يجب أن تكون التطبيقات على علم بأن تغيير المفتاح العام الثابت أو IV سيمنع الاتصالات الواردة عبر SSU2 من أجهزة التوجيه التي قامت بحفظ RouterInfo أقدم في التخزين المؤقت. نشر RouterInfo، واختيار أقران النفق (بما في ذلك كل من OBGW وأقرب قفزة IB)، واختيار النفق صفر القفزات، واختيار النقل، واستراتيجيات التطبيق الأخرى يجب أن تأخذ هذا في الاعتبار.

دوران مفاتيح Intro يخضع لنفس القواعد المطبقة على دوران المفاتيح.

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

Identity Hiding

إنكار المعرفة ليس هدفاً. انظر النظرة العامة أعلاه.

يتم تعيين خصائص لكل نمط تصف السرية المقدمة للمفتاح العام الثابت للمبادر، وللمفتاح العام الثابت للمجيب. الافتراضات الأساسية هي أن المفاتيح الخاصة المؤقتة آمنة، وأن الأطراف تُجهض المصافحة إذا تلقوا مفتاحاً عاماً ثابتاً من الطرف الآخر لا يثقون به.

يأخذ هذا القسم بعين الاعتبار فقط تسريب الهوية من خلال حقول المفاتيح العامة الثابتة في handshakes. بالطبع، قد تتعرض هويات المشاركين في Noise من خلال وسائل أخرى، بما في ذلك حقول payload، وتحليل حركة البيانات، أو metadata مثل عناوين IP.

أليس: (8) مُشفّرة مع السرية المستقبلية إلى طرف مُصادق عليه.

Bob: (3) لا يتم إرسالها، ولكن يمكن للمهاجم السلبي فحص المرشحين للمفتاح الخاص للمستجيب وتحديد ما إذا كان المرشح صحيحاً أم لا.

ينشر بوب مفتاحه العام الثابت في netDb. أليس قد لا تفعل ذلك، لكن يجب أن تتضمنه في RI المرسل إلى بوب.

Packet Guidelines

التشفير المُصادق عليه

رسائل المصافحة (Session Request/Created/Confirmed، Retry) الخطوات الأساسية، بالترتيب:

• إنشاء header بحجم 16 أو 32 بايت
• إنشاء payload
• تطبيق mixHash() على header (باستثناء Retry)
• تشفير payload باستخدام Noise (باستثناء Retry، استخدم ChaChaPoly مع header كـ AD)
• تشفير header، وللـ Session Request/Created، تشفير ephemeral key

الخطوات الأساسية لرسائل مرحلة البيانات، بالترتيب:

• إنشاء header بحجم 16 بايت
• إنشاء payload
• تشفير الـ payload باستخدام ChaChaPoly مع استخدام الـ header كـ AD
• تشفير الـ header

Inbound Packet Handling

الحمولة

المعالجة الأولية لجميع الرسائل الواردة:

• فك تشفير البايتات الثمانية الأولى من الرأس (Destination Connection ID) باستخدام intro key
• البحث عن الاتصال باستخدام Destination Connection ID
• إذا تم العثور على الاتصال وكان في مرحلة البيانات، انتقل إلى قسم مرحلة البيانات
• إذا لم يتم العثور على الاتصال، انتقل إلى قسم المصافحة
• ملاحظة: رسائل Peer Test و Hole Punch قد يتم البحث عنها أيضاً باستخدام Destination Connection ID المُنشأ من test أو relay nonce.

معالجة رسائل المصافحة (طلب الجلسة/تم الإنشاء/مؤكد، إعادة المحاولة، طلب الرمز المميز) ورسائل أخرى خارج الجلسة (اختبار النظير، خرق الثقب):

• فك تشفير البايتات 8-15 من الرأس (نوع الحزمة، الإصدار، ومعرف الشبكة) باستخدام مفتاح الدخول. إذا كان Session Request أو Token Request أو Peer Test أو Hole Punch صالح، تابع
• إذا لم تكن رسالة صالحة، ابحث عن اتصال صادر معلق بواسطة IP/منفذ مصدر الحزمة، تعامل مع الحزمة كـ Session Created أو Retry. أعد فك تشفير أول 8 بايتات من الرأس بالمفتاح الصحيح، والبايتات 8-15 من الرأس (نوع الحزمة، الإصدار، ومعرف الشبكة). إذا كان Session Created أو Retry صالح، تابع
• إذا لم تكن رسالة صالحة، فشل، أو ضعها في الطابور كحزمة بيانات محتملة خارجة عن الترتيب
• لـ Session Request/Created، Retry، Token Request، Peer Test، وHole Punch، فك تشفير البايتات 16-31 من الرأس
• لـ Session Request/Created، فك تشفير المفتاح المؤقت
• تحقق من صحة جميع حقول الرأس، توقف إذا لم تكن صالحة
• mixHash() الرأس
• لـ Session Request/Created/Confirmed، فك تشفير الحمولة باستخدام Noise
• لـ Retry ومرحلة البيانات، فك تشفير الحمولة باستخدام ChaChaPoly
• معالج الرأس والحمولة

معالجة رسائل مرحلة البيانات:

• فك تشفير البايتات 8-15 من الرأس (نوع الحزمة، الإصدار، ومعرف الشبكة) باستخدام المفتاح الصحيح
• فك تشفير الحمولة باستخدام ChaChaPoly مع استخدام الرأس كـ AD
• معالجة الرأس والحمولة

Details

في SSU 1، تصنيف الحزم الواردة أمر صعب، لأنه لا يوجد header لتحديد رقم الجلسة. يجب على أجهزة router أولاً مطابقة IP المصدر والمنفذ مع حالة peer موجودة، وإذا لم توجد، محاولة عمليات فك تشفير متعددة بمفاتيح مختلفة للعثور على حالة peer المناسبة أو بدء واحدة جديدة. في حالة تغيير IP المصدر أو المنفذ لجلسة موجودة، ربما بسبب سلوك NAT، قد يستخدم جهاز router طرق استدلال مكلفة لمحاولة مطابقة الحزمة مع جلسة موجودة واسترداد المحتويات.

تم تصميم SSU 2 لتقليل جهد تصنيف الحزم الواردة مع الحفاظ على مقاومة DPI والتهديدات الأخرى على المسار. يتم تضمين رقم Connection ID في الرأس لجميع أنواع الرسائل، ومشفر (مشوش) باستخدام ChaCha20 بمفتاح ونونس معروفين. بالإضافة إلى ذلك، يتم أيضاً تضمين نوع الرسالة في الرأس (مشفر مع حماية الرأس بمفتاح معروف ثم مشوش بـ ChaCha20) ويمكن استخدامه للتصنيف الإضافي. في أي حال لا تكون هناك حاجة لعملية DH تجريبية أو عملية تشفير غير متماثل أخرى لتصنيف الحزمة.

بالنسبة لجميع الرسائل تقريباً من جميع النظراء، فإن مفتاح ChaCha20 لتشفير معرّف الاتصال هو مفتاح التعريف الخاص بموجه الوجهة كما هو منشور في netDb.

الاستثناءات الوحيدة هي الرسائل الأولى المرسلة من Bob إلى Alice (Session Created أو Retry) حيث لا يكون مفتاح التقديم الخاص بـ Alice معروفاً لدى Bob بعد. في هذه الحالات، يُستخدم مفتاح التقديم الخاص بـ Bob كمفتاح.

تم تصميم البروتوكول لتقليل معالجة تصنيف الحزم التي قد تتطلب عمليات تشفير إضافية في خطوات احتياطية متعددة أو استدلالات معقدة. بالإضافة إلى ذلك، الغالبية العظمى من الحزم المستلمة لن تتطلب بحثاً احتياطياً (مكلفاً محتملاً) بواسطة IP/port المصدر وفك تشفير ثانٍ للرأسية. فقط Session Created و Retry (وربما أخرى TBD) ستتطلب المعالجة الاحتياطية. إذا غيّر endpoint عنوان IP أو المنفذ بعد إنشاء الجلسة، فإن connection ID لا يزال يُستخدم للبحث عن الجلسة. ليس من الضروري أبداً استخدام الاستدلالات لإيجاد الجلسة، على سبيل المثال عن طريق البحث عن جلسة مختلفة بنفس IP ولكن بمنفذ مختلف.

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

1. فك تشفير البايتات الـ 8 الأولى باستخدام ChaCha20 مع مفتاح التعريف المحلي، لاستعادة معرف اتصال الوجهة. إذا كان معرف الاتصال يطابق جلسة واردة حالية أو معلقة:

أ) باستخدام المفتاح المناسب، فك تشفير بايتات الرأس 8-15

  to recover the version, net ID, and message type.

ب) إذا كان نوع الرسالة Session Confirmed، فهو long header.

  Verify the net ID and protocol version are valid.
  Decrypt the bytes 15-31 of the header with ChaCha20
  using the local intro key. Then MixHash() the
  decrypted 32 byte header and decrypt the message with Noise.

ج) إذا كان نوع الرسالة صالحاً ولكن ليس Session Confirmed،

  it is a short header.
  Verify the net ID and protocol version are valid.
  decrypt the rest of the message with ChaCha20/Poly1305
  using the session key, using the decrypted 16-byte header
  as the AD.

د) (اختياري) إذا كان معرف الاتصال جلسة واردة معلقة

  awaiting a Session Confirmed message,
  but the net ID, protocol, or message type is not valid,
  it could be a Data message received out-of-order before the
  Session Confirmed, so the data phase header protection keys are not yet known,
  and the header bytes 8-15 were incorrectly decrypted.
  Queue the message, and attempt to decrypt it once the
  Session Confirmed message is received.

هـ) إذا فشل b) أو c)، قم بإسقاط الرسالة.

2. إذا لم يتطابق معرف الاتصال مع جلسة حالية: تحقق من أن رأس النص العادي في البايتات 8-15 صحيح (دون تنفيذ أي عملية حماية رأس). تأكد من أن معرف الشبكة وإصدار البروتوكول صحيحان، وأن نوع الرسالة هو Session Request، أو نوع رسالة آخر مسموح خارج الجلسة (TBD).

أ) إذا كان كل شيء صالحاً ونوع الرسالة هو Session Request،

  decrypt bytes 16-31 of the header and the 32-byte X value
  with ChaCha20 using the local intro key.

• إذا تم قبول الرمز المميز في البايتات 24-31 من الهيدر، فقم بتطبيق MixHash() على الهيدر المفكوك بحجم 32 بايت و فك تشفير الرسالة باستخدام Noise. أرسل Session Created كاستجابة.
  • إذا لم يتم قبول الرمز المميز، أرسل رسالة Retry إلى عنوان IP/المنفذ المصدر مع رمز مميز. لا تحاول فك تشفير الرسالة باستخدام Noise لتجنب هجمات DDoS.

ب) إذا كان نوع الرسالة هو رسالة أخرى صالحة

  out-of-session, presumably with a short header,
  decrypt the rest of the message with ChaCha20/Poly1305
  using the intro key, and using the decrypted 16-byte header
  as the AD. Process the message.

ج) إذا فشلت الخطوة أ) أو ب)، انتقل إلى الخطوة 3)

3. ابحث عن جلسة صادرة معلقة باستخدام عنوان IP/المنفذ المصدر للحزمة.

أ) إذا تم العثور عليها، قم بإعادة فك تشفير البايتات الثمانية الأولى باستخدام ChaCha20 مع مفتاح المقدمة الخاص بـ Bob

  to recover the Destination Connection ID.

ب) إذا كان معرف الاتصال يطابق الجلسة المعلقة:

  Using the correct key, decrypt bytes 8-15 of the header
  to recover the version, net ID, and message type.
  Verify the net ID and protocol version are valid, and
  the message type is Session Created or Retry, or other message type
  allowed out-of-session (TBD).

• إذا كانت جميع البيانات صحيحة ونوع الرسالة هو Session Created، فك تشفير الـ 16 بايت التالية من الرأس وقيمة Y البالغة 32 بايت باستخدام ChaCha20 مع مفتاح المقدمة الخاص بـ Bob. ثم قم بتطبيق MixHash() على رأس الـ 32 بايت المفكوك التشفير و فك تشفير الرسالة باستخدام Noise. أرسل Session Confirmed كرد.

  • إذا كانت جميع البيانات صحيحة ونوع الرسالة هو Retry، فك تشفير البايتات 16-31 من الرأس باستخدام ChaCha20 مع مفتاح المقدمة الخاص بـ Bob. فك تشفير والتحقق من صحة الرسالة باستخدام ChaCha20/Poly1305 مع استخدام TBD كمفتاح و TBD كـ nonce ورأس الـ 32 بايت المفكوك التشفير كـ AD. أعد إرسال Session Request مع الرمز المُستلم كرد.
  • إذا كان نوع الرسالة هو رسالة أخرى صحيحة خارج الجلسة، على الأرجح برأس قصير، فك تشفير باقي الرسالة باستخدام ChaCha20/Poly1305 مع استخدام مفتاح المقدمة، واستخدام رأس الـ 16 بايت المفكوك التشفير كـ AD. عالج الرسالة.

  c) If a pending outbound session is not found, or the connection ID does not match the pending session, drop the message, unless the port is shared with SSU 1.

4. إذا كان SSU 1 يعمل على نفس المنفذ، حاول معالجة الرسالة كحزمة SSU 1.

Error Handling

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

في معظم الحالات، ببساطة قم بإسقاط الحزمة. قد تقوم عملية التنفيذ، ولكن ليس مطلوباً منها، بإعادة إرسال الحزمة المرسلة سابقاً (رسالة handshake أو ACK 0) كاستجابة.

بعد إرسال Session Created كـ Bob، الحزم غير المتوقعة عادة ما تكون حزم Data التي لا يمكن فك تشفيرها لأن حزم Session Confirmed قد ضاعت أو وصلت خارج الترتيب. ضع الحزم في طابور واحاول فك تشفيرها بعد استلام حزم Session Confirmed.

بعد استلام Session Confirmed كـ Bob، الحزم غير المتوقعة عادة ما تكون حزم Session Confirmed معاد إرسالها، وذلك لأن ACK 0 الخاص بـ Session Confirmed قد فُقد. يمكن إسقاط الحزم غير المتوقعة. يجوز للتطبيق، ولكن ليس مطلوباً منه، إرسال حزمة Data تحتوي على كتلة ACK كاستجابة.

Notes

بالنسبة لـ Session Created و Session Confirmed، يجب على التطبيقات التحقق بعناية من جميع حقول الرأس المفكوكة التشفير (Connection IDs، رقم الحزمة، نوع الحزمة، الإصدار، المعرف، frag، والأعلام) قبل استدعاء mixHash() على الرأس ومحاولة فك تشفير الحمولة باستخدام Noise AEAD. إذا فشل فك تشفير Noise AEAD، فلا يجوز إجراء أي معالجة أخرى، لأن mixHash() ستكون قد أفسدت حالة المصافحة، ما لم يقم التطبيق بحفظ حالة الـ hash و"التراجع" عنها.

Version Detection

قد لا يكون من الممكن اكتشاف ما إذا كانت الحزم الواردة من الإصدار 1 أو 2 على نفس المنفذ الوارد بكفاءة. قد يكون من المنطقي تنفيذ الخطوات المذكورة أعلاه قبل معالجة SSU 1، لتجنب محاولة عمليات DH التجريبية باستخدام كلا إصداري البروتوكول.

سيتم تحديده إذا لزم الأمر.

Recommended Constants

• مهلة إعادة إرسال المصافحة الصادرة: 1.25 ثانية، مع تراجع أسي (إعادة الإرسال عند 1.25، 3.75، و 8.75 ثانية)
• إجمالي مهلة المصافحة الصادرة: 15 ثانية
• مهلة إعادة إرسال المصافحة الواردة: 1 ثانية، مع تراجع أسي (إعادة الإرسال عند 1، 3، و 7 ثواني)
• إجمالي مهلة المصافحة الواردة: 12 ثانية
• المهلة بعد إرسال إعادة المحاولة: 9 ثواني
• تأخير ACK: max(10, min(rtt/6, 150)) ms
• تأخير ACK الفوري: min(rtt/16, 5) ms
• الحد الأقصى لنطاقات ACK: 256؟
• الحد الأقصى لعمق ACK: 512؟
• توزيع الحشو: 0-15 بايت، أو أكثر

Variants, Fallbacks, and General Issues

سيتم تحديده لاحقاً

Packet Overhead Analysis

يفترض IPv4، لا يشمل الحشو الإضافي، لا يشمل أحجام رؤوس IP و UDP. الحشو هو حشو mod-16 لـ SSU 1 فقط.

SSU 1