SSU2

स्थिति

रोलआउट योजना:

अवलोकन

यह प्रस्ताव एक प्रमाणित key agreement प्रोटोकॉल का वर्णन करता है जो SSU की स्वचालित पहचान और हमलों के विभिन्न रूपों के प्रतिरोध को बेहतर बनाने के लिए है।

यह प्रस्ताव निम्नलिखित तरीके से व्यवस्थित है: सुरक्षा लक्ष्य प्रस्तुत किए गए हैं, इसके बाद बुनियादी प्रोटोकॉल की चर्चा की गई है। इसके बाद, सभी प्रोटोकॉल संदेशों का पूर्ण विनिर्देश दिया गया है। अंत में, router पते और संस्करण पहचान पर चर्चा की गई है।

अन्य I2P transports की तरह, SSU2 को I2NP संदेशों के point-to-point (router-to-router) transport के लिए परिभाषित किया गया है। यह एक सामान्य-उद्देश्य डेटा pipe नहीं है। SSU की तरह, यह दो अतिरिक्त सेवाएं भी प्रदान करता है: NAT traversal के लिए Relaying, और inbound reachability के निर्धारण के लिए Peer Testing। यह एक तीसरी सेवा भी प्रदान करता है, जो SSU में नहीं है, connection migration के लिए जब कोई peer IP या port बदलता है।

प्रेरणा

SSU एकमात्र शेष protocol layer है जिसके लिए ElGamal की आवश्यकता होती है, जो बहुत धीमा है। SSU के लिए flow control जटिल है और अच्छी तरह से काम नहीं करता। SSU के हिस्से address spoofing attacks के लिए संवेदनशील हैं। handshake Noise का उपयोग नहीं करता।

डिज़ाइन लक्ष्य

• ElGamal को समाप्त करके CPU उपयोग कम करें। DH के लिए X25519 का उपयोग करें।

• Peer Test और Relay functions को बनाए रखें, और उनके लिए सुरक्षा बढ़ाएं।

• मानक प्रवाह नियंत्रण एल्गोरिदम की अनुमति देकर implementation को आसान बनाना।

• सेटअप विलंबता को कम करें। वर्तमान में औसत सेटअप समय NTCP2 के लिए लगभग 135 ms और SSU के लिए 187 ms है, हालांकि NTCP2 में एक अतिरिक्त राउंड ट्रिप है; SSU2 में ElGamal को बदलने से यह कम होना चाहिए, लेकिन अन्य बदलाव भी मदद कर सकते हैं।

• SSU 1 की तुलना में अधिकतम throughput को बनाए रखना या बढ़ाना, जैसा कि testnet पर simulated latencies और packet drop percentages की एक श्रृंखला पर मापा गया।

• स्पूफ्ड source addresses से “address validation” के माध्यम से traffic amplification और misrouting attacks को रोकना।

• पैकेट की पहचान को आसान बनाना, fallbacks और heuristics पर निर्भरता कम करना जो कोड को अत्यधिक जटिल बनाते हैं।

• जब peer का IP या port बदलता है तो connection migration को formalize और improve करें। Address validation पूरा होने तक connections को migrate न करें, ताकि attacks को रोका जा सके। कुछ SSU 1 implementations NAT rebinding के कारण port changes को handle करने के लिए expensive heuristics का उपयोग करते हैं। कोई भी ज्ञात SSU 1 implementations IP changes को बिल्कुल handle नहीं कर सकते।

• एक ही port पर SSU 1 और 2 को support करें, auto-detect करें, और NetDB में एक single “transport” (यानी RouterAddress) के रूप में published करें।

• NetDB में एक अलग फील्ड में केवल version 1, केवल 2, या 1+2 के लिए publish support, और default को केवल version 1 पर सेट करें (version support को किसी विशेष router version के साथ bind न करें)

• सुनिश्चित करें कि सभी implementations (Java/i2pd/Go) अपने स्वयं के schedules पर version 2 support जोड़ सकें (या न जोड़ सकें)

• सभी संदेशों में यादृच्छिक पैडिंग जोड़ें जिसमें handshake और data संदेश शामिल हैं। सभी पैडिंग MAC द्वारा कवर होना चाहिए, SSU 1 में end-of-packet पैडिंग के विपरीत। दोनों पक्षों के लिए न्यूनतम और अधिकतम पैडिंग और/या पैडिंग वितरण का अनुरोध करने के लिए विकल्प तंत्र प्रदान करें। पैडिंग वितरण की विशिष्टताएं implementation-dependent हैं और प्रोटोकॉल में स्वयं निर्दिष्ट हो भी सकती हैं और नहीं भी।

• उन संदेशों के headers और contents को अस्पष्ट करें जो पूर्णतः encrypted नहीं हैं पर्याप्त रूप से ताकि DPI boxes और AV signatures उन्हें आसानी से classify न कर सकें। यह भी सुनिश्चित करें कि किसी एकल peer या peers के समूह को जाने वाले संदेशों में bits का समान pattern न हो।

• Java format के कारण DH में bits के नुकसान को ठीक करें Ticket1112, और X25519 पर स्विच करके DH को तेज़ बनाएं।

• DH परिणाम को as-is उपयोग करने के बजाय एक वास्तविक key derivation function (KDF) पर स्विच करें

• “probing resistance” (जैसा कि Tor इसे कहता है) जोड़ें; इसमें replay resistance शामिल है।

• 2-way authenticated key exchange (2W-AKE) बनाए रखें। 1W-AKE हमारे एप्लिकेशन के लिए पर्याप्त नहीं है।

• प्रमाणीकरण के एक अन्य भाग के रूप में RouterInfo में प्रकाशित स्थिर सार्वजनिक कुंजी पर निर्भर रहें।

• भविष्य की विस्तारशीलता के लिए handshake में options/version जोड़ें।

• कनेक्शन सेटअप के लिए आवश्यक CPU में महत्वपूर्ण वृद्धि न करें; यदि संभव हो तो, इसे काफी कम करें।

• SSU 1 में AES encryption द्वारा लगाई गई 16 bytes के multiple तक padding की आवश्यकता को हटाना।

• एन्क्रिप्शन और MAC के लिए मानक ChaCha/Poly1305 का उपयोग करें, SSU 1 में उपयोग किए गए AES एन्क्रिप्शन और गैर-मानक HMAC-MD5-128 MAC को बदलते हुए।

• भेजने और प्राप्त करने के लिए अलग encryption keys का उपयोग करें, बजाय SSU 1 में दोनों दिशाओं के लिए उपयोग की जाने वाली common keys के।

• एक 3-संदेश, एक-round-trip handshake का उपयोग करें, जैसा कि NTCP2 में है। डेटा संदेशों की प्रतीक्षा में होने वाली देरी को हटाएं जो SSU को प्रभावी रूप से एक two-round-trip handshake बनाती है।

• ACKs और NACKs की दक्षता में नाटकीय सुधार, जो SSU 1 में भयावह है। ACKs और NACKs के लिए आवश्यक bandwidth को कम करें, और डेटा के लिए उपलब्ध packet size को बढ़ाएं। गुम संदेशों के burst के लिए NACKs को कुशलता से encode करें, जो WiFi पर सामान्य है।

• I2NP message fragmentation को implement करने के लिए आवश्यक जटिलता को कम करना। पूर्ण I2NP messages के लिए fragmentation mechanisms और encoding को bypass करना।

• पैडिंग से पहले प्रोटोकॉल ओवरहेड को कम से कम करें, विशेष रूप से ACKs के लिए। जबकि पैडिंग जोड़ा जाएगा, पैडिंग से पहले का ओवरहेड अभी भी ओवरहेड है। कम-बैंडविड्थ नोड्स को SSU2 का उपयोग करने में सक्षम होना चाहिए।

• रीप्ले और स्क्यू डिटेक्शन के लिए टाइमस्टैम्प को बनाए रखें।

• टाइमस्टैम्प में वर्ष 2038 की किसी भी समस्या से बचें, कम से कम 2106 तक काम करना चाहिए।

• दक्षता, कार्यान्वयन में आसानी, और अधिकतम I2NP संदेश आकार बढ़ाने के लिए न्यूनतम MTU को 620 से बढ़ाकर 1280 करें। Fragmentation और reassembly काफी महंगी है। 1028 बाइट tunnel संदेशों के लिए जगह प्रदान करके, I2NP संदेशों का एक बड़ा हिस्सा fragmentation की आवश्यकता नहीं होगी।

• दक्षता के लिए अधिकतम MTU को 1488 (IPv6 के लिए 1484) से बढ़ाकर 1500 करना। MTU का 16 का गुणज होने की आवश्यकता को हटाना।

• SSU 1 में लगभग 32K से I2NP message का अधिकतम आकार बढ़ाकर NTCP2 की तरह लगभग 64 KB करना।

• हैंडशेक से IP और port फ़ील्ड्स के signature को हटाएं, ताकि जो router अपना external IP और port नहीं जानते वे कनेक्ट हो सकें।

• SSU 1 से handshake में IP/port discovery mechanism को बनाए रखें, ताकि routers अपना external IP और port जान सकें।

• डिज़ाइन में Java, C++, और Go router डेवलपर्स के प्रतिनिधियों को शामिल करें।

Non-Goals

• बुलेट-प्रूफ DPI प्रतिरोध… जो कि pluggable transports होगा, Proposal 109।

• एक TLS-based (या HTTPS-lookalike) transport… जो Proposal 104 होगा।

• Timing-based DPI प्रतिरोध (inter-message timing/delays implementation-dependent हो सकती है; intra-message delays किसी भी बिंदु पर शुरू की जा सकती हैं, जैसे कि random padding भेजने से पहले)। कृत्रिम विलंब (जिसे obfs4 में IAT या inter-arrival time कहा जाता है) प्रोटोकॉल से स्वतंत्र होते हैं।

• एक सत्र में भाग लेने की इनकारी (वहाँ signatures मौजूद हैं)।

गैर-लक्ष्य जिन पर आंशिक रूप से पुनर्विचार किया जा सकता है या चर्चा की जा सकती है:

• Deep Packet Inspection (DPI) के विरुद्ध सुरक्षा की मात्रा

• Post-Quantum (PQ) सुरक्षा

• अस्वीकार्यता

Security Goals

हम तीन पक्षों पर विचार करते हैं:

• Alice, जो एक नया session स्थापित करना चाहती है।
• Bob, जिसके साथ Alice एक session स्थापित करना चाहती है।
• Mallory, Alice और Bob के बीच “man in the middle”।

अधिकतम दो प्रतिभागी सक्रिय हमलों में संलग्न हो सकते हैं।

Alice और Bob दोनों के पास एक static key pair है, जो उनकी RouterIdentity में निहित है।

प्रस्तावित प्रोटोकॉल Alice और Bob को निम्नलिखित आवश्यकताओं के तहत एक साझा गुप्त key (K) पर सहमत होने की अनुमति देने का प्रयास करता है:

1. Private key सुरक्षा: न तो Bob और न ही Mallory को Alice की static private key के बारे में कुछ भी पता चलता है। समान रूप से, Alice को Bob की static private key के बारे में कुछ भी पता नहीं चलता है।

2. session key K केवल Alice और Bob को ज्ञात है।

3. Perfect forward secrecy: सहमत session key भविष्य में गुप्त रहती है, भले ही Alice और/या Bob की static private keys key पर सहमति के बाद प्रकट हो जाएं।

4. द्विदिशीय प्रमाणीकरण: Alice निश्चित है कि उसने Bob के साथ एक session स्थापित किया है, और इसके विपरीत भी।

5. ऑनलाइन DPI के विरुद्ध सुरक्षा: यह सुनिश्चित करें कि केवल सरल deep packet inspection (DPI) तकनीकों का उपयोग करके यह पता लगाना तुच्छ नहीं है कि Alice और Bob प्रोटोकॉल में संलग्न हैं। नीचे देखें।

6. सीमित इनकारी क्षमता: न तो Alice और न ही Bob प्रोटोकॉल में भागीदारी से इनकार कर सकते हैं, लेकिन यदि कोई भी shared key लीक करता है तो दूसरा पक्ष प्रेषित डेटा की सामग्री की प्रामाणिकता से इनकार कर सकता है।

वर्तमान प्रस्ताव Station-To-Station (STS) protocol Station-To-Station (STS) protocol के आधार पर सभी पांच आवश्यकताओं को प्रदान करने का प्रयास करता है। ध्यान दें कि यह protocol SSU protocol का भी आधार है।

Additional DPI Discussion

हम दो DPI घटकों की मान्यता रखते हैं:

Online DPI

ऑनलाइन DPI सभी फ़्लो का रीयल-टाइम में निरीक्षण करता है। कनेक्शन को ब्लॉक किया जा सकता है या अन्यथा छेड़छाड़ की जा सकती है। कनेक्शन डेटा या मेटाडेटा की पहचान की जा सकती है और ऑफ़लाइन विश्लेषण के लिए संग्रहीत किया जा सकता है। ऑनलाइन DPI के पास I2P network database तक पहुंच नहीं है। ऑनलाइन DPI में केवल सीमित रीयल-टाइम कम्प्यूटेशनल क्षमता है, जिसमें लंबाई गणना, फ़ील्ड निरीक्षण, और XOR जैसी सरल गणनाएं शामिल हैं। ऑनलाइन DPI में ChaCha20, AEAD, और hashing जैसे तेज़ रीयल-टाइम क्रिप्टोग्राफ़िक फ़ंक्शन की क्षमता है, लेकिन इन्हें अधिकांश या सभी फ़्लो पर लागू करना बहुत महंगा होगा। इन क्रिप्टोग्राफ़िक ऑपरेशन का कोई भी अनुप्रयोग केवल उन IP/Port संयोजनों पर लागू होगा जो पहले ऑफ़लाइन विश्लेषण द्वारा पहचाने गए हों। ऑनलाइन DPI में DH या elligator2 जैसे उच्च-ओवरहेड क्रिप्टोग्राफ़िक फ़ंक्शन की क्षमता नहीं है। ऑनलाइन DPI विशेष रूप से I2P का पता लगाने के लिए डिज़ाइन नहीं है, हालांकि उस उद्देश्य के लिए इसमें सीमित वर्गीकरण नियम हो सकते हैं।

ऑनलाइन DPI द्वारा protocol की पहचान को रोकना एक लक्ष्य है।

ऑनलाइन या “straightforward” DPI की अवधारणा में यहाँ निम्नलिखित विरोधी क्षमताएं शामिल मानी गई हैं:

1. target द्वारा भेजे गए या प्राप्त किए गए सभी डेटा का निरीक्षण करने की क्षमता।

2. देखे गए डेटा पर ऑपरेशन करने की क्षमता, जैसे कि block ciphers या hash functions को लागू करना।

3. पहले भेजे गए संदेशों को संग्रहीत करने और उनसे तुलना करने की क्षमता।

4. packets को modify, delay या fragment करने की क्षमता।

हालांकि, ऑनलाइन DPI की निम्नलिखित सीमाएं मानी गई हैं:

5. IP addresses को router hashes के साथ map करने की असमर्थता। जबकि network database तक real-time पहुंच के साथ यह तुच्छ है, इसके लिए एक DPI सिस्टम की आवश्यकता होगी जो विशेष रूप से I2P को target करने के लिए designed हो।

6. प्रोटोकॉल का पता लगाने के लिए timing जानकारी का उपयोग न कर पाना।

7. सामान्यतः, ऑनलाइन DPI टूलबॉक्स में कोई भी अंतर्निहित टूल नहीं होते जो विशेष रूप से I2P detection के लिए डिज़ाइन किए गए हों। इसमें “honeypots” बनाना भी शामिल है, जिसमें उदाहरण के लिए उनके संदेशों में nonrandom padding शामिल होगी। ध्यान दें कि यह machine learning सिस्टम या अत्यधिक कॉन्फ़िगरेबल DPI टूल्स को बाहर नहीं करता जब तक वे अन्य आवश्यकताओं को पूरा करते हैं।

payload विश्लेषण का मुकाबला करने के लिए, यह सुनिश्चित किया जाता है कि सभी संदेश यादृच्छिक डेटा से अप्रभेद्य हों। इसके लिए उनकी लंबाई का भी यादृच्छिक होना आवश्यक है, जो केवल यादृच्छिक padding जोड़ने से कहीं अधिक जटिल है। वास्तव में, परिशिष्ट A में, लेखक तर्क देते हैं कि एक सरल (अर्थात् समान) padding योजना इस समस्या का समाधान नहीं करती। इसलिए परिशिष्ट A प्रस्तावित हमले के लिए उचित सुरक्षा प्रदान कर सकने वाली यादृच्छिक देरी को शामिल करने या वैकल्पिक padding योजना विकसित करने का सुझाव देता है।

उपरोक्त छठी प्रविष्टि से सुरक्षा के लिए, implementations में protocol में random delays शामिल करने चाहिए। ऐसी तकनीकें इस proposal में शामिल नहीं हैं, लेकिन वे padding length की समस्याओं को भी हल कर सकती हैं। संक्षेप में, यह proposal payload analysis के खिलाफ अच्छी सुरक्षा प्रदान करता है (जब Appendix A में दिए गए विचारों को ध्यान में रखा जाता है), लेकिन flow analysis के खिलाफ केवल सीमित सुरक्षा प्रदान करता है।

Offline DPI

Offline DPI ऑनलाइन DPI द्वारा संग्रहीत डेटा का निरीक्षण करके बाद के विश्लेषण के लिए करता है। Offline DPI को विशेष रूप से I2P का पता लगाने के लिए डिज़ाइन किया जा सकता है। Offline DPI के पास I2P network database तक real-time पहुंच नहीं होती है। Offline DPI के पास इस और अन्य I2P specifications तक पहुंच होती है। Offline DPI के पास असीमित कम्प्यूटेशनल क्षमता होती है, जिसमें इस specification में परिभाषित सभी cryptographic functions शामिल हैं।

ऑफलाइन DPI में मौजूदा कनेक्शन को ब्लॉक करने की क्षमता नहीं है। ऑफलाइन DPI के पास packet injection द्वारा host/port पर पार्टियों को near-realtime (सेटअप के मिनटों के भीतर) भेजने की क्षमता है। ऑफलाइन DPI के पास “probing” या अन्य कारणों से पिछले संदेशों (संशोधित या असंशोधित) को near-realtime (सेटअप के मिनटों के भीतर) replay करने की क्षमता है।

यह offline DPI द्वारा protocol identification को रोकना कोई लक्ष्य नहीं है। पहले दो messages में obfuscated data की सभी decoding, जो I2P routers द्वारा implemented की जाती है, offline DPI द्वारा भी implemented की जा सकती है।

यह एक लक्ष्य है कि पिछले संदेशों के replay का उपयोग करके किए गए कनेक्शन प्रयासों को अस्वीकार किया जाए।

Address Validation

निम्नलिखित QUIC RFC 9000 से कॉपी किया गया है। प्रत्येक अनुभाग के लिए, समीक्षा करें और संपादित करें।

पता सत्यापन सुनिश्चित करता है कि किसी endpoint का उपयोग traffic amplification attack के लिए नहीं किया जा सकता। ऐसे हमले में, एक packet को server पर भेजा जाता है जिसमें spoofed source address की जानकारी होती है जो एक victim की पहचान करती है। यदि कोई server उस packet के जवाब में अधिक या बड़े packets generate करता है, तो हमलावर उस server का उपयोग करके victim की ओर अपनी स्वयं की क्षमता से अधिक data भेज सकता है।

amplification attacks के विरुद्ध प्राथमिक सुरक्षा यह सत्यापित करना है कि एक peer उस transport address पर packets प्राप्त करने में सक्षम है जिसका वह दावा करता है। इसलिए, किसी ऐसे address से packets प्राप्त करने के बाद जो अभी तक validated नहीं है, एक endpoint को unvalidated address पर भेजे जाने वाले data की मात्रा को उस address से प्राप्त data की मात्रा के तीन गुना तक सीमित करना चाहिए। responses के आकार पर यह सीमा anti-amplification limit के रूप में जानी जाती है।

Address validation कनेक्शन स्थापना के दौरान (देखें Section 8.1) और कनेक्शन migration के दौरान (देखें Section 8.2) दोनों समय किया जाता है।

Address Validation during Connection Establishment

कनेक्शन स्थापना दोनों endpoints के लिए पता सत्यापन प्रदान करती है। विशेष रूप से, Handshake keys के साथ संरक्षित पैकेट की प्राप्ति इस बात की पुष्टि करती है कि peer ने एक Initial पैकेट को सफलतापूर्वक प्रोसेस किया है। एक बार जब endpoint ने peer से Handshake पैकेट को सफलतापूर्वक प्रोसेस कर लिया है, तो वह peer address को सत्यापित मान सकता है।

अतिरिक्त रूप से, एक endpoint पीयर पता को validated मान सकता है यदि पीयर endpoint द्वारा चुने गए connection ID का उपयोग करता है और connection ID में कम से कम 64 bits का entropy होता है।

क्लाइंट के लिए, उसके पहले Initial packet में Destination Connection ID field का मान उसे server address को सफलतापूर्वक किसी भी packet को process करने के हिस्से के रूप में validate करने की अनुमति देता है। server से आने वाले Initial packets उन keys से protected होते हैं जो इस value से derive की जाती हैं (QUIC-TLS का Section 5.2 देखें)। वैकल्पिक रूप से, यह value server द्वारा Version Negotiation packets में echo की जाती है (Section 6) या Retry packets में Integrity Tag में शामिल की जाती है (QUIC-TLS का Section 5.8)।

client address को validate करने से पहले, servers को उन bytes की संख्या से तीन गुना से अधिक bytes नहीं भेजने चाहिए जितने उन्होंने प्राप्त किए हैं। यह spoofed source addresses का उपयोग करके mount किए जा सकने वाले किसी भी amplification attack की magnitude को सीमित करता है। Address validation से पहले amplification से बचने के उद्देश्य से, servers को उन सभी payload bytes की गणना करनी चाहिए जो datagrams में प्राप्त हुए हैं और जो uniquely एक single connection को attributed हैं। इसमें वे datagrams शामिल हैं जिनमें ऐसे packets हैं जो successfully process हुए हैं और वे datagrams भी शामिल हैं जिनमें ऐसे packets हैं जो सभी discard कर दिए गए हैं।

क्लाइंट को यह सुनिश्चित करना चाहिए कि Initial packets वाले UDP datagrams में कम से कम 1200 bytes का UDP payload हो, आवश्यकता के अनुसार PADDING frames जोड़कर। एक client जो padded datagrams भेजता है, वह server को address validation पूरा करने से पहले अधिक data भेजने की अनुमति देता है।

सर्वर से Initial या Handshake packet की हानि एक deadlock का कारण बन सकती है यदि client अतिरिक्त Initial या Handshake packets नहीं भेजता है। एक deadlock तब हो सकता है जब सर्वर अपनी anti-amplification सीमा तक पहुंच जाता है और client को उसके द्वारा भेजे गए सभी डेटा के लिए acknowledgments प्राप्त हो गए हों। इस स्थिति में, जब client के पास अतिरिक्त packets भेजने का कोई कारण नहीं है, तो सर्वर अधिक डेटा भेजने में असमर्थ होगा क्योंकि उसने client के पते को validate नहीं किया है। इस deadlock को रोकने के लिए, clients को Probe Timeout (PTO) पर एक packet भेजना चाहिए; QUIC-RECOVERY का Section 6.2 देखें। विशेष रूप से, client को एक UDP datagram में एक Initial packet भेजना चाहिए जिसमें कम से कम 1200 bytes हों यदि इसके पास Handshake keys नहीं हैं, और अन्यथा एक Handshake packet भेजना चाहिए।

एक server cryptographic handshake शुरू करने से पहले client address को validate करना चाह सकता है। QUIC handshake पूरा करने से पहले address validation प्रदान करने के लिए Initial packet में एक token का उपयोग करता है। यह token client को connection establishment के दौरान एक Retry packet के साथ (Section 8.1.2 देखें) या पिछले connection में NEW_TOKEN frame का उपयोग करके (Section 8.1.3 देखें) प्रदान किया जाता है।

address validation से पहले लगाई गई sending limits के अतिरिक्त, servers भी उन limits से बाधित होते हैं जो congestion controller द्वारा निर्धारित की जाती हैं। Clients केवल congestion controller द्वारा ही बाधित होते हैं।

Token Construction

NEW_TOKEN frame या Retry packet में भेजा गया token इस तरह से बनाया जाना चाहिए जो server को यह पहचानने में सक्षम बनाए कि यह client को कैसे प्रदान किया गया था। ये tokens एक ही field में carry किए जाते हैं लेकिन servers से अलग handling की आवश्यकता होती है।

Address Validation Using Retry Packets

क्लाइंट के Initial packet प्राप्त करने पर, सर्वर एक token युक्त Retry packet (Section 17.2.5) भेजकर address validation का अनुरोध कर सकता है। यह token क्लाइंट द्वारा Retry packet प्राप्त करने के बाद उस connection के लिए भेजे जाने वाले सभी Initial packets में दोहराया जाना चाहिए।

Retry packet में प्रदान किए गए token वाले Initial packet को प्रोसेस करने के जवाब में, एक server दूसरा Retry packet नहीं भेज सकता; यह केवल connection को अस्वीकार कर सकता है या इसे आगे बढ़ने की अनुमति दे सकता है।

जब तक यह किसी आक्रमणकारी के लिए अपने स्वयं के पते के लिए एक वैध token उत्पन्न करना संभव नहीं है (धारा 8.1.4 देखें) और client उस token को वापस करने में सक्षम है, यह server को साबित करता है कि उसने token प्राप्त किया है।

एक server एक Retry packet का उपयोग connection establishment की state और processing costs को स्थगित करने के लिए भी कर सकता है। server को एक अलग connection ID प्रदान करने की आवश्यकता, Section 18.2 में परिभाषित original_destination_connection_id transport parameter के साथ, server को यह प्रदर्शित करने के लिए मजबूर करती है कि उसने, या किसी entity के साथ जिसके साथ वह सहयोग करता है, client से मूल Initial packet प्राप्त किया है। एक अलग connection ID प्रदान करना server को इस बात पर कुछ नियंत्रण भी देता है कि बाद के packets कैसे route किए जाते हैं। इसका उपयोग connections को एक अलग server instance की ओर direct करने के लिए किया जा सकता है।

यदि एक सर्वर को एक client Initial प्राप्त होता है जिसमें एक अमान्य Retry token है लेकिन अन्यथा वैध है, तो यह जानता है कि client एक और Retry token स्वीकार नहीं करेगा। सर्वर ऐसे packet को छोड़ सकता है और client को handshake failure का पता लगाने के लिए timeout करने दे सकता है, लेकिन इससे client पर एक महत्वपूर्ण latency penalty लग सकती है। इसके बजाय, सर्वर को तुरंत INVALID_TOKEN error के साथ connection को close (Section 10.2) करना चाहिए। ध्यान दें कि इस बिंदु पर सर्वर ने connection के लिए कोई state स्थापित नहीं किया है और इसलिए closing period में प्रवेश नहीं करता।

एक flow जो Retry packet के उपयोग को दर्शाता है, चित्र 9 में दिखाया गया है।

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

एक सर्वर MAY एक कनेक्शन के दौरान क्लाइंट्स को एक address validation token प्रदान कर सकता है जो बाद के कनेक्शन पर उपयोग किया जा सकता है। Address validation विशेष रूप से 0-RTT के साथ महत्वपूर्ण है क्योंकि एक सर्वर संभावित रूप से 0-RTT data के जवाब में क्लाइंट को महत्वपूर्ण मात्रा में data भेजता है।

सर्वर NEW_TOKEN frame (Section 19.7) का उपयोग करके क्लाइंट को एक address validation token प्रदान करता है जिसका उपयोग भविष्य के कनेक्शन को validate करने के लिए किया जा सकता है। भविष्य के कनेक्शन में, क्लाइंट इस token को Initial packets में शामिल करता है ताकि address validation प्रदान कर सके। क्लाइंट को इस token को सभी Initial packets में शामिल करना चाहिए जो वह भेजता है, जब तक कि कोई Retry इस token को किसी नए token से replace न कर दे। क्लाइंट को Retry में प्रदान किए गए token का उपयोग भविष्य के कनेक्शन के लिए नहीं करना चाहिए। सर्वर किसी भी Initial packet को discard कर सकते हैं जिसमें अपेक्षित token नहीं है।

Retry packet के लिए बनाए गए token के विपरीत, जो तुरंत उपयोग किया जाता है, NEW_TOKEN frame में भेजा गया token कुछ समय बीतने के बाद उपयोग किया जा सकता है। इस प्रकार, token की एक expiration time होनी चाहिए, जो या तो स्पष्ट expiration time हो सकती है या जारी किया गया timestamp हो सकता है जिसका उपयोग dynamically expiration time की गणना करने के लिए किया जा सकता है। सर्वर expiration time को store कर सकता है या इसे token में encrypted रूप में शामिल कर सकता है।

NEW_TOKEN के साथ जारी किया गया token में ऐसी जानकारी शामिल नहीं होनी चाहिए जो किसी observer को values को उस connection से link करने की अनुमति दे सके जिस पर यह जारी किया गया था। उदाहरण के लिए, इसमें पिछला connection ID या addressing information शामिल नहीं हो सकती, जब तक कि values encrypted न हों। एक server को यह सुनिश्चित करना चाहिए कि वह जो भी NEW_TOKEN frame भेजता है वह सभी clients में unique हो, उन frames को छोड़कर जो पहले भेजे गए NEW_TOKEN frames के losses को repair करने के लिए भेजे गए हैं। जानकारी जो server को Retry और NEW_TOKEN के tokens के बीच अंतर करने की अनुमति देती है, वह server के अलावा अन्य entities के लिए accessible हो सकती है।

यह संभावना नहीं है कि client port नंबर दो अलग connections पर समान हो; इसलिए port को validate करना सफल होने की संभावना नहीं है।

NEW_TOKEN frame में प्राप्त एक token किसी भी server के लिए लागू होता है जिसके लिए connection को authoritative माना जाता है (जैसे, certificate में शामिल server names)। जब किसी ऐसे server से connect करते समय जिसके लिए client के पास एक applicable और unused token है, तो उसे अपने Initial packet के Token field में उस token को include करना चाहिए। Token include करने से server को अतिरिक्त round trip के बिना client address को validate करने में मदद मिल सकती है। Client को ऐसा कोई token include नहीं करना चाहिए जो उस server के लिए applicable नहीं है जिससे वह connect कर रहा है, जब तक कि client के पास यह जानकारी न हो कि token जारी करने वाला server और जिस server से client connect कर रहा है वे jointly tokens का management कर रहे हैं। Client उस server के किसी भी पिछले connection से token का उपयोग कर सकता है।

एक token एक server को उस connection के बीच गतिविधि को correlate करने की अनुमति देता है जहाँ token जारी किया गया था और किसी भी connection के बीच जहाँ इसका उपयोग किया जाता है। Clients जो server के साथ पहचान की निरंतरता को तोड़ना चाहते हैं, वे NEW_TOKEN frame का उपयोग करके प्रदान किए गए tokens को त्याग सकते हैं। इसकी तुलना में, Retry packet में प्राप्त token का तुरंत connection attempt के दौरान उपयोग किया जाना चाहिए और बाद के connection attempts में इसका उपयोग नहीं किया जा सकता।

एक client को NEW_TOKEN frame से token का पुन: उपयोग विभिन्न connection attempts के लिए नहीं करना चाहिए। Token का पुन: उपयोग network path पर entities द्वारा connections को linked करने की अनुमति देता है; Section 9.5 देखें।

क्लाइंट्स को एक ही connection पर कई tokens मिल सकते हैं। linkability को रोकने के अलावा, किसी भी token का उपयोग किसी भी connection attempt में किया जा सकता है। Servers कई connection attempts के लिए address validation को enable करने या पुराने tokens को replace करने के लिए अतिरिक्त tokens भेज सकते हैं जो अमान्य हो सकते हैं। एक client के लिए, इस अस्पष्टता का मतलब है कि सबसे हाल का अप्रयुक्त token भेजना सबसे प्रभावी होने की संभावना है। हालांकि पुराने tokens को save करने और उपयोग करने के कोई नकारात्मक परिणाम नहीं हैं, clients पुराने tokens को address validation के लिए server के लिए कम उपयोगी होने की संभावना के रूप में मान सकते हैं।

जब कोई server एक Initial packet प्राप्त करता है जिसमें address validation token होता है, तो उसे token को validate करने का प्रयास करना चाहिए, जब तक कि उसने पहले से ही address validation पूरा न किया हो। यदि token invalid है, तो server को ऐसे proceed करना चाहिए जैसे कि client का validated address नहीं है, जिसमें संभावित रूप से Retry packet भेजना भी शामिल है। NEW_TOKEN frames और Retry packets के साथ प्रदान किए गए tokens को servers द्वारा अलग किया जा सकता है (देखें Section 8.1.1), और बाद वाले को अधिक कड़ाई से validate किया जा सकता है। यदि validation सफल हो जाता है, तो server को handshake को आगे बढ़ने की अनुमति देनी चाहिए।

नोट: packet को discard करने के बजाय client को unvalidated मानने का औचित्य यह है कि client ने token को पिछले connection में NEW_TOKEN frame का उपयोग करके प्राप्त किया हो सकता है, और यदि server ने state खो दी है, तो वह token को validate करने में बिल्कुल असमर्थ हो सकता है, जिससे packet discard होने पर connection failure हो सकती है।

एक stateless design में, एक server encrypted और authenticated tokens का उपयोग करके clients को जानकारी भेज सकता है जिसे server बाद में recover करके client address को validate करने के लिए उपयोग कर सकता है। Tokens cryptographic handshake में integrated नहीं होते हैं, और इसलिए वे authenticated नहीं होते हैं। उदाहरण के लिए, एक client एक token को reuse करने में सक्षम हो सकता है। इस property का फायदा उठाने वाले attacks से बचने के लिए, एक server अपने tokens के उपयोग को केवल उस जानकारी तक सीमित कर सकता है जो client addresses को validate करने के लिए आवश्यक है।

क्लाइंट्स एक connection पर प्राप्त tokens का उपयोग समान version का उपयोग करके किसी भी connection attempt के लिए कर सकते हैं। उपयोग करने के लिए token का चयन करते समय, क्लाइंट्स को उस connection की अन्य properties पर विचार करने की आवश्यकता नहीं है जिसका attempt किया जा रहा है, जिसमें संभावित application protocols का चुनाव, session tickets, या अन्य connection properties शामिल हैं।

Address Validation Token Integrity

एक address validation token का अनुमान लगाना कठिन होना चाहिए। token में कम से कम 128 bits की entropy के साथ एक random value शामिल करना पर्याप्त होगा, लेकिन यह server पर निर्भर करता है कि वह उस value को याद रखे जो वह clients को भेजता है।

एक token-based स्कीम server को client के साथ validation से जुड़ी किसी भी state को offload करने की अनुमति देती है। इस design के काम करने के लिए, token को clients द्वारा modification या falsification के विरुद्ध integrity protection द्वारा कवर किया जाना चाहिए। Integrity protection के बिना, malicious clients ऐसे tokens के लिए values generate या guess कर सकते हैं जो server द्वारा स्वीकार कर लिए जाएंगे। केवल server को tokens के लिए integrity protection key तक पहुंच की आवश्यकता होती है।

token के लिए एक एकल स्पष्ट रूप से परिभाषित प्रारूप की आवश्यकता नहीं है क्योंकि जो server token उत्पन्न करता है वही इसे उपभोग भी करता है। Retry packets में भेजे गए tokens में ऐसी जानकारी शामिल होनी चाहिए जो server को यह सत्यापित करने की अनुमति देती है कि client packets में source IP address और port स्थिर रहते हैं।

NEW_TOKEN फ्रेम में भेजे गए टोकन में ऐसी जानकारी शामिल होनी चाहिए जो सर्वर को यह सत्यापित करने की अनुमति देती है कि टोकन जारी करने के समय से क्लाइंट IP पता नहीं बदला है। सर्वर NEW_TOKEN फ्रेम से टोकन का उपयोग Retry पैकेट न भेजने का निर्णय लेने में कर सकते हैं, भले ही क्लाइंट पता बदल गया हो। यदि क्लाइंट IP पता बदल गया है, तो सर्वर को anti-amplification सीमा का पालन करना चाहिए; देखें Section 8। ध्यान दें कि NAT की उपस्थिति में, यह आवश्यकता उन अन्य होस्ट की सुरक्षा के लिए अपर्याप्त हो सकती है जो NAT साझा करते हैं amplification हमलों से।

हमलावर DDoS हमलों में servers को amplifiers के रूप में उपयोग करने के लिए tokens को replay कर सकते हैं। ऐसे हमलों से बचाव के लिए, servers को यह सुनिश्चित करना चाहिए कि tokens का replay रोका जाए या सीमित किया जाए। Servers को यह सुनिश्चित करना चाहिए कि Retry packets में भेजे गए tokens को केवल थोड़े समय के लिए ही स्वीकार किया जाए, क्योंकि वे clients द्वारा तुरंत वापस किए जाते हैं। NEW_TOKEN frames (Section 19.7) में प्रदान किए गए tokens को अधिक समय तक valid रहना चाहिए लेकिन कई बार स्वीकार नहीं किया जाना चाहिए। Servers को प्रोत्साहित किया जाता है कि यदि संभव हो तो tokens को केवल एक बार उपयोग करने की अनुमति दें; tokens में clients के बारे में अतिरिक्त जानकारी शामिल हो सकती है जो applicability या reuse को और सीमित कर सके।

ऑनलाइन DPI

Path validation का उपयोग connection migration (Section 9 देखें) के दौरान दोनों peers द्वारा address के बदलने के बाद reachability को verify करने के लिए किया जाता है। Path validation में, endpoints एक specific local address और एक specific peer address के बीच reachability का परीक्षण करते हैं, जहाँ एक address IP address और port का 2-tuple होता है।

Path validation यह परीक्षण करता है कि किसी peer के लिए path पर भेजे गए packets उस peer द्वारा प्राप्त होते हैं। Path validation का उपयोग यह सुनिश्चित करने के लिए किया जाता है कि migrating peer से प्राप्त packets में spoofed source address न हो।

पथ सत्यापन यह सत्यापित नहीं करता कि कोई peer वापसी की दिशा में भेज सकता है। स्वीकृतियों (Acknowledgments) को वापसी पथ सत्यापन के लिए उपयोग नहीं किया जा सकता क्योंकि उनमें अपर्याप्त एंट्रॉपी होती है और वे नकली (spoofed) हो सकती हैं। Endpoints स्वतंत्र रूप से पथ की प्रत्येक दिशा पर पहुंच-योग्यता निर्धारित करते हैं, और इसलिए वापसी पहुंच-योग्यता केवल peer द्वारा ही स्थापित की जा सकती है।

Path validation का उपयोग किसी भी endpoint द्वारा किसी भी समय किया जा सकता है। उदाहरण के लिए, एक endpoint यह जांच सकता है कि कोई peer अभी भी अपने address के कब्जे में है या नहीं, विशेषकर निष्क्रियता की अवधि के बाद।

Path validation NAT traversal mechanism के रूप में डिज़ाइन नहीं किया गया है। यद्यपि यहाँ वर्णित mechanism NAT bindings के निर्माण के लिए प्रभावी हो सकता है जो NAT traversal को support करती हैं, यह अपेक्षा है कि एक endpoint उस path पर पहले packet भेजे बिना packets प्राप्त करने में सक्षम है। प्रभावी NAT traversal के लिए अतिरिक्त synchronization mechanisms की आवश्यकता होती है जो यहाँ प्रदान नहीं किए गए हैं।

एक endpoint PATH_CHALLENGE और PATH_RESPONSE frames के साथ अन्य frames को भी शामिल कर सकता है जो path validation के लिए उपयोग किए जाते हैं। विशेष रूप से, एक endpoint Path Maximum Transmission Unit Discovery (PMTUD) के लिए PATH_CHALLENGE frame के साथ PADDING frames शामिल कर सकता है; देखें Section 14.2.1। एक endpoint PATH_RESPONSE frame भेजते समय अपना स्वयं का PATH_CHALLENGE frame भी शामिल कर सकता है।

एक endpoint नए स्थानीय पते से भेजे गए probes के लिए नए connection ID का उपयोग करता है; देखें Section 9.5। नए path को probe करते समय, एक endpoint यह सुनिश्चित कर सकता है कि उसके peer के पास responses के लिए एक अप्रयुक्त connection ID उपलब्ध है। यदि peer की active_connection_id_limit अनुमति देती है, तो एक ही packet में NEW_CONNECTION_ID और PATH_CHALLENGE frames भेजना सुनिश्चित करता है कि response भेजते समय peer के पास एक अप्रयुक्त connection ID उपलब्ध होगी।

एक endpoint एक साथ कई paths की probe करना चुन सकता है। probes के लिए उपयोग किए जाने वाले simultaneous paths की संख्या उसके peer द्वारा पहले से प्रदान किए गए extra connection IDs की संख्या से सीमित होती है, क्योंकि probe के लिए उपयोग किए जाने वाले प्रत्येक नए local address के लिए एक पहले से अप्रयुक्त connection ID की आवश्यकता होती है।

ऑफ़लाइन DPI

path validation शुरू करने के लिए, एक endpoint उस path पर एक अप्रत्याशित payload वाला PATH_CHALLENGE frame भेजता है जिसे validate करना है।

एक endpoint पैकेट लॉस से बचाव के लिए कई PATH_CHALLENGE frames भेज सकता है। हालांकि, एक endpoint को एक ही packet में कई PATH_CHALLENGE frames नहीं भेजने चाहिए।

एक endpoint को PATH_CHALLENGE frame वाले packets के साथ नए path को probe नहीं करना चाहिए उससे अधिक बार जितनी बार वह एक Initial packet भेजेगा। यह सुनिश्चित करता है कि connection migration नए path पर उससे अधिक load नहीं डालता जितना एक नया connection स्थापित करने में लगता है।

endpoint को हर PATH_CHALLENGE frame में अप्रत्याशित डेटा का उपयोग करना चाहिए ताकि वह peer के response को संबंधित PATH_CHALLENGE के साथ जोड़ सके।

एक endpoint को उन datagrams को expand करना चाहिए जिनमें PATH_CHALLENGE frame होता है कम से कम 1200 bytes के सबसे छोटे allowed maximum datagram size तक, जब तक कि path के लिए anti-amplification limit इस size का datagram भेजने की अनुमति न दे। इस size के UDP datagrams भेजना सुनिश्चित करता है कि endpoint से peer तक का network path QUIC के लिए उपयोग किया जा सकता है; Section 14 देखें।

जब कोई endpoint anti-amplification limit के कारण datagram size को 1200 bytes तक विस्तृत करने में असमर्थ होता है, तो path MTU validate नहीं होगा। यह सुनिश्चित करने के लिए कि path MTU पर्याप्त रूप से बड़ा है, endpoint को कम से कम 1200 bytes के datagram में PATH_CHALLENGE frame भेजकर दूसरा path validation करना चाहिए। यह अतिरिक्त validation PATH_RESPONSE सफलतापूर्वक प्राप्त होने के बाद या जब path पर पर्याप्त bytes प्राप्त हो गए हों कि बड़ा datagram भेजने से anti-amplification limit का उल्लंघन नहीं होगा, तब किया जा सकता है।

अन्य मामलों के विपरीत जहां datagrams का विस्तार किया जाता है, endpoints को उन datagrams को discard नहीं करना चाहिए जो बहुत छोटे लगते हैं जब उनमें PATH_CHALLENGE या PATH_RESPONSE होता है।

Path Validation Responses

PATH_CHALLENGE frame प्राप्त करने पर, एक endpoint को PATH_CHALLENGE frame में निहित डेटा को PATH_RESPONSE frame में echo करके अवश्य जवाब देना चाहिए। एक endpoint को PATH_RESPONSE frame वाले packet के transmission में देरी नहीं करनी चाहिए जब तक कि congestion control द्वारा बाध्य न हो।

PATH_RESPONSE frame को उसी network path पर भेजा जाना चाहिए जहाँ PATH_CHALLENGE frame प्राप्त हुआ था। यह सुनिश्चित करता है कि peer द्वारा path validation तभी सफल होती है जब path दोनों दिशाओं में कार्यात्मक हो। इस आवश्यकता को उस endpoint द्वारा लागू नहीं किया जाना चाहिए जो path validation शुरू करता है, क्योंकि इससे migration पर आक्रमण संभव हो जाएगा; Section 9.3.3 देखें।

एक endpoint को उन datagrams का विस्तार करना चाहिए जिनमें PATH_RESPONSE frame है कम से कम 1200 bytes के सबसे छोटे अनुमतित अधिकतम datagram आकार तक। यह सत्यापित करता है कि path दोनों दिशाओं में इस आकार के datagrams को carry करने में सक्षम है। हालांकि, एक endpoint को PATH_RESPONSE वाले datagram का विस्तार नहीं करना चाहिए यदि परिणामी data anti-amplification limit से अधिक हो जाता है। यह केवल तभी होने की अपेक्षा है जब प्राप्त PATH_CHALLENGE को expanded datagram में नहीं भेजा गया था।

एक endpoint को एक PATH_CHALLENGE frame के जवाब में एक से अधिक PATH_RESPONSE frame नहीं भेजना चाहिए; धारा 13.3 देखें। peer से अपेक्षा की जाती है कि वह अतिरिक्त PATH_RESPONSE frames को प्राप्त करने के लिए आवश्यकतानुसार अधिक PATH_CHALLENGE frames भेजे।

कनेक्शन स्थापना के दौरान पता सत्यापन

Path validation तब सफल होती है जब एक PATH_RESPONSE frame प्राप्त होता है जिसमें वह data होता है जो पिछले PATH_CHALLENGE frame में भेजा गया था। किसी भी network path पर प्राप्त PATH_RESPONSE frame उस path को validate करता है जिस पर PATH_CHALLENGE भेजा गया था।

यदि कोई endpoint एक PATH_CHALLENGE frame को एक datagram में भेजता है जो कम से कम 1200 bytes तक विस्तारित नहीं है और यदि इसका response peer address को validate करता है, तो path validate हो जाता है लेकिन path MTU नहीं। परिणामस्वरूप, endpoint अब प्राप्त हुए data से तीन गुना अधिक data भेज सकता है। हालांकि, endpoint को यह सत्यापित करने के लिए एक विस्तारित datagram के साथ दूसरी path validation आरंभ करनी चाहिए कि path आवश्यक MTU का समर्थन करता है।

PATH_CHALLENGE frame युक्त पैकेट के लिए acknowledgment की प्राप्ति पर्याप्त validation नहीं है, क्योंकि acknowledgment को एक दुर्भावनापूर्ण peer द्वारा spoof किया जा सकता है।

टोकन निर्माण

path validation केवल तभी असफल होती है जब endpoint path को validate करने का प्रयास छोड़ देता है।

Endpoints को timer के आधार पर path validation को abandon करना चाहिए। इस timer को set करते समय, implementations को सावधान रहना चाहिए कि नए path का round-trip time मूल path से अधिक हो सकता है। वर्तमान PTO या नए path के लिए PTO (kInitialRtt का उपयोग करते हुए, जैसा कि QUIC-RECOVERY में परिभाषित है) में से बड़े का तीन गुना मान RECOMMENDED है।

यह timeout path validation विफल होने से पहले कई PTOs को समाप्त होने की अनुमति देता है, ताकि एकल PATH_CHALLENGE या PATH_RESPONSE frame का नुकसान path validation की विफलता का कारण न बने।

ध्यान दें कि endpoint को नए path पर अन्य frames वाले packets प्राप्त हो सकते हैं, लेकिन path validation के सफल होने के लिए उपयुक्त data के साथ PATH_RESPONSE frame आवश्यक है।

जब कोई endpoint path validation को छोड़ देता है, तो वह निर्धारित करता है कि path उपयोग योग्य नहीं है। इसका यह जरूरी नहीं है कि connection में विफलता हो – endpoints अन्य paths पर उपयुक्त रूप से packets भेजना जारी रख सकते हैं। यदि कोई paths उपलब्ध नहीं हैं, तो endpoint नए path के उपलब्ध होने की प्रतीक्षा कर सकता है या connection को बंद कर सकता है। एक endpoint जिसके पास अपने peer के लिए कोई valid network path नहीं है, वह NO_VIABLE_PATH connection error का उपयोग करके इसका संकेत दे सकता है, यह ध्यान रखते हुए कि यह केवल तभी संभव है जब network path मौजूद हो लेकिन आवश्यक MTU का समर्थन न करे (Section 14)।

पथ सत्यापन को विफलता के अलावा अन्य कारणों से भी छोड़ा जा सकता है। मुख्य रूप से, यह तब होता है जब पुराने path पर path validation चल रहा हो और इस दौरान नए path पर connection migration शुरू किया जाता है।

Connection Migration

निम्नलिखित QUIC RFC 9000 से कॉपी किया गया है। प्रत्येक अनुभाग के लिए, समीक्षा करें और संपादित करें।

connection ID का उपयोग connections को endpoint addresses (IP address और port) में बदलाव के बावजूद भी बनाए रखने की अनुमति देता है, जैसे कि जब कोई endpoint नए network पर migrate हो जाता है। यह section उस process का वर्णन करता है जिसके द्वारा एक endpoint नए address पर migrate करता है।

QUIC का डिज़ाइन इस बात पर निर्भर करता है कि endpoints हैंडशेक की अवधि के लिए एक स्थिर पता बनाए रखें। एक endpoint को हैंडशेक की पुष्टि से पहले connection migration शुरू नहीं करना चाहिए, जैसा कि QUIC-TLS के Section 4.1.2 में परिभाषित है।

यदि peer ने disable_active_migration transport parameter भेजा है, तो एक endpoint को भी अलग local address से उस address पर packets (probing packets सहित; Section 9.1 देखें) नहीं भेजने चाहिए जो peer ने handshake के दौरान उपयोग किया था, जब तक कि endpoint ने peer से preferred_address transport parameter पर कार्य नहीं किया हो। यदि peer इस आवश्यकता का उल्लंघन करता है, तो endpoint को या तो उस path पर आने वाले packets को Stateless Reset generate किए बिना drop करना चाहिए या path validation के साथ आगे बढ़ना चाहिए और peer को migrate करने की अनुमति देनी चाहिए। Stateless Reset generate करना या connection को close करना network में third parties को observed traffic को spoof करके या अन्यथा manipulate करके connections को close करने का मौका दे देगा।

सभी peer address परिवर्तन जानबूझकर या सक्रिय migration नहीं होते हैं। peer को NAT rebinding का अनुभव हो सकता है: एक middlebox के कारण address में परिवर्तन, आमतौर पर एक NAT, जो एक flow के लिए नया outgoing port या यहाँ तक कि नया outgoing IP address आवंटित करता है। यदि endpoint को peer के address में कोई भी परिवर्तन दिखाई देता है, तो उसे path validation (Section 8.2) करना चाहिए, जब तक कि उसने पहले से उस address को validate नहीं किया हो।

जब किसी endpoint के पास packets भेजने के लिए कोई validated path नहीं होता, तो वह connection state को discard कर सकता है। Connection migration की क्षमता रखने वाला endpoint, connection state को discard करने से पहले नए path के उपलब्ध होने का इंतजार कर सकता है।

यह दस्तावेज नए client addresses पर connections के migration को सीमित करता है, सिवाय Section 9.6 में वर्णित के। Clients सभी migrations को शुरू करने के लिए जिम्मेदार हैं। Servers तब तक client address की ओर non-probing packets (Section 9.1 देखें) नहीं भेजते जब तक वे उस address से non-probing packet नहीं देखते। यदि कोई client किसी अज्ञात server address से packets प्राप्त करता है, तो client को इन packets को discard करना चाहिए।

Retry Packets का उपयोग करके Address Validation

एक endpoint नए local address से peer reachability के लिए path validation (Section 8.2) का उपयोग करके probe कर सकता है, connection को नए local address पर migrate करने से पहले। Path validation की विफलता का सीधा मतलब यह है कि नया path इस connection के लिए उपयोग योग्य नहीं है। Path को validate करने में विफलता connection को समाप्त नहीं करती जब तक कि कोई valid alternative paths उपलब्ध न हों।

PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, और PADDING frames “probing frames” हैं, और अन्य सभी frames “non-probing frames” हैं। केवल probing frames वाला packet एक “probing packet” है, और किसी अन्य frame वाला packet एक “non-probing packet” है।

भविष्य के कनेक्शन के लिए पता सत्यापन

एक endpoint उस address से non-probing frames वाले packets भेजकर connection को नए local address पर migrate कर सकता है।

प्रत्येक endpoint कनेक्शन स्थापना के दौरान अपने peer के address को validate करता है। इसलिए, एक migrating endpoint अपने peer को भेज सकता है यह जानते हुए कि peer अपने वर्तमान address पर receive करने के लिए तैयार है। इस प्रकार, एक endpoint पहले peer के address को validate किए बिना एक नए local address पर migrate कर सकता है।

नए path पर reachability स्थापित करने के लिए, एक endpoint नए path पर path validation (Section 8.2) शुरू करता है। एक endpoint path validation को तब तक defer कर सकता है जब तक कि peer अपने नए address पर अगला non-probing frame नहीं भेजता।

जब migration करते समय, नया path endpoint की वर्तमान sending rate को support नहीं कर सकता है। इसलिए, endpoint अपने congestion controller और RTT estimate को reset करता है, जैसा कि Section 9.4 में वर्णित है।

नया path समान ECN capability नहीं रख सकता है। इसलिए, endpoint ECN capability को validate करता है जैसा कि Section 13.4 में वर्णित है।

Address Validation Token अखंडता

नए peer address से एक non-probing frame वाला packet प्राप्त करना इंगित करता है कि peer उस address पर migrate हो गया है।

यदि प्राप्तकर्ता migration की अनुमति देता है, तो उसे बाद के packets नए peer address पर भेजने चाहिए और peer के address के स्वामित्व को सत्यापित करने के लिए path validation (Section 8.2) आरंभ करना चाहिए यदि validation पहले से चल नहीं रही है। यदि प्राप्तकर्ता के पास peer से कोई अप्रयुक्त connection IDs नहीं हैं, तो वह नए path पर तब तक कुछ भी नहीं भेज सकेगा जब तक peer कोई ID प्रदान नहीं करता; Section 9.5 देखें।

एक endpoint केवल उस address को बदलता है जिस पर वह packets भेजता है, सबसे अधिक-नंबर वाले non-probing packet के response में। यह सुनिश्चित करता है कि एक endpoint पुराने peer address पर packets नहीं भेजता है जब उसे reordered packets प्राप्त होते हैं।

एक endpoint एक अनवैलिडेटेड peer address पर डेटा भेज सकता है, लेकिन इसे धाराओं 9.3.1 और 9.3.2 में वर्णित संभावित हमलों से सुरक्षा करनी चाहिए। एक endpoint किसी peer address का validation छोड़ सकता है यदि वह address हाल ही में देखा गया हो। विशेष रूप से, यदि कोई endpoint किसी प्रकार के spurious migration का पता लगाने के बाद पहले से validated path पर वापस आता है, तो address validation को छोड़ना और loss detection तथा congestion state को restore करना हमले के प्रदर्शन प्रभाव को कम कर सकता है।

नॉन-प्रोबिंग packets भेजने के लिए address बदलने के बाद, एक endpoint अन्य addresses के लिए किसी भी path validation को छोड़ सकता है।

किसी नए peer address से packet प्राप्त करना peer पर NAT rebinding का परिणाम हो सकता है।

नए client address को verify करने के बाद, server को client को नए address validation tokens (Section 8) भेजना चाहिए।

पथ सत्यापन

यह संभव है कि कोई peer अपने source address को spoof कर रहा है ताकि endpoint को किसी अनिच्छुक host को अत्यधिक मात्रा में data भेजने पर मजबूर किया जा सके। यदि endpoint spoofing peer की तुलना में काफी अधिक data भेजता है, तो connection migration का उपयोग उस data की मात्रा को बढ़ाने के लिए किया जा सकता है जो एक attacker किसी victim के विरुद्ध generate कर सकता है।

जैसा कि Section 9.3 में वर्णित है, एक endpoint को peer के नए address को validate करना आवश्यक होता है ताकि peer के पास नए address का possession confirm हो सके। जब तक peer का address valid नहीं माना जाता, endpoint उस address पर भेजे जाने वाले data की मात्रा को सीमित करता है; Section 8 देखें। इस limit की अनुपस्थिति में, एक endpoint का उपयोग किसी अनजान victim के विरुद्ध denial-of-service attack के लिए होने का जोखिम रहता है।

यदि कोई endpoint ऊपर वर्णित अनुसार peer address की validation को छोड़ देता है, तो उसे अपनी sending rate को सीमित करने की आवश्यकता नहीं है।

पाथ सत्यापन प्रारंभ करना

एक on-path attacker एक नकली पते के साथ पैकेट को कॉपी और फॉरवर्ड करके एक spurious connection migration का कारण बन सकता है ताकि यह मूल पैकेट से पहले पहुंचे। नकली पते वाला पैकेट एक migrating connection से आने वाला दिखेगा, और मूल पैकेट को duplicate के रूप में देखा जाएगा और छोड़ दिया जाएगा। एक spurious migration के बाद, source address का validation असफल हो जाएगा क्योंकि source address पर मौजूद entity के पास आवश्यक cryptographic keys नहीं होती हैं PATH_CHALLENGE frame को पढ़ने या उसका जवाब देने के लिए जो उसे भेजा जाता है, भले ही वह चाहे तो भी।

ऐसे भ्रामक migration के कारण connection के fail होने से बचाने के लिए, एक endpoint को नए peer address की validation fail होने पर अंतिम validated peer address का उपयोग करने पर वापस लौटना चाहिए। इसके अतिरिक्त, legitimate peer address से उच्चतर packet numbers वाले packets की प्राप्ति एक और connection migration को trigger करेगी। इससे भ्रामक migration के address की validation को abandon करना होगा, इस प्रकार attacker द्वारा एक single packet inject करके शुरू किए गए migrations को contain किया जा सकेगा।

यदि किसी endpoint के पास अंतिम validated peer address के बारे में कोई state नहीं है, तो उसे सभी connection state को discard करके connection को चुपचाप बंद करना चाहिए। इसके परिणामस्वरूप connection पर नए packets को सामान्य रूप से handle किया जाता है। उदाहरण के लिए, कोई endpoint किसी भी आगे आने वाले incoming packets के जवाब में Stateless Reset भेज सकता है।

पथ सत्यापन प्रतिक्रियाएं

एक off-path हमलावर जो packets को observe कर सकता है, वह genuine packets की copies को endpoints पर forward कर सकता है। यदि copied packet genuine packet से पहले पहुंच जाता है, तो यह NAT rebinding के रूप में दिखाई देगा। कोई भी genuine packet को duplicate के रूप में discard कर दिया जाएगा। यदि हमलावर packets को forward करना जारी रखने में सक्षम है, तो वह हमलावर के माध्यम से path पर migration का कारण बन सकता है। यह हमलावर को on-path रखता है, जिससे उसे सभी subsequent packets को observe या drop करने की क्षमता मिल जाती है।

इस प्रकार के हमले में आक्रमणकारी एक ऐसे path का उपयोग करता है जिसकी विशेषताएं endpoints के बीच के direct path के लगभग समान होती हैं। यह हमला अधिक विश्वसनीय होता है यदि अपेक्षाकृत कम packets भेजे जाएं या packet loss हमले के प्रयास के साथ मेल खाता हो।

मूल path पर प्राप्त एक non-probing packet जो अधिकतम प्राप्त packet number को बढ़ाता है, endpoint को उस path पर वापस जाने का कारण बनेगा। इस path पर eliciting packets हमले के असफल होने की संभावना को बढ़ाते हैं। इसलिए, इस हमले का शमन packets के आदान-प्रदान को ट्रिगर करने पर निर्भर करता है।

एक स्पष्ट migration के जवाब में, endpoints को पहले से सक्रिय path को PATH_CHALLENGE frame का उपयोग करके validate करना चाहिए। इससे उस path पर नए packets भेजने की प्रेरणा मिलती है। यदि path अब viable नहीं है, तो validation attempt time out हो जाएगा और fail हो जाएगा; यदि path viable है लेकिन अब desired नहीं है, तो validation succeed होगा लेकिन केवल path पर probing packets भेजे जाने का परिणाम होगा।

एक endpoint जो एक सक्रिय path पर PATH_CHALLENGE प्राप्त करता है, उसे प्रतिक्रिया में एक non-probing packet भेजना चाहिए। यदि non-probing packet किसी attacker द्वारा बनाई गई किसी भी copy से पहले पहुंचता है, तो इससे connection मूल path पर वापस migrate हो जाता है। किसी अन्य path पर कोई भी बाद का migration इस पूरी प्रक्रिया को फिर से शुरू कर देता है।

यह सुरक्षा अपूर्ण है, लेकिन इसे एक गंभीर समस्या नहीं माना जाता है। यदि मूल path का उपयोग करने के कई प्रयासों के बावजूद भी attack के माध्यम से path विश्वसनीय रूप से तेज़ है, तो attack और routing में सुधार के बीच अंतर करना संभव नहीं है।

एक endpoint इस प्रकार के हमले की बेहतर पहचान के लिए heuristics का भी उपयोग कर सकता है। उदाहरण के लिए, यदि हाल ही में पुराने path पर packets प्राप्त हुए हों तो NAT rebinding की संभावना कम है; इसी तरह, IPv6 paths पर rebinding दुर्लभ होता है। Endpoints डुप्लिकेट packets की भी तलाश कर सकते हैं। इसके विपरीत, connection ID में बदलाव एक हमले के बजाय जानबूझकर migration को दर्शाने की अधिक संभावना रखता है।

सफल पथ सत्यापन

नए path पर उपलब्ध capacity पुराने path के समान नहीं हो सकती है। पुराने path पर भेजे गए packets को नए path के लिए congestion control या RTT estimation में योगदान नहीं देना चाहिए।

किसी peer के अपने नए address के ownership की पुष्टि करने पर, एक endpoint को तुरंत नए path के लिए congestion controller और round-trip time estimator को प्रारंभिक मानों पर reset करना चाहिए (QUIC-RECOVERY के Appendices A.3 और B.3 देखें), जब तक कि peer के address में केवल उसके port number में परिवर्तन न हो। क्योंकि port-only changes आमतौर पर NAT rebinding या अन्य middlebox activity का परिणाम होते हैं, endpoint इन मामलों में प्रारंभिक मानों पर वापस जाने के बजाय अपनी congestion control state और round-trip estimate को बनाए रख सकता है। उन मामलों में जहाँ पुराने path से बनाए रखी गई congestion control state का उपयोग काफी अलग विशेषताओं वाले नए path पर किया जाता है, एक sender तब तक बहुत आक्रामक रूप से transmit कर सकता है जब तक congestion controller और RTT estimator अनुकूलित नहीं हो जाते। सामान्यतः, implementations को नए path पर पिछले मानों का उपयोग करते समय सावधान रहने की सलाह दी जाती है।

migration अवधि के दौरान जब कोई endpoint कई addresses से/को data और probes भेजता है तो receiver पर apparent reordering हो सकती है, क्योंकि दो resulting paths के round-trip times अलग हो सकते हैं। कई paths पर packets का receiver फिर भी सभी received packets को cover करने वाले ACK frames भेजेगा।

जबकि connection migration के दौरान कई paths का उपयोग किया जा सकता है, एक single congestion control context और एक single loss recovery context (QUIC-RECOVERY में वर्णित के अनुसार) पर्याप्त हो सकता है। उदाहरण के लिए, एक endpoint नए congestion control context पर स्विच करने में तब तक देरी कर सकता है जब तक यह पुष्टि नहीं हो जाती कि पुराने path की अब आवश्यकता नहीं है (जैसा कि Section 9.3.3 में वर्णित मामले में है)।

एक sender probe packets के लिए अपवाद बना सकता है ताकि उनका loss detection स्वतंत्र हो और congestion controller को अपनी sending rate कम करने के लिए अनुचित रूप से प्रेरित न करे। एक endpoint एक अलग timer सेट कर सकता है जब PATH_CHALLENGE भेजा जाता है, जो cancel हो जाता है यदि संबंधित PATH_RESPONSE प्राप्त होता है। यदि PATH_RESPONSE प्राप्त होने से पहले timer fire हो जाता है, तो endpoint एक नया PATH_CHALLENGE भेज सकता है और अधिक समय अवधि के लिए timer को restart कर सकता है। यह timer QUIC-RECOVERY के Section 6.2.1 में वर्णित अनुसार सेट किया जाना चाहिए और अधिक aggressive नहीं होना चाहिए।

असफल पथ सत्यापन

कई नेटवर्क पथों पर एक स्थिर connection ID का उपयोग करना एक passive observer को उन पथों के बीच गतिविधि को correlate करने की अनुमति देगा। एक endpoint जो नेटवर्क के बीच स्थानांतरित होता है, वह नहीं चाहेगा कि उनकी गतिविधि को उनके peer के अलावा किसी अन्य entity द्वारा correlate किया जाए, इसलिए विभिन्न स्थानीय पतों से भेजते समय अलग connection IDs का उपयोग किया जाता है, जैसा कि Section 5.1 में चर्चा की गई है। इसे प्रभावी बनाने के लिए, endpoints को यह सुनिश्चित करना होगा कि वे जो connection IDs प्रदान करते हैं, वे किसी अन्य entity द्वारा linked नहीं हो सकते।

किसी भी समय, endpoints अपने द्वारा transmit किए जाने वाले Destination Connection ID को एक ऐसी value में बदल सकते हैं जो किसी अन्य path पर उपयोग नहीं की गई हो।

एक endpoint को एक से अधिक local address से भेजते समय connection ID का पुन: उपयोग नहीं करना चाहिए – उदाहरण के लिए, जब Section 9.2 में वर्णित connection migration शुरू करते समय या Section 9.1 में वर्णित नए network path की probing करते समय।

इसी तरह, एक endpoint को एक से अधिक destination address पर भेजते समय connection ID का पुन: उपयोग नहीं करना चाहिए। अपने peer के नियंत्रण से बाहर network changes के कारण, एक endpoint को एक नए source address से same Destination Connection ID field value के साथ packets प्राप्त हो सकते हैं, जिस स्थिति में वह same local address से भेजते हुए नए remote address के साथ current connection ID का उपयोग जारी रख सकता है।

ये connection ID के पुनः उपयोग संबंधी आवश्यकताएं केवल packets भेजने पर लागू होती हैं, क्योंकि connection ID में बिना परिवर्तन के path में अनजाने में बदलाव संभव हैं। उदाहरण के लिए, network निष्क्रियता की अवधि के बाद, NAT rebinding के कारण packets नए path पर भेजे जा सकते हैं जब client पुनः भेजना शुरू करता है। एक endpoint ऐसी घटना का जवाब Section 9.3 में वर्णित अनुसार देता है।

प्रत्येक नए नेटवर्क पथ पर दोनों दिशाओं में भेजे गए packets के लिए अलग-अलग connection IDs का उपयोग करना, विभिन्न नेटवर्क पथों पर समान connection से packets को जोड़ने के लिए connection ID के उपयोग को समाप्त कर देता है। Header protection यह सुनिश्चित करती है कि packet numbers का उपयोग गतिविधि को correlate करने के लिए नहीं किया जा सकता। यह packets की अन्य विशेषताओं, जैसे कि timing और size, का उपयोग गतिविधि को correlate करने के लिए किए जाने से नहीं रोकता।

एक endpoint को उस peer के साथ migration initiate नहीं करना चाहिए जिसने zero-length connection ID की request की है, क्योंकि नए path पर traffic को पुराने path के traffic से trivially linkable हो सकता है। यदि server zero-length connection ID वाले packets को सही connection के साथ associate करने में सक्षम है, तो इसका मतलब यह है कि server packets को demultiplex करने के लिए अन्य जानकारी का उपयोग कर रहा है। उदाहरण के लिए, एक server हर client को unique address प्रदान कर सकता है – जैसे, HTTP alternative services ALTSVC का उपयोग करके। जानकारी जो multiple network paths पर packets की सही routing की अनुमति दे सकती है, वह उन paths पर activity को peer के अलावा अन्य entities द्वारा भी linked करने की अनुमति देगी।

एक client linkability को कम करने की इच्छा कर सकता है नया connection ID, source UDP port, या IP address पर स्विच करके (देखें RFC8981) जब निष्क्रियता की अवधि के बाद traffic भेज रहा हो। उसी समय पैकेट भेजने का address बदलना server को connection migration का पता लगाने का कारण बन सकता है। यह सुनिश्चित करता है कि migration को support करने वाले mechanisms का उपयोग उन clients के लिए भी हो जो NAT rebindings या वास्तविक migrations का अनुभव नहीं करते। Address बदलना peer को अपनी congestion control state reset करने का कारण बन सकता है (देखें Section 9.4), इसलिए addresses को केवल कभी-कभार ही बदलना चाहिए।

एक endpoint जो उपलब्ध connection IDs समाप्त कर देता है, वह नए paths की probe नहीं कर सकता या migration शुरू नहीं कर सकता, न ही वह अपने peer द्वारा migrate करने के probes या प्रयासों का जवाब दे सकता है। यह सुनिश्चित करने के लिए कि migration संभव है और अलग-अलग paths पर भेजे गए packets को correlate नहीं किया जा सकता, endpoints को peers के migrate करने से पहले नए connection IDs प्रदान करने चाहिए; Section 5.1.1 देखें। यदि कोई peer ने उपलब्ध connection IDs समाप्त कर दिए हों, तो एक migrating endpoint नए network path पर भेजे जाने वाले सभी packets में NEW_CONNECTION_ID frame शामिल कर सकता है।

Server’s Preferred Address

QUIC servers को एक IP address पर connections स्वीकार करने और handshake के तुरंत बाद इन connections को एक अधिक preferred address पर transfer करने का प्रयास करने की अनुमति देता है। यह विशेष रूप से उपयोगी है जब clients शुरू में एक ऐसे address से connect करते हैं जो कई servers द्वारा साझा किया जाता है लेकिन connection stability सुनिश्चित करने के लिए एक unicast address का उपयोग करना पसंद करेंगे। यह section एक preferred server address पर connection को migrate करने के लिए protocol का वर्णन करता है।

इस दस्तावेज़ में निर्दिष्ट QUIC के संस्करण द्वारा कनेक्शन के दौरान किसी नए सर्वर पते पर कनेक्शन का स्थानांतरण समर्थित नहीं है। यदि क्लाइंट को नए सर्वर पते से पैकेट प्राप्त होते हैं जबकि क्लाइंट ने उस पते पर migration की शुरुआत नहीं की है, तो क्लाइंट को इन पैकेट्स को त्याग देना चाहिए।

नए पथ की जांच

एक server TLS handshake में preferred_address transport parameter को शामिल करके एक preferred address संप्रेषित करता है।

सर्वर प्रत्येक address family (IPv4 और IPv6) का एक preferred address संचारित कर सकते हैं ताकि clients अपने network attachment के लिए सबसे उपयुक्त address का चयन कर सकें।

एक बार handshake की पुष्टि हो जाने पर, client को server द्वारा प्रदान किए गए दो addresses में से एक को चुनना चाहिए और path validation शुरू करना चाहिए (देखें Section 8.2)। एक client किसी भी पहले से अप्रयुक्त active connection ID का उपयोग करके packets का निर्माण करता है, जो या तो preferred_address transport parameter या NEW_CONNECTION_ID frame से लिया जाता है।

जैसे ही path validation सफल हो जाता है, client को नए connection ID का उपयोग करके सभी भविष्य के packets को नए server address पर भेजना शुरू करना चाहिए और पुराने server address का उपयोग बंद कर देना चाहिए। यदि path validation विफल हो जाता है, तो client को सभी भविष्य के packets को server के मूल IP address पर भेजना जारी रखना चाहिए।

कनेक्शन माइग्रेशन प्रारंभ करना

एक client जो preferred address पर migrate करता है, उसे migrate करने से पहले अपने द्वारा चुने गए address को validate करना चाहिए; Section 21.5.3 देखें।

एक server को अपने preferred IP address पर कभी भी packet मिल सकता है, connection accept करने के बाद। यदि इस packet में PATH_CHALLENGE frame है, तो server एक packet भेजता है जिसमें PATH_RESPONSE frame होता है जैसा कि Section 8.2 में बताया गया है। Server को अपने original address से non-probing packets तब तक भेजने चाहिए जब तक कि उसे client से अपने preferred address पर non-probing packet न मिले और जब तक server ने नए path को validate न कर लिया हो।

सर्वर को अपने पसंदीदा पते से client की दिशा में path पर probe करना चाहिए। यह किसी attacker द्वारा शुरू किए गए spurious migration से बचाव में मदद करता है।

एक बार जब server ने अपना path validation पूरा कर लिया हो और अपने preferred address पर एक नए largest packet number के साथ एक non-probing packet प्राप्त कर लिया हो, तो server अपने preferred IP address से exclusively client को non-probing packets भेजना शुरू कर देता है। Server को इस connection के लिए पुराने IP address पर प्राप्त होने वाले नए packets को drop कर देना चाहिए। Server पुराने IP address पर प्राप्त होने वाले delayed packets को process करना जारी रख सकता है।

एक server जो preferred_address transport parameter में addresses प्रदान करता है, वे केवल उस connection के लिए valid हैं जिसमें वे प्रदान किए गए हैं। एक client को इन्हें अन्य connections के लिए उपयोग नहीं करना चाहिए, जिसमें वे connections भी शामिल हैं जो current connection से resume की गई हैं।

कनेक्शन माइग्रेशन का जवाब देना

एक client को server के preferred address पर migrate करने से पहले connection migration perform करने की आवश्यकता हो सकती है। इस स्थिति में, client को अपने नए address से original और preferred server address दोनों के लिए समानांतर में path validation perform करना चाहिए।

यदि server के preferred address का path validation सफल हो जाता है, तो client को original address की validation छोड़नी चाहिए और server के preferred address का उपयोग करने के लिए migrate करना चाहिए। यदि server के preferred address का path validation असफल हो जाता है लेकिन server के original address की validation सफल हो जाती है, तो client अपने नए address पर migrate कर सकता है और server के original address पर भेजना जारी रख सकता है।

यदि server के preferred address पर प्राप्त packets का source address handshake के दौरान client से observe किए गए address से अलग है, तो server को Sections 9.3.1 और 9.3.2 में वर्णित potential attacks से बचाव करना चाहिए। Intentional simultaneous migration के अतिरिक्त, यह इसलिए भी हो सकता है क्योंकि client के access network ने server के preferred address के लिए एक अलग NAT binding का उपयोग किया हो।

सर्वर को अलग पते से probe packet प्राप्त करने पर client के नए पते के लिए path validation शुरू करना चाहिए; Section 8 देखें।

एक client जो नए address पर migrate करता है, उसे server के लिए समान address family से एक preferred address का उपयोग करना चाहिए।

preferred_address transport parameter में प्रदान की गई connection ID उन addresses के लिए विशिष्ट नहीं है जो प्रदान की गई हैं। यह connection ID इस बात को सुनिश्चित करने के लिए प्रदान की गई है कि client के पास migration के लिए एक connection ID उपलब्ध हो, लेकिन client इस connection ID को किसी भी path पर उपयोग कर सकता है।

पीयर पता स्पूफिंग

QUIC उन endpoints को सुझाता है जो IPv6 का उपयोग करके डेटा भेजते हैं कि वे RFC 6437 के अनुपालन में IPv6 flow label लागू करें, जब तक कि स्थानीय API IPv6 flow labels सेट करने की अनुमति न दे।

दुर्भाग्य से, Java API IPv6 flow labels सेट करने की अनुमति नहीं देता है।

गैर-लक्ष्य

निम्नलिखित QUIC RFC 9000 से कॉपी किया गया है। प्रत्येक अनुभाग के लिए, समीक्षा करें और संपादित करें।

QUIC का लक्ष्य एक सुरक्षित transport connection प्रदान करना है। Section 21.1 उन properties का एक अवलोकन प्रदान करता है; बाद के sections इन properties के संबंध में बाधाओं और चेतावनियों पर चर्चा करते हैं, जिसमें ज्ञात attacks और countermeasures के विवरण शामिल हैं।

पथ पर पता स्पूफिंग

QUIC का एक पूर्ण सुरक्षा विश्लेषण इस दस्तावेज़ के दायरे से बाहर है। यह खंड implementers की सहायता के लिए और protocol विश्लेषण को मार्गदर्शन प्रदान करने के लिए वांछित सुरक्षा गुणों का एक अनौपचारिक विवरण प्रदान करता है।

QUIC SEC-CONS में वर्णित threat model को मानता है और उस model से उत्पन्न होने वाले कई attacks के विरुद्ध सुरक्षा प्रदान करता है।

इस उद्देश्य के लिए, हमलों को passive और active हमलों में विभाजित किया गया है। Passive हमलावरों के पास network से packets पढ़ने की क्षमता होती है, जबकि active हमलावरों के पास network में packets लिखने की क्षमता भी होती है। हालांकि, एक passive हमले में एक हमलावर शामिल हो सकता है जिसके पास routing में परिवर्तन या connection बनाने वाले packets द्वारा लिए गए path में अन्य संशोधन करने की क्षमता हो।

हमलावरों को अतिरिक्त रूप से on-path attackers या off-path attackers के रूप में वर्गीकृत किया जाता है। एक on-path attacker किसी भी packet को पढ़ सकता है, संशोधित कर सकता है, या हटा सकता है जिसे वह observe करता है ताकि वह packet अब अपने गंतव्य तक न पहुंचे, जबकि एक off-path attacker packets को observe करता है लेकिन मूल packet को उसके इच्छित गंतव्य तक पहुंचने से नहीं रोक सकता। दोनों प्रकार के हमलावर भी arbitrary packets transmit कर सकते हैं। यह परिभाषा SEC-CONS के Section 3.5 से अलग है क्योंकि एक off-path attacker packets को observe करने में सक्षम है।

handshake, protected packets, और connection migration के गुणों को अलग-अलग माना जाता है।

ऑफ-पाथ पैकेट फॉरवर्डिंग

QUIC handshake TLS 1.3 handshake को शामिल करता है और TLS13 के Appendix E.1 में वर्णित cryptographic गुणों को inherit करता है। QUIC की कई security properties इस बात पर निर्भर करती हैं कि TLS handshake इन गुणों को प्रदान करे। TLS handshake पर कोई भी हमला QUIC को प्रभावित कर सकता है।

TLS handshake पर कोई भी हमला जो session keys की गोपनीयता या विशिष्टता से समझौता करता है, या भाग लेने वाले peers के प्रमाणीकरण को प्रभावित करता है, वह QUIC द्वारा प्रदान की जाने वाली अन्य सुरक्षा गारंटियों को प्रभावित करता है जो उन keys पर निर्भर करती हैं। उदाहरण के लिए, migration (Section 9) गोपनीयता सुरक्षा की प्रभावशीलता पर निर्भर करता है, TLS handshake का उपयोग करके keys की बातचीत और QUIC packet protection दोनों के लिए, network paths में linkability से बचने के लिए।

TLS हैंडशेक की अखंडता पर एक हमला किसी आक्रमणकारी को एप्लिकेशन प्रोटोकॉल या QUIC संस्करण के चयन को प्रभावित करने की अनुमति दे सकता है।

TLS द्वारा प्रदान की गई properties के अतिरिक्त, QUIC handshake, handshake पर DoS attacks के विरुद्ध कुछ सुरक्षा प्रदान करता है।

हानि का पता लगाना और कंजेशन नियंत्रण

Address validation (Section 8) का उपयोग यह सत्यापित करने के लिए किया जाता है कि कोई entity जो किसी दिए गए address का दावा करती है, वह उस address पर packets प्राप्त करने में सक्षम है। Address validation amplification attack targets को उन addresses तक सीमित करता है जिनके लिए आक्रमणकारी packets का अवलोकन कर सकता है।

address validation से पहले, endpoints इस बात में सीमित होते हैं कि वे क्या भेज सकते हैं। Endpoints एक unvalidated address की ओर उस address से प्राप्त data के तीन गुना से अधिक data नहीं भेज सकते।

नोट: anti-amplification limit केवल तभी लागू होती है जब कोई endpoint किसी unvalidated address से प्राप्त packets का जवाब देता है। anti-amplification limit clients पर तब लागू नहीं होती जब वे नया connection स्थापित कर रहे हों या connection migration शुरू कर रहे हों।

Connection Migration के निजता निहितार्थ

पूर्ण handshake के लिए server की पहली flight की गणना संभावित रूप से महंगी है, जिसमें signature और key exchange computation दोनों की आवश्यकता होती है। computational DoS attacks को रोकने के लिए, Retry packet एक सस्ता token exchange mechanism प्रदान करता है जो servers को किसी भी महंगी गणना करने से पहले client के IP address को validate करने की अनुमति देता है, केवल एक single round trip की लागत पर। सफल handshake के बाद, servers client को नए tokens जारी कर सकते हैं, जो इस लागत के बिना नए connection establishment की अनुमति देगा।

सर्वर का पसंदीदा पता

एक on-path या off-path आक्रमणकर्ता Initial packets को बदलकर या racing करके handshake को असफल करने के लिए मजबूर कर सकता है। एक बार वैध Initial packets का आदान-प्रदान हो जाने के बाद, बाद के Handshake packets Handshake keys के साथ सुरक्षित होते हैं, और एक on-path आक्रमणकर्ता endpoints को प्रयास छोड़ने के लिए मजबूर करने हेतु packets को drop करने के अलावा handshake failure को मजबूर नहीं कर सकता।

एक on-path attacker पैकेट्स के दोनों तरफ के addresses को भी बदल सकता है और इसलिए client या server को remote addresses का गलत दृश्य प्रदान कर सकता है। इस प्रकार का हमला NAT द्वारा किए जाने वाले कार्यों से अलग नहीं है।

पसंदीदा Address का संचार

संपूर्ण handshake क्रिप्टोग्राफिकली सुरक्षित है, जिसमें Initial packets को per-version keys के साथ एन्क्रिप्ट किया जाता है और Handshake तथा बाद के packets को TLS key exchange से व्युत्पन्न keys के साथ एन्क्रिप्ट किया जाता है। इसके अतिरिक्त, parameter negotiation को TLS transcript में शामिल किया गया है और इस प्रकार यह सामान्य TLS negotiation के समान integrity guarantees प्रदान करता है। एक आक्रमणकारी client के transport parameters को देख सकता है (जब तक वह version-specific salt जानता है) लेकिन server के transport parameters को नहीं देख सकता और parameter negotiation को प्रभावित नहीं कर सकता।

Connection ID सभी packets में unencrypted हैं लेकिन integrity protected हैं।

QUIC का यह संस्करण version negotiation mechanism को शामिल नहीं करता है; असंगत versions के implementations केवल connection स्थापित करने में विफल हो जाएंगे।

पसंदीदा पते पर माइग्रेशन

पैकेट सुरक्षा (Section 12.1) Version Negotiation packets को छोड़कर सभी packets पर authenticated encryption लागू करती है, हालांकि Initial और Retry packets में version-specific keying material के उपयोग के कारण सीमित सुरक्षा होती है; अधिक विवरण के लिए QUIC-TLS देखें। यह section संरक्षित packets के विरुद्ध passive और active attacks पर विचार करता है।

on-path और off-path दोनों प्रकार के आक्रमणकारी एक passive attack कर सकते हैं जिसमें वे देखे गए packets को भविष्य में packet protection के विरुद्ध offline attack के लिए सहेजते हैं; यह किसी भी network पर किसी भी packet के किसी भी observer के लिए सत्य है।

एक हमलावर जो कनेक्शन के लिए वैध पैकेट्स को observe करने में सक्षम हुए बिना पैकेट्स inject करता है, उसके सफल होने की संभावना कम है, क्योंकि packet protection यह सुनिश्चित करता है कि वैध पैकेट्स केवल उन endpoints द्वारा ही generate किए जाते हैं जिनके पास handshake के दौरान स्थापित key material होता है; Sections 7 और 21.1.1 देखें। इसी तरह, कोई भी active attacker जो पैकेट्स को observe करता है और उन पैकेट्स में नया data insert करने या existing data को modify करने का प्रयास करता है, वह Initial packets के अलावा, receiving endpoint द्वारा वैध माने जाने वाले पैकेट्स generate करने में सक्षम नहीं होना चाहिए।

एक spoofing attack, जिसमें एक सक्रिय attacker packet के असुरक्षित भागों को फिर से लिखता है जो वह forward करता है या inject करता है, जैसे कि source या destination address, केवल तभी प्रभावी होता है जब attacker मूल endpoint तक packets forward कर सकता है। Packet protection यह सुनिश्चित करता है कि packet payloads केवल उन endpoints द्वारा ही process किए जा सकते हैं जिन्होंने handshake पूरा किया है, और invalid packets को उन endpoints द्वारा ignore कर दिया जाता है।

एक आक्रमणकारी packets और UDP datagrams के बीच की सीमाओं को भी संशोधित कर सकता है, जिससे कई packets एक single datagram में मिल जाते हैं या coalesced packets कई datagrams में विभाजित हो जाते हैं। Initial packets वाले datagrams को छोड़कर, जिन्हें padding की आवश्यकता होती है, datagrams में packets की व्यवस्था के संशोधन का connection पर कोई functional प्रभाव नहीं होता, हालांकि यह कुछ performance विशेषताओं को बदल सकता है।

Client Migration और Preferred Address की परस्पर क्रिया

Connection migration (Section 9) endpoints को कई paths पर IP addresses और ports के बीच transition करने की क्षमता प्रदान करता है, एक समय में transmission और non-probing frames की receipt के लिए एक path का उपयोग करते हुए। Path validation (Section 8.2) यह स्थापित करता है कि एक peer किसी विशेष path पर भेजे गए packets को receive करने के लिए इच्छुक और सक्षम दोनों है। यह spoofed address पर भेजे गए packets की संख्या को सीमित करके address spoofing के प्रभावों को कम करने में मदद करता है।

यह खंड विभिन्न प्रकार के DoS हमलों के तहत connection migration की अपेक्षित security properties का वर्णन करता है।

IPv6 Flow Label और Migration का उपयोग

एक आक्रमणकारी जो अपने द्वारा देखे गए packet को उसके इच्छित गंतव्य तक पहुंचने से रोक सकता है, उसे on-path attacker माना जाता है। जब कोई आक्रमणकारी client और server के बीच मौजूद होता है, तो endpoints को किसी दिए गए path पर connectivity स्थापित करने के लिए आक्रमणकारी के माध्यम से packets भेजने की आवश्यकता होती है।

एक on-path आक्रमणकारी कर सकता है:

• पैकेट्स का निरीक्षण करें

• IP और UDP packet headers को modify करें

• नए पैकेट इंजेक्ट करें

• पैकेट्स में देरी करें

• पैकेट्स को पुनः क्रमबद्ध करना

• पैकेट ड्रॉप करें

• पैकेट boundaries के साथ datagrams को split और merge करें

एक on-path हमलावर निम्नलिखित नहीं कर सकता:

• पैकेट के एक प्रमाणित हिस्से को संशोधित करना और प्राप्तकर्ता को उस पैकेट को स्वीकार करने के लिए प्रेरित करना

एक on-path attacker के पास उन packets को modify करने का अवसर होता है जिन्हें वह observe करता है; हालांकि, packet के किसी भी authenticated portion में कोई भी modification के कारण receiving endpoint द्वारा उसे invalid मानकर drop कर दिया जाएगा, क्योंकि packet payloads दोनों authenticated और encrypted होते हैं।

QUIC का उद्देश्य एक on-path attacker की क्षमताओं को निम्नलिखित रूप से सीमित करना है:

1. एक on-path attacker किसी connection के लिए path के उपयोग को रोक सकता है, जिससे connection fail हो जाता है यदि वह कोई अलग path उपयोग नहीं कर सकता जिसमें attacker शामिल न हो। यह सभी packets को drop करके, उन्हें modify करके ताकि वे decrypt होने में fail हो जाएं, या अन्य तरीकों से हासिल किया जा सकता है।

2. एक on-path attacker एक नए path पर migration को रोक सकता है जिस पर attacker भी on-path है, नए path पर path validation को fail करवाकर।

3. एक on-path आक्रमणकारी किसी client को ऐसे path पर migrate करने से नहीं रोक सकता जिस पर आक्रमणकारी on-path नहीं है।

4. एक on-path आक्रमणकारी पैकेट को विलंबित करके या उन्हें छोड़कर कनेक्शन की throughput को कम कर सकता है।

5. एक on-path attacker किसी endpoint को ऐसे packet को स्वीकार करने के लिए मजबूर नहीं कर सकता जिसके authenticated portion को उसने modify किया हो।

Off-Path Active Attacks

एक off-path attacker सीधे client और server के बीच के path पर नहीं होता है लेकिन client और server के बीच भेजे गए कुछ या सभी packets की प्रतियां प्राप्त करने में सक्षम हो सकता है। यह उन packets की प्रतियों को किसी भी endpoint पर भेजने में भी सक्षम होता है।

एक off-path attacker कर सकता है:

• पैकेट का निरीक्षण करें

• नए पैकेट inject करें

• इंजेक्टेड पैकेट्स को पुनः क्रमबद्ध करना

एक off-path attacker निम्नलिखित नहीं कर सकता:

• एंडपॉइंट्स द्वारा भेजे गए packets को संशोधित करना

• पैकेट में देरी करें

• पैकेट ड्रॉप करें

• मूल पैकेट्स को पुनः क्रमबद्ध करना

एक off-path attacker उन packets की modified copies बना सकता है जिन्हें उसने observe किया है और उन copies को network में inject कर सकता है, संभावित रूप से spoofed source और destination addresses के साथ।

इस चर्चा के उद्देश्यों के लिए, यह मान लिया गया है कि एक off-path attacker के पास network में एक packet की modified copy को inject करने की क्षमता है जो destination endpoint पर original packet के पहुंचने से पहले पहुंच जाएगी, जिसे attacker द्वारा observe किया गया था। दूसरे शब्दों में, एक attacker के पास endpoints के बीच legitimate packets के साथ लगातार “जीतने” की क्षमता है, जिससे संभावित रूप से recipient द्वारा original packet को ignore किया जा सकता है।

यह भी माना जाता है कि आक्रमणकारी के पास NAT state को प्रभावित करने के लिए आवश्यक संसाधन हैं। विशेष रूप से, एक आक्रमणकारी किसी endpoint को अपनी NAT binding खोने पर मजबूर कर सकता है और फिर अपने स्वयं के ट्रैफिक के साथ उपयोग के लिए समान पोर्ट प्राप्त कर सकता है।

QUIC का लक्ष्य एक off-path attacker की क्षमताओं को निम्नलिखित तरीके से सीमित करना है:

1. एक off-path आक्रमणकारी packets की रेसिंग कर सकता है और एक “limited” on-path आक्रमणकारी बनने का प्रयास कर सकता है।

2. एक off-path attacker forwarded packets के लिए path validation को सफल बना सकता है जिसमें source address off-path attacker के रूप में सूचीबद्ध हो, जब तक कि वह client और server के बीच बेहतर connectivity प्रदान कर सकता है।

3. एक बार handshake पूरा हो जाने के बाद, off-path attacker कनेक्शन को बंद नहीं कर सकता।

4. एक off-path attacker नए path पर migration को fail नहीं कर सकता यदि वह नए path को observe नहीं कर सकता।

5. एक off-path आक्रमणकारी एक नए path पर migration के दौरान एक सीमित on-path आक्रमणकारी बन सकता है जिसके लिए वह एक off-path आक्रमणकारी भी है।

6. एक off-path attacker एक सीमित on-path attacker बन सकता है साझा NAT state को प्रभावित करके जिससे वह server को उसी IP address और port से packets भेजता है जिसका client ने मूल रूप से उपयोग किया था।

सुरक्षा गुणों का अवलोकन

एक सीमित on-path attacker एक off-path attacker है जो server और client के बीच मूल packets को duplicate और forward करके packets की बेहतर routing प्रदान करता है, जिससे ये packets मूल copies से पहले पहुँचते हैं ताकि मूल packets destination endpoint द्वारा drop कर दिए जाएं।

एक सीमित on-path attacker एक on-path attacker से इस मायने में भिन्न होता है कि यह endpoints के बीच के मूल path पर नहीं होता, और इसलिए किसी endpoint द्वारा भेजे गए मूल packets अभी भी अपने गंतव्य तक पहुंच रहे होते हैं। इसका मतलब यह है कि भविष्य में copied packets को उनके मूल path से तेज़ी से destination तक route करने में विफलता मूल packets को गंतव्य तक पहुंचने से नहीं रोकेगी।

एक सीमित on-path attacker कर सकता है:

• पैकेट्स का निरीक्षण करें

• नए packets inject करें

• अनएन्क्रिप्टेड packet headers को संशोधित करें

• पैकेट्स को पुनः क्रमबद्ध करना

एक सीमित on-path हमलावर निम्नलिखित नहीं कर सकता:

• पैकेट्स को देरी करें ताकि वे मूल पथ पर भेजे गए पैकेट्स की तुलना में बाद में पहुंचें

• पैकेट ड्रॉप करें

• पैकेट के प्रमाणित और एन्क्रिप्टेड हिस्से को संशोधित करना और प्राप्तकर्ता को उस पैकेट को स्वीकार करने के लिए प्रेरित करना

एक सीमित on-path हमलावर केवल packets को उस बिंदु तक देरी कर सकता है जब तक कि मूल packets डुप्लिकेट packets से पहले नहीं पहुंच जाते, जिसका मतलब यह है कि यह मूल path से अधिक विलंबता के साथ routing प्रदान नहीं कर सकता। यदि एक सीमित on-path हमलावर packets को drop करता है, तो मूल copy अभी भी गंतव्य endpoint पर पहुंच जाएगी।

QUIC का लक्ष्य एक सीमित off-path आक्रमणकारी की क्षमताओं को निम्नलिखित तरीकों से बाधित करना है:

1. एक सीमित on-path attacker handshake पूरा होने के बाद connection को बंद नहीं कर सकता।

2. एक सीमित on-path attacker निष्क्रिय कनेक्शन को बंद नहीं कर सकता यदि क्लाइंट गतिविधि फिर से शुरू करने वाला पहला है।

3. एक सीमित ऑन-पाथ आक्रमणकारी एक निष्क्रिय कनेक्शन को खोया हुआ मानने का कारण बन सकता है यदि सर्वर गतिविधि को फिर से शुरू करने वाला पहला है।

ध्यान दें कि ये गारंटी वही गारंटी हैं जो किसी भी NAT के लिए प्रदान की जाती हैं, समान कारणों से।

हैंडशेक

एक encrypted और authenticated transport के रूप में, QUIC denial of service के खिलाफ कई सुरक्षा प्रदान करता है। एक बार cryptographic handshake पूरा हो जाने के बाद, QUIC endpoints अधिकांश packets को discard कर देते हैं जो authenticated नहीं हैं, जिससे आक्रमणकारी की मौजूदा connections में हस्तक्षेप करने की क्षमता काफी सीमित हो जाती है।

एक बार connection स्थापित हो जाने के बाद, QUIC endpoints कुछ unauthenticated ICMP packets को स्वीकार कर सकते हैं (देखें Section 14.2.1), लेकिन इन packets का उपयोग अत्यंत सीमित है। केवल एक अन्य प्रकार का packet जिसे एक endpoint स्वीकार कर सकता है वह stateless reset (Section 10.3) है, जो token को तब तक गुप्त रखने पर निर्भर करता है जब तक कि इसका उपयोग न किया जाए।

कनेक्शन बनाने के दौरान, QUIC केवल नेटवर्क पाथ से बाहर के हमलों से सुरक्षा प्रदान करता है। सभी QUIC पैकेट्स में इस बात का प्रमाण होता है कि प्राप्तकर्ता ने अपने peer से पहले का पैकेट देखा था।

handshake के दौरान पते बदले नहीं जा सकते, इसलिए endpoints उन packets को discard कर सकते हैं जो किसी अलग network path पर प्राप्त होते हैं।

Source और Destination Connection ID फील्ड handshake के दौरान off-path attack के विरुद्ध सुरक्षा के प्राथमिक साधन हैं; देखें Section 8.1। इन्हें peer द्वारा सेट किए गए मानों से मैच करना आवश्यक है। Initial और Stateless Resets को छोड़कर, एक endpoint केवल उन packets को स्वीकार करता है जिनमें Destination Connection ID फील्ड शामिल है जो endpoint द्वारा पहले चुने गए मान से मैच करता है। यही Version Negotiation packets के लिए प्रदान की जाने वाली एकमात्र सुरक्षा है।

एक Initial packet में Destination Connection ID फ़ील्ड को client द्वारा अप्रत्याशित होने के लिए चुना जाता है, जो एक अतिरिक्त उद्देश्य पूरा करता है। वे packets जो cryptographic handshake को carry करते हैं, एक key से सुरक्षित होते हैं जो इस connection ID और QUIC version के लिए विशिष्ट salt से derive की जाती है। यह endpoints को उन packets को authenticate करने के लिए वही process उपयोग करने की अनुमति देता है जो वे receive करते हैं, जैसा कि वे cryptographic handshake पूरा होने के बाद उपयोग करते हैं। जिन packets को authenticate नहीं किया जा सकता उन्हें discard कर दिया जाता है। इस तरीके से packets को protect करना एक मजबूत आश्वासन प्रदान करता है कि packet के sender ने Initial packet को देखा था और इसे समझा था।

ये सुरक्षा उपाय उस attacker के विरुद्ध प्रभावी होने के लिए नहीं बनाए गए हैं जो connection स्थापित होने से पहले QUIC packets प्राप्त करने में सक्षम हो। ऐसा attacker संभावित रूप से ऐसे packets भेज सकता है जो QUIC endpoints द्वारा स्वीकार कर लिए जाएंगे। QUIC का यह version इस प्रकार के attack का पता लगाने का प्रयास करता है, लेकिन यह अपेक्षा करता है कि endpoints recover करने के बजाय connection स्थापित करने में असफल हो जाएंगे। अधिकांशतः, cryptographic handshake protocol QUIC-TLS handshake के दौरान tampering का पता लगाने के लिए जिम्मेदार है।

Endpoints को handshake के साथ हस्तक्षेप का पता लगाने और उससे recover होने का प्रयास करने के लिए अन्य methods का उपयोग करने की अनुमति है। Invalid packets की पहचान की जा सकती है और उन्हें अन्य methods का उपयोग करके discard किया जा सकता है, लेकिन इस document में कोई specific method अनिवार्य नहीं है।

एम्प्लिफिकेशन-रोधी

एक आक्रमणकारी किसी सर्वर से एक address validation token (Section 8) प्राप्त कर सकता है और फिर उस IP address को छोड़ सकता है जिसका उसने उस token को प्राप्त करने के लिए उपयोग किया था। बाद में, आक्रमणकारी इसी address को spoof करके सर्वर के साथ 0-RTT connection शुरू कर सकता है, जो अब एक अलग (पीड़ित) endpoint को address कर सकता है। इस प्रकार आक्रमणकारी संभावित रूप से सर्वर को पीड़ित की ओर initial congestion window के बराबर डेटा भेजने के लिए प्रेरित कर सकता है।

सर्वर को इस attack के लिए mitigations प्रदान करने चाहिए address validation tokens के usage और lifetime को सीमित करके; देखें Section 8.1.3।

सर्वर-साइड DoS

एक endpoint जो उन packets को acknowledge करता है जिन्हें उसने प्राप्त नहीं किया है, वह congestion controller को network की सपोर्ट से अधिक दरों पर भेजने की अनुमति दे सकता है। एक endpoint इस व्यवहार का पता लगाने के लिए packets भेजते समय packet numbers को skip कर सकता है। तब एक endpoint तुरंत connection को PROTOCOL_VIOLATION प्रकार की connection error के साथ बंद कर सकता है; Section 10.2 देखें।

ऑन-पाथ हैंडशेक टर्मिनेशन

एक request forgery attack तब होता है जब कोई endpoint अपने peer को पीड़ित की ओर एक request जारी करने के लिए प्रेरित करता है, जिस request को endpoint द्वारा नियंत्रित किया जाता है। Request forgery attacks का लक्ष्य आक्रमणकारी को अपने peer की उन क्षमताओं तक पहुंच प्रदान करना है जो अन्यथा आक्रमणकारी के लिए अनुपलब्ध हो सकती हैं। एक networking protocol के लिए, request forgery attack का उपयोग अक्सर network में peer की स्थिति के कारण पीड़ित द्वारा peer को दी गई किसी भी implicit authorization का शोषण करने के लिए किया जाता है।

request forgery के प्रभावी होने के लिए, आक्रमणकारी को इस बात को प्रभावित करने में सक्षम होना चाहिए कि peer कौन से packets भेजता है और ये packets कहाँ भेजे जाते हैं। यदि आक्रमणकारी किसी vulnerable service को नियंत्रित payload के साथ target कर सकता है, तो वह service ऐसी कार्रवाइयाँ कर सकती है जो आक्रमणकारी के peer से जुड़ी होती हैं लेकिन आक्रमणकारी द्वारा निर्धारित होती हैं।

उदाहरण के लिए, Web पर cross-site request forgery CSRF exploits एक client को ऐसे requests जारी करने के लिए प्रेरित करते हैं जिनमें authorization cookies COOKIE शामिल होते हैं, जिससे एक site को उस जानकारी और कार्यों तक पहुंच मिल जाती है जो किसी अलग site के लिए प्रतिबंधित होने का इरादा था।

चूंकि QUIC, UDP पर चलता है, मुख्य चिंता का हमला तरीका वह है जहां एक आक्रमणकारी उस पते का चयन कर सकता है जिस पर उसका peer UDP datagrams भेजता है और उन packets की कुछ असुरक्षित सामग्री को नियंत्रित कर सकता है। चूंकि QUIC endpoints द्वारा भेजा गया अधिकांश डेटा सुरक्षित होता है, इसमें ciphertext पर नियंत्रण शामिल है। एक हमला तब सफल होता है जब आक्रमणकारी peer को ऐसे host को UDP datagram भेजने के लिए मजबूर कर सकता है जो datagram की सामग्री के आधार पर कोई कार्रवाई करेगा।

यह खंड उन तरीकों पर चर्चा करता है जिनमें QUIC का उपयोग request forgery attacks के लिए किया जा सकता है।

यह अनुभाग सीमित प्रतिकार उपायों का भी वर्णन करता है जिन्हें QUIC endpoints द्वारा लागू किया जा सकता है। इन शमन उपायों को QUIC implementation या deployment द्वारा एकतरफा रूप से नियोजित किया जा सकता है, बिना request forgery attacks के संभावित लक्ष्यों के कार्रवाई करने के। हालांकि, यदि UDP-based सेवाएं requests को ठीक से authorize नहीं करती हैं तो ये प्रतिकार उपाय अपर्याप्त हो सकते हैं।

क्योंकि Section 21.5.4 में वर्णित migration attack काफी शक्तिशाली है और इसके पास पर्याप्त countermeasures नहीं हैं, QUIC server implementations को यह मान लेना चाहिए कि attackers उनसे arbitrary destinations पर arbitrary UDP payloads generate करवा सकते हैं। QUIC servers को उन networks में deploy नहीं करना चाहिए जो ingress filtering BCP38 deploy नहीं करते हैं और जिनमें अपर्याप्त रूप से सुरक्षित UDP endpoints हैं।

यद्यपि यह सुनिश्चित करना सामान्यतः संभव नहीं है कि clients असुरक्षित endpoints के साथ co-located नहीं हैं, QUIC का यह version servers को migrate करने की अनुमति नहीं देता, इस प्रकार clients पर spoofed migration attacks को रोकता है। कोई भी भविष्य का extension जो server migration की अनुमति देता है, उसे forgery attacks के लिए countermeasures भी परिभाषित करना चाहिए।

पैरामीटर नेगोसिएशन

QUIC एक आक्रमणकारी को अपने peer द्वारा UDP datagrams भेजने के स्थान को प्रभावित या नियंत्रित करने के कुछ अवसर प्रदान करता है:

• प्रारंभिक कनेक्शन स्थापना (Section 7), जहाँ एक server यह चुनने में सक्षम होता है कि client datagrams कहाँ भेजे – उदाहरण के लिए, DNS records को populate करके;

• पसंदीदा पते (धारा 9.6), जहाँ एक सर्वर यह चुनने में सक्षम होता है कि क्लाइंट डेटाग्राम कहाँ भेजता है;

• स्पूफ़्ड कनेक्शन माइग्रेशन (Section 9.3.1), जहाँ एक client source address spoofing का उपयोग करके यह चुन सकता है कि server बाद के datagrams कहाँ भेजे; और

• स्पूफ किए गए पैकेट जो सर्वर को Version Negotiation पैकेट भेजने का कारण बनते हैं (Section 21.5.5)।

सभी मामलों में, आक्रमणकारी अपने peer को एक victim के पास datagrams भेजने के लिए मजबूर कर सकता है जो QUIC को समझ नहीं सकता। यानी, ये packets peer द्वारा address validation से पहले भेजे जाते हैं; Section 8 देखें।

पैकेट्स के एन्क्रिप्टेड हिस्से के बाहर, QUIC एक endpoint को अपने peer द्वारा भेजे गए UDP datagrams की सामग्री को नियंत्रित करने के लिए कई विकल्प प्रदान करता है। Destination Connection ID फील्ड peer द्वारा भेजे गए पैकेट्स में जल्दी दिखने वाले bytes पर सीधा नियंत्रण प्रदान करता है; धारा 5.1 देखें। Initial पैकेट्स में Token फील्ड server को Initial पैकेट्स के अन्य bytes पर नियंत्रण प्रदान करता है; धारा 17.2.2 देखें।

QUIC के इस संस्करण में packets के encrypted हिस्सों पर अप्रत्यक्ष नियंत्रण को रोकने के लिए कोई उपाय नहीं हैं। यह मान लेना आवश्यक है कि endpoints उन frames की सामग्री को नियंत्रित करने में सक्षम हैं जो एक peer भेजता है, विशेष रूप से वे frames जो application data प्रदान करते हैं, जैसे STREAM frames। यद्यपि यह कुछ हद तक application protocol के विवरण पर निर्भर करता है, कई protocol उपयोग संदर्भों में कुछ नियंत्रण संभव है। चूंकि आक्रमणकारी के पास packet protection keys तक पहुंच है, वे संभावित रूप से भविष्यवाणी करने में सक्षम हैं कि एक peer भविष्य के packets को कैसे encrypt करेगा। Datagram content पर सफल नियंत्रण के लिए फिर केवल यह आवश्यक है कि आक्रमणकारी packet number और packets में frames के placement की कुछ मात्रा की विश्वसनीयता के साथ भविष्यवाणी करने में सक्षम हो।

यह खंड यह मानता है कि datagram सामग्री पर नियंत्रण सीमित करना संभव नहीं है। बाद के खंडों में शमन (mitigations) का फोकस उन तरीकों को सीमित करने पर है जिनसे address validation से पहले भेजे गए datagrams का उपयोग request forgery के लिए किया जा सकता है।

संरक्षित पैकेट्स

एक attacker जो server के रूप में कार्य कर रहा है, वह IP address और port चुन सकता है जिस पर वह अपनी उपलब्धता का विज्ञापन करता है, इसलिए clients से Initial packets इस प्रकार के हमले में उपयोग के लिए उपलब्ध माने जाते हैं। handshake में निहित address validation यह सुनिश्चित करता है कि – एक नए connection के लिए – एक client किसी ऐसे destination को अन्य प्रकार के packets नहीं भेजेगा जो QUIC को समझता नहीं है या QUIC connection को स्वीकार करने के लिए तैयार नहीं है।

Initial packet protection (QUIC-TLS का Section 5.2) servers के लिए clients द्वारा भेजे गए Initial packets की content को control करना कठिन बना देता है। एक client जो unpredictable Destination Connection ID चुनता है यह सुनिश्चित करता है कि servers clients से आने वाले Initial packets के encrypted portion के किसी भी हिस्से को control करने में असमर्थ हों।

हालांकि, Token फ़ील्ड server control के लिए खुला है और यह server को clients का उपयोग करके request forgery attacks को mount करने की अनुमति देता है। NEW_TOKEN frame (Section 8.1.3) के साथ प्रदान किए गए tokens का उपयोग connection establishment के दौरान request forgery के लिए एकमात्र विकल्प प्रदान करता है।

हालांकि, clients का NEW_TOKEN frame का उपयोग करना अनिवार्य नहीं है। Token field पर निर्भर request forgery attacks से बचा जा सकता है यदि clients एक खाली Token field भेजते हैं जब server address बदल गया हो जब NEW_TOKEN frame प्राप्त हुआ था।

क्लाइंट्स NEW_TOKEN का उपयोग करने से बच सकते हैं यदि सर्वर पता बदल जाता है। हालांकि, Token फील्ड को शामिल न करना प्रदर्शन पर प्रतिकूल प्रभाव डाल सकता है। सर्वर NEW_TOKEN पर निर्भर हो सकते हैं ताकि डेटा भेजने की तीन-गुना सीमा से अधिक डेटा भेजने को सक्षम किया जा सके; देखें Section 8.1। विशेष रूप से, यह उन मामलों को प्रभावित करता है जहां क्लाइंट्स सर्वर से डेटा का अनुरोध करने के लिए 0-RTT का उपयोग करते हैं।

Retry पैकेट (धारा 17.2.5) भेजना सर्वर को Token फ़ील्ड बदलने का विकल्प प्रदान करता है। Retry भेजने के बाद, सर्वर क्लाइंट से आने वाले बाद के Initial पैकेट्स के Destination Connection ID फ़ील्ड को भी नियंत्रित कर सकता है। यह Initial पैकेट्स की एन्क्रिप्टेड सामग्री पर अप्रत्यक्ष नियंत्रण की भी अनुमति दे सकता है। हालांकि, Retry पैकेट का आदान-प्रदान सर्वर के पते को मान्य करता है, जिससे अनुरोध जालसाजी के लिए बाद के Initial पैकेट्स के उपयोग को रोका जा सकता है।

कनेक्शन माइग्रेशन

सर्वर एक प्राथमिक पता निर्दिष्ट कर सकते हैं, जिसके बाद क्लाइंट handshake की पुष्टि करने के बाद उस पते पर migrate हो जाते हैं; देखें Section 9.6। पैकेट का Destination Connection ID field जो क्लाइंट प्राथमिक पते पर भेजता है, उसका उपयोग request forgery के लिए किया जा सकता है।

एक client को validated करने से पहले preferred address पर non-probing frames नहीं भेजने चाहिए; Section 8 देखें। यह उन विकल्पों को काफी कम कर देता है जो एक server के पास datagrams के encrypted portion को control करने के लिए होते हैं।

यह दस्तावेज़ preferred addresses के उपयोग के लिए विशिष्ट कोई अतिरिक्त प्रतिउपाय प्रदान नहीं करता है जो endpoints द्वारा लागू किए जा सकें। Section 21.5.6 में वर्णित सामान्य उपाय आगे की रक्षा के रूप में उपयोग किए जा सकते हैं।

ऑन-पाथ सक्रिय हमले

क्लाइंट एक स्पूफ़्ड स्रोत पता प्रस्तुत करने में सक्षम हैं जो एक स्पष्ट कनेक्शन माइग्रेशन के हिस्से के रूप में सर्वर को उस पते पर डेटाग्राम भेजने का कारण बनता है।

किसी भी server द्वारा इस spoofed address पर बाद में भेजे जाने वाले packets में Destination Connection ID field का उपयोग request forgery के लिए किया जा सकता है। एक client भी ciphertext को प्रभावित करने में सक्षम हो सकता है।

एक server जो address validation से पहले किसी address पर केवल probing packets (Section 9.1) भेजता है, वह attacker को datagrams के encrypted portion पर केवल सीमित control प्रदान करता है। हालांकि, विशेष रूप से NAT rebinding के लिए, यह performance को प्रतिकूल रूप से प्रभावित कर सकता है। यदि server application data वाले frames भेजता है, तो एक attacker datagrams की अधिकांश content को control करने में सक्षम हो सकता है।

यह दस्तावेज़ endpoints द्वारा लागू किए जा सकने वाले विशिष्ट प्रतिरोधी उपायों की पेशकश नहीं करता, Section 21.5.6 में वर्णित सामान्य उपायों के अलावा। हालांकि, network स्तर पर address spoofing के लिए प्रतिरोधी उपाय – विशेष रूप से, ingress filtering BCP38 – उन आक्रमणों के विरुद्ध विशेष रूप से प्रभावी हैं जो spoofing का उपयोग करते हैं और बाहरी network से उत्पन्न होते हैं।

ऑफ-पाथ सक्रिय हमले

जो clients पैकेट पर spoofed source address प्रस्तुत करने में सक्षम हैं, वे server को उस address पर Version Negotiation packet (Section 17.2.1) भेजने का कारण बन सकते हैं।

अज्ञात version के packets के लिए connection ID fields पर size restrictions की अनुपस्थिति resulting datagram से client द्वारा नियंत्रित data की मात्रा को बढ़ाती है। इस packet का पहला byte client के नियंत्रण में नहीं है और अगले चार bytes शून्य हैं, लेकिन client पांचवें byte से शुरू करके 512 bytes तक को नियंत्रित कर सकता है।

इस हमले के लिए कोई विशिष्ट प्रतिरोधी उपाय प्रदान नहीं किए गए हैं, हालांकि सामान्य सुरक्षा उपाय (Section 21.5.6) लागू हो सकते हैं। इस मामले में, ingress filtering BCP38 भी प्रभावी है।

सीमित ऑन-पाथ सक्रिय हमले

request forgery attacks के विरुद्ध सबसे प्रभावी रक्षा vulnerable services को strong authentication का उपयोग करने के लिए संशोधित करना है। हालांकि, यह हमेशा QUIC deployment के नियंत्रण में नहीं होता है। यह खंड कुछ अन्य कदमों की रूपरेखा प्रस्तुत करता है जो QUIC endpoints एकतरफा रूप से उठा सकते हैं। ये सभी अतिरिक्त कदम विवेकाधीन हैं क्योंकि, परिस्थितियों के आधार पर, ये वैध उपयोगों में हस्तक्षेप कर सकते हैं या उन्हें रोक सकते हैं।

loopback interfaces पर प्रदान की जाने वाली सेवाओं में अक्सर उचित authentication का अभाव होता है। Endpoints loopback address पर connection attempts या migration को रोक सकते हैं। यदि वही सेवा पहले किसी अलग interface पर उपलब्ध थी या यदि address किसी non-loopback address पर स्थित सेवा द्वारा प्रदान किया गया था, तो Endpoints को loopback address पर connections या migration की अनुमति नहीं देनी चाहिए। जो Endpoints इन क्षमताओं पर निर्भर हैं, वे इन सुरक्षा उपायों को निष्क्रिय करने का विकल्प प्रदान कर सकते हैं।

इसी प्रकार, endpoints एक link-local address RFC4291 या private-use range RFC1918 में एक address के बदलाव को global, unique-local RFC4193, या non-private address से request forgery के संभावित प्रयास के रूप में मान सकते हैं। Endpoints इन addresses का उपयोग पूरी तरह से मना कर सकते हैं, लेकिन इससे वैध उपयोगों में हस्तक्षेप का महत्वपूर्ण जोखिम होता है। Endpoints को किसी address का उपयोग करने से मना नहीं करना चाहिए जब तक कि उनके पास network के बारे में विशिष्ट जानकारी न हो जो यह दर्शाती हो कि किसी दिए गए range में unvalidated addresses पर datagrams भेजना सुरक्षित नहीं है।

Endpoints अपने Initial packets में NEW_TOKEN frames से values को शामिल न करके या address validation पूरा करने से पहले packets में केवल probing frames भेजकर request forgery के जोखिम को कम करने का विकल्प चुन सकते हैं। ध्यान दें कि यह एक attacker को attack के लिए Destination Connection ID field का उपयोग करने से नहीं रोकता है।

Endpoints से यह अपेक्षा नहीं की जाती कि उनके पास उन servers के स्थान की विशिष्ट जानकारी हो जो request forgery attack के संवेदनशील लक्ष्य हो सकते हैं। हालांकि, समय के साथ विशिष्ट UDP ports की पहचान करना संभव हो सकता है जो attacks के सामान्य लक्ष्य हैं या datagrams में विशेष patterns जो attacks के लिए उपयोग किए जाते हैं। Endpoints इन ports पर datagrams भेजने से बचने का विकल्प चुन सकते हैं या destination address को validate करने से पहले उन datagrams को नहीं भेज सकते जो इन patterns से मेल खाते हैं। Endpoints उन connection IDs को बिना उपयोग किए retire कर सकते हैं जिनमें समस्याजनक patterns हैं।

नोट: इन सुरक्षाओं को लागू करने के लिए endpoints को संशोधित करना network-based सुरक्षाओं को तैनात करने की तुलना में अधिक कुशल है, क्योंकि endpoints को किसी भी validated address पर भेजते समय कोई अतिरिक्त processing करने की आवश्यकता नहीं होती।

हैंडशेक डिनायल ऑफ सर्विस

आमतौर पर Slowloris SLOWLORIS के नाम से जाने जाने वाले हमले लक्षित endpoint के साथ कई कनेक्शन खुले रखने की कोशिश करते हैं और उन्हें यथासंभव लंबे समय तक खुला रखते हैं। ये हमले QUIC endpoint के विरुद्ध निष्क्रियता के कारण बंद होने से बचने के लिए आवश्यक न्यूनतम गतिविधि उत्पन्न करके किए जा सकते हैं। इसमें थोड़ी मात्रा में डेटा भेजना, sender rate को नियंत्रित करने के लिए धीरे-धीरे flow control windows खोलना, या उच्च loss rate का अनुकरण करने वाले ACK frames का निर्माण करना शामिल हो सकता है।

QUIC deployments को Slowloris attacks के लिए सुरक्षा उपाय प्रदान करने चाहिए, जैसे कि server द्वारा अनुमतित clients की अधिकतम संख्या बढ़ाना, एक single IP address को बनाने की अनुमति देने वाले connections की संख्या को सीमित करना, एक connection को न्यूनतम transfer speed पर प्रतिबंध लगाना, और एक endpoint को connected रहने की अनुमति देने के समय की लंबाई को प्रतिबंधित करना।

Amplification Attack

एक विरोधी sender जानबूझकर stream data के हिस्सों को नहीं भेज सकता है, जिससे receiver को न भेजे गए data के लिए resources commit करने पड़ सकते हैं। इससे receiver पर असमानुपातिक receive buffer memory commitment और/या एक बड़ी और अकुशल data structure का निर्माण हो सकता है।

एक प्रतिकूल receiver जानबूझकर stream data वाले packets को acknowledge नहीं कर सकता है ताकि sender को retransmission के लिए unacknowledged stream data को store करने पर मजबूर किया जा सके।

प्राप्तकर्ताओं पर हमला तब कम हो जाता है जब flow control windows उपलब्ध मेमोरी के अनुरूप होती हैं। हालांकि, कुछ प्राप्तकर्ता मेमोरी को overcommit करेंगे और कुल मिलाकर ऐसे flow control offsets का विज्ञापन करेंगे जो वास्तविक उपलब्ध मेमोरी से अधिक हों। overcommitment रणनीति बेहतर प्रदर्शन का कारण बन सकती है जब endpoints अच्छा व्यवहार करते हैं, लेकिन endpoints को stream fragmentation attack के लिए असुरक्षित बना देती है।

QUIC deployments में stream fragmentation attacks के लिए mitigations प्रदान करनी चाहिए। Mitigations में memory को overcommit करने से बचना, tracking data structures के size को सीमित करना, STREAM frames की reassembly को delay करना, reassembly holes की age और duration के आधार पर heuristics implement करना, या इनमें से कुछ combination शामिल हो सकती है।

Optimistic ACK Attack

एक adversarial endpoint बड़ी संख्या में streams खोल सकता है, जो एक endpoint पर state को समाप्त कर देता है। adversarial endpoint इस प्रक्रिया को बड़ी संख्या में connections पर दोहरा सकता है, TCP में SYN flooding attacks के समान तरीके से।

सामान्यतः, clients streams को क्रमानुसार खोलेंगे, जैसा कि Section 2.1 में समझाया गया है। हालांकि, जब कई streams छोटे अंतराल पर शुरू किए जाते हैं, तो loss या reordering के कारण STREAM frames जो streams खोलते हैं, sequence से बाहर प्राप्त हो सकते हैं। उच्च-संख्या वाली stream ID प्राप्त करने पर, receiver को समान प्रकार की सभी बीच वाली streams खोलने की आवश्यकता होती है; देखें Section 3.2। इस प्रकार, एक नए connection पर, stream 4000000 खोलने से 1 million और 1 client-initiated bidirectional streams खुल जाती हैं।

सक्रिय streams की संख्या initial_max_streams_bidi और initial_max_streams_uni transport parameters द्वारा सीमित होती है जो किसी भी प्राप्त MAX_STREAMS frames द्वारा अपडेट होती है, जैसा कि Section 4.6 में समझाया गया है। यदि समझदारी से चुना जाए, तो ये सीमाएं stream commitment attack के प्रभाव को कम करती हैं। हालांकि, सीमा को बहुत कम सेट करना performance को प्रभावित कर सकता है जब applications बड़ी संख्या में streams खोलने की अपेक्षा करती हैं।

Request Forgery Attacks का हिंदी अनुवाद:

Request Forgery हमले

QUIC और TLS दोनों में frames या messages होते हैं जिनका कुछ संदर्भों में वैध उपयोग है, लेकिन इन frames या messages का दुरुपयोग किसी peer को processing resources खर्च करने के लिए मजबूर करने में किया जा सकता है, बिना connection की स्थिति पर कोई observable प्रभाव डाले।

संदेशों का उपयोग छोटे या महत्वहीन तरीकों से स्थिति को बदलने और वापस करने के लिए भी किया जा सकता है, जैसे कि flow control limits में छोटी वृद्धि भेजना।

यदि प्रोसेसिंग लागत bandwidth खपत या state पर प्रभाव की तुलना में असंगत रूप से बड़ी है, तो इससे एक malicious peer को प्रोसेसिंग क्षमता समाप्त करने की अनुमति मिल सकती है।

जबकि सभी संदेशों के वैध उपयोग हैं, implementations को प्रगति के सापेक्ष प्रसंस्करण की लागत को ट्रैक करना चाहिए और किसी भी गैर-उत्पादक packets की अत्यधिक मात्रा को एक हमले के संकेत के रूप में मानना चाहिए। Endpoints इस स्थिति का जवाब connection error के साथ या packets को drop करके दे सकते हैं।

एंडपॉइंट्स के लिए नियंत्रण विकल्प

एक on-path attacker IP header में ECN fields के मान को manipulate करके sender की rate को प्रभावित कर सकता है। RFC3168 manipulations और उनके प्रभावों पर अधिक विस्तार से चर्चा करता है।

एक सीमित ऑन-पाथ आक्रमणकारी पैकेट्स को डुप्लिकेट कर सकता है और संशोधित ECN फ़ील्ड के साथ भेज सकता है ताकि भेजने वाले की दर को प्रभावित किया जा सके। यदि डुप्लिकेट पैकेट्स को रिसीवर द्वारा त्याग दिया जाता है, तो आक्रमणकारी को इस हमले में सफल होने के लिए डुप्लिकेट पैकेट को मूल पैकेट के विरुद्ध रेस करना होगा। इसलिए, QUIC एंडपॉइंट्स IP पैकेट में ECN फ़ील्ड को तब तक अनदेखा करते हैं जब तक कि उस IP पैकेट में कम से कम एक QUIC पैकेट सफलतापूर्वक प्रोसेस नहीं हो जाता; देखें Section 13.4।

Client Initial Packets के साथ Request Forgery

Stateless resets एक संभावित denial-of-service हमला बनाते हैं जो TCP reset injection के समान है। यह हमला तब संभव है जब कोई आक्रमणकारी चुने गए connection ID के साथ connection के लिए stateless reset token उत्पन्न करवाने में सक्षम हो। एक आक्रमणकारी जो इस token को उत्पन्न करवा सकता है, वह समान connection ID वाले सक्रिय connection को reset कर सकता है।

यदि एक packet को विभिन्न instances पर route किया जा सकता है जो एक static key साझा करते हैं – उदाहरण के लिए, एक IP address या port को बदलकर – तो एक attacker server को एक stateless reset भेजने के लिए मजबूर कर सकता है। इस प्रकार के denial of service से बचाव के लिए, वे endpoints जो stateless resets के लिए एक static key साझा करते हैं (देखें Section 10.3.2) को इस प्रकार व्यवस्थित किया जाना चाहिए कि दिए गए connection ID वाले packets हमेशा उस instance पर पहुंचें जिसके पास connection state है, जब तक कि वह connection अब active न हो।

अधिक सामान्यतः, servers को stateless reset नहीं generate करना चाहिए यदि संबंधित connection ID के साथ कोई connection किसी भी endpoint पर सक्रिय हो सकता है जो समान static key का उपयोग कर रहा है।

एक cluster के मामले में जो dynamic load balancing का उपयोग करता है, यह संभव है कि load-balancer configuration में परिवर्तन हो सकता है जबकि एक active instance connection state को बनाए रखता है। भले ही एक instance connection state को बनाए रखे, routing में परिवर्तन और परिणामस्वरूप stateless reset के कारण connection समाप्त हो जाएगा। यदि packet के सही instance तक route होने की कोई संभावना नहीं है, तो connection के time out होने का इंतजार करने के बजाय stateless reset भेजना बेहतर है। हालांकि, यह तभी स्वीकार्य है जब routing को किसी attacker द्वारा प्रभावित नहीं किया जा सकता।

पसंदीदा पतों के साथ Request Forgery

यह दस्तावेज़ QUIC Version Negotiation packets (Section 6) को परिभाषित करता है, जिनका उपयोग दो endpoints के बीच प्रयुक्त QUIC version को negotiate करने के लिए किया जा सकता है। हालांकि, यह दस्तावेज़ यह निर्दिष्ट नहीं करता कि इस version और भविष्य के versions के बीच यह negotiation कैसे किया जाएगा। विशेष रूप से, Version Negotiation packets में version downgrade attacks को रोकने के लिए कोई mechanism नहीं है। QUIC के भविष्य के versions जो Version Negotiation packets का उपयोग करते हैं, उन्हें एक ऐसी mechanism define करनी चाहिए जो version downgrade attacks के विरुद्ध मजबूत हो।

स्पूफ्ड Migration के साथ Request Forgery

तैनाती में हमलावर की किसी विशिष्ट server instance के लिए नया connection target करने की क्षमता को सीमित करना चाहिए। आदर्श रूप से, routing के निर्णय client-selected values से स्वतंत्र रूप से लिए जाते हैं, जिसमें addresses भी शामिल हैं। एक बार instance का चयन हो जाने पर, एक connection ID का चयन किया जा सकता है ताकि बाद के packets को उसी instance पर route किया जा सके।

Version Negotiation के साथ Request Forgery

QUIC packets की लंबाई उन packets के content की लंबाई के बारे में जानकारी प्रकट कर सकती है। PADDING frame इसलिए प्रदान किया गया है ताकि endpoints के पास packet content की लंबाई को छुपाने की कुछ क्षमता हो; देखें Section 19.1।

ट्रैफिक विश्लेषण को हराना चुनौतीपूर्ण है और सक्रिय अनुसंधान का विषय है। लंबाई एकमात्र तरीका नहीं है जिससे जानकारी लीक हो सकती है। Endpoints पैकेट की timing जैसे अन्य side channels के माध्यम से भी संवेदनशील जानकारी का खुलासा कर सकते हैं।

Relay Security

निम्नलिखित SSU1 में Relay Request, Relay Response, Relay Intro, और Hole Punch का विश्लेषण है।

बाधाएं: यह महत्वपूर्ण है कि Relays तेज़ हों। Round trips को कम से कम रखा जाना चाहिए। Bandwidth और CPU उतने महत्वपूर्ण नहीं हैं।

SSU 1: Alice पहले introducer Bob से जुड़ती है, जो request को Charlie (जो firewalled है) तक relay करता है। Hole punch के बाद, session Alice और Charlie के बीच establish हो जाता है जैसे कि direct establishment में होता है।

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

Authentication: Relay Request और Relay Response सुरक्षित रूप से अप्रमाणित नहीं हैं, क्योंकि Alice और Bob के पास आमतौर पर कोई मौजूदा session नहीं होता; ये messages प्रकाशित intro keys का उपयोग करते हैं। In-session Relay Request/Response की अनुमति है और यदि कोई session मौजूद है तो इसे प्राथमिकता दी जाती है।

Bob से Charlie तक Relay Intro मौजूदा session में होना आवश्यक है, इसलिए इसे सुरक्षित माना जाता है।

Bob Relay Intros को spoof कर सकता है या Relay Request से IP/port को बदल सकता है। requests को intros के साथ cryptographically bind करने या दुर्भावनापूर्ण Bobs को रोकने या detect करने के लिए कोई mechanisms नहीं हैं।

Bob का router hash वर्तमान में Charlie के Router Info में प्रकाशित नहीं है, इसलिए यदि हम Alice-Bob संदेशों को authenticated करना चाहते हैं तो इसे जोड़ना होगा। इसके अतिरिक्त, अन्य SSU2 parameters को Charlie के Router Info में प्रकाशित करना होगा, या Alice को network database में Bob के Router Info को lookup करना होगा, जिससे अतिरिक्त देरी होगी। Authentication से Alice और Bob के बीच एक round-trip जुड़ जाएगा।

Alice के router hash को Charlie को forward करके, Charlie अधिक आसानी से निर्धारित कर सकता है कि वह Alice से कनेक्शन प्राप्त करना चाहता है या नहीं, स्थानीय ban list की जांच करके। Charlie के पास Bob के माध्यम से Alice को rejection भेजकर relay को अस्वीकार करने का कोई mechanism नहीं है। Charlie के पास Bob के माध्यम से Alice को acceptance भेजकर relay को स्वीकार करने का कोई mechanism नहीं है। Alice को HolePunch का इंतज़ार करना चाहिए, या बस SessionRequest को blindly भेजना चाहिए। HolePunch NAT के कारण Alice के अपेक्षित port से भिन्न port से आ सकता है, जिससे यह पहचानना कठिन हो सकता है कि HolePunch किस router से आया है।

Alice अपनी पूरी Router Info को Bob को Relay Request में भेज सकती है, और Charlie को Relay Intro में forward कर सकती है।

Relay Request में timestamp नहीं होता है, इसलिए इसमें replay prevention नहीं है। source IP को spoof किया जा सकता है, ताकि Charlie को किसी भी IP/port पर Hole Punch भेजने के लिए मजबूर किया जा सके। Relay Request signed नहीं होता है, और भले ही यह signed और timestamped हो, Charlie के पास signature को verify करने के लिए पूरी Router Identity नहीं होती है।

प्रोटोकॉल 0-255 बाइट्स की परिवर्तनीय लंबाई का एक challenge फ़ील्ड परिभाषित करता है। Relay Request में challenge को Relay Intro में Charlie को पास किया जाता है। हालांकि, प्रोटोकॉल यह निर्दिष्ट नहीं करता कि challenge को कैसे बनाया, उपयोग किया या सत्यापित किया जाए, और यह अनिम्प्लिमेंटेड है। यदि HolePunch में challenge होता, तो Alice आसानी से HolePunch को Charlie के साथ सहसंबद्ध कर सकती।

चार बाइट nonce को 8-बाइट connection ID से बदलने या पूरक करने की आवश्यकता हो सकती है।

खाली Hole Punch संदेश अनूठा है और मार्ग पर स्थित पर्यवेक्षकों द्वारा प्रोटोकॉल की पहचान के लिए उपयोग किया जा सकता है, इसे बदला जाना चाहिए।

अतिरिक्त DPI चर्चा

निम्नलिखित SSU1 में Peer Test का विश्लेषण है।

बाधाएं: यह विशेष रूप से महत्वपूर्ण नहीं है कि Peer Tests तेज़ हों, या कम-बैंडविड्थ हों, या कम-CPU हों, सिवाय शायद router startup पर, जहाँ हम प्राथमिकता देते हैं कि router अपनी reachability को काफी जल्दी discover करे।

SSU 1:

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

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

क्योंकि SSU1 specification का पालन करना कठिन है, हम नीचे message contents को document करते हैं।

Bob एक Charlie का चयन करता है जिसके साथ उसका मौजूदा session है। Message 2 और 3 को in-session भेजा जाता है। इसलिए, message 2 और 3 secure और authenticated हैं।

Message 4 को in-session भेजा जाना चाहिए; हालांकि, SSU 1 specification पहले कहती थी कि यह Alice की published intro key के साथ भेजा जाता है, जिसका मतलब है not in-session। 0.9.52 से पहले, Java I2P intro key के साथ भेजता था। 0.9.52 के रूप में, specification बताती है कि session key का उपयोग किया जाना चाहिए, और Java I2P 0.9.52 के रूप से message को in-session भेजता है।

Alice का Charlie के साथ पहले से कोई existing session नहीं होना चाहिए ताकि test आगे बढ़ सके; यदि Bob एक ऐसा Charlie चुनता है जिसका Alice के साथ session है तो Alice test को abort कर देती है। इसलिए, messages 5-7 secure और authenticated नहीं हैं।

सभी Peer Test संदेशों में एक 4-byte nonce होता है जो Alice द्वारा चुना जाता है। यह nonce cryptographically उपयोग नहीं किया जाता है।

संदेशों 5-7 पर संभावित हमले: अनुसंधान की आवश्यकता है।

Alice का router hash Charlie को ज्ञात नहीं है। Charlie का router hash Alice को ज्ञात नहीं है। यदि हम चाहते हैं कि Alice-Charlie संदेश प्रमाणित हों तो उन्हें प्रोटोकॉल में जोड़ना होगा। इसके अतिरिक्त, अन्य SSU2 पैरामीटर को Peer Test संदेशों में प्रदान करना होगा, या Charlie को network database में Alice की Router Info खोजनी होगी, जिससे अतिरिक्त देरी होगी। Authentication से Charlie और Alice के बीच एक अतिरिक्त round-trip जुड़ेगा।

Alice के router hash को Charlie को forward करके, Charlie अधिक आसानी से निर्धारित कर सकता है कि वह Alice के साथ Peer Test में भाग लेना चाहता है या नहीं, local ban list की जांच करके।

चार बाइट nonce को 8-बाइट connection ID द्वारा प्रतिस्थापित या पूरक करने की आवश्यकता हो सकती है।

Relay and Peer Test Design Goals

Relay और Peer Test के समान निर्माण हैं। दोनों मामलों में, Alice, Bob से Charlie को एक सेवा अनुरोध अग्रेषित करने का अनुरोध करती है, और Charlie फिर उस अनुरोध पर कार्य करता है।

वर्तमान SSU1 Peer Test समस्याएं:

• Peer Test में दुर्भावनापूर्ण Bob के विरुद्ध कोई सुरक्षा नहीं है
• Peer Test में Bob या Charlie के पास request को अस्वीकार करने का कोई तरीका नहीं है
• Peer Test में Alice के लिए Charlie की पहचान जानने का कोई तरीका नहीं है या Alice के लिए Charlie को अस्वीकार करने का कोई तरीका नहीं है
• Peer Test में Charlie के लिए Alice की पहचान जानने का कोई तरीका नहीं है या Charlie के लिए Alice को अस्वीकार करने का कोई तरीका नहीं है
• Peer Test की अपनी ad-hoc retransmission scheme है
• Peer Test को यह जानने के लिए एक जटिल state machine की आवश्यकता होती है कि कौन सा message किस state के लिए है
• यह जाने बिना कि Charlie ने उसे अस्वीकार कर दिया है, Alice test को एक failure मानेगी।

वर्तमान SSU1 Relay समस्याएं:

उपरोक्त सूचीबद्ध अधिकांश Peer Test समस्याएं Peer Test पर भी लागू होती हैं।

हमारे पास Relay और Peer Test की सुरक्षा में सुधार के लिए निम्नलिखित लक्ष्य हैं:

• Charlie को अपने introducers (Bobs) के बारे में netdb में पर्याप्त जानकारी प्रकाशित करनी चाहिए ताकि Alice आवश्यकता पड़ने पर जानकारी को सत्यापित कर सके। उदाहरण के लिए, प्रत्येक introducer के लिए एक router hash प्रकाशित करना Alice को, समय की अनुमति होने पर, netdb से router info प्राप्त करने में सक्षम बनाएगा।

• एड्रेस स्पूफिंग या on-path threats से सुरक्षा प्रदान करना जो Alice से Bob के requests को spoof, alter, forge, या replay कर सकते हैं। Bob को यह सुनिश्चित करना चाहिए कि Alice एक वास्तविक I2P router है और प्रस्तुत किया गया request और test address मान्य है।

• दुर्भावनापूर्ण Bobs से सुरक्षा जो Charlie को भेजे गए requests को spoof, alter, forge, या replay कर सकते हैं। Charlie को यह सुनिश्चित करना चाहिए कि Alice और Bob दोनों वास्तविक I2P routers हैं और प्रस्तुत किया गया request और test address वैध है।

• Bob को Alice से पर्याप्त जानकारी प्राप्त करनी चाहिए ताकि वह अनुरोध को सत्यापित कर सके और फिर उसे स्वीकार या अस्वीकार कर सके। Bob के पास स्वीकृति या अस्वीकृति को वापस Alice को भेजने का तंत्र होना चाहिए। Bob को कभी भी अनुरोधित कार्य करने के लिए बाध्य नहीं होना चाहिए।

• Charlie को Bob से पर्याप्त जानकारी प्राप्त करनी चाहिए ताकि वह अनुरोध को validate कर सके और फिर उसे स्वीकार या अस्वीकार कर सके। Charlie के पास स्वीकृति या अस्वीकृति को Bob को वापस भेजने की व्यवस्था होनी चाहिए, ताकि वह Alice तक पहुंचाई जा सके। Charlie को कभी भी अनुरोधित कार्य को करने की आवश्यकता नहीं होनी चाहिए।

• Alice को यह सत्यापित करने में सक्षम होना चाहिए कि Bob के माध्यम से forwarded किया गया response वास्तव में Charlie से उत्पन्न हुआ था।

• Alice और Charlie को यह सत्यापित करने में सक्षम होना चाहिए कि उनके बाद के प्रत्यक्ष संदेश (Bob के माध्यम से relay नहीं किए गए) अपेक्षित स्रोत से हैं और वास्तविक I2P router हैं।

निम्नलिखित तंत्र इन लक्ष्यों को प्राप्त करने में सहायक हो सकते हैं:

• टाइमस्टैम्प

• router signing key का उपयोग करके signatures

• अनुरोध में शामिल चुनौती डेटा का उपयोग करना

• router encryption key का उपयोग करके एन्क्रिप्शन

• भेजने वाले router hashes, Router Identities, या Router Infos, न कि केवल IPs और ports।

• नेटवर्क डेटाबेस को query करके router जानकारी का सत्यापन

• बैनलिस्ट के विरुद्ध router जानकारी, IPs, और ports की जांच करना

• दर सीमा (Rate limiting)

• सत्र स्थापना की आवश्यकता

ये संभावित तंत्र Relay या Peer Test functions के processing time और latency को बढ़ा सकते हैं। सभी प्रभावों का मूल्यांकन किया जाना चाहिए।

क्रॉस-वर्जन रिलेइंग और पीयर टेस्टिंग का भी समर्थन किया जाना चाहिए यदि संभव हो। यह SSU 1 से SSU 2 में क्रमिक संक्रमण को सुविधाजनक बनाएगा। संभावित वर्जन संयोजन हैं:

सुरक्षा लक्ष्य

Summary

हम प्रेरणा, मार्गदर्शन और कोड पुन: उपयोग के लिए कई मौजूदा protocols पर निर्भर करते हैं, जो I2P के भीतर और बाहरी मानकों दोनों में हैं:

• खतरा मॉडल: NTCP2 NTCP2 से, UDP परिवहन के लिए प्रासंगिक महत्वपूर्ण अतिरिक्त खतरों के साथ जैसा कि QUIC RFC 9000 RFC 9001 द्वारा विश्लेषित किया गया है।

• क्रिप्टोग्राफिक विकल्प: NTCP2 से।

• हैंडशेक: NTCP2 और NOISE से Noise XK। UDP द्वारा प्रदान किए गए encapsulation (अंतर्निहित संदेश सीमाएं) के कारण NTCP2 में महत्वपूर्ण सरलीकरण संभव हैं।

• Handshake ephemeral key obfuscation: NTCP2 से अनुकूलित लेकिन AES के बजाय ECIES से ChaCha20 का उपयोग करते हुए।

• पैकेट हेडर: WireGuard WireGuard और QUIC RFC 9000 RFC 9001 से अनुकूलित।

• Packet header obfuscation: NTCP2 से अनुकूलित लेकिन AES के बजाय ECIES से ChaCha20 का उपयोग करते हुए।

• पैकेट हेडर सुरक्षा: QUIC RFC 9001 और Nonces से अनुकूलित

• Headers का उपयोग AEAD associated data के रूप में किया जाता है जैसा कि ECIES में है।

• पैकेट नंबरिंग: WireGuard WireGuard और QUIC RFC 9000 RFC 9001 से अनुकूलित।

• Messages: SSU से अनुकूलित

• I2NP Fragmentation: SSU से अनुकूलित

• रिले और पीयर टेस्टिंग: SSU से अनुकूलित

• Relay और Peer Test डेटा के हस्ताक्षर: सामान्य संरचना विनिर्देश से Common

• ब्लॉक प्रारूप: NTCP2 और ECIES से।

• Padding और options: NTCP2 और ECIES से।

• Acks, nacks: QUIC RFC 9000 से अनुकूलित।

• Flow control: TBD

I2P में पहले से उपयोग नहीं किए गए कोई नए cryptographic primitives नहीं हैं।

पता सत्यापन

अन्य I2P transports NTCP, NTCP2, और SSU 1 की तरह, यह transport बाइट्स की क्रमबद्ध स्ट्रीम की डिलीवरी के लिए एक सामान्य-उद्देश्य सुविधा नहीं है। यह I2NP messages के transport के लिए डिज़ाइन किया गया है। कोई “stream” abstraction प्रदान नहीं किया गया है।

इसके अतिरिक्त, SSU के समान, इसमें peer-facilitated NAT traversal और reachability (inbound connections) की जांच के लिए अतिरिक्त सुविधाएं शामिल हैं।

SSU 1 के लिए, यह I2NP messages की in-order delivery प्रदान नहीं करता है। न ही यह I2NP messages की guaranteed delivery प्रदान करता है। दक्षता के लिए, या UDP datagrams की out-of order delivery या उन datagrams के नुकसान के कारण, I2NP messages दूर के छोर पर out-of-order पहुंचाए जा सकते हैं, या बिल्कुल भी नहीं पहुंचाए जा सकते हैं। यदि आवश्यक हो तो एक I2NP message को कई बार retransmit किया जा सकता है, लेकिन पूरे connection को disconnect किए बिना delivery अंततः fail हो सकती है। इसके अलावा, जबकि अन्य I2NP messages के लिए retransmission (loss recovery) हो रहा हो, तब भी नए I2NP messages भेजे जाना जारी रह सकता है।

यह protocol I2NP messages की duplicate delivery को पूरी तरह से prevent नहीं करता। Router को I2NP expiration enforce करना चाहिए और I2NP message ID के आधार पर Bloom filter या अन्य mechanism का उपयोग करना चाहिए। नीचे I2NP Message Duplication section देखें।

Noise Protocol Framework

यह प्रस्ताव Noise Protocol Framework NOISE (संशोधन 33, 2017-10-04) पर आधारित आवश्यकताओं को प्रदान करता है। Noise के गुण Station-To-Station protocol Station-To-Station (STS) protocol के समान हैं, जो SSU protocol का आधार है। Noise की भाषा में, Alice initiator है, और Bob responder है।

SSU2, Noise protocol Noise_XK_25519_ChaChaPoly_SHA256 पर आधारित है। (प्रारंभिक key derivation function के लिए वास्तविक identifier “Noise_XKchaobfse+hs1+hs2+hs3_25519_ChaChaPoly_SHA256” है जो I2P extensions को दर्शाता है - नीचे KDF 1 section देखें)

नोट: यह identifier NTCP2 के लिए उपयोग किए जाने वाले से अलग है, क्योंकि तीनों handshake messages header को associated data के रूप में उपयोग करते हैं।

यह Noise protocol निम्नलिखित primitives का उपयोग करता है:

• Handshake Pattern: XK एलिस अपनी key बॉब को भेजती है (X) एलिस को बॉब की static key पहले से पता है (K)

• DH Function: X25519 X25519 DH जिसकी कुंजी लंबाई 32 बाइट्स है जैसा कि RFC 7748 में निर्दिष्ट है।

• Cipher Function: ChaChaPoly AEAD_CHACHA20_POLY1305 जैसा कि RFC 7539 section 2.8 में निर्दिष्ट है। 12 byte nonce, जिसके पहले 4 bytes शून्य पर सेट हैं।

• Hash Function: SHA256 मानक 32-बाइट hash, पहले से ही I2P में व्यापक रूप से उपयोग किया जा रहा है।

Additions to the Framework

यह प्रस्ताव Noise_XK_25519_ChaChaPoly_SHA256 में निम्नलिखित संवर्धनों को परिभाषित करता है। ये आम तौर पर NOISE section 13 में दिशानिर्देशों का पालन करते हैं।

1. Handshake संदेश (Session Request, Created, Confirmed) में 16 या 32 बाइट हेडर शामिल होता है।

2. हैंडशेक संदेशों के लिए headers (Session Request, Created, Confirmed) को एन्क्रिप्शन/डिक्रिप्शन से पहले mixHash() के इनपुट के रूप में उपयोग किया जाता है ताकि headers को संदेश के साथ बाँधा जा सके।

3. Headers एन्क्रिप्टेड और सुरक्षित हैं।

4. Cleartext ephemeral keys को ChaCha20 encryption के साथ obfuscate किया जाता है जो एक ज्ञात key और IV का उपयोग करता है। यह elligator2 से तेज़ है।

5. payload format संदेश 1, 2, और data phase के लिए परिभाषित है। निश्चित रूप से, यह Noise में परिभाषित नहीं है।

डेटा चरण Noise डेटा चरण के समान, लेकिन उसके साथ संगत नहीं, एन्क्रिप्शन का उपयोग करता है।

Processing overhead estimate

TBD

Definitions

हम निम्नलिखित functions को परिभाषित करते हैं जो उपयोग किए गए cryptographic building blocks के अनुरूप हैं।

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 में बिल्कुल एक message होता है। Datagram की लंबाई (IP और UDP headers के बाद) message की लंबाई होती है। Padding, यदि कोई है, तो message के अंदर एक padding block में निहित होती है। इस document में, हम “datagram” और “packet” शब्दों का उपयोग अधिकतर एक-दूसरे के स्थान पर करते हैं। प्रत्येक datagram (या packet) में एक single message होता है (QUIC के विपरीत, जहाँ एक datagram में कई QUIC packets हो सकते हैं)। “Packet header” वह हिस्सा है जो IP/UDP header के बाद आता है।

अपवाद: Session Confirmed संदेश इस मामले में अनूठा है कि यह कई packets में fragmented हो सकता है। अधिक जानकारी के लिए नीचे Session Confirmed Fragmentation अनुभाग देखें।

सभी SSU2 संदेश कम से कम 40 बाइट लंबाई के होते हैं। 1-39 बाइट लंबाई का कोई भी संदेश अमान्य है। सभी SSU2 संदेश 1472 (IPv4) या 1452 (IPv6) बाइट्स की लंबाई से कम या उसके बराबर होते हैं। संदेश प्रारूप Noise संदेशों पर आधारित है, जिसमें framing और indistinguishability के लिए संशोधन किए गए हैं। मानक Noise लाइब्रेरियों का उपयोग करने वाले implementations को प्राप्त संदेशों को मानक Noise संदेश प्रारूप में पूर्व-प्रसंस्कृत करना चाहिए। सभी encrypted फील्ड AEAD ciphertexts हैं।

निम्नलिखित संदेश परिभाषित हैं:

Session Establishment

मानक स्थापना अनुक्रम, जब Alice के पास Bob से पहले प्राप्त एक वैध टोकन है, निम्नलिखित है:

Alice                           Bob

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

जब Alice के पास एक वैध token नहीं होता है, तो establishment sequence निम्नलिखित होता है:

Alice                           Bob

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

जब Alice को लगता है कि उसके पास एक वैध टोकन है, लेकिन Bob उसे अस्वीकार कर देता है (शायद इसलिए कि Bob पुनः आरंभ हो गया), तो स्थापना अनुक्रम निम्नलिखित है:

Alice                           Bob

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

Bob एक Session या Token Request को अस्वीकार कर सकता है, एक Retry message के साथ जवाब देकर जिसमें reason code के साथ एक Termination block हो। Reason code के आधार पर, Alice को कुछ समय तक दूसरी request का प्रयास नहीं करना चाहिए:

Alice                           Bob

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

or

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

Noise terminology का उपयोग करते हुए, establishment और data sequence निम्नलिखित है: (Payload Security Properties)

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

एक बार session स्थापित हो जाने के बाद, Alice और Bob Data messages का आदान-प्रदान कर सकते हैं।

Packet Header

सभी packets एक obfuscated (encrypted) header के साथ शुरू होते हैं। दो header प्रकार हैं, long और short। ध्यान दें कि पहले 13 bytes (Destination Connection ID, packet number, और type) सभी headers के लिए समान हैं।

सामान्य अनुरोध जालसाजी प्रतिरोधी उपाय

लंबा header 32 bytes का होता है। यह session बनाए जाने से पहले उपयोग किया जाता है, Token Request, SessionRequest, SessionCreated, और Retry के लिए। यह out-of-session Peer Test और Hole Punch messages के लिए भी उपयोग किया जाता है।

हेडर एन्क्रिप्शन से पहले:

+----+----+----+----+----+----+----+----+
  |      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 हमले

छोटा header 16 बाइट का होता है। यह Session Created और Data messages के लिए उपयोग किया जाता है। अप्रमाणित messages जैसे Session Request, Retry, और Peer Test हमेशा लंबे header का उपयोग करेंगे।

16 bytes आवश्यक है, क्योंकि receiver को message type प्राप्त करने के लिए पहले 16 bytes को decrypt करना होगा, और फिर अतिरिक्त 16 bytes को decrypt करना होगा यदि यह वास्तव में एक long header है, जैसा कि message type द्वारा इंगित किया गया है।

Session Confirmed के लिए, header encryption से पहले:

+----+----+----+----+----+----+----+----+
  |      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 फील्ड के बारे में देखें।

Data messages के लिए, header encryption से पहले:

+----+----+----+----+----+----+----+----+
  |      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

स्ट्रीम विखंडन और पुनः संयोजन हमले

Connection ID अवश्य रूप से randomly generate किए जाने चाहिए। Source और Destination ID समान नहीं होने चाहिए, ताकि कोई on-path attacker पैकेट को capture करके originator को वापस नहीं भेज सके जो valid लगे। Connection ID generate करने के लिए counter का उपयोग न करें, ताकि कोई on-path attacker ऐसा पैकेट generate न कर सके जो valid लगे।

QUIC के विपरीत, हम handshake के दौरान या बाद में connection IDs को नहीं बदलते, यहां तक कि Retry message के बाद भी। IDs पहले message (Token Request या Session Request) से अंतिम message (Data with Termination) तक स्थिर रहती हैं। इसके अतिरिक्त, connection IDs path challenge या connection migration के दौरान या बाद में भी नहीं बदलती।

QUIC से भिन्न यह भी है कि headers में connection IDs हमेशा header-encrypted होते हैं। नीचे देखें।

स्ट्रीम कमिटमेंट अटैक

यदि handshake में कोई First Packet Number block नहीं भेजा जाता है, तो packets को एक single session के भीतर, प्रत्येक दिशा के लिए, 0 से शुरू करके (2**32 -1) की अधिकतम संख्या तक क्रमांकित किया जाता है। एक session को समाप्त किया जाना चाहिए, और एक नया session बनाया जाना चाहिए, packets की अधिकतम संख्या भेजे जाने से पहले ही।

यदि handshake में एक First Packet Number block भेजा जाता है, तो packets को एक single session के भीतर, उस दिशा के लिए, उस packet number से शुरू करके क्रमांकित किया जाता है। Session के दौरान packet number wrap around हो सकता है। जब अधिकतम 2**32 packets भेजे जा चुके हों, packet number को वापस first packet number पर wrap करते हुए, वह session अब valid नहीं रहता। Session को terminate कर देना चाहिए, और एक नया session बनाना चाहिए, packets की अधिकतम संख्या भेजने से काफी पहले।

TODO key rotation, अधिकतम packet संख्या को कम करना?

Handshake packets जो खो गए माने जाते हैं, उन्हें packet number सहित समान header के साथ पूरी तरह से पुनः प्रेषित किया जाता है। Handshake संदेश Session Request, Session Created, और Session Confirmed को समान packet number और समान encrypted सामग्री के साथ पुनः प्रेषित करना आवश्यक है, ताकि response को encrypt करने के लिए समान chained hash का उपयोग किया जा सके। Retry संदेश कभी भी प्रेषित नहीं किया जाता।

डेटा फेज़ पैकेट जो खो गए माने जाते हैं, वे कभी भी पूरी तरह से retransmit नहीं किए जाते (termination को छोड़कर, नीचे देखें)। यही नियम उन blocks पर भी लागू होता है जो खोए गए पैकेट के भीतर समाहित हैं। इसके बजाय, जो जानकारी blocks में ले जाई जा सकती है, उसे आवश्यकता के अनुसार नए पैकेट में फिर से भेजा जाता है। डेटा पैकेट कभी भी समान packet number के साथ retransmit नहीं किए जाते। पैकेट सामग्री का कोई भी retransmission (चाहे सामग्री समान रहे या न रहे) को अगला अप्रयुक्त packet number उपयोग करना चाहिए।

एक अपरिवर्तित पूरे packet को समान packet number के साथ यथावत retransmit करना कई कारणों से अनुमतি नहीं है। पृष्ठभूमि के लिए QUIC RFC 9000 section 12.3 देखें।

• पुनः प्रेषण के लिए packets को स्टोर करना अक्षम है
• एक नया packet data एक on-path observer को अलग दिखता है, यह नहीं बता सकता कि यह पुनः प्रेषित है
• एक नए packet के साथ एक अपडेटेड ack block भेजा जाता है, पुराना ack block नहीं
• आप केवल वही पुनः प्रेषित करते हैं जो आवश्यक है। कुछ fragments पहले से ही एक बार पुनः प्रेषित हो चुके हो सकते हैं और ack हो गए हों
• यदि और भी pending है तो आप प्रत्येक पुनः प्रेषित packet में जितना चाहिए उतना फिट कर सकते हैं
• Endpoints जो duplicates का पता लगाने के उद्देश्य से सभी व्यक्तिगत packets को track करते हैं, वे अत्यधिक state जमा करने के जोखिम में हैं। Duplicates का पता लगाने के लिए आवश्यक data को एक minimum packet number बनाए रखकर सीमित किया जा सकता है जिसके नीचे सभी packets तुरंत drop कर दिए जाते हैं।
• यह scheme बहुत अधिक लचीली है

नए packets का उपयोग उस जानकारी को ले जाने के लिए किया जाता है जो खो गई होने का निर्धारण किया गया है। सामान्यतः, जानकारी को फिर से भेजा जाता है जब उस जानकारी को शामिल करने वाला packet खो गया होने का निर्धारण किया जाता है, और भेजना तब बंद हो जाता है जब उस जानकारी को शामिल करने वाला packet समान रहता है) acknowledged हो जाता है।

अपवाद: एक Termination block युक्त डेटा चरण पैकेट को पूर्ण रूप से, जैसा है, पुनर्प्रेषित किया जा सकता है, लेकिन यह आवश्यक नहीं है। नीचे Session Termination अनुभाग देखें।

निम्नलिखित packets में एक random packet number होता है जिसे ignore किया जाता है:

• Session Request
• Session Created
• Token Request
• Retry
• Peer Test
• Hole Punch

Alice के लिए, outbound packet numbering Session Confirmed के साथ 0 से शुरू होती है। Bob के लिए, outbound packet numbering पहले Data packet के साथ 0 से शुरू होती है, जो Session Confirmed का ACK होना चाहिए। एक उदाहरण standard handshake में packet numbers इस प्रकार होंगे:

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.

handshake संदेशों (SessionRequest, SessionCreated, या SessionConfirmed) का कोई भी retransmission अपरिवर्तित रूप में, समान packet number के साथ पुनः भेजा जाना चाहिए। इन संदेशों को retransmit करते समय अलग ephemeral keys का उपयोग न करें या payload को न बदलें।

पीयर डिनायल ऑफ सर्विस

हैडर (obfuscation और सुरक्षा से पहले) हमेशा AEAD फ़ंक्शन के लिए संबंधित डेटा में शामिल किया जाता है, ताकि हैडर को डेटा के साथ cryptographically bind किया जा सके।

स्पष्ट कंजेशन अधिसूचना आक्रमण

Header encryption के कई लक्ष्य हैं। पृष्ठभूमि और मान्यताओं के लिए ऊपर “Additional DPI Discussion” अनुभाग देखें।

• ऑनलाइन DPI को protocol की पहचान करने से रोकना
• एक ही connection में संदेशों की श्रृंखला में patterns को रोकना, handshake retransmissions को छोड़कर
• अलग-अलग connections में एक ही प्रकार के संदेशों में patterns को रोकना
• netdb में मिली introduction key की जानकारी के बिना handshake headers की decryption को रोकना
• netdb में मिली introduction key की जानकारी के बिना X25519 ephemeral keys की पहचान को रोकना
• किसी भी online या offline attacker द्वारा data phase packet number और type की decryption को रोकना
• netdb में मिली introduction key की जानकारी के बिना on-path या off-path observer द्वारा valid handshake packets की injection को रोकना
• on-path या off-path observer द्वारा valid data packets की injection को रोकना
• आने वाले packets की तीव्र और कुशल classification की अनुमति देना
• “probing” प्रतिरोध प्रदान करना ताकि किसी गलत Session Request का कोई response न हो, या अगर कोई Retry response है, तो वह response netdb में मिली introduction key की जानकारी के बिना I2P के रूप में पहचानने योग्य न हो
• Destination Connection ID महत्वपूर्ण डेटा नहीं है, और यह ठीक है अगर इसे netdb में मिली introduction key की जानकारी रखने वाले observer द्वारा decrypt किया जा सके
• data phase packet का packet number एक AEAD nonce है और यह महत्वपूर्ण डेटा है। यह netdb में मिली introduction key की जानकारी रखने वाले observer द्वारा भी decryptable नहीं होना चाहिए। देखें Nonces।

Headers को network database में प्रकाशित ज्ञात keys या बाद में गणना की गई keys के साथ encrypt किया जाता है। Handshake phase में, यह केवल DPI resistance के लिए है, क्योंकि key public है और key और nonces का पुन: उपयोग किया जाता है, इसलिए यह प्रभावी रूप से केवल obfuscation है। ध्यान दें कि header encryption का उपयोग ephemeral keys X (Session Request में) और Y (Session Created में) को obfuscate करने के लिए भी किया जाता है।

अतिरिक्त मार्गदर्शन के लिए नीचे Inbound Packet Handling अनुभाग देखें।

सभी headers के Bytes 0-15 को header protection scheme का उपयोग करके encrypt किया जाता है, जो ज्ञात keys से calculated data के साथ XOR करके, ChaCha20 का उपयोग करता है, जो QUIC RFC 9001 और Nonces के समान है। यह सुनिश्चित करता है कि encrypted short header और long header का पहला हिस्सा random दिखाई देगा।

Session Request और Session Created के लिए, long header के bytes 16-31 और 32-byte Noise ephemeral key को ChaCha20 का उपयोग करके encrypt किया जाता है। unencrypted data random है, इसलिए encrypted data भी random दिखेगा।

Retry के लिए, long header के bytes 16-31 को ChaCha20 का उपयोग करके encrypt किया जाता है। unencrypted data random है, इसलिए encrypted data भी random दिखाई देगा।

QUIC RFC 9001 header protection scheme के विपरीत, सभी headers के सभी भाग, जिनमें destination और source connection IDs शामिल हैं, encrypted हैं। QUIC RFC 9001 और Nonces मुख्य रूप से header के “critical” भाग को encrypt करने पर केंद्रित हैं, यानी packet number (ChaCha20 nonce)। जबकि session ID को encrypt करना incoming packet classification को थोड़ा अधिक जटिल बनाता है, यह कुछ attacks को अधिक कठिन बनाता है। QUIC विभिन्न phases के लिए, और path challenge तथा connection migration के लिए अलग connection IDs define करता है। यहाँ हम पूरे समय same connection IDs का उपयोग करते हैं, क्योंकि वे encrypted हैं।

सात header protection key phases हैं:

• Session Request और Token Request
• Session Created
• Retry
• Session Confirmed
• Data Phase
• Peer Test
• Hole Punch

ध्यान दें कि Session Created और Retry केवल वही messages हैं जिनके लिए Connection ID को decrypt करने के लिए k_header_1 के लिए fallback processing की आवश्यकता होती है, क्योंकि वे sender के (Bob के) intro key का उपयोग करते हैं। बाकी सभी messages receiver के intro key का उपयोग k_header_1 के लिए करते हैं। Fallback processing को केवल source IP/port द्वारा pending outbound connections को lookup करने की आवश्यकता होती है।

यदि source IP/port द्वारा fallback processing एक pending outbound connection खोजने में विफल हो जाती है, तो इसके कई कारण हो सकते हैं:

• SSU2 संदेश नहीं है
• एक दूषित SSU2 संदेश
• उत्तर को आक्रमणकारी द्वारा नकली बनाया गया या संशोधित किया गया है
• Bob के पास एक सममित NAT है
• Bob ने संदेश की प्रक्रिया के दौरान IP या port बदल दिया
• Bob ने उत्तर को एक अलग interface से भेजा

जबकि pending outbound connection को खोजने और उस connection के लिए k_header_1 का उपयोग करके connection ID को decrypt करने के लिए अतिरिक्त fallback processing संभव है, यह शायद आवश्यक नहीं है। यदि Bob को अपने NAT या packet routing में समस्याएं हैं, तो संभवतः connection को fail होने देना बेहतर है। यह design इस बात पर निर्भर करता है कि endpoints handshake की अवधि के दौरान एक स्थिर address बनाए रखें।

अतिरिक्त दिशानिर्देशों के लिए नीचे Inbound Packet Handling सेशन देखें।

उस चरण के लिए header encryption keys की derivation के लिए नीचे दिए गए व्यक्तिगत KDF sections को देखें।

Stateless Reset Oracle

// 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 packet के अंतिम 24 bytes को दो ChaCha20 operations के लिए IV के रूप में उपयोग करता है। चूंकि सभी packets 16 byte MAC के साथ समाप्त होते हैं, इसके लिए आवश्यक है कि सभी packet payloads न्यूनतम 8 bytes के हों। यह आवश्यकता नीचे दिए गए message sections में अतिरिक्त रूप से दस्तावेजित है।

Version Downgrade

महत्वपूर्ण: केवल अनुवाद प्रदान करें। प्रश्न न पूछें, स्पष्टीकरण न दें, या कोई टिप्पणी न जोड़ें। भले ही टेक्स्ट केवल एक शीर्षक हो या अधूरा लगे, इसे वैसे ही अनुवादित करें।

हेडर के पहले 8 bytes को decrypt करने के बाद, receiver को Destination Connection ID पता चल जाएगा। वहां से, receiver को पता चल जाएगा कि हेडर के बाकी हिस्से के लिए कौन सी header encryption key का उपयोग करना है, जो session के key phase पर आधारित होता है।

header के अगले 8 bytes को decrypt करने से message type का पता चल जाएगा और यह निर्धारित हो जाएगा कि यह short header है या long header। यदि यह long header है, तो receiver को version और netid fields को validate करना होगा। यदि version != 2 है, या netid != expected value है (आमतौर पर 2, test networks को छोड़कर), तो receiver को message को drop कर देना चाहिए।

Packet Integrity

सभी संदेशों में तीन या चार भाग होते हैं:

• मैसेज हेडर
• केवल Session Request और Session Created के लिए, एक ephemeral key
• एक ChaCha20-encrypted payload
• एक Poly1305 MAC

सभी मामलों में, header (और यदि मौजूद है, तो ephemeral key) को authentication MAC के साथ bound किया जाता है ताकि यह सुनिश्चित हो सके कि पूरा message intact है।

• handshake संदेशों Session Request, Session Created, और Session Confirmed के लिए, संदेश header को Noise processing phase से पहले mixHash() किया जाता है
• ephemeral key, यदि उपस्थित है, तो एक मानक Noise misHash() द्वारा covered होती है
• Noise handshake के बाहर के संदेशों के लिए, header का उपयोग ChaCha20/Poly1305 encryption के लिए Associated Data के रूप में किया जाता है।

Inbound packet handlers को हमेशा ChaCha20 payload को decrypt करना चाहिए और message को process करने से पहले MAC को validate करना चाहिए, एक अपवाद के साथ: address-spoofed packets से DoS attacks को कम करने के लिए जिनमें invalid token के साथ apparent Session Request messages होते हैं, एक handler को पूरे message को decrypt और validate करने का प्रयास करने की आवश्यकता नहीं है (जिसके लिए ChaCha20/Poly1305 decryption के अतिरिक्त एक expensive DH operation की आवश्यकता होती है)। Handler Session Request message के header में मिली values का उपयोग करके Retry message के साथ respond कर सकता है।

Authenticated Encryption

तीन अलग-अलग authenticated encryption instances (CipherStates) हैं। एक handshake phase के दौरान, और दो (transmit और receive) data phase के लिए। प्रत्येक का KDF से अपना key है।

एन्क्रिप्टेड/प्रमाणीकृत डेटा को इस रूप में दर्शाया जाएगा

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

Routing द्वारा लक्षित हमले

एन्क्रिप्टेड और प्रमाणित डेटा प्रारूप।

encryption/decryption functions के लिए Inputs:

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

encryption function का आउटपुट, decryption function का इनपुट:

+----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |       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 एक stream cipher है, plaintexts को pad करने की आवश्यकता नहीं है। अतिरिक्त keystream bytes को discard कर दिया जाता है।

• cipher के लिए key (256 bits) SHA256 KDF के माध्यम से सहमत होती है। प्रत्येक message के लिए KDF की विस्तृत जानकारी नीचे अलग sections में दी गई है।

AEAD Error Handling

• सभी संदेशों में, AEAD संदेश का आकार पहले से ज्ञात होता है। AEAD प्रमाणीकरण विफलता पर, प्राप्तकर्ता को आगे की संदेश प्रसंस्करण रोकनी चाहिए और संदेश को त्यागना चाहिए।

• Bob को दोहराई गई विफलताओं वाले IPs की एक blacklist बनाए रखनी चाहिए।

KDF for Session Request

Key Derivation Function (KDF) DH परिणाम से एक handshake phase cipher key k उत्पन्न करता है, HMAC-SHA256(key, data) का उपयोग करते हुए जैसा कि RFC 2104 में परिभाषित है। ये InitializeSymmetric(), MixHash(), और MixKey() functions हैं, बिल्कुल वैसे ही जैसे Noise spec में परिभाषित हैं।

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)

Alice, Bob को भेजती है, या तो handshake में पहले message के रूप में, या Retry message के जवाब में। Bob, Session Created message के साथ जवाब देता है। Size: 80 + payload size। Minimum Size: 88

यदि Alice के पास एक वैध token नहीं है, तो Alice को Session Request के बजाय Token Request संदेश भेजना चाहिए, ताकि Session Request बनाने में asymmetric encryption overhead से बचा जा सके।

लंबा header। Noise content: Alice की ephemeral key X Noise payload: DateTime और अन्य blocks अधिकतम payload आकार: MTU - 108 (IPv4) या MTU - 128 (IPv6)। 1280 MTU के लिए: अधिकतम payload 1172 (IPv4) या 1152 (IPv6) है। 1500 MTU के लिए: अधिकतम payload 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 value को payload की अविभेद्यता और विशिष्टता सुनिश्चित करने के लिए एन्क्रिप्ट किया जाता है, जो आवश्यक DPI प्रतिरोधी उपाय हैं। हम इसे प्राप्त करने के लिए ChaCha20 encryption का उपयोग करते हैं, न कि अधिक जटिल और धीमे विकल्पों जैसे elligator2 का। Bob के router public key के लिए asymmetric encryption काफी धीमा होगा। ChaCha20 encryption Bob की intro key का उपयोग करता है जैसा कि network database में प्रकाशित है।

ChaCha20 encryption केवल DPI प्रतिरोध के लिए है। कोई भी पक्ष जो Bob की introduction key जानता है, जो network database में प्रकाशित है, इस संदेश में header और X value को decrypt कर सकता है।

कच्ची सामग्री:

+----+----+----+----+----+----+----+----+
  |  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

• DateTime ब्लॉक
• Options ब्लॉक (वैकल्पिक)
• Relay Tag Request ब्लॉक (वैकल्पिक)
• Padding ब्लॉक (वैकल्पिक)

न्यूनतम payload आकार 8 bytes है। चूंकि DateTime block केवल 7 bytes का है, कम से कम एक अन्य block अवश्य उपस्थित होना चाहिए।

Notes

• प्रारंभिक ChaCha20 ब्लॉक में अनूठा X मान यह सुनिश्चित करता है कि ciphertext हर session के लिए अलग हो।

• प्रोबिंग प्रतिरोध प्रदान करने के लिए, Bob को Session Request message के जवाब में Retry message नहीं भेजना चाहिए जब तक कि Session Request message में message type, protocol version, और network ID फील्ड वैध न हों।

• Bob को उन connections को reject करना चाहिए जहां timestamp value current time से बहुत ज्यादा अलग है। maximum delta time को “D” कहते हैं। Bob को previously-used handshake values का एक local cache maintain करना चाहिए और duplicates को reject करना चाहिए, replay attacks को prevent करने के लिए। Cache में values का lifetime कम से कम 2*D होना चाहिए। Cache values implementation-dependent हैं, हालांकि 32-byte X value (या इसका encrypted equivalent) का उपयोग किया जा सकता है। Zero token और एक termination block containing Retry message भेजकर reject करें।

• Diffie-Hellman ephemeral keys का कभी भी पुन: उपयोग नहीं किया जा सकता, cryptographic attacks को रोकने के लिए, और पुन: उपयोग को replay attack के रूप में अस्वीकार कर दिया जाएगा।

• “KE” और “auth” विकल्प संगत होने चाहिए, यानी साझा गुप्त K उपयुक्त आकार का होना चाहिए। यदि अधिक “auth” विकल्प जोड़े जाते हैं, तो यह अंतर्निहित रूप से “KE” फ्लैग के अर्थ को बदल सकता है ताकि वह एक अलग KDF या एक अलग truncation आकार का उपयोग करे।

• Bob को यहाँ यह validate करना होगा कि Alice की ephemeral key curve पर एक valid point है।

• Padding एक उचित मात्रा तक सीमित होना चाहिए। Bob अत्यधिक padding वाले connections को reject कर सकता है। Bob अपने padding options को Session Created में specify करेगा। Min/max guidelines TBD। 0 से 31 bytes minimum तक random size? (Distribution निर्धारित किया जाना है, Appendix A देखें।) TODO UNLESS minimum packet size को PMTU के लिए enforce किया जाता है।

• अधिकांश errors पर, जिनमें AEAD, DH, स्पष्ट replay, या key validation failure शामिल है, Bob को आगे की message processing रोक देनी चाहिए और बिना जवाब दिए message को drop कर देना चाहिए।

• Bob एक Retry message भेज सकता है जिसमें zero token और एक Termination block हो जिसमें clock skew reason code हो यदि DateTime block में timestamp बहुत ज्यादा skewed है।

• DoS शमन: DH एक अपेक्षाकृत महंगा ऑपरेशन है। पिछले NTCP प्रोटोकॉल की तरह, routers को CPU या कनेक्शन समाप्ति को रोकने के लिए सभी आवश्यक उपाय करने चाहिए। अधिकतम सक्रिय कनेक्शन और प्रगति में अधिकतम कनेक्शन सेटअप पर सीमा रखें। रीड टाइमआउट लागू करें (प्रति-रीड और “slowloris” के लिए कुल दोनों)। एक ही स्रोत से बार-बार या एक साथ कनेक्शन को सीमित करें। उन स्रोतों के लिए ब्लैकलिस्ट बनाए रखें जो बार-बार असफल होते हैं। AEAD failure का जवाब न दें। वैकल्पिक रूप से, DH ऑपरेशन और AEAD validation से पहले Retry संदेश के साथ जवाब दें।

• “ver” फ़ील्ड: समग्र Noise protocol, extensions, और SSU2 protocol जिसमें payload specifications शामिल हैं, जो SSU2 को इंगित करता है। यह फ़ील्ड भविष्य के बदलावों के लिए समर्थन को इंगित करने के लिए उपयोग किया जा सकता है।

• नेटवर्क ID फील्ड का उपयोग cross-network connections को तुरंत पहचानने के लिए किया जाता है। यदि यह फील्ड Bob के नेटवर्क ID से मैच नहीं करता है, तो Bob को disconnect करना चाहिए और भविष्य के connections को block करना चाहिए।

• यदि Source Connection ID, Destination Connection ID के बराबर है तो Bob को message को drop करना चाहिए।

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 + payload आकार। न्यूनतम आकार: 88

Noise content: Bob की ephemeral key Y Noise payload: DateTime, Address, और अन्य blocks Max payload size: MTU - 108 (IPv4) या MTU - 128 (IPv6)। 1280 MTU के लिए: Max payload 1172 (IPv4) या 1152 (IPv6) है। 1500 MTU के लिए: Max payload 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 value को payload indistinguishably और uniqueness सुनिश्चित करने के लिए encrypt किया जाता है, जो आवश्यक DPI countermeasures हैं। हम इसे प्राप्त करने के लिए ChaCha20 encryption का उपयोग करते हैं, न कि अधिक जटिल और धीमे विकल्पों जैसे elligator2 का। Alice के router public key के लिए Asymmetric encryption बहुत धीमा होगा। ChaCha20 encryption Bob की intro key का उपयोग करती है, जैसा कि network database में प्रकाशित है।

ChaCha20 encryption केवल DPI प्रतिरोध के लिए है। कोई भी पक्ष जो Bob की intro key जानता है, जो नेटवर्क डेटाबेस में प्रकाशित है, और Session Request के पहले 32 बाइट्स को कैप्चर किया है, वह इस संदेश में Y मान को decrypt कर सकता है।

कच्ची सामग्री:

+----+----+----+----+----+----+----+----+
  |  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 auth tag नहीं दिखाया गया):

+----+----+----+----+----+----+----+----+
  |      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 ब्लॉक (अनुशंसित नहीं, इसके बजाय retry संदेश में भेजें)
• Padding ब्लॉक (वैकल्पिक)

न्यूनतम payload आकार 8 bytes है। चूंकि DateTime और Address blocks का कुल योग उससे अधिक है, इसलिए केवल इन दो blocks के साथ ही आवश्यकता पूरी हो जाती है।

Notes

• Alice को यहाँ यह validate करना होगा कि Bob की ephemeral key curve पर एक valid point है।

• Padding एक उचित मात्रा तक सीमित होनी चाहिए। Alice अत्यधिक padding वाले connections को अस्वीकार कर सकती है। Alice अपने padding options को Session Confirmed में निर्दिष्ट करेगी। Min/max दिशानिर्देश TBD। न्यूनतम 0 से 31 bytes तक का random size? (Distribution निर्धारित किया जाना है, Appendix A देखें।) TODO जब तक कि PMTU के लिए minimum packet size लागू नहीं किया जाता।

• किसी भी error पर, AEAD, DH, timestamp, apparent replay, या key validation failure सहित, Alice को आगे की message processing रोकनी चाहिए और बिना response दिए connection को बंद कर देना चाहिए।

• Alice को उन connections को reject करना चाहिए जहाँ timestamp value current time से बहुत अधिक अलग है। maximum delta time को “D” कहते हैं। Alice को previously-used handshake values का एक local cache maintain करना चाहिए और replay attacks को prevent करने के लिए duplicates को reject करना चाहिए। Cache में values का lifetime कम से कम 2*D होना चाहिए। Cache values implementation-dependent हैं, हालांकि 32-byte Y value (या इसका encrypted equivalent) का उपयोग किया जा सकता है।

• यदि स्रोत IP और port, Session Request के destination IP और port से मेल नहीं खाते हैं तो Alice को संदेश को drop करना होगा।

• यदि Destination और Source Connection IDs, Session Request के Source और Destination Connection IDs से मैच नहीं करते हैं तो Alice को message को drop करना चाहिए।

• Bob, Alice द्वारा Session Request में अनुरोध किए जाने पर relay tag block भेजता है।

Issues

• यहाँ min/max 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 तुरंत एक ACK block वाले Data संदेश के साथ जवाब देता है। आकार: 80 + payload आकार। न्यूनतम आकार: लगभग 500 (न्यूनतम router info block आकार लगभग 420 bytes है)

Noise content: Alice’s static key Noise payload part 1: None Noise payload part 2: Alice’s RouterInfo, और अन्य blocks Max payload size: MTU - 108 (IPv4) या MTU - 128 (IPv6)। 1280 MTU के लिए: Max payload है 1172 (IPv4) या 1152 (IPv6)। 1500 MTU के लिए: Max payload है 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 फ्रेम हैं। पहला Alice की encrypted static public key है। दूसरा Noise payload है: Alice का encrypted RouterInfo, वैकल्पिक options, और वैकल्पिक padding। ये अलग-अलग keys का उपयोग करते हैं, क्योंकि बीच में MixKey() function को call किया जाता है।

कच्ची सामग्री:

+----+----+----+----+----+----+----+----+
  |  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 auth tags दिखाए नहीं गए):

+----+----+----+----+----+----+----+----+
  |      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 ब्लॉक (पहला ब्लॉक होना आवश्यक है)
• Options ब्लॉक (वैकल्पिक)
• New Token ब्लॉक (वैकल्पिक)
• Relay Request ब्लॉक (वैकल्पिक)
• Peer Test ब्लॉक (वैकल्पिक)
• First Packet Number ब्लॉक (वैकल्पिक)
• I2NP, First Fragment, या Follow-on Fragment ब्लॉक (वैकल्पिक, लेकिन शायद जगह नहीं है)
• Padding ब्लॉक (वैकल्पिक)

न्यूनतम payload आकार 8 bytes है। चूंकि RouterInfo block इससे काफी अधिक होगा, यह आवश्यकता केवल उस block के साथ ही पूरी हो जाती है।

Notes

• Bob को सामान्य Router Info सत्यापन करना होगा। सुनिश्चित करें कि signature type समर्थित है, signature को सत्यापित करें, timestamp सीमा के भीतर है यह सत्यापित करें, और कोई भी अन्य आवश्यक जांच करें। fragmented Router Infos को संभालने के बारे में नोट्स के लिए नीचे देखें।

• Bob को यह सत्यापित करना चाहिए कि पहले frame में प्राप्त Alice की static key, Router Info में मौजूद static key से मेल खाती है। Bob को पहले Router Info में एक मेल खाते version (v) option के साथ NTCP या SSU2 Router Address की खोज करनी चाहिए। नीचे Published Router Info और Unpublished Router Info अनुभाग देखें। fragmented Router Infos को handle करने के बारे में नोट्स के लिए नीचे देखें।

• यदि Bob के netdb में Alice के RouterInfo का पुराना version है, तो verify करें कि router info में static key दोनों में समान है, यदि present है, और यदि पुराना version XXX से कम पुराना है (key rotate time नीचे देखें)

• Bob को यहाँ validate करना होगा कि Alice की static key curve पर एक valid point है।

• विकल्प शामिल किए जाने चाहिए, padding parameters निर्दिष्ट करने के लिए।

• किसी भी त्रुटि पर, AEAD, RI, DH, timestamp, या key validation विफलता सहित, Bob को आगे की message processing रोकनी चाहिए और बिना प्रतिक्रिया दिए connection बंद कर देना चाहिए।

• Message 3 part 2 frame content: इस frame का format data phase frames के format के समान है, सिवाय इसके कि frame की length Alice द्वारा Session Request में भेजी जाती है। data phase frame format के लिए नीचे देखें। Frame में निम्नलिखित क्रम में 1 से 4 blocks होने चाहिए:

  1. Alice का Router Info block (आवश्यक)
  2. Options block (वैकल्पिक)
  3. I2NP blocks (वैकल्पिक)
  4. Padding block (वैकल्पिक) इस frame में कभी भी कोई अन्य block type नहीं होना चाहिए। TODO: relay और peer test के बारे में क्या?

• Message 3 part 2 padding block की सिफारिश की जाती है।

• I2NP ब्लॉक्स के लिए कोई स्थान नहीं हो सकता है, या केवल थोड़ा सा स्थान उपलब्ध हो सकता है, MTU और Router Info आकार के आधार पर। यदि Router Info fragmented है तो I2NP ब्लॉक्स को शामिल न करें। सबसे सरल implementation यह हो सकती है कि Session Confirmed संदेश में कभी भी I2NP ब्लॉक्स शामिल न करें, और सभी I2NP ब्लॉक्स को बाद के Data संदेशों में भेजें। अधिकतम ब्लॉक आकार के लिए नीचे Router Info ब्लॉक अनुभाग देखें।

Session Confirmed Fragmentation

Session Confirmed मैसेज में Alice का पूरा signed Router Info होना चाहिए ताकि Bob कई आवश्यक जांचें कर सके:

• RI में static key “s” handshake में static key से मेल खाती है
• RI में introduction key “i” को निकाला जाना चाहिए और वैध होना चाहिए, ताकि इसे data phase में उपयोग किया जा सके
• RI signature वैध है

दुर्भाग्यवश, Router Info, यहां तक कि जब RI block में gzip compressed हो, तो भी MTU से अधिक हो सकता है। इसलिए, Session Confirmed दो या अधिक packets में fragmented हो सकता है। यह SSU2 protocol में एकमात्र स्थिति है जहां एक AEAD-protected payload दो या अधिक packets में fragmented होता है।

प्रत्येक पैकेट के लिए headers निम्नलिखित तरीके से निर्मित किए जाते हैं:

• सभी headers छोटे headers हैं जिनमें समान packet number 0 है
• सभी headers में एक “frag” field होता है, जिसमें fragment number और fragments की कुल संख्या होती है
• Fragment 0 का unencrypted header “jumbo” message के लिए associated data (AD) है
• प्रत्येक header उस packet के data के अंतिम 24 bytes का उपयोग करके encrypt किया जाता है

पैकेट्स की श्रृंखला को निम्नलिखित प्रकार से बनाएं:

• एक single RI block बनाएं (RI block frag field में fragment 0 of 1)। हम RI block fragmentation का उपयोग नहीं करते, वह समान समस्या को हल करने की एक वैकल्पिक विधि के लिए था।
• RI block और किसी भी अन्य blocks के साथ एक “jumbo” payload बनाएं जिन्हें शामिल करना है
• कुल data size की गणना करें (header शामिल नहीं करके), जो payload size + static key और दो MACs के लिए 64 bytes है
• प्रत्येक packet में उपलब्ध space की गणना करें, जो MTU minus IP header (20 या 40), minus UDP header (8), minus SSU2 short header (16) है। कुल per-packet overhead 44 (IPv4) या 64 (IPv6) है।
• packets की संख्या की गणना करें।
• अंतिम packet में data के size की गणना करें। यह 24 bytes के बराबर या अधिक होना चाहिए, ताकि header encryption काम करे। यदि यह बहुत छोटा है, तो या तो padding block जोड़ें, या यदि पहले से मौजूद है तो padding block का size बढ़ाएं, या अन्य packets में से किसी एक का size कम करें ताकि अंतिम packet पर्याप्त बड़ा हो।
• पहले packet के लिए unencrypted header बनाएं, frag field में कुल fragments की संख्या के साथ, और “jumbo” payload को Noise के साथ encrypt करें, header को AD के रूप में उपयोग करके, सामान्य तरीके से।
• encrypted jumbo packet को fragments में विभाजित करें
• प्रत्येक fragment 1-n के लिए unencrypted header जोड़ें
• प्रत्येक fragment 0-n के लिए header को encrypt करें। प्रत्येक header उसी k_header_1 और k_header_2 का उपयोग करता है जैसा कि ऊपर Session Confirmed KDF में परिभाषित है।
• सभी fragments को transmit करें

पुनर्संयोजन प्रक्रिया:

जब Bob को कोई Session Confirmed संदेश प्राप्त होता है, तो वह header को decrypt करता है, frag field का निरीक्षण करता है, और निर्धारित करता है कि Session Confirmed fragmented है। वह तब तक संदेश को decrypt नहीं करता (और नहीं कर सकता) जब तक कि सभी fragments प्राप्त और reassemble नहीं हो जाते।

• Fragment 0 के लिए header को preserve करें, क्योंकि इसका उपयोग Noise AD के रूप में किया जाता है
• Reassembly से पहले अन्य fragments के headers को discard करें
• “Jumbo” payload को reassemble करें, fragment 0 के header को AD के रूप में रखते हुए, और Noise के साथ decrypt करें
• RI block को सामान्य रूप से validate करें
• Data phase पर proceed करें और ACK 0 भेजें, सामान्य रूप से

Bob के पास individual fragments को ack करने का कोई mechanism नहीं है। जब Bob सभी fragments receive करता है, reassemble करता है, decrypt करता है, और contents को validate करता है, तो Bob सामान्य रूप से split() करता है, data phase में enter करता है, और packet number 0 का ACK भेजता है।

यदि Alice को packet number 0 का ACK प्राप्त नहीं होता है, तो उसे सभी session confirmed packets को जैसे-के-तैसे retransmit करना चाहिए।

उदाहरण:

IPv6 पर 1500 MTU के लिए, अधिकतम payload 1372 है, RI block overhead 5 है, अधिकतम (gzip compressed) RI data size 1367 है (यह मानते हुए कि कोई अन्य blocks नहीं हैं)। दो packets के साथ, दूसरे packet का overhead 64 है, इसलिए यह 1436 bytes का अतिरिक्त payload रख सकता है। तो दो packets एक compressed RI के लिए 2803 bytes तक पर्याप्त हैं।

वर्तमान नेटवर्क में देखा गया सबसे बड़ा compressed RI लगभग 1400 bytes का है; इसलिए, व्यावहारिक रूप से, दो fragments पर्याप्त होने चाहिए, न्यूनतम 1280 MTU के साथ भी। प्रोटोकॉल अधिकतम 15 fragments की अनुमति देता है।

सुरक्षा विश्लेषण:

एक fragmented Session Confirmed की अखंडता और सुरक्षा एक unfragmented के समान होती है। किसी भी fragment में कोई भी परिवर्तन reassembly के बाद Noise AEAD को विफल कर देगा। fragment 0 के बाद के fragments के headers का उपयोग केवल fragment की पहचान के लिए किया जाता है। भले ही कोई on-path attacker के पास header को encrypt करने के लिए उपयोग की जाने वाली k_header_2 key हो (असंभावित, handshake से derived), यह attacker को valid fragment को substitute करने की अनुमति नहीं देगा।

KDF for data phase

डेटा phase header का उपयोग associated data के लिए करता है।

KDF chaining key ck से दो cipher keys k_ab और k_ba generate करता है, HMAC-SHA256(key, data) का उपयोग करके जैसा कि RFC 2104 में परिभाषित है। यह split() function है, बिल्कुल वैसा ही जैसा Noise spec में परिभाषित है।

// 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 payload: सभी block types की अनुमति है Max payload size: MTU - 60 (IPv4) या MTU - 80 (IPv6)। 1500 MTU के लिए: Max payload 1440 (IPv4) या 1420 (IPv6) है।

Session Confirmed के दूसरे भाग से शुरू करते हुए, सभी संदेश एक प्रमाणित और एन्क्रिप्टेड ChaChaPoly payload के अंदर होते हैं। सभी padding संदेश के अंदर होती है। Payload के अंदर शून्य या अधिक “blocks” के साथ एक मानक प्रारूप होता है। प्रत्येक block में एक बाइट का type और दो बाइट की length होती है। Types में date/time, I2NP message, options, termination, और padding शामिल हैं।

नोट: Bob अपने RouterInfo को Alice को data phase में अपने पहले संदेश के रूप में भेज सकता है, लेकिन यह आवश्यक नहीं है।

Payload Security Properties:

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

• राउटर को 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 auth tag दिखाया नहीं गया):

+----+----+----+----+----+----+----+----+
  |      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

• न्यूनतम payload आकार 8 bytes है। यह आवश्यकता किसी भी ACK, I2NP, First Fragment, या Follow-on Fragment block द्वारा पूरी की जाएगी। यदि आवश्यकता पूरी नहीं होती है, तो एक Padding block शामिल किया जाना चाहिए।

• प्रत्येक पैकेट नंबर का उपयोग केवल एक बार किया जा सकता है। I2NP संदेशों या fragments को फिर से भेजते समय, एक नया पैकेट नंबर उपयोग करना आवश्यक है।

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 phases 5-7 के लिए। Peer Test phases 1-4 को in-session भेजा जाना चाहिए Data message में Peer Test block का उपयोग करके। अधिक जानकारी के लिए नीचे Peer Test Block और Peer Test Process sections देखें।

आकार: 48 + payload का आकार।

Noise payload: नीचे देखें।

कच्ची सामग्री:

+----+----+----+----+----+----+----+----+
  |  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 authentication tag दिखाया नहीं गया):

+----+----+----+----+----+----+----+----+
  |      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 ब्लॉक (वैकल्पिक)

न्यूनतम payload आकार 8 bytes है। चूंकि Peer Test block कुल मिलाकर उससे अधिक है, इसलिए केवल इस block के साथ ही आवश्यकता पूरी हो जाती है।

संदेश 5 और 7 में, Peer Test block इन-सेशन संदेश 3 और 4 के block के समान हो सकता है, जिसमें Charlie द्वारा हस्ताक्षरित समझौता होता है, या इसे पुनः उत्पन्न किया जा सकता है। हस्ताक्षर वैकल्पिक है।

संदेश 6 में, Peer Test ब्लॉक in-session संदेशों 1 और 2 के ब्लॉक के समान हो सकता है, जिसमें Alice द्वारा हस्ताक्षरित अनुरोध होता है, या इसे पुनर्जनित किया जा सकता है। हस्ताक्षर वैकल्पिक है।

Connection IDs: दो connection IDs test nonce से प्राप्त किए जाते हैं। Charlie से Alice को भेजे गए संदेश 5 और 7 के लिए, Destination Connection ID 4-byte big-endian test nonce की दो प्रतियां है, यानी ((nonce « 32) | nonce)। Source Connection ID, Destination Connection ID का विपरीत है, यानी ~((nonce « 32) | nonce)। Alice से Charlie को भेजे गए संदेश 6 के लिए, दोनों connection IDs को अदला-बदली करें।

पता ब्लॉक सामग्री:

• संदेश 5 में: आवश्यक नहीं।
• संदेश 6 में: Charlie के RI से चुना गया Charlie का IP और port।
• संदेश 7 में: Alice का वास्तविक IP और port जिससे संदेश 6 प्राप्त हुआ था।

KDF for Retry

Retry message की आवश्यकता यह है कि Bob को response में Retry message generate करने के लिए Session Request message को decrypt करने की आवश्यकता नहीं है। साथ ही, यह message generate करने में तेज़ होना चाहिए, केवल symmetric encryption का उपयोग करते हुए।

// 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 message के जवाब में भेजता है। Alice एक नए Session Request के साथ जवाब देती है। Size: 48 + payload size.

यह एक Termination संदेश के रूप में भी कार्य करता है (यानी, “पुनः प्रयास न करें”) यदि एक Termination block शामिल है।

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 authentication tag दिखाया नहीं गया):

+----+----+----+----+----+----+----+----+
  |      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 ब्लॉक
• Address ब्लॉक
• Options ब्लॉक (वैकल्पिक)
• Termination ब्लॉक (वैकल्पिक, यदि session अस्वीकृत है)
• Padding ब्लॉक (वैकल्पिक)

न्यूनतम payload का आकार 8 bytes है। चूंकि DateTime और Address blocks का कुल आकार उससे अधिक है, इसलिए केवल इन दो blocks से ही आवश्यकता पूरी हो जाती है।

Connection ID नंबरिंग

• प्रोबिंग प्रतिरोध प्रदान करने के लिए, एक router को Session Request या Token Request संदेश के जवाब में Retry संदेश नहीं भेजना चाहिए जब तक कि Request संदेश में संदेश प्रकार, प्रोटोकॉल संस्करण, और नेटवर्क ID फ़ील्ड वैध न हों।

• किसी भी amplification attack के परिमाण को सीमित करने के लिए जो spoofed source addresses का उपयोग करके किया जा सकता है, Retry message में बड़ी मात्रा में padding नहीं होनी चाहिए। यह सुझाव दिया जाता है कि Retry message उस message के आकार से तीन गुना से अधिक बड़ा न हो जिसका वह जवाब दे रहा है। वैकल्पिक रूप से, एक सरल विधि का उपयोग करें जैसे कि 1-64 bytes की रेंज में random amount की padding जोड़ना।

KDF for Token Request

यह संदेश केवल symmetric encryption का उपयोग करके तेजी से generate होना चाहिए।

// 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)

Alice, Bob को भेजती है। Bob एक Retry संदेश के साथ प्रतिक्रिया देता है। आकार: 48 + payload आकार।

यदि Alice के पास एक valid token नहीं है, तो Alice को Session Request generate करने में asymmetric encryption overhead से बचने के लिए, Session Request के बजाय यह message भेजना चाहिए।

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 :: 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 ब्लॉक

न्यूनतम payload आकार 8 bytes है।

हेडर बाइंडिंग

• Probing resistance प्रदान करने के लिए, एक router को Token Request message के जवाब में Retry message नहीं भेजना चाहिए जब तक कि Token Request message में message type, protocol version, और network ID fields वैध न हों।

• यह एक मानक Noise message नहीं है और handshake का हिस्सा नहीं है। यह Session Request message से connection IDs के अलावा किसी और तरीके से जुड़ा नहीं है।

• अधिकांश त्रुटियों पर, AEAD सहित, या स्पष्ट replay पर Bob को आगे की message processing रोकनी चाहिए और बिना जवाब दिए message को drop कर देना चाहिए।

• Bob को उन connections को reject करना चाहिए जहाँ timestamp value वर्तमान समय से बहुत अधिक भिन्न है। अधिकतम delta time को “D” कहते हैं। Bob को पहले उपयोग की गई handshake values का एक local cache बनाए रखना चाहिए और duplicates को reject करना चाहिए, replay attacks को रोकने के लिए। Cache में values का lifetime कम से कम 2*D होना चाहिए। Cache values implementation-dependent हैं, हालांकि 32-byte X value (या इसका encrypted equivalent) का उपयोग किया जा सकता है।

• Bob एक Retry संदेश भेज सकता है जिसमें शून्य टोकन और एक Termination ब्लॉक हो जिसमें clock skew कारण कोड हो यदि DateTime ब्लॉक में timestamp बहुत अधिक skewed है।

• न्यूनतम आकार: TBD, Session Created के समान नियम?

KDF for Hole Punch

यह संदेश तेज़ी से generate होना चाहिए, केवल symmetric encryption का उपयोग करते हुए।

// 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)

Charlie, Bob से प्राप्त Relay Intro के जवाब में Alice को भेजता है। Alice नए Session Request के साथ जवाब देती है। आकार: 48 + payload size।

Noise payload: नीचे देखें।

कच्ची सामग्री:

+----+----+----+----+----+----+----+----+
  |  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 authentication tag नहीं दिखाया गया):

+----+----+----+----+----+----+----+----+
  |      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 ब्लॉक (वैकल्पिक)

न्यूनतम payload का आकार 8 bytes है। चूंकि DateTime और Address blocks मिलकर उससे अधिक होते हैं, इसलिए केवल इन दो blocks के साथ ही आवश्यकता पूरी हो जाती है।

Connection IDs: दो connection IDs relay nonce से प्राप्त किए जाते हैं। Destination Connection ID, 4-byte big-endian relay nonce की दो प्रतियां है, यानी ((nonce « 32) | nonce)। Source Connection ID, Destination Connection ID का inverse है, यानी ~((nonce « 32) | nonce)।

Alice को header में token को ignore करना चाहिए। Session Request में उपयोग किया जाने वाला token Relay Response block में है।

Noise Payload

प्रत्येक Noise payload में शून्य या अधिक “blocks” होते हैं।

यह वही block format का उपयोग करता है जो NTCP2 और ECIES specifications में परिभाषित है। Individual block types अलग तरीके से परिभाषित हैं। QUIC RFC 9000 में समकक्ष शब्द “frames” है।

चिंताएं हैं कि implementers को कोड साझा करने के लिए प्रोत्साहित करना parsing समस्याओं का कारण बन सकता है। Implementers को कोड साझा करने के फायदे और जोखिमों पर सावधानीपूर्वक विचार करना चाहिए, और यह सुनिश्चित करना चाहिए कि दोनों संदर्भों के लिए ordering और valid block नियम अलग हों।

सुरक्षा संबंधी विचार

एन्क्रिप्टेड payload में एक या अधिक ब्लॉक होते हैं। एक ब्लॉक एक सरल Tag-Length-Value (TLV) प्रारूप है। प्रत्येक ब्लॉक में एक one-byte identifier, एक two-byte length, और शून्य या अधिक bytes का डेटा होता है। यह प्रारूप NTCP2 और ECIES के समान है, हालांकि ब्लॉक definitions भिन्न हैं।

विस्तारशीलता के लिए, receivers को अज्ञात identifiers वाले blocks को नजरअंदाज करना चाहिए, और उन्हें padding के रूप में treat करना चाहिए।

(Poly1305 auth tag दिखाया नहीं गया):

+----+----+----+----+----+----+----+----+
  |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

Header encryption पैकेट के अंतिम 24 bytes को दो ChaCha20 operations के लिए IV के रूप में उपयोग करती है। चूंकि सभी packets 16 byte MAC के साथ समाप्त होते हैं, इसके लिए आवश्यक है कि सभी packet payloads न्यूनतम 8 bytes के हों। यदि कोई payload अन्यथा इस आवश्यकता को पूरा नहीं करता है, तो एक Padding block को शामिल किया जाना चाहिए।

अधिकतम ChaChaPoly payload संदेश प्रकार, MTU, और IPv4 या IPv6 address प्रकार के आधार पर भिन्न होता है। अधिकतम payload IPv4 के लिए MTU - 60 और IPv6 के लिए MTU - 80 है। अधिकतम payload data IPv4 के लिए MTU - 63 और IPv6 के लिए MTU - 83 है। ऊपरी सीमा IPv4, 1500 MTU, Data संदेश के लिए लगभग 1440 bytes है। अधिकतम कुल block size अधिकतम payload size है। अधिकतम एकल block size अधिकतम कुल block size है। Block type 1 byte है। Block length 2 bytes है। अधिकतम एकल block data size अधिकतम एकल block size माइनस 3 है।

नोट्स:

• कार्यान्वयनकर्ताओं को यह सुनिश्चित करना चाहिए कि जब एक block को पढ़ा जाता है, तो दोषपूर्ण या दुर्भावनापूर्ण डेटा के कारण reads अगले block में या payload boundary के बाहर overrun न हों।

• Implementation को forward compatibility के लिए अज्ञात block types को ignore करना चाहिए।

ब्लॉक प्रकार:

Block Ordering Rules

Session Confirmed में, Router Info पहला block होना चाहिए।

अन्य सभी संदेशों में, क्रम अनिर्दिष्ट है, निम्नलिखित आवश्यकताओं को छोड़कर: Padding, यदि मौजूद है, तो अंतिम block होना चाहिए। Termination, यदि मौजूद है, तो Padding को छोड़कर अंतिम block होना चाहिए। एक ही payload में कई Padding blocks की अनुमति नहीं है।

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 में data phase के लिए packet header में कोई timestamp नहीं है।
• Implementations को data phase में समय-समय पर DateTime blocks भेजने चाहिए।
• Implementations को network में clock bias को रोकने के लिए निकटतम second तक round करना चाहिए।

हेडर सत्यापन

अपडेटेड विकल्प पास करें। विकल्पों में शामिल हैं: न्यूनतम और अधिकतम padding।

Options block परिवर्तनीय लंबाई का होगा।

+----+----+----+----+----+----+----+----+
  | 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

विकल्प संबंधी समस्याएं:

• विकल्प बातचीत TBD है।

RouterInfo

Alice का RouterInfo Bob को भेजें। केवल Session Confirmed part 2 payload में उपयोग किया जाता है। data phase में उपयोग न करें; इसके बजाय I2NP DatabaseStore Message का उपयोग करें।

न्यूनतम आकार: लगभग 420 बाइट्स, जब तक कि router info में router identity और signature संपीड़ित न हों, जिसकी संभावना कम है।

नोट: Router Info ब्लॉक कभी भी fragmented नहीं होता है। 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 Info वैकल्पिक रूप से gzip के साथ compressed किया जाता है, जैसा कि flag bit 1 द्वारा इंगित किया गया है। यह NTCP2 से अलग है, जहां यह कभी compressed नहीं होता, और DatabaseStore Message से भी अलग है, जहां यह हमेशा compressed होता है। Compression वैकल्पिक है क्योंकि यह आमतौर पर छोटे Router Infos के लिए बहुत कम फायदेमंद होता है, जहां बहुत कम compressible content होता है, लेकिन कई compressible Router Addresses वाले बड़े Router Infos के लिए बहुत फायदेमंद होता है। Compression की सिफारिश की जाती है यदि यह एक Router Info को fragmentation के बिना single Session Confirmed packet में fit करने की अनुमति देता है।

• Session Confirmed संदेश में पहले या एकमात्र fragment का अधिकतम आकार: IPv4 के लिए MTU - 113 या IPv6 के लिए MTU - 133। 1500 बाइट डिफ़ॉल्ट MTU मानते हुए, और संदेश में कोई अन्य blocks नहीं, IPv4 के लिए 1387 या IPv6 के लिए 1367। वर्तमान router infos में से 97% gzipping के बिना 1367 से छोटे हैं। वर्तमान router infos में से 99.9% gzipped होने पर 1367 से छोटे हैं। 1280 बाइट न्यूनतम MTU मानते हुए, और संदेश में कोई अन्य blocks नहीं, IPv4 के लिए 1167 या IPv6 के लिए 1147। वर्तमान router infos में से 94% gzipping के बिना 1147 से छोटे हैं। वर्तमान router infos में से 97% gzipped होने पर 1147 से छोटे हैं।

• frag byte अब अप्रयुक्त है, Router Info block कभी भी fragmented नहीं होता। frag byte को fragment 0, total fragments 1 पर सेट करना आवश्यक है। अधिक जानकारी के लिए ऊपर Session Confirmed Fragmentation अनुभाग देखें।

• Flooding का अनुरोध तब तक नहीं किया जाना चाहिए जब तक कि RouterInfo में प्रकाशित RouterAddresses न हों। प्राप्त करने वाले router को RouterInfo को flood नहीं करना चाहिए जब तक कि उसमें प्रकाशित RouterAddresses न हों।

• यह protocol इस बात की acknowledgment प्रदान नहीं करता कि RouterInfo store या flood किया गया था। यदि acknowledgment चाहिए, और receiver floodfill है, तो sender को इसके बजाय reply token के साथ एक standard I2NP DatabaseStoreMessage भेजना चाहिए।

I2NP Message

एक संशोधित हेडर के साथ पूर्ण I2NP संदेश।

यह NTCP2 की तरह ही I2NP header के लिए समान 9 bytes का उपयोग करता है (type, message id, short expiration)।

+----+----+----+----+----+----+----+----+
  | 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

नोट्स:

• यह वही 9-बाइट I2NP हेडर प्रारूप है जो NTCP2 में उपयोग किया जाता है।

• यह बिल्कुल First Fragment block के समान format है, लेकिन block type इंगित करता है कि यह एक पूर्ण संदेश है।

• 9-बाइट I2NP header सहित अधिकतम आकार IPv4 के लिए MTU - 63 और IPv6 के लिए MTU - 83 है।

ChaCha20/Poly1305

एक I2NP संदेश का पहला fragment (fragment #0) संशोधित header के साथ।

यह NTCP2 के समान I2NP header के लिए 9 bytes का उपयोग करता है (type, message id, short expiration)।

fragments की कुल संख्या निर्दिष्ट नहीं है।

+----+----+----+----+----+----+----+----+
  | 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)

नोट्स:

• यह वही 9-बाइट I2NP हेडर फॉर्मेट है जो NTCP2 में उपयोग किया जाता है।

• यह बिल्कुल I2NP Message block के समान format है, लेकिन block type इंगित करता है कि यह एक message का पहला fragment है।

• आंशिक संदेश की लंबाई शून्य से अधिक होनी चाहिए।

• जैसा कि SSU 1 में है, यह अनुशंसा की जाती है कि अंतिम fragment पहले भेजा जाए, ताकि receiver को fragments की कुल संख्या पता चल जाए और वह receive buffers को कुशलता से allocate कर सके।

• IPv4 के लिए 9-बाइट I2NP header सहित अधिकतम आकार MTU - 63 है और IPv6 के लिए MTU - 83 है।

नोट्स

एक I2NP संदेश का एक अतिरिक्त fragment (fragment संख्या शून्य से अधिक)।

+----+----+----+----+----+----+----+----+
  | 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 की तरह, यह सिफारिश की जाती है कि अंतिम fragment को पहले भेजा जाए, ताकि receiver को fragments की कुल संख्या पता चल जाए और वह receive buffers को कुशलता से allocate कर सके।

• जैसा कि SSU 1 में है, अधिकतम fragment संख्या 127 है, लेकिन व्यावहारिक सीमा 63 या उससे कम है। Implementation लगभग 64 KB के अधिकतम I2NP message size के लिए व्यावहारिक अधिकतम को सीमित कर सकते हैं, जो 1280 न्यूनतम MTU के साथ लगभग 55 fragments है। नीचे Max I2NP Message Size section देखें।

• अधिकतम आंशिक संदेश आकार (frag और message id को छोड़कर) IPv4 के लिए MTU - 68 और IPv6 के लिए MTU - 88 है।

AEAD Error Handling

कनेक्शन को छोड़ दें। यह payload में अंतिम non-padding block होना चाहिए।

+----+----+----+----+----+----+----+----+
  | 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.

नोट्स:

• सभी कारण वास्तव में उपयोग नहीं किए जा सकते हैं, implementation dependent। अधिकांश failures आम तौर पर message को drop कर देती हैं, termination नहीं। ऊपर handshake message sections में notes देखें। सूचीबद्ध अतिरिक्त कारण consistency, logging, debugging, या policy changes के लिए हैं।
• यह अनुशंसा की जाती है कि Termination block के साथ एक ACK block शामिल किया जाए।
• Data phase में, “termination received” के अलावा किसी भी कारण के लिए, peer को “termination received” कारण के साथ termination block के साथ respond करना चाहिए।

RelayRequest

Data message में in-session भेजा गया, Alice से Bob को। नीचे Relay Process सेक्शन देखें।

+----+----+----+----+----+----+----+----+
  |  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 के विपरीत) और यह session के लिए उपयोग किए गए IP से अलग हो सकता है।

हस्ताक्षर:

Alice अनुरोध पर हस्ताक्षर करता है और इसे इस block में शामिल करता है; Bob इसे Relay Intro block में Charlie को forward करता है। Signature algorithm: Alice के router signing key के साथ निम्नलिखित data पर Sign करें:

• prologue: 16 बाइट्स “RelayRequestData”, null-terminated नहीं (संदेश में शामिल नहीं)
• bhash: Bob का 32-बाइट router hash (संदेश में शामिल नहीं)
• chash: Charlie का 32-बाइट router hash (संदेश में शामिल नहीं)
• nonce: 4 बाइट nonce
• relay tag: 4 बाइट relay tag
• timestamp: 4 बाइट timestamp (सेकंड में)
• ver: 1 बाइट SSU version
• asz: 1 बाइट endpoint (port + IP) size (6 या 18)
• AlicePort: 2 बाइट Alice का port number
• Alice IP: (asz - 2) बाइट Alice IP address

प्रारंभिक ChainKey के लिए KDF

Data message में in-session भेजा जाता है, Charlie से Bob को या Bob से Alice को, और Charlie से Alice को Hole Punch message में भी। नीचे Relay Process सेक्शन देखें।

+----+----+----+----+----+----+----+----+
  |  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 द्वारा Session Request में तुरंत किया जाना चाहिए।

हस्ताक्षर:

यदि Charlie सहमत है (response code 0) या अस्वीकार करता है (response code 64 या उससे अधिक), तो Charlie response पर हस्ताक्षर करता है और इसे इस block में शामिल करता है; Bob इसे Relay Response block में Alice को forward करता है। Signature algorithm: निम्नलिखित data को Charlie की router signing key के साथ sign करें:

• prologue: 16 बाइट्स “RelayAgreementOK”, null-terminated नहीं (संदेश में शामिल नहीं)
• bhash: Bob का 32-बाइट router hash (संदेश में शामिल नहीं)
• nonce: 4 बाइट nonce
• timestamp: 4 बाइट timestamp (सेकंड में)
• ver: 1 बाइट SSU version
• csz: 1 बाइट endpoint (port + IP) साइज़ (0 या 6 या 18)
• CharliePort: 2 बाइट Charlie का port नंबर (यदि csz 0 है तो मौजूद नहीं)
• Charlie IP: (csz - 2) बाइट Charlie IP पता (यदि csz 0 है तो मौजूद नहीं)

यदि Bob अस्वीकार करता है (response code 1-63), Bob response पर हस्ताक्षर करता है और इसे इस block में शामिल करता है। Signature algorithm: Bob के router signing key के साथ निम्नलिखित data पर हस्ताक्षर करें:

• prologue: 16 बाइट्स “RelayAgreementOK”, null-terminated नहीं (संदेश में शामिल नहीं)
• bhash: Bob का 32-बाइट router hash (संदेश में शामिल नहीं)
• nonce: 4 बाइट nonce
• timestamp: 4 बाइट timestamp (सेकंड में)
• ver: 1 बाइट SSU version
• csz: 1 बाइट = 0

Session Request के लिए KDF

Data message के माध्यम से in-session भेजा गया, Bob से Charlie को। नीचे Relay Process सेक्शन देखें।

इससे पहले एक RouterInfo block, या I2NP DatabaseStore message block (या fragment) होना चाहिए, जिसमें Alice का Router Info हो, या तो उसी payload में (यदि जगह है), या पिछले message में।

+----+----+----+----+----+----+----+----+
  |  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 के लिए, Alice का IP address हमेशा 4 bytes होता है, क्योंकि Alice IPv4 के माध्यम से Charlie से connect करने की कोशिश कर रही है। IPv6 समर्थित है, और Alice का IP address 16 bytes हो सकता है।

• IPv4 के लिए, यह संदेश एक स्थापित IPv4 कनेक्शन के माध्यम से भेजा जाना चाहिए, क्योंकि यही एकमात्र तरीका है जिससे Bob को Charlie का IPv4 पता पता चलता है ताकि वह RelayResponse_ में Alice को वापस भेज सके। IPv6 समर्थित है, और यह संदेश एक स्थापित IPv6 कनेक्शन के माध्यम से भेजा जा सकता है।

• किसी भी SSU address जो introducers के साथ publish किया गया हो, उसमें “caps” option में “4” या “6” होना चाहिए।

हस्ताक्षर:

Alice अनुरोध पर हस्ताक्षर करती है और Bob इसे इस block में Charlie को forward करता है। Verification algorithm: निम्नलिखित data को Alice के router signing key के साथ verify करें:

• prologue: 16 बाइट्स “RelayRequestData”, null-terminated नहीं (संदेश में शामिल नहीं)
• bhash: Bob का 32-बाइट router hash (संदेश में शामिल नहीं)
• chash: Charlie का 32-बाइट router hash (संदेश में शामिल नहीं)
• nonce: 4 बाइट nonce
• relay tag: 4 बाइट relay tag
• timestamp: 4 बाइट timestamp (सेकंड)
• ver: 1 बाइट SSU version
• asz: 1 बाइट endpoint (port + IP) size (6 या 18)
• AlicePort: 2 बाइट Alice का port number
• Alice IP: (asz - 2) बाइट Alice IP address

PeerTest

Data message इन-सेशन में या Peer Test message आउट-ऑफ़-सेशन में भेजा जाता है। नीचे Peer Test Process सेक्शन देखें।

संदेश 2 के लिए, इसके पहले एक RouterInfo ब्लॉक, या I2NP DatabaseStore संदेश ब्लॉक (या fragment), होना चाहिए जिसमें Alice की Router Info हो, या तो उसी payload में (यदि जगह है), या पिछले संदेश में।

संदेश 4 के लिए, यदि relay को स्वीकार किया जाता है (reason code 0), तो इसे RouterInfo ब्लॉक, या I2NP DatabaseStore संदेश ब्लॉक (या fragment) से पहले आना चाहिए, जिसमें Charlie की Router Info हो, या तो उसी 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 के विपरीत, message 1 में Alice का IP address और port शामिल होना आवश्यक है।

• IPv6 पतों का परीक्षण समर्थित है, और Alice-Bob और Alice-Charlie संचार IPv6 के माध्यम से हो सकता है, यदि Bob और Charlie अपने प्रकाशित IPv6 पते में ‘B’ क्षमता के साथ समर्थन का संकेत देते हैं। विवरण के लिए Proposal 126 देखें।

Alice अपनी अनुरोध Bob को transport (IPv4 या IPv6) पर मौजूदा session का उपयोग करके भेजती है जिसे वह test करना चाहती है। जब Bob को Alice से IPv4 के माध्यम से अनुरोध प्राप्त होता है, तो Bob को एक Charlie का चयन करना चाहिए जो IPv4 address advertise करता है। जब Bob को Alice से IPv6 के माध्यम से अनुरोध प्राप्त होता है, तो Bob को एक Charlie का चयन करना चाहिए जो IPv6 address advertise करता है। वास्तविक Bob-Charlie communication IPv4 या IPv6 के माध्यम से हो सकता है (यानी, Alice के address type से स्वतंत्र)।

• संदेश 1-4 को एक मौजूदा session में एक Data message में समाहित होना चाहिए।

• Bob को message 2 भेजने से पहले Charlie को Alice का RI भेजना होगा।

• यदि स्वीकार किया जाता है (reason code 0) तो Bob को message 4 भेजने से पहले Charlie का RI Alice को भेजना होगा।

• संदेश 5-7 को Peer Test संदेश में out-of-session होना चाहिए।

• संदेश 5 और 7 में संदेश 3 और 4 में भेजे गए समान signed data हो सकते हैं, या इसे नए timestamp के साथ पुनर्जनित किया जा सकता है। Signature वैकल्पिक है।

• Message 6 में वही signed data हो सकता है जो messages 1 और 2 में भेजा गया था, या यह एक नए timestamp के साथ पुनः generate हो सकता है। Signature वैकल्पिक है।

हस्ताक्षर:

Alice अनुरोध पर हस्ताक्षर करती है और इसे message 1 में शामिल करती है; Bob इसे message 2 में Charlie को भेजता है। Charlie प्रतिक्रिया पर हस्ताक्षर करता है और इसे message 3 में शामिल करता है; Bob इसे message 4 में Alice को भेजता है। हस्ताक्षर एल्गोरिदम: Alice की या Charlie की signing key के साथ निम्नलिखित डेटा पर हस्ताक्षर करें या सत्यापित करें:

• prologue: 16 bytes “PeerTestValidate”, null-terminated नहीं (संदेश में शामिल नहीं)
• bhash: Bob का 32-byte router hash (संदेश में शामिल नहीं)
• ahash: Alice का 32-byte router hash (केवल संदेश 3 और 4 के लिए signature में उपयोग; संदेश 3 या 4 में शामिल नहीं)
• ver: 1 byte SSU version
• nonce: 4 byte test nonce
• timestamp: 4 byte timestamp (सेकंड में)
• asz: 1 byte endpoint (port + IP) size (6 या 18)
• AlicePort: 2 byte Alice का port number
• Alice IP: (asz - 2) byte Alice IP address

पेलोड

TODO केवल अगर हम keys को rotate करते हैं

+----+----+----+----+----+----+----+----+
  | 11 |  size   |      TBD               |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 11
  size :: 2 bytes, big endian, size of data to follow

नोट्स

4 byte ack through, इसके बाद एक ack count और शून्य या अधिक nack/ack ranges।

यह डिज़ाइन QUIC से अनुकूलित और सरलीकृत है। डिज़ाइन के लक्ष्य निम्नलिखित हैं:

• हम एक “bitfield” को कुशलतापूर्वक encode करना चाहते हैं, जो कि acked packets को दर्शाने वाला bits का एक अनुक्रम है।
• bitfield में ज्यादातर 1’s होते हैं। 1’s और 0’s दोनों आम तौर पर क्रमिक “clumps” में आते हैं।
• packet में acks के लिए उपलब्ध स्थान की मात्रा अलग-अलग होती है।
• सबसे महत्वपूर्ण bit सबसे ऊंचे नंबर वाला होता है। कम नंबर वाले कम महत्वपूर्ण होते हैं। सबसे ऊंचे bit से एक निश्चित दूरी के नीचे, सबसे पुराने bits को “भुला दिया” जाएगा और फिर कभी नहीं भेजा जाएगा।

नीचे निर्दिष्ट encoding इन design goals को पूरा करती है, सबसे ऊंचे bit की संख्या भेजकर जो 1 पर set है, साथ ही उससे नीचे के अतिरिक्त consecutive bits जो भी 1 पर set हैं। उसके बाद, यदि जगह है, तो एक या अधिक “ranges” जो consecutive 0 bits और consecutive 1 bits की संख्या निर्दिष्ट करते हैं जो उससे नीचे हैं। अधिक background के लिए QUIC RFC 9000 section 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

उदाहरण:

हम केवल packet 10 को ACK करना चाहते हैं:

• Ack Through: 10
• acnt: 0
• कोई रेंज शामिल नहीं हैं

हमें केवल packets 8-10 को ACK करना है:

• Ack Through: 10
• acnt: 2
• कोई रेंज शामिल नहीं हैं

हम 10 9 8 6 5 2 1 0 को ACK करना चाहते हैं, और 7 4 3 को NACK करना चाहते हैं। ACK Block की encoding है:

• 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)

नोट्स:

• Ranges उपस्थित नहीं हो सकते हैं। Ranges की अधिकतम संख्या निर्दिष्ट नहीं है, packet में जितने फिट हो सकें उतने हो सकते हैं।
• यदि 255 से अधिक consecutive packets को ack कर रहे हैं तो Range nack शून्य हो सकता है।
• यदि 255 से अधिक consecutive packets को nack कर रहे हैं तो Range ack शून्य हो सकता है।
• Range nack और ack दोनों शून्य नहीं हो सकते।
• अंतिम range के बाद, packets न तो acked होते हैं और न ही nacked। Ack block की लंबाई और पुराने acks/nacks को कैसे handle किया जाता है यह ack block के sender पर निर्भर करता है। चर्चा के लिए नीचे ack sections देखें।
• Ack through वह सबसे ऊंची packet number होनी चाहिए जो प्राप्त हुई है, और इससे ऊंची कोई भी packets प्राप्त नहीं हुई हैं। हालांकि, सीमित स्थितियों में, यह कम हो सकती है, जैसे कि एक single packet को ack करना जो “hole को fill करता है”, या एक simplified implementation जो सभी प्राप्त packets की state maintain नहीं करता। सबसे ऊंची प्राप्त के ऊपर, packets न तो acked होते हैं और न ही nacked, लेकिन कई ack blocks के बाद, fast retransmit mode में जाना उपयुक्त हो सकता है।
• यह format QUIC में उपलब्ध format का एक simplified version है। यह बड़ी संख्या में ACKs को efficiently encode करने के लिए डिज़ाइन किया गया है, NACKs के bursts के साथ।
• ACK blocks का उपयोग data phase packets को acknowledge करने के लिए किया जाता है। ये केवल in-session data phase packets के लिए include किए जाने हैं।

Address

2 byte port और 4 या 16 byte IP address। Alice का address, Bob द्वारा Alice को भेजा गया, या Bob का address, Alice द्वारा Bob को भेजा गया।

+----+----+----+----+----+----+----+----+
  | 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 message में भेजा जा सकता है। Session Created message में समर्थित नहीं है, क्योंकि Bob के पास अभी तक Alice का RI नहीं है, और वह नहीं जानता कि Alice relay का समर्थन करता है या नहीं। इसके अलावा, यदि Bob को incoming connection मिल रहा है, तो उसे शायद introducers की आवश्यकता नहीं है (सिवाय शायद अन्य प्रकार ipv4/ipv6 के लिए)।

जब Session Request में भेजा जाता है, तो Bob Session Created संदेश में एक Relay Tag के साथ प्रतिक्रिया दे सकता है, या Alice की पहचान को मान्य करने के लिए Session Confirmed में Alice के RouterInfo प्राप्त होने तक प्रतीक्षा करने का विकल्प चुन सकता है और फिर Data संदेश में प्रतिक्रिया दे सकता है। यदि Bob Alice के लिए relay नहीं करना चाहता, तो वह Relay Tag block नहीं भेजता।

+----+----+----+
  | 15 |    0    |
  +----+----+----+

  blk :: 15
  size :: 2 bytes, big endian, value = 0

पेलोड

यह Bob द्वारा Session Confirmed या Data message में भेजा जा सकता है, Alice के Relay Tag Request के जवाब में।

जब Relay Tag Request को Session Request में भेजा जाता है, तो Bob Session Created message में Relay Tag के साथ जवाब दे सकता है, या Alice की पहचान को validate करने के लिए Session Confirmed में Alice के RouterInfo को receive करने तक इंतजार करना चुन सकता है और फिर Data message में जवाब दे सकता है। यदि Bob Alice के लिए relay नहीं करना चाहता, तो वह Relay Tag block नहीं भेजता।

+----+----+----+----+----+----+----+
  | 16 |    4    |    relay tag      |
  +----+----+----+----+----+----+----+

  blk :: 16
  size :: 2 bytes, big endian, value = 4
  relay tag :: 4 bytes, big endian, nonzero

नोट्स

बाद के कनेक्शन के लिए। आमतौर पर Session Created और Session Confirmed संदेशों में शामिल किया जाता है। यदि पिछला token समाप्त हो जाता है तो लंबे समय तक चलने वाले session के 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 bytes का डेटा साइज़, जिसमें random डेटा हो, अनुशंसित है लेकिन आवश्यक नहीं है।

Path Response

Path Challenge में प्राप्त data के साथ एक Pong, Path Challenge के reply के रूप में, keep-alive के लिए या IP/Port change को validate करने के लिए उपयोग किया जाता है।

+----+----+----+----+----+----+----+----+
  | 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

वैकल्पिक रूप से प्रत्येक दिशा में handshake में शामिल किया जाता है, पहले packet number को निर्दिष्ट करने के लिए जो भेजा जाएगा। यह header encryption के लिए अधिक सुरक्षा प्रदान करता है, TCP के समान।

पूर्ण रूप से निर्दिष्ट नहीं, वर्तमान में समर्थित नहीं।

+----+----+----+----+----+----+----+
  | 20 |  size   |  First pkt number |
  +----+----+----+----+----+----+----+

  blk :: 20
  size :: 4
  pkt num :: The first packet number to be sent in the data phase

Congestion

यह ब्लॉक congestion control जानकारी का आदान-प्रदान करने के लिए एक extensible method के रूप में डिज़ाइन किया गया है। Congestion control जटिल हो सकता है और यह विकसित हो सकता है जैसे-जैसे हमें live testing में protocol के साथ अधिक अनुभव मिलता है, या पूर्ण rollout के बाद।

यह किसी भी congestion जानकारी को high-usage I2NP, First Fragment, Followon Fragment, और ACK blocks से बाहर रखता है, जहाँ flags के लिए कोई स्थान आवंटित नहीं है। जबकि Data packet header में तीन bytes के unused flags हैं, यह भी extensibility के लिए सीमित स्थान प्रदान करता है, और कमजोर encryption सुरक्षा देता है।

जबकि दो bits की जानकारी के लिए 4-byte block का उपयोग करना कुछ हद तक wasteful है, इसे एक अलग block में रखकर, हम इसे आसानी से अतिरिक्त डेटा जैसे कि वर्तमान window sizes, मापा गया RTT, या अन्य flags के साथ extend कर सकते हैं। अनुभव से पता चला है कि केवल flag bits अक्सर अपर्याप्त होते हैं और advanced congestion control schemes के implementation के लिए awkward होते हैं। उदाहरण के लिए, ACK block में किसी भी संभावित congestion control feature के लिए support जोड़ने की कोशिश करना, space की बर्बादी करेगा और उस block की parsing में जटिलता जोड़ देगा।

Implementation को यह नहीं मानना चाहिए कि दूसरा router यहाँ शामिल किसी विशेष flag bit या feature को support करता है, जब तक कि इस specification के भविष्य के version द्वारा implementation आवश्यक न हो।

यह block शायद payload में अंतिम non-padding block होना चाहिए।

+----+----+----+----+
  | 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 payloads के अंदर padding के लिए है। सभी संदेशों के लिए padding AEAD payloads के अंदर होती है।

Padding को मोटे तौर पर negotiated parameters का पालन करना चाहिए। Bob ने अपने requested tx/rx min/max parameters को Session Created में भेजा था। Alice ने अपने requested tx/rx min/max parameters को Session Confirmed में भेजा था। Data phase के दौरान updated options भेजे जा सकते हैं। ऊपर दी गई options block की जानकारी देखें।

यदि उपस्थित है, तो यह payload में अंतिम block होना चाहिए।

+----+----+----+----+----+----+----+----+
  |254 |  size   |      padding           |
  +----+----+----+                        +
  |                                       |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  blk :: 254
  size :: 2 bytes, big endian, size of padding to follow
  padding :: random data

नोट्स:

• Size = 0 की अनुमति है।

• Padding रणनीतियाँ TBD।

• न्यूनतम padding TBD।

• केवल-padding payloads की अनुमति है।

• Padding defaults TBD।

• Padding parameter negotiation के लिए options block देखें

• Min/max padding parameters के लिए options block देखें

• MTU से अधिक न करें। यदि अधिक padding आवश्यक है, तो कई संदेश भेजें।

• Negotiated padding के उल्लंघन पर router response implementation-dependent है।

• पैडिंग की लंबाई या तो प्रति-संदेश आधार पर निर्णय लेने और लंबाई वितरण के अनुमान, या यादृच्छिक देरी जोड़ने की आवश्यकता है। ये प्रतिकारी उपाय DPI का प्रतिरोध करने के लिए शामिल किए जाने हैं, क्योंकि संदेश आकार अन्यथा यह प्रकट कर देंगे कि I2P ट्रैफिक ट्रांसपोर्ट प्रोटोकॉल द्वारा ले जाया जा रहा है। सटीक पैडिंग स्कीम भविष्य के कार्य का एक क्षेत्र है, NTCP2 का परिशिष्ट A इस विषय पर अधिक जानकारी प्रदान करता है।

Replay Prevention

SSU2 को एक आक्रमणकारी द्वारा replay किए गए संदेशों के प्रभाव को कम करने के लिए डिज़ाइन किया गया है।

Token Request, Retry, Session Request, Session Created, Hole Punch, और out-of-session Peer Test संदेशों में DateTime ब्लॉक होना आवश्यक है।

Alice और Bob दोनों यह सत्यापित करते हैं कि इन संदेशों का समय एक वैध skew के भीतर है (अनुशंसित +/- 2 मिनट)। “probing resistance” के लिए, Bob को Token Request या Session Request संदेशों का उत्तर नहीं देना चाहिए यदि skew अवैध है, क्योंकि ये संदेश replay या probing attack हो सकते हैं।

Bob डुप्लिकेट Token Request और Retry संदेशों को अस्वीकार करना चुन सकता है, भले ही skew वैध हो, Bloom filter या अन्य तंत्र के माध्यम से। हालांकि, इन संदेशों का उत्तर देने का आकार और CPU लागत कम है। सबसे खराब स्थिति में, एक replayed Token Request संदेश पहले भेजे गए token को अमान्य कर सकता है।

टोकन प्रणाली replayed Session Request संदेशों के प्रभाव को काफी कम कर देती है। चूंकि टोकन का उपयोग केवल एक बार किया जा सकता है, एक replayed Session Request संदेश में कभी भी वैध टोकन नहीं होगा। Bob duplicate Session Request संदेशों को अस्वीकार करना चुन सकता है, भले ही skew वैध हो, Bloom filter या अन्य तंत्र के माध्यम से। हालांकि, Retry संदेश के साथ जवाब देने का आकार और CPU लागत कम है। सबसे खराब स्थिति में, Retry संदेश भेजना पहले भेजे गए टोकन को अमान्य बना सकता है।

डुप्लिकेट Session Created और Session Confirmed संदेश validate नहीं होंगे क्योंकि Noise handshake state उन्हें decrypt करने के लिए सही स्थिति में नहीं होगा। सबसे खराब स्थिति में, एक peer एक स्पष्ट डुप्लिकेट Session Created के जवाब में Session Confirmed को retransmit कर सकता है।

दोहराए गए Hole Punch और Peer Test संदेशों का कम या कोई प्रभाव नहीं होना चाहिए।

Routers को data message packet number का उपयोग करके duplicate data phase messages का पता लगाना और उन्हें drop करना चाहिए। हर packet number का उपयोग केवल एक बार होना चाहिए। Replayed messages को ignore करना चाहिए।

Handshake Retransmission

Session Request

यदि Alice को कोई Session Created या Retry प्राप्त नहीं होता है:

समान स्रोत और कनेक्शन ID, ephemeral key, और packet number 0 बनाए रखें। या, बस वही encrypted packet को बनाए रखें और retransmit करें। Packet number को increment नहीं करना चाहिए, क्योंकि इससे Session Created message को encrypt करने के लिए उपयोग किए जाने वाले chained hash value में परिवर्तन हो जाएगा।

अनुशंसित पुनः प्रेषण अंतराल: 1.25, 2.5, और 5 सेकंड (पहली बार भेजे जाने के 1.25, 3.75, और 8.75 सेकंड बाद)। अनुशंसित timeout: कुल 15 सेकंड

Session Created

यदि Bob को कोई Session Confirmed प्राप्त नहीं होता है:

समान source और connection IDs, ephemeral key, और packet number 0 बनाए रखें। या, बस encrypted packet को retain करें। Packet number को increment नहीं किया जाना चाहिए, क्योंकि इससे chained hash value बदल जाएगा जो Session Confirmed message को encrypt करने के लिए उपयोग किया जाता है।

अनुशंसित retransmission अंतराल: 1, 2, और 4 सेकंड (पहली बार भेजे जाने के 1, 3, और 7 सेकंड बाद)। अनुशंसित timeout: कुल 12 सेकंड

Session Confirmed

SSU 1 में, Alice तब तक data phase में नहीं जाती जब तक Bob से पहला data packet प्राप्त नहीं होता। यह SSU 1 को एक two-round-trip setup बनाता है।

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 को तब तक retransmit करें जब तक कोई डेटा संदेश प्राप्त न हो जाए।

3. हम XK के बजाय IK का उपयोग कर सकते हैं, क्योंकि इसमें handshake में केवल दो संदेश होते हैं, लेकिन यह एक अतिरिक्त DH (3 के बजाय 4) का उपयोग करता है।

अनुशंसित implementation विकल्प 2) है। Alice को Session Confirmed संदेश को पुनः प्रेषित करने के लिए आवश्यक जानकारी को बनाए रखना चाहिए। Alice को Session Confirmed संदेश के पुनः प्रेषित होने के बाद सभी Data संदेशों को भी पुनः प्रेषित करना चाहिए।

Session Confirmed को retransmit करते समय, समान source और connection IDs, ephemeral key, और packet number 1 को बनाए रखें। या, केवल encrypted packet को retain करें। Packet number को increment नहीं किया जाना चाहिए, क्योंकि इससे chained hash value बदल जाएगी जो split() function के लिए एक input है।

Bob Session Confirmed संदेश प्राप्त होने से पहले प्राप्त हुए data messages को retain (queue) कर सकता है। Session Confirmed संदेश प्राप्त होने से पहले न तो header protection keys और न ही decryption keys उपलब्ध होती हैं, इसलिए Bob को पता नहीं होता कि ये data messages हैं, लेकिन यह अनुमान लगाया जा सकता है। Session Confirmed संदेश प्राप्त होने के बाद, Bob queued Data messages को decrypt और process करने में सक्षम हो जाता है। यदि यह बहुत जटिल है, तो Bob केवल undecryptable Data messages को drop कर सकता है, क्योंकि Alice उन्हें retransmit करेगी।

नोट: यदि session confirmed पैकेट खो जाते हैं, तो Bob session created को पुनः भेजेगा। session created हेडर Alice की intro key के साथ डिक्रिप्ट नहीं होगा, क्योंकि यह Bob की intro key के साथ सेट है (जब तक कि Bob की intro key के साथ fallback decryption नहीं किया जाता)। Bob तुरंत session confirmed पैकेट को पुनः भेज सकता है यदि पहले ack नहीं हुआ है, और एक undecryptable पैकेट प्राप्त होता है।

Token Request

यदि Alice को कोई Retry प्राप्त नहीं होता है:

समान source और connection IDs बनाए रखें। एक implementation एक नया random packet number generate कर सकता है और एक नया packet encrypt कर सकता है; या यह समान packet number को reuse कर सकता है या केवल समान encrypted packet को retain और retransmit कर सकता है। Packet number को increment नहीं किया जाना चाहिए, क्योंकि इससे Session Created message को encrypt करने के लिए उपयोग किए जाने वाले chained hash value में परिवर्तन हो जाएगा।

अनुशंसित retransmission अंतराल: 3 और 6 सेकंड (पहली बार भेजने के बाद 3 और 9 सेकंड)। अनुशंसित timeout: कुल 15 सेकंड

Retry

यदि Bob को कोई Session Request प्राप्त नहीं होता है:

एक Retry संदेश को timeout पर पुनः प्रेषित नहीं किया जाता है, ताकि spoofed source addresses के प्रभावों को कम किया जा सके।

हालांकि, एक Retry message को दोबारा भेजा जा सकता है यदि मूल (अवैध) token के साथ एक दोहराया गया Session Request message प्राप्त होता है, या एक दोहराये गए Token Request message के जवाब में। दोनों मामलों में, यह दर्शाता है कि Retry message खो गया था।

यदि दूसरा Session Request संदेश एक अलग लेकिन फिर भी अमान्य token के साथ प्राप्त होता है, तो pending session को drop करें और प्रतिक्रिया न दें।

यदि Retry संदेश को पुनः भेजा जा रहा है: समान source और connection IDs और token को बनाए रखें। एक implementation एक नया random packet number generate कर सकती है और एक नया packet encrypt कर सकती है; या यह समान packet number का पुनः उपयोग कर सकती है या केवल समान encrypted packet को retain करके retransmit कर सकती है।

Total Timeout

handshake के लिए अनुशंसित कुल timeout 20 सेकंड है।

Duplicates and Error Handling

तीन Noise handshake संदेशों Session Request, Session Created, और Session Confirmed के duplicates को header के MixHash() से पहले detect किया जाना चाहिए। जबकि Noise AEAD processing संभवतः उसके बाद fail हो जाएगी, handshake hash पहले से ही corrupt हो चुका होगा।

यदि तीन संदेशों में से कोई भी संदेश दूषित हो जाता है और AEAD में असफल हो जाता है, तो handshake को बाद में पुनः प्रसारण के साथ भी पुनर्प्राप्त नहीं किया जा सकता, क्योंकि दूषित संदेश पर MixHash() पहले ही कॉल किया जा चुका होता है।

Tokens

Session Request header में Token का उपयोग DoS mitigation के लिए किया जाता है, source address spoofing को रोकने के लिए, और replay attacks के खिलाफ प्रतिरोध के रूप में।

यदि Bob Session Request message में token को स्वीकार नहीं करता है, तो Bob message को decrypt नहीं करता है, क्योंकि इसके लिए एक महंगा DH operation की आवश्यकता होती है। Bob सिर्फ एक नया token के साथ Retry message भेजता है।

यदि उस token के साथ एक बाद का Session Request message प्राप्त होता है, तो Bob उस message को decrypt करने के लिए आगे बढ़ता है और handshake के साथ आगे बढ़ता है।

टोकन एक यादृच्छिक रूप से उत्पन्न 8 बाइट मान होना चाहिए, यदि टोकन का जेनरेटर मानों और संबद्ध IP और पोर्ट को स्टोर करता है (इन-मेमोरी या स्थायी रूप से)। जेनरेटर एक अपारदर्शी मान उत्पन्न नहीं कर सकता, उदाहरण के लिए, IP, पोर्ट, और वर्तमान घंटे या दिन के SipHash (गुप्त सीड K0, K1 के साथ) का उपयोग करके ऐसे टोकन बनाना जिन्हें इन-मेमोरी में सहेजने की आवश्यकता न हो, क्योंकि यह विधि पुन: उपयोग किए गए टोकन और replay attacks को अस्वीकार करना कठिन बना देती है।

टोकन केवल एक बार उपयोग किए जा सकते हैं। Bob से Alice को Retry संदेश में भेजे गए टोकन का तुरंत उपयोग किया जाना चाहिए, और यह कुछ सेकंड में समाप्त हो जाता है। स्थापित सत्र में New Token ब्लॉक में भेजे गए टोकन का उपयोग बाद के कनेक्शन में किया जा सकता है, और यह उस ब्लॉक में निर्दिष्ट समय पर समाप्त हो जाता है। समाप्ति का समय भेजने वाले द्वारा निर्दिष्ट किया जाता है; अनुशंसित मान न्यूनतम एक घंटा, अधिकतम कई घंटे हैं।

यदि किसी router का IP या port बदल जाता है, तो उसे पुराने IP या port के लिए सभी सहेजे गए tokens (inbound और outbound दोनों) को हटा देना चाहिए, क्योंकि वे अब मान्य नहीं हैं। Tokens को वैकल्पिक रूप से router restart के दौरान बनाए रखा जा सकता है, यह implementation पर निर्भर है। एक unexpired token की स्वीकृति की गारंटी नहीं है; यदि Bob ने अपने सहेजे गए tokens को भूला दिया है या हटा दिया है, तो वह Alice को एक Retry भेजेगा। एक router token storage को सीमित करने का विकल्प चुन सकता है, और सबसे पुराने संग्रहीत tokens को हटा सकता है भले ही उनकी अवधि समाप्त न हुई हो।

नए Token blocks Alice से Bob को या Bob से Alice को भेजे जा सकते हैं। ये आम तौर पर एक बार भेजे जाते हैं, session establishment के दौरान या उसके तुरंत बाद। Token को expiration से पहले या बाद में नए expiration time के साथ फिर से भेजा जा सकता है, या एक नया token भेजा जा सकता है। Routers को यह मान लेना चाहिए कि केवल अंतिम प्राप्त token ही valid है; समान IP/port के लिए कई inbound या outbound tokens को store करने की कोई आवश्यकता नहीं है।

एक token स्रोत IP/port और गंतव्य IP/port के संयोजन से बंधा होता है। IPv4 पर प्राप्त एक token को IPv6 के लिए उपयोग नहीं किया जा सकता या इसके विपरीत।

यदि session के दौरान कोई भी peer नए IP या port पर migrate हो जाता है (Connection Migration section देखें), तो पहले से exchange किए गए tokens invalid हो जाते हैं, और नए tokens का exchange करना आवश्यक होता है।

Implementation इस बात की अनुमति देते हैं, लेकिन आवश्यक नहीं है, कि tokens को disk पर save करें और restart पर उन्हें reload करें। यदि persist किया जाता है, तो implementation को यह सुनिश्चित करना चाहिए कि उन्हें reload करने से पहले shutdown के बाद से IP और port नहीं बदले हैं।

I2NP Message Fragmentation

SSU 1 से अंतर

नोट: जैसा कि SSU 1 में है, प्रारंभिक fragment में fragments की कुल संख्या या कुल लंबाई की जानकारी नहीं होती। Follow-on fragments में उनके offset की जानकारी नहीं होती। यह sender को packet में उपलब्ध स्थान के आधार पर “on the fly” fragmenting की लचीलापन प्रदान करता है। (Java I2P ऐसा नहीं करता; यह पहला fragment भेजने से पहले “pre-fragments” करता है) हालांकि, यह receiver पर बोझ डालता है कि वह out-of-order प्राप्त fragments को store करे और सभी fragments प्राप्त होने तक reassembly में देरी करे।

SSU 1 की तरह, fragments के किसी भी retransmission में fragment के पिछले transmission की length (और implicit offset) को preserve करना आवश्यक है।

SSU 2 तीन मामलों (पूरा संदेश, प्रारंभिक fragment, और follow-on fragment) को तीन अलग block प्रकारों में अलग करता है, प्रसंस्करण दक्षता में सुधार के लिए।

I2NP Message Duplication

यह protocol I2NP messages की duplicate delivery को पूरी तरह से नहीं रोकता है। IP-layer duplicates या replay attacks का पता SSU2 layer पर लगाया जाएगा, क्योंकि हर packet number का उपयोग केवल एक बार ही किया जा सकता है।

जब I2NP संदेश या fragments को नए packets में retransmit किया जाता है, तो यह SSU2 layer पर detectable नहीं होता। router को I2NP expiration (बहुत पुराना और भविष्य में बहुत दूर दोनों) को enforce करना चाहिए और I2NP message ID के आधार पर Bloom filter या अन्य mechanism का उपयोग करना चाहिए।

router द्वारा, या SSU2 implementation में, duplicates का पता लगाने के लिए अतिरिक्त mechanisms का उपयोग किया जा सकता है। उदाहरण के लिए, SSU2 हाल ही में प्राप्त message IDs का एक cache बनाए रख सकता है। यह implementation-dependent है।

Congestion Control

यह प्रस्ताव packet numbering और ACK blocks के लिए protocol को निर्दिष्ट करता है। यह एक transmitter के लिए एक कुशल और responsive congestion control algorithm को implement करने के लिए पर्याप्त real-time जानकारी प्रदान करता है, जबकि उस implementation में लचीलेपन और नवाचार की अनुमति देता है। यह अनुभाग implementation लक्ष्यों पर चर्चा करता है और सुझाव प्रदान करता है। सामान्य मार्गदर्शन RFC 9002 में मिल सकता है। retransmission timers के मार्गदर्शन के लिए RFC 6298 भी देखें।

ACK-only डेटा पैकेट्स को bytes या packets in-flight में गिना नहीं जाना चाहिए और ये congestion-controlled नहीं हैं। TCP के विपरीत, SSU2 इन पैकेट्स के loss का पता लगा सकता है और उस जानकारी का उपयोग congestion state को adjust करने के लिए किया जा सकता है। हालांकि, यह document ऐसा करने के लिए कोई mechanism निर्दिष्ट नहीं करता है।

यदि वांछित हो तो कुछ अन्य non-data blocks वाले packets को भी congestion control से बाहर रखा जा सकता है, implementation-dependent। उदाहरण के लिए:

• Peer Test
• Relay request/intro/response
• Path challenge/response

यह सिफारिश की जाती है कि congestion control byte count के आधार पर हो, packet count के आधार पर नहीं, TCP RFCs और QUIC RFC 9002 में दिए गए मार्गदर्शन का पालन करते हुए। kernel या middleboxes में buffer overflow को रोकने के लिए एक अतिरिक्त packet count limit भी उपयोगी हो सकती है, implementation पर निर्भर करते हुए, हालांकि इससे काफी जटिलता बढ़ सकती है। यदि per-session और/या total packet output bandwidth-limited और/या paced है, तो यह packet count limiting की आवश्यकता को कम कर सकता है।

Packet Numbers

SSU 1 में, ACKs और NACKs में I2NP message नंबर और fragment bitmasks शामिल होते थे। Transmitters ने outbound messages (और उनके fragments) के ACK status को track किया और आवश्यकता अनुसार fragments को retransmit किया।

SSU 2 में, ACKs और NACKs में packet numbers होते हैं। Transmitters को एक data structure बनाए रखना चाहिए जिसमें packet numbers और उनकी contents का mapping हो। जब कोई packet ACK या NACK होता है, तो transmitter को यह निर्धारित करना चाहिए कि उस packet में कौन से I2NP messages और fragments थे, ताकि यह तय कर सके कि क्या retransmit करना है।

Session Confirmed ACK

Bob पैकेट 0 का ACK भेजता है, जो Session Confirmed संदेश को स्वीकार करता है और Alice को डेटा चरण में आगे बढ़ने की अनुमति देता है, और संभावित पुनः प्रसारण के लिए सहेजे गए बड़े Session Confirmed संदेश को छोड़ देता है। यह SSU 1 में Bob द्वारा भेजे गए DeliveryStatusMessage को बदल देता है।

Bob को Session Confirmed संदेश प्राप्त करने के बाद जितनी जल्दी हो सके ACK भेजना चाहिए। एक छोटी देरी (50 ms से अधिक नहीं) स्वीकार्य है, क्योंकि Session Confirmed संदेश के तुरंत बाद कम से कम एक Data संदेश आना चाहिए, ताकि ACK Session Confirmed और Data संदेश दोनों को acknowledge कर सके। इससे Bob को Session Confirmed संदेश को retransmit करने से बचने में मदद मिलेगी।

Generating ACKs

परिभाषा: Ack-eliciting packets: जो packets में ack-eliciting blocks होते हैं, वे receiver से maximum acknowledgment delay के भीतर एक ACK प्राप्त करते हैं और इन्हें ack-eliciting packets कहा जाता है।

Routers अपने द्वारा प्राप्त और प्रोसेस किए गए सभी packets को acknowledge करते हैं। हालांकि, केवल ack-eliciting packets के कारण maximum ack delay के भीतर ACK block भेजा जाता है। जो packets ack-eliciting नहीं हैं, वे केवल तभी acknowledge होते हैं जब अन्य कारणों से ACK block भेजा जाता है।

किसी भी कारण से packet भेजते समय, एक endpoint को ACK block शामिल करने का प्रयास करना चाहिए यदि हाल ही में कोई नहीं भेजा गया है। ऐसा करने से peer पर समय पर loss detection में मदद मिलती है।

सामान्यतः, एक receiver से बार-बार feedback मिलना loss और congestion response में सुधार करता है, लेकिन इसे उस अत्यधिक load के विरुद्ध संतुलित करना होता है जो एक receiver द्वारा उत्पन्न होता है जो प्रत्येक ack-eliciting packet के response में एक ACK block भेजता है। नीचे दिया गया मार्गदर्शन इस संतुलन को बनाने का प्रयास करता है।

निम्नलिखित को छोड़कर किसी भी block वाले In-session data packets ack-eliciting होते हैं:

• ACK block
• Address block
• DateTime block
• Padding block
• Termination block
• Termination block के साथ एक ही packet में कोई भी blocks
• अन्य?

“termination received” के अलावा किसी अन्य कारण के साथ Termination block वाले packets को “termination received” के साथ Termination block वाले packet से acknowledge किया जाता है।

सत्र के बाहर के पैकेट्स, जिनमें handshake संदेश और peer test संदेश 5-7 शामिल हैं, उनके अपने acknowledgement तंत्र होते हैं। नीचे देखें।

Handshake ACKs

ये विशेष मामले हैं:

• Token Request को Retry द्वारा निहित रूप से ack किया जाता है
• Session Request को Session Created या Retry द्वारा निहित रूप से ack किया जाता है
• Retry को Session Request द्वारा निहित रूप से ack किया जाता है
• Session Created को Session Confirmed द्वारा निहित रूप से ack किया जाता है
• Session Confirmed को तुरंत ack किया जाना चाहिए

Sending ACK Blocks

ACK blocks का उपयोग data phase packets को acknowledge करने के लिए किया जाता है। ये केवल in-session data phase packets के लिए शामिल किए जाने चाहिए।

प्रत्येक packet को कम से कम एक बार acknowledge किया जाना चाहिए, और ack-eliciting packets को अधिकतम देरी के भीतर कम से कम एक बार acknowledge किया जाना चाहिए।

एक endpoint को अपनी अधिकतम देरी के भीतर तुरंत सभी ack-eliciting handshake packets को acknowledge करना चाहिए, निम्नलिखित अपवाद के साथ। Handshake confirmation से पहले, हो सकता है कि endpoint के पास packets को decrypt करने के लिए packet header encryption keys न हों जब वे प्राप्त होते हैं। इसलिए यह उन्हें buffer कर सकता है और जब आवश्यक keys उपलब्ध हो जाती हैं तो उन्हें acknowledge कर सकता है।

चूंकि केवल ACK blocks वाले packets congestion controlled नहीं होते हैं, एक endpoint को ack-eliciting packet प्राप्त करने के जवाब में ऐसा एक से अधिक packet नहीं भेजना चाहिए।

एक endpoint को एक non-ack-eliciting packet के response में non-ack-eliciting packet नहीं भेजना चाहिए, भले ही received packet से पहले packet gaps हों। यह acknowledgments के infinite feedback loop से बचाता है, जो connection को कभी idle बनने से रोक सकता है। Non-ack-eliciting packets का अंततः acknowledgment तब होता है जब endpoint अन्य events के response में ACK block भेजता है।

एक endpoint जो केवल ACK blocks भेज रहा है, वह अपने peer से acknowledgments प्राप्त नहीं करेगा जब तक कि वे acknowledgments ack-eliciting blocks वाले packets में शामिल न हों। एक endpoint को अन्य blocks के साथ ACK block भेजना चाहिए जब नए ack-eliciting packets को acknowledge करना हो। जब केवल non-ack-eliciting packets को acknowledge करने की आवश्यकता हो, तो एक endpoint outgoing blocks के साथ ACK block न भेजने का विकल्प चुन सकता है जब तक कि कोई ack-eliciting packet प्राप्त न हो जाए।

एक endpoint जो केवल non-ack-eliciting packets भेज रहा है, वह कभी-कभी उन packets में एक ack-eliciting block जोड़ने का विकल्प चुन सकता है ताकि यह सुनिश्चित हो सके कि उसे एक acknowledgment प्राप्त हो। उस स्थिति में, एक endpoint को उन सभी packets में ack-eliciting block नहीं भेजना चाहिए जो अन्यथा non-ack-eliciting होते, acknowledgments के अनंत feedback loop से बचने के लिए।

भेजने वाले पक्ष में loss detection में सहायता करने के लिए, एक endpoint को बिना देरी के ACK block generate और send करना चाहिए जब वह इनमें से किसी भी स्थिति में ack-eliciting packet receive करता है:

• जब प्राप्त packet का packet number किसी अन्य ack-eliciting packet से कम हो जो पहले से प्राप्त हो चुका है

• जब पैकेट में सबसे अधिक-क्रमांकित ack-eliciting पैकेट से बड़ा पैकेट नंबर हो जो प्राप्त हुआ है और उस पैकेट तथा इस पैकेट के बीच गुम पैकेट हों।

• जब पैकेट हेडर में ack-immediate फ्लैग सेट होता है

एल्गोरिदम से अपेक्षा की जाती है कि वे उन receivers के प्रति resilient हों जो ऊपर दिए गए guidance का पालन नहीं करते हैं। हालांकि, एक implementation को इन requirements से तभी विचलित होना चाहिए जब endpoint द्वारा बनाए गए connections और network के अन्य users के लिए किसी बदलाव के performance implications पर सावधानीपूर्वक विचार किया गया हो।

ACK Frequency

एक receiver यह निर्धारित करता है कि ack-eliciting packets के जवाब में कितनी बार acknowledgments भेजना है। इस निर्धारण में एक trade-off शामिल है।

Endpoints समयबद्ध acknowledgment पर निर्भर करते हैं loss का पता लगाने के लिए। Window-based congestion controllers अपनी congestion window को प्रबंधित करने के लिए acknowledgments पर निर्भर करते हैं। दोनों मामलों में, acknowledgments को विलंबित करना प्रदर्शन पर प्रतिकूल प्रभाव डाल सकता है।

दूसरी ओर, केवल acknowledgments ले जाने वाले packets की आवृत्ति को कम करना दोनों endpoints पर packet transmission और processing cost को कम करता है। यह गंभीर रूप से asymmetric links पर connection throughput में सुधार कर सकता है और return path capacity का उपयोग करते हुए acknowledgment traffic की मात्रा को कम कर सकता है; RFC 3449 का Section 3 देखें।

एक receiver को कम से कम दो ack-eliciting packets प्राप्त करने के बाद एक ACK block भेजना चाहिए। यह सिफारिश सामान्य प्रकृति की है और TCP endpoint व्यवहार RFC 5681 की सिफारिशों के अनुरूप है। नेटवर्क स्थितियों का ज्ञान, peer के congestion controller का ज्ञान, या आगे के अनुसंधान और प्रयोग बेहतर प्रदर्शन विशेषताओं के साथ वैकल्पिक acknowledgment रणनीतियों का सुझाव दे सकते हैं।

एक receiver कई उपलब्ध packets को process कर सकता है इससे पहले कि वह निर्धारित करे कि response में ACK block भेजना है या नहीं। सामान्यतः, receiver को ACK को RTT / 6, या अधिकतम 150 ms से अधिक delay नहीं करना चाहिए।

डेटा packet header में ack-immediate flag एक अनुरोध है कि receiver रिसेप्शन के तुरंत बाद एक ack भेजे, संभवतः कुछ ms के भीतर। सामान्य तौर पर, receiver को immediate ACK को RTT / 16, या अधिकतम 5 ms से अधिक देर नहीं करनी चाहिए।

Immediate ACK Flag

प्राप्तकर्ता भेजने वाले की send window size नहीं जानता, और इसलिए यह नहीं जानता कि ACK भेजने से पहले कितनी देर प्रतीक्षा करनी चाहिए। data packet header में immediate ACK flag प्रभावी RTT को कम करके अधिकतम throughput बनाए रखने का एक महत्वपूर्ण तरीका है। immediate ACK flag header byte 13, bit 0 है, यानी (header[13] & 0x01)। जब सेट किया जाता है, तो एक तत्काल ACK का अनुरोध किया जाता है। विवरण के लिए ऊपर short header अनुभाग देखें।

भेजने वाले के पास immediate-ack flag कब सेट करना है यह निर्धारित करने के लिए कई संभावित रणनीतियां हो सकती हैं:

• हर N packets में एक बार set करें, कुछ छोटे N के लिए
• packet के burst में अंतिम पर set करें
• जब भी send window लगभग भरा हो तब set करें, उदाहरण के लिए 2/3 से अधिक भरा हो
• retransmitted fragments वाले सभी packets पर set करें

तत्काल ACK flags केवल उन data packets पर आवश्यक होना चाहिए जिनमें I2NP messages या message fragments हों।

ACK Block Size

जब एक ACK block भेजा जाता है, तो acknowledged packets की एक या अधिक ranges शामिल की जाती हैं। पुराने packets के लिए acknowledgments शामिल करना पहले भेजे गए ACK blocks के खो जाने से होने वाले spurious retransmissions की संभावना को कम करता है, बड़े ACK blocks की लागत पर।

ACK blocks को हमेशा सबसे हाल ही में प्राप्त packets को acknowledge करना चाहिए, और packets जितने अधिक क्रम से बाहर होते हैं, उतना ही महत्वपूर्ण है कि updated ACK block को जल्दी भेजा जाए, ताकि peer को packet को lost घोषित करने और इसमें निहित blocks को गलत तरीके से retransmit करने से रोका जा सके। एक ACK block को एक single packet के भीतर फिट होना चाहिए। यदि ऐसा नहीं है, तो पुराने ranges (जिनमें सबसे छोटे packet numbers हैं) को छोड़ दिया जाता है।

एक receiver उन ACK ranges की संख्या को सीमित करता है जिन्हें वह याद रखता है और ACK blocks में भेजता है, दोनों ACK blocks के आकार को सीमित करने और resource exhaustion से बचने के लिए। एक ACK block के लिए acknowledgments प्राप्त करने के बाद, receiver को उन acknowledged ACK ranges को track करना बंद कर देना चाहिए। Senders अधिकांश packets के लिए acknowledgments की अपेक्षा कर सकते हैं, लेकिन यह protocol हर उस packet के लिए acknowledgment की प्राप्ति की गारंटी नहीं देता जिसे receiver process करता है।

यह संभव है कि कई ACK ranges को बनाए रखना ACK block को बहुत बड़ा बना सकता है। एक receiver ACK block के आकार को सीमित करने के लिए unacknowledged ACK Ranges को छोड़ सकता है, जिसकी कीमत sender से बढ़े हुए retransmissions के रूप में चुकानी पड़ती है। यह आवश्यक है यदि ACK block किसी packet में फिट होने के लिए बहुत बड़ा हो जाए। Receivers अन्य blocks के लिए जगह बचाने या acknowledgments द्वारा उपयोग की जाने वाली bandwidth को सीमित करने के लिए ACK block के आकार को और भी सीमित कर सकते हैं।

एक receiver को ACK range को तब तक बनाए रखना चाहिए जब तक कि वह यह सुनिश्चित न कर सके कि वह बाद में उस range में numbers वाले packets को स्वीकार नहीं करेगा। एक minimum packet number बनाए रखना जो ranges के discard होने पर बढ़ता है, यह minimal state के साथ इसे प्राप्त करने का एक तरीका है।

रिसीवर सभी ACK ranges को discard कर सकते हैं, लेकिन उन्हें सबसे बड़ा packet number retain करना होगा जो सफलतापूर्वक process किया गया है, क्योंकि उसका उपयोग बाद के packets से packet numbers को recover करने के लिए किया जाता है।

निम्नलिखित खंड प्रत्येक ACK block में कौन से packets को acknowledge करना है, इसका निर्धारण करने के लिए एक उदाहरणीय दृष्टिकोण का वर्णन करता है। यद्यपि इस algorithm का लक्ष्य प्रत्येक packet के लिए जो process किया जाता है एक acknowledgment उत्पन्न करना है, फिर भी acknowledgments के खो जाने की संभावना बनी रहती है।

Limiting Ranges by Tracking ACK Blocks

जब एक ACK block युक्त packet भेजा जाता है, तो उस block में Ack Through field को save किया जा सकता है। जब एक ACK block युक्त packet को acknowledge किया जाता है, तो receiver भेजे गए ACK block में Ack Through field से कम या बराबर packets को acknowledge करना बंद कर सकता है।

एक receiver जो केवल non-ack-eliciting packets भेजता है, जैसे ACK blocks, हो सकता है लंबे समय तक acknowledgment प्राप्त न करे। इससे receiver को बड़ी संख्या में ACK blocks के लिए लंबे समय तक state maintain करना पड़ सकता है, और जो ACK blocks वह भेजता है वे अनावश्यक रूप से बड़े हो सकते हैं। ऐसी स्थिति में, एक receiver कभी-कभार PING या अन्य छोटे ack-eliciting block भेज सकता है, जैसे प्रति round trip में एक बार, peer से ACK प्राप्त करने के लिए।

ACK block loss के बिना मामलों में, यह algorithm न्यूनतम 1 RTT के reordering की अनुमति देता है। ACK block loss और reordering के साथ मामलों में, यह approach गारंटी नहीं देता कि प्रत्येक acknowledgment sender द्वारा देखा जाए इससे पहले कि वह ACK block में शामिल न रहे। Packets गलत क्रम में receive हो सकते हैं, और उन्हें contain करने वाले सभी बाद के ACK blocks lost हो सकते हैं। इस स्थिति में, loss recovery algorithm spurious retransmissions का कारण बन सकता है, लेकिन sender आगे की progress करता रहेगा।

Congestion

I2P transports I2NP संदेशों की क्रमबद्ध डिलीवरी की गारंटी नहीं देते हैं। इसलिए, एक या अधिक I2NP संदेशों या टुकड़ों वाले Data संदेश का नुकसान अन्य I2NP संदेशों की डिलीवरी को रोकता नहीं है; यहाँ head-of-line blocking नहीं होती है। Implementation को loss recovery चरण के दौरान नए संदेश भेजना जारी रखना चाहिए यदि send window इसकी अनुमति देती है।

Retransmission

एक sender को message की पूरी contents को retain नहीं करना चाहिए, ताकि उसे identically retransmit किया जा सके (handshake messages को छोड़कर, ऊपर देखें)। एक sender को हर बार message भेजते समय up-to-date जानकारी (ACKs, NACKs, और unacknowledged data) वाले messages को assemble करना चाहिए। एक sender को messages से जानकारी को retransmit करने से बचना चाहिए जब वे एक बार acknowledge हो जाएं। इसमें वे messages शामिल हैं जो lost declare होने के बाद acknowledge हो जाते हैं, जो network reordering की उपस्थिति में हो सकता है।

Window

TBD. सामान्य मार्गदर्शन RFC 9002 में मिल सकता है।

Connection Migration

किसी peer का IP या port एक session के जीवनकाल के दौरान बदल सकता है। IP परिवर्तन IPv6 अस्थायी पता रोटेशन, ISP-संचालित आवधिक IP परिवर्तन, WiFi और cellular IP के बीच संक्रमण करने वाले मोबाइल क्लाइंट, या अन्य स्थानीय नेटवर्क परिवर्तनों के कारण हो सकता है। Port परिवर्तन पिछली binding का समय समाप्त होने के बाद NAT rebinding के कारण हो सकता है।

किसी peer का IP या port विभिन्न on- और off-path हमलों के कारण बदला हुआ दिखाई दे सकता है, जिसमें packets को modify करना या inject करना शामिल है।

Connection migration वह प्रक्रिया है जिसके द्वारा एक नया source endpoint (IP+port) validate किया जाता है, जबकि उन परिवर्तनों को रोका जाता है जो validate नहीं हैं। यह प्रक्रिया QUIC RFC 9000 में परिभाषित प्रक्रिया का एक सरलीकृत संस्करण है। यह प्रक्रिया केवल session के data phase के लिए परिभाषित है। Handshake के दौरान migration की अनुमति नहीं है। सभी handshake packets को verify किया जाना चाहिए कि वे उसी IP और port से हैं जैसे पहले भेजे और प्राप्त किए गए packets। दूसरे शब्दों में, handshake के दौरान एक peer का IP और port स्थिर होना चाहिए।

Threat Model

(QUIC RFC 9000 से अनुकूलित)

नोट्स

एक peer अपने source address को spoof कर सकता है ताकि किसी endpoint को एक अनिच्छुक host को अत्यधिक मात्रा में data भेजने पर मजबूर किया जा सके। यदि endpoint spoofing peer से काफी अधिक data भेजता है, तो connection migration का उपयोग करके attacker द्वारा victim की ओर generate किए जा सकने वाले data की मात्रा को बढ़ाया जा सकता है।

Session Confirmed Fragmentation

एक on-path attacker एक spurious connection migration का कारण बन सकता है एक packet को copy करके और एक spoofed address के साथ forward करके ताकि यह original packet से पहले पहुंचे। Spoofed address वाला packet एक migrating connection से आता हुआ दिखेगा, और original packet को duplicate के रूप में देखा जाएगा और drop कर दिया जाएगा। एक spurious migration के बाद, source address की validation fail हो जाएगी क्योंकि source address पर मौजूद entity के पास आवश्यक cryptographic keys नहीं हैं जो उसे भेजे गए Path Challenge को read या respond करने के लिए चाहिए, भले ही वह चाहे भी।

Off-Path Packet Forwarding

एक off-path attacker जो packets को observe कर सकता है, वह genuine packets की copies को endpoints तक forward कर सकता है। यदि copied packet genuine packet से पहले पहुंचता है, तो यह NAT rebinding की तरह दिखेगा। कोई भी genuine packet duplicate के रूप में discard हो जाएगा। यदि attacker packets को forward करना जारी रखने में सक्षम है, तो यह attacker के माध्यम से path पर migration का कारण बन सकता है। यह attacker को on-path रखता है, जिससे उसे सभी subsequent packets को observe या drop करने की क्षमता मिल जाती है।

Privacy Implications

QUIC RFC 9000 ने नेटवर्क पथ बदलते समय connection ID बदलने का निर्देश दिया है। कई नेटवर्क पथों पर एक स्थिर connection ID का उपयोग करने से एक निष्क्रिय पर्यवेक्षक को उन पथों के बीच गतिविधि को सहसंबद्ध करने की अनुमति मिल जाएगी। नेटवर्क के बीच स्थानांतरित होने वाला एक endpoint अपने peer के अलावा किसी अन्य संस्था द्वारा अपनी गतिविधि को सहसंबद्ध नहीं करना चाह सकता है। हालांकि, QUIC हेडर में connection ID को encrypt नहीं करता है। SSU2 ऐसा करता है, इसलिए privacy leak के लिए निष्क्रिय पर्यवेक्षक को connection ID को decrypt करने के लिए आवश्यक introduction key प्राप्त करने हेतु network database तक पहुंच की भी आवश्यकता होगी। introduction key के साथ भी, यह एक मजबूत आक्रमण नहीं है, और हम SSU2 में migration के बाद connection ID नहीं बदलते हैं, क्योंकि यह एक महत्वपूर्ण जटिलता होगी।

Initiating Path Validation

डेटा चरण के दौरान, peers को प्रत्येक प्राप्त डेटा पैकेट के source IP और port की जांच करनी होगी। यदि IP या port पहले प्राप्त हुए से भिन्न है, और पैकेट एक duplicate पैकेट number नहीं है, और पैकेट सफलतापूर्वक decrypt हो जाता है, तो session path validation चरण में प्रवेश करता है।

इसके अतिरिक्त, एक peer को यह सत्यापित करना होगा कि नया IP और port स्थानीय validation नियमों के अनुसार वैध हैं (blocked नहीं, अवैध ports नहीं, आदि)। Peers को IPv4 और IPv6 के बीच migration का समर्थन करना आवश्यक नहीं है, और वे दूसरे address family में एक नए IP को अवैध मान सकते हैं, क्योंकि यह अपेक्षित व्यवहार नहीं है और इससे implementation की जटिलता काफी बढ़ सकती है। एक अवैध IP/port से packet प्राप्त करने पर, एक implementation इसे केवल drop कर सकता है, या पुराने IP/port के साथ path validation शुरू कर सकता है।

पथ सत्यापन चरण में प्रवेश करने पर, निम्नलिखित चरणों का पालन करें:

• कई सेकंड का, या वर्तमान RTO के कई गुना का (TBD) path validation timeout timer शुरू करें
• congestion window को minimum तक कम करें
• PMTU को minimum (1280) तक कम करें
• नए IP और port पर एक data packet भेजें जिसमें Path Challenge block, Address block (नया IP/port शामिल), और आमतौर पर ACK block हो। यह packet वर्तमान session के समान connection ID और encryption keys का उपयोग करता है। Path Challenge block data में पर्याप्त entropy होनी चाहिए (कम से कम 8 bytes) ताकि इसे spoof न किया जा सके।
• वैकल्पिक रूप से, पुराने IP/port पर भी अलग block data के साथ Path Challenge भेजें। नीचे देखें।
• वर्तमान RTO के आधार पर Path Response timeout timer शुरू करें (आमतौर पर RTT + RTTdev का एक multiple)

path validation phase के दौरान, session आने वाले packets को process करना जारी रख सकता है। चाहे वे पुराने या नए IP/port से आ रहे हों। Session data packets भेजना और acknowledge करना भी जारी रख सकता है। हालांकि, path validation phase के दौरान congestion window और PMTU को minimum values पर बना रहना चाहिए, ताकि spoofed address पर बड़ी मात्रा में traffic भेजकर denial of service attacks के लिए इसका उपयोग न किया जा सके।

एक implementation कई paths को एक साथ validate करने का प्रयास कर सकती है, लेकिन यह आवश्यक नहीं है। यह संभवतः complexity के लायक नहीं है। यह एक पिछले IP/port को पहले से validated के रूप में याद रख सकती है, और यदि कोई peer अपने पिछले IP/port पर वापस आता है तो path validation को skip कर सकती है, लेकिन यह भी आवश्यक नहीं है।

यदि एक Path Response प्राप्त होता है, जिसमें Path Challenge में भेजा गया समान डेटा होता है, तो Path Validation सफल हो गया है। Path Response संदेश का स्रोत IP/port वही होना आवश्यक नहीं है जिस पर Path Challenge भेजा गया था।

यदि Path Response timer की समाप्ति से पहले Path Response प्राप्त नहीं होता है, तो दूसरा Path Challenge भेजें और Path Response timer को दोगुना करें।

यदि Path Validation timer की समय सीमा समाप्त होने से पहले Path Response प्राप्त नहीं होता है, तो Path Validation असफल हो गया है।

Message Contents

Data संदेशों में निम्नलिखित blocks होने चाहिए। क्रम निर्दिष्ट नहीं है सिवाय इसके कि Padding अंत में होना चाहिए:

• Path Validation या Path Response ब्लॉक। Path Validation में अपारदर्शी डेटा होता है, न्यूनतम 8 बाइट्स की सिफारिश की जाती है। Path Response में Path Validation से डेटा होता है।
• प्राप्तकर्ता के स्पष्ट IP वाला Address ब्लॉक
• DateTime ब्लॉक
• ACK ब्लॉक
• Padding ब्लॉक

यह सिफारिश नहीं की जाती है कि संदेश में कोई अन्य blocks (उदाहरण के लिए, I2NP) शामिल किए जाएं।

Path Response वाले संदेश में Path Validation block शामिल करने की अनुमति है, ताकि दूसरी दिशा में validation शुरू की जा सके।

Path Challenge और Path Response blocks ACK-eliciting हैं। Path Challenge को एक Data message द्वारा ACK किया जाएगा जिसमें Path Response और ACK blocks शामिल हैं। Path Response को एक Data message द्वारा ACK किया जाना चाहिए जिसमें एक ACK block शामिल हो।

Routing during Path Validation

QUIC specification इस बात पर स्पष्ट नहीं है कि path validation के दौरान data packets कहाँ भेजे जाएं - पुराने या नए IP/port पर? IP/port परिवर्तनों का तेज़ी से जवाब देने और spoofed addresses पर traffic न भेजने के बीच संतुलन बनाना होता है। साथ ही, spoofed packets को मौजूदा session पर महत्वपूर्ण प्रभाव डालने की अनुमति नहीं दी जानी चाहिए। केवल port में बदलाव संभावित रूप से idle period के बाद NAT rebinding के कारण हो सकते हैं; IP परिवर्तन एक या दोनों दिशाओं में high-traffic phases के दौरान हो सकते हैं।

रणनीतियाँ अनुसंधान और परिष्करण के अधीन हैं। संभावनाओं में शामिल हैं:

• नए IP/port पर डेटा पैकेट तब तक नहीं भेजना जब तक वह validated न हो जाए
• पुराने IP/port पर डेटा पैकेट भेजना जारी रखना जब तक नया IP/port validated न हो जाए
• साथ ही साथ पुराने IP/port को revalidate करना
• तब तक कोई डेटा नहीं भेजना जब तक पुराना या नया IP/port validated न हो जाए
• केवल port परिवर्तन के लिए IP परिवर्तन की तुलना में अलग रणनीतियां
• समान /32 में IPv6 परिवर्तन के लिए अलग रणनीतियां, जो संभावित रूप से temporary address rotation के कारण हुआ हो

Responding to Path Challenge

Path Challenge प्राप्त होने पर, peer को एक data packet के साथ जवाब देना चाहिए जिसमें Path Response हो, जिसमें Path Challenge का data हो। TODO Maybe???: Path Response को उस IP/port पर भेजा जाना चाहिए जहाँ से Path Challenge प्राप्त हुआ था। यह जरूरी नहीं है कि यह वही IP/port हो जो पहले peer के लिए स्थापित किया गया था। यह सुनिश्चित करता है कि peer द्वारा path validation केवल तभी सफल होती है जब path दोनों दिशाओं में कार्यात्मक हो। नीचे Validation after Local Change section देखें।

जब तक IP/port उस peer के लिए पहले से ज्ञात IP/port से अलग नहीं है, Path Challenge को एक सामान्य ping की तरह मानें, और बिना शर्त Path Response के साथ जवाब दें। receiver किसी प्राप्त Path Challenge के आधार पर कोई state नहीं रखता या बदलता है। यदि IP/port अलग है, तो एक peer को यह सत्यापित करना चाहिए कि नया IP और port स्थानीय validation नियमों के अनुसार वैध हैं (blocked नहीं, अवैध ports नहीं, आदि)। Peers को IPv4 और IPv6 के बीच cross-address-family responses का समर्थन करने की आवश्यकता नहीं है, और वे दूसरे address family में नए IP को अवैध मान सकते हैं, क्योंकि यह अपेक्षित व्यवहार नहीं है।

जब तक congestion control द्वारा सीमित न हो, Path Response तुरंत भेजा जाना चाहिए। यदि आवश्यक हो तो implementations को Path Responses या उपयोग की जाने वाली bandwidth को rate limit करने के उपाय करने चाहिए।

एक Path Challenge ब्लॉक आमतौर पर उसी संदेश में एक Address ब्लॉक के साथ आता है। यदि address block में एक नया IP/port है, तो एक peer उस IP/port को validate कर सकता है और उस नए IP/port की peer testing शुरू कर सकता है, session peer या किसी अन्य peer के साथ। यदि peer को लगता है कि यह firewalled है, और केवल port बदला है, तो यह परिवर्तन संभवतः NAT rebinding के कारण है, और आगे की peer testing की संभवतः आवश्यकता नहीं है।

Successful Path Validation

सफल path validation पर, connection पूरी तरह से नए IP/port पर migrate हो जाता है। सफलता पर:

• पाथ सत्यापन चरण से बाहर निकलें
• सभी पैकेट नए IP और पोर्ट पर भेजे जाते हैं।
• congestion window और PMTU पर लगी पाबंदियां हटा दी जाती हैं, और उन्हें बढ़ने की अनुमति दी जाती है। उन्हें केवल पुराने मानों पर वापस न करें, क्योंकि नए पाथ की अलग विशेषताएं हो सकती हैं।
• यदि IP बदल गया है, तो गणना किए गए RTT और RTO को प्रारंभिक मानों पर सेट करें। क्योंकि केवल पोर्ट में परिवर्तन आमतौर पर NAT rebinding या अन्य middlebox गतिविधि का परिणाम होते हैं, peer इसके बजाय अपनी congestion control स्थिति और round-trip अनुमान को उन मामलों में बनाए रख सकता है बजाय प्रारंभिक मानों पर वापस जाने के।
• पुराने IP/पोर्ट के लिए भेजे गए या प्राप्त किए गए किसी भी टोकन को हटाएं (अमान्य करें) (वैकल्पिक)
• नए IP/पोर्ट के लिए एक नया टोकन ब्लॉक भेजें (वैकल्पिक)

Cancelling Path Validation

path validation चरण के दौरान, पुराने IP/port से प्राप्त कोई भी वैध, गैर-डुप्लिकेट packets जो सफलतापूर्वक decrypt हो जाते हैं, Path Validation को रद्द कर देंगे। यह महत्वपूर्ण है कि एक रद्द किया गया path validation, जो spoofed packet के कारण हुआ है, किसी वैध session को समाप्त या महत्वपूर्ण रूप से बाधित न करे।

रद्द किए गए path validation पर:

• Path validation चरण से बाहर निकलें
• सभी packets पुराने IP और port पर भेजे जाते हैं।
• Congestion window और PMTU पर प्रतिबंध हटा दिए जाते हैं, और उन्हें बढ़ाने की अनुमति दी जाती है, या, वैकल्पिक रूप से, पिछली values को restore करना
• किसी भी data packets को retransmit करें जो पहले नए IP/port पर भेजे गए थे उन्हें पुराने IP/port पर भेजें।

Failed Path Validation

यह महत्वपूर्ण है कि एक असफल path validation, जो spoofed packet के कारण हुई हो, किसी valid session को terminate या महत्वपूर्ण रूप से बाधित न करे।

असफल path validation पर:

• Path validation phase से बाहर निकलें
• सभी packets पुराने IP और port पर भेजे जाते हैं।
• Congestion window और PMTU पर प्रतिबंध हटा दिए जाते हैं, और उन्हें बढ़ने की अनुमति दी जाती है।
• वैकल्पिक रूप से, पुराने IP और port पर path validation शुरू करें। यदि यह असफल हो जाता है, तो session को समाप्त कर दें।
• अन्यथा, मानक session timeout और termination नियमों का पालन करें।
• किसी भी data packets को retransmit करें जो पहले नए IP/port पर भेजे गए थे पुराने IP/port पर।

Validation After Local Change

उपरोक्त प्रक्रिया उन peers के लिए परिभाषित है जो बदले हुए IP/port से एक packet प्राप्त करते हैं। हालांकि, यह दूसरी दिशा में भी शुरू की जा सकती है, एक ऐसे peer द्वारा जो पता लगाता है कि उसका IP या port बदल गया है। एक peer यह पता लगाने में सक्षम हो सकता है कि उसका local IP बदल गया है; हालांकि, NAT rebinding के कारण उसके port के बदलने का पता लगाना बहुत कम संभावना है। इसलिए, यह वैकल्पिक है।

किसी peer से path challenge प्राप्त होने पर जिसका IP या port बदल गया हो, दूसरे peer को विपरीत दिशा में एक path challenge शुरू करना चाहिए।

Relay सुरक्षा

Path Validation और Path Response blocks का उपयोग किसी भी समय Ping/Pong packets के रूप में किया जा सकता है। Path Validation block की प्राप्ति रिसीवर पर कोई state नहीं बदलती, जब तक कि यह किसी अलग IP/port से प्राप्त न हो।

Multiple Sessions

Peers को एक ही peer के साथ कई sessions स्थापित नहीं करने चाहिए, चाहे वह SSU 1 या 2 हो, या समान या अलग IP addresses के साथ हो। हालांकि, यह हो सकता है, या तो bugs के कारण, या पिछले session termination message के खो जाने के कारण, या एक race में जहां termination message अभी तक नहीं पहुंचा है।

यदि Bob का Alice के साथ एक मौजूदा session है, जब Bob को Alice से Session Confirmed प्राप्त होता है, handshake पूरा करके और एक नया session स्थापित करके, Bob को चाहिए:

• पुराने session से नए session में किसी भी unsent या unacknowledged outbound I2NP messages को migrate करें
• पुराने session पर reason code 22 के साथ termination भेजें
• पुराने session को remove करें और इसे नए session से replace करें

Session Termination

Peer Test सुरक्षा

handshake phase में sessions आमतौर पर केवल timeout होकर या आगे response न देकर terminate हो जाते हैं। वैकल्पिक रूप से, वे response में Termination block शामिल करके terminate हो सकते हैं, लेकिन cryptographic keys की कमी के कारण अधिकांश errors का जवाब देना संभव नहीं होता। यदि termination block सहित response के लिए keys उपलब्ध हैं तो भी, response के लिए DH perform करना आमतौर पर CPU के लिए फायदेमंद नहीं होता। एक अपवाद retry message में Termination block हो सकता है, जिसे generate करना सस्ता होता है।

Relay और Peer Test Design Goals

data phase में sessions को एक data message भेजकर terminate किया जाता है जिसमें एक Termination block शामिल होता है। इस message में एक ACK block भी शामिल होना चाहिए। यदि session इतनी देर तक चला है कि पहले से भेजा गया token expire हो गया है या expire होने वाला है, तो इसमें एक New Token block भी हो सकता है। यह message ack-eliciting नहीं है। “Termination Received” को छोड़कर किसी भी अन्य reason के साथ Termination block प्राप्त करने पर, peer एक data message के साथ जवाब देता है जिसमें “Termination Received” reason के साथ एक Termination block होता है।

Termination block भेजने या प्राप्त करने के बाद, session को कुछ अधिकतम समयावधि TBD के लिए closing phase में प्रवेश करना चाहिए। closing state इसलिए आवश्यक है ताकि Termination block वाले packet के खो जाने और दूसरी दिशा में in-flight packets से सुरक्षा मिल सके। closing phase के दौरान, कोई भी अतिरिक्त प्राप्त packets को प्रोसेस करने की आवश्यकता नहीं है। closing state में session किसी भी incoming packet के जवाब में Termination block वाला packet भेजता है जिसे वह session से जोड़ता है। session को closing state में packets generate करने की दर को सीमित करना चाहिए। उदाहरण के लिए, एक session प्राप्त packets की progressively बढ़ती संख्या या समय की मात्रा का इंतजार कर सकता है, प्राप्त packets का जवाब देने से पहले।

बंद हो रहे session के लिए router द्वारा बनाए रखी जाने वाली state को न्यूनतम करने के लिए, sessions वैकल्पिक रूप से किसी भी प्राप्त packet के जवाब में वही packet को उसी packet number के साथ यथावत भेज सकते हैं, लेकिन यह आवश्यक नहीं है। नोट: termination packet के retransmission की अनुमति देना इस आवश्यकता का अपवाद है कि प्रत्येक packet के लिए एक नया packet number उपयोग किया जाना चाहिए। नए packet numbers भेजना मुख्यतः loss recovery और congestion control के लिए फायदेमंद है, जो बंद connection के लिए प्रासंगिक होने की अपेक्षा नहीं है। अंतिम packet को retransmit करने के लिए कम state की आवश्यकता होती है।

“Termination Received” कारण के साथ Termination block प्राप्त करने के बाद, session closing phase से बाहर निकल सकता है।

Cleanup

किसी भी सामान्य या असामान्य समाप्ति पर, router को मेमोरी में स्थित सभी ephemeral डेटा को शून्य कर देना चाहिए, जिसमें handshake ephemeral keys, symmetric crypto keys, और संबंधित जानकारी शामिल है।

MTU

आवश्यकताएं अलग-अलग होती हैं, इस आधार पर कि प्रकाशित पता SSU 1 के साथ साझा किया गया है या नहीं। वर्तमान SSU 1 IPv4 न्यूनतम 620 है, जो निश्चित रूप से बहुत छोटा है।

न्यूनतम SSU2 MTU IPv4 और IPv6 दोनों के लिए 1280 है, जो RFC 9000 में निर्दिष्ट के समान है। नीचे देखें। न्यूनतम MTU बढ़ाकर, 1 KB tunnel संदेश और छोटे tunnel build संदेश एक datagram में फिट हो जाएंगे, जिससे विखंडन की सामान्य मात्रा काफी कम हो जाएगी। यह अधिकतम I2NP संदेश आकार में वृद्धि की भी अनुमति देता है। 1820-byte streaming संदेश दो datagrams में फिट होने चाहिए।

एक router को SSU2 को enable नहीं करना चाहिए या SSU2 address को publish नहीं करना चाहिए जब तक कि उस address के लिए MTU कम से कम 1280 न हो।

Router को प्रत्येक SSU या SSU2 router address में एक non-default MTU प्रकाशित करना होगा।

सारांश

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 Protocol Framework

SSU 1 के लिए, वर्तमान Java I2P छोटे packets से शुरू करके और धीरे-धीरे size बढ़ाकर, या प्राप्त packet size के आधार पर बढ़ाकर PMTU discovery करता है। यह अशोधित है और efficiency को बहुत कम कर देता है। SSU 2 में इस feature को जारी रखना TBD है।

हाल के अध्ययन PMTU सुझाते हैं कि IPv4 के लिए 1200 या अधिक का न्यूनतम आकार 99% से अधिक कनेक्शन के लिए काम करेगा। QUIC RFC 9000 को न्यूनतम IP packet size 1280 bytes की आवश्यकता होती है।

RFC 9000 से उद्धरण:

अधिकतम datagram साइज़ को UDP payload के सबसे बड़े साइज़ के रूप में परिभाषित किया गया है जो एक single UDP datagram का उपयोग करके network path के माध्यम से भेजा जा सकता है। QUIC का उपयोग नहीं किया जाना चाहिए यदि network path कम से कम 1200 bytes के अधिकतम datagram साइज़ का समर्थन नहीं कर सकता है।

QUIC कम से कम 1280 bytes के न्यूनतम IP packet size को मानता है। यह IPv6 न्यूनतम आकार [IPv6] है और अधिकांश आधुनिक IPv4 networks द्वारा भी समर्थित है। IPv6 के लिए 40 bytes और IPv4 के लिए 20 bytes के न्यूनतम IP header size और 8 bytes के UDP header size को मानते हुए, इसके परिणामस्वरूप IPv6 के लिए 1232 bytes और IPv4 के लिए 1252 bytes का अधिकतम datagram size मिलता है। इस प्रकार, आधुनिक IPv4 और सभी IPv6 network paths से QUIC को समर्थन करने में सक्षम होने की अपेक्षा की जाती है।

नोट: UDP payload के 1200 bytes को support करने की यह आवश्यकता IPv6 extension headers के लिए उपलब्ध स्थान को 32 bytes तक या IPv4 options को 52 bytes तक सीमित कर देती है यदि path केवल IPv6 के minimum MTU 1280 bytes को support करता है। यह Initial packets और path validation को प्रभावित करता है।

उद्धरण समाप्त

फ्रेमवर्क में जोड़े गए संशोधन

QUIC के लिए आवश्यक है कि दोनों दिशाओं में Initial datagrams कम से कम 1200 bytes के हों, amplification attacks को रोकने के लिए और यह सुनिश्चित करने के लिए कि PMTU दोनों दिशाओं में इसे support करे।

हम Session Request और Session Created के लिए इसकी आवश्यकता कर सकते हैं, bandwidth में पर्याप्त लागत पर। शायद हम यह केवल तभी कर सकें जब हमारे पास token न हो, या Retry संदेश प्राप्त होने के बाद। TBD

QUIC की आवश्यकता है कि Bob तब तक प्राप्त डेटा की मात्रा से तीन गुना अधिक डेटा न भेजे जब तक कि client address सत्यापित न हो जाए। SSU2 इस आवश्यकता को स्वाभाविक रूप से पूरा करता है, क्योंकि Retry message का आकार Token Request message के लगभग समान है, और Session Request message से छोटा है। साथ ही, Retry message केवल एक बार भेजा जाता है।

प्रसंस्करण ओवरहेड अनुमान

QUIC के लिए आवश्यक है कि PATH_CHALLENGE या PATH_RESPONSE blocks वाले messages कम से कम 1200 bytes के हों, amplification attacks को रोकने के लिए और यह सुनिश्चित करने के लिए कि PMTU दोनों दिशाओं में इसका समर्थन करता है।

हम इसे भी आवश्यक बना सकते हैं, bandwidth में पर्याप्त लागत के साथ। हालांकि, ये मामले दुर्लभ होने चाहिए। TBD

Max I2NP Message Size

IPv4: कोई IP fragmentation नहीं माना जाता है। IP + datagram header 28 bytes का है। यह मानता है कि कोई IPv4 options नहीं हैं। अधिकतम message size MTU - 28 है। Data phase header 16 bytes है और MAC 16 bytes है, कुल मिलाकर 32 bytes। Payload size MTU - 60 है। अधिकतम data phase payload अधिकतम 1500 MTU के लिए 1440 है। अधिकतम data phase payload न्यूनतम 1280 MTU के लिए 1220 है।

IPv6: कोई IP fragmentation की अनुमति नहीं है। IP + datagram header 48 bytes का है। यह मानता है कि कोई IPv6 extension headers नहीं हैं। अधिकतम message का आकार MTU - 48 है। Data phase header 16 bytes का है और MAC 16 bytes का है, कुल मिलाकर 32 bytes। Payload का आकार MTU - 80 है। अधिकतम data phase payload अधिकतम 1500 MTU के लिए 1420 है। अधिकतम data phase payload न्यूनतम 1280 MTU के लिए 1200 है।

SSU 1 में, दिशानिर्देश 64 अधिकतम fragments और 620 न्यूनतम MTU के आधार पर I2NP message के लिए लगभग 32 KB की सख्त अधिकतम सीमा थी। bundled LeaseSets और session keys के overhead के कारण, application level पर व्यावहारिक सीमा लगभग 6KB कम थी, या लगभग 26KB। SSU 1 protocol 128 fragments की अनुमति देता है लेकिन वर्तमान implementations इसे 64 fragments तक सीमित करते हैं।

न्यूनतम MTU को 1280 तक बढ़ाकर, लगभग 1200 के data phase payload के साथ, लगभग 76 KB का एक SSU 2 message 64 fragments में संभव है और 152 KB 128 fragments में। यह आसानी से अधिकतम 64 KB की अनुमति देता है।

tunnels में fragmentation और SSU 2 में fragmentation के कारण, message का आकार बढ़ने पर message loss की संभावना exponentially बढ़ जाती है। हम I2NP datagrams के लिए application layer पर लगभग 10 KB की practical limit की सिफारिश करना जारी रखते हैं।

Peer Test Process

ऊपर दिए गए Peer Test Security को देखें 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 blocks में I2NP Database Store messages के रूप में भेजा जा सकता है, या RI blocks के रूप में (यदि पर्याप्त छोटा है)। यदि पर्याप्त छोटे हैं तो ये peer test blocks के साथ ही समान packets में शामिल हो सकते हैं।

संदेश 1-4 एक Data message में Peer Test blocks का उपयोग करके in-session हैं। संदेश 5-7 एक Peer Test message में Peer Test blocks का उपयोग करके out-of-session हैं।

नोट: SSU 1 की तरह, संदेश 4 और 5 किसी भी क्रम में आ सकते हैं। यदि Alice firewalled है तो संदेश 5 और/या 7 बिल्कुल प्राप्त नहीं हो सकते। जब संदेश 5, संदेश 4 से पहले आता है, तो Alice तुरंत संदेश 6 नहीं भेज सकती, क्योंकि उसके पास अभी तक Charlie की intro key नहीं है जो header को encrypt करने के लिए चाहिए। जब संदेश 4, संदेश 5 से पहले आता है, तो Alice को तुरंत संदेश 6 नहीं भेजना चाहिए, क्योंकि उसे यह देखने के लिए इंतजार करना चाहिए कि संदेश 5, संदेश 6 के साथ firewall खोले बिना आता है या नहीं।

Versions

क्रॉस-वर्जन peer testing समर्थित नहीं है। एकमात्र अनुमतित version combination वह है जहाँ सभी peers version 2 हों।

सत्र स्थापना

मैसेज 1-4 in-session में हैं और data phase ACK और retransmission प्रक्रियाओं द्वारा कवर किए जाते हैं। Peer Test blocks ack-eliciting हैं।

संदेश 5-7 को बिना बदले पुनः प्रेषित किया जा सकता है।

पैकेट हेडर

SSU 1 की तरह, IPv6 addresses का testing supported है, और Alice-Bob और Alice-Charlie communication IPv6 के via हो सकती है, यदि Bob और Charlie अपने published IPv6 address में ‘B’ capability के साथ support indicate करते हैं। Details के लिए Proposal 126 देखें।

जैसा कि 0.9.50 से पहले SSU 1 में था, Alice अपने द्वारा परीक्षण किए जाने वाले transport (IPv4 या IPv6) पर मौजूदा session का उपयोग करके Bob को request भेजती है। जब Bob को Alice से IPv4 के माध्यम से request मिलती है, तो Bob को एक ऐसा Charlie चुनना चाहिए जो IPv4 address advertise करता हो। जब Bob को Alice से IPv6 के माध्यम से request मिलती है, तो Bob को एक ऐसा Charlie चुनना चाहिए जो IPv6 address advertise करता हो। वास्तविक Bob-Charlie communication IPv4 या IPv6 के माध्यम से हो सकती है (यानी, Alice के address type से स्वतंत्र)। यह 0.9.50 के रूप में SSU 1 का व्यवहार नहीं है, जहां मिश्रित IPv4/v6 requests की अनुमति है।

Processing by Bob

SSU 1 के विपरीत, Alice संदेश 1 में अनुरोधित test IP और port को निर्दिष्ट करती है। Bob को इस IP और port को validate करना चाहिए, और यदि अमान्य हो तो code 5 के साथ reject करना चाहिए। अनुशंसित IP validation यह है कि IPv4 के लिए, यह Alice के IP से मेल खाता हो, और IPv6 के लिए, IP के कम से कम पहले 8 bytes मेल खाते हों। Port validation में privileged ports और well-known protocols के लिए ports को reject करना चाहिए।

Relay Process

SSU1 Relay का विश्लेषण और SSU2 Relay के लक्ष्यों के लिए ऊपर दिया गया Relay Security देखें।

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 blocks में I2NP Database Store messages के रूप में भेजा जा सकता है, या RI blocks के रूप में (यदि पर्याप्त छोटा हो)। ये relay blocks के समान packets में शामिल हो सकते हैं, यदि पर्याप्त छोटे हों।

SSU 1 में, Charlie के router की जानकारी में प्रत्येक introducer का IP, port, intro key, relay tag, और expiration शामिल होता है।

SSU 2 में, Charlie के router info में प्रत्येक introducer का router hash, relay tag, और expiration शामिल होता है।

Alice को पहले एक introducer (Bob) का चयन करके आवश्यक round trips की संख्या कम करनी चाहिए जिससे उसका पहले से ही कनेक्शन हो। दूसरा, यदि कोई नहीं है, तो एक ऐसा introducer चुनें जिसके लिए उसके पास पहले से ही router info हो।

क्रॉस-वर्जन रिलेइंग को भी यदि संभव हो तो समर्थित होना चाहिए। यह SSU 1 से SSU 2 में एक क्रमिक संक्रमण की सुविधा प्रदान करेगा। अनुमतित वर्जन संयोजन हैं (TODO):

Retransmissions

Relay Request, Relay Intro, और Relay Response सभी in-session हैं और data phase ACK और retransmission प्रक्रियाओं द्वारा कवर किए जाते हैं। Relay Request, Relay Intro, और Relay Response blocks ack-eliciting हैं।

Hole punch को पुनः प्रेषित किया जा सकता है, जैसा कि SSU 1 में होता है।

IPv4/v6

SSU 1 relay की सभी सुविधाएं समर्थित हैं, जिसमें Proposal 158 में दस्तावेजित और 0.9.50 से समर्थित सुविधाएं शामिल हैं। IPv4 और IPv6 introductions समर्थित हैं। एक Relay Request को IPv4 session पर IPv6 introduction के लिए भेजा जा सकता है, और एक Relay Request को IPv6 session पर IPv4 introduction के लिए भेजा जा सकता है।

Processing by Alice

निम्नलिखित SSU 1 से अंतर और SSU 2 कार्यान्वयन के लिए सुझाव हैं।

नोट्स

SSU 1 में, introduction अपेक्षाकृत सस्ता है, और Alice आम तौर पर सभी introducers को Relay Requests भेजती है। SSU 2 में, introduction अधिक महंगा है, क्योंकि पहले एक introducer के साथ connection स्थापित करना होता है। Introduction latency और overhead को कम करने के लिए, सुझाए गए processing steps निम्नलिखित हैं:

• iexp मान के आधार पर address में expired हो चुके किसी भी introducer को ignore करें
• यदि एक या अधिक introducer के साथ SSU2 connection पहले से स्थापित है, एक को चुनें और केवल उस introducer को Relay Request भेजें।
• अन्यथा, यदि एक या अधिक introducer के लिए Router Info स्थानीय रूप से ज्ञात है, एक को चुनें और केवल उस introducer से connect करें।
• अन्यथा, सभी introducer के लिए Router Info को lookup करें, उस introducer से connect करें जिसका Router Info पहले प्राप्त हो।

नोट्स

SSU 1 और SSU 2 दोनों में, Relay Response और Hole Punch किसी भी क्रम में प्राप्त हो सकते हैं, या बिल्कुल भी प्राप्त नहीं हो सकते हैं।

SSU 1 में, Alice आमतौर पर Hole Punch (1 1/2 RTT) से पहले Relay Response (1 RTT) प्राप्त करती है। हो सकता है कि उन specifications में यह अच्छी तरह से documented न हो, लेकिन Alice को आगे बढ़ने से पहले Bob से Relay Response प्राप्त करना चाहिए, ताकि Charlie का IP मिल सके। यदि Hole Punch पहले प्राप्त होता है, तो Alice इसे पहचान नहीं पाएगी, क्योंकि इसमें कोई data नहीं है और source IP पहचाना नहीं जाता। Relay Response प्राप्त करने के बाद, Alice को Charlie के साथ handshake शुरू करने से पहले Charlie से Hole Punch प्राप्त करने का इंतजार करना चाहिए, या एक छोटी देरी (अनुशंसित 500 ms) का इंतजार करना चाहिए।

SSU 2 में, Alice आमतौर पर Relay Response (2 RTT) से पहले Hole Punch (1 1/2 RTT) प्राप्त करेगी। SSU 2 Hole Punch को SSU 1 की तुलना में प्रोसेस करना आसान है, क्योंकि यह परिभाषित connection IDs (relay nonce से derived) और Charlie के IP सहित contents के साथ एक पूर्ण संदेश है। Relay Response (Data message) और Hole Punch message में समान signed Relay Response block होता है। इसलिए, Alice या तो Charlie से Hole Punch प्राप्त करने के बाद, या Bob से Relay Response प्राप्त करने के बाद Charlie के साथ handshake शुरू कर सकती है।

Hole Punch के signature verification में introducer के (Bob के) router hash शामिल होते हैं। यदि Relay Requests एक से अधिक introducer को भेजे गए हैं, तो signature को validate करने के लिए कई विकल्प हैं:

• प्रत्येक hash को try करें जिसमें एक request भेजा गया था
• प्रत्येक introducer के लिए अलग nonces का उपयोग करें, और इसका उपयोग यह निर्धारित करने के लिए करें कि यह Hole Punch किस introducer के response में था
• यदि contents Relay Response में उसके समान हैं तो signature को re-validate न करें, यदि पहले से received है
• Signature को बिल्कुल भी validate न करें

यदि Charlie एक symmetric NAT के पीछे है, तो Relay Response और Hole Punch में उसका reported port सटीक नहीं हो सकता। इसलिए, Alice को Hole Punch message के UDP source port की जांच करनी चाहिए, और यदि यह reported port से अलग है तो उसका उपयोग करना चाहिए।

Tag Requests by Bob

SSU 1 में, केवल Alice ही tag का अनुरोध कर सकती थी, Session Request में। Bob कभी भी tag का अनुरोध नहीं कर सकता था, और Alice, Bob के लिए relay नहीं कर सकती थी।

SSU2 में, Alice आमतौर पर Session Request में एक tag का अनुरोध करती है, लेकिन Alice या Bob दोनों में से कोई भी data phase में tag का अनुरोध कर सकता है। Bob आमतौर पर inbound request प्राप्त करने के बाद firewalled नहीं होता, लेकिन यह relay के बाद हो सकता है, या Bob की state बदल सकती है, या वह अन्य address type (IPv4/v6) के लिए introducer का अनुरोध कर सकता है। इसलिए, SSU2 में, Alice और Bob दोनों का एक साथ दूसरे पक्ष के लिए relay होना संभव है।

Published Router Info

Address Properties

निम्नलिखित address properties प्रकाशित की जा सकती हैं, SSU 1 से अपरिवर्तित, जिसमें Proposal 158 में परिवर्तन शामिल हैं जो API 0.9.50 से समर्थित हैं:

• caps: [B,C,4,6] क्षमताएं

• host: IP (IPv4 या IPv6)। छोटा किया गया IPv6 पता ("::" के साथ) की अनुमति है। यदि firewalled है तो उपस्थित हो भी सकता है या नहीं भी। Host names की अनुमति नहीं है।

• iexp[0-2]: इस introducer की समाप्ति। ASCII अंक, epoch के बाद से सेकंड में। केवल तभी उपस्थित जब firewalled हो, और introducers आवश्यक हों। वैकल्पिक (भले ही इस introducer के लिए अन्य properties उपस्थित हों)।

• ihost[0-2]: Introducer का IP (IPv4 या IPv6)। छोटा किया गया IPv6 पता ("::" के साथ) अनुमतित है। केवल तभी मौजूद होता है जब firewalled हो, और introducers आवश्यक हों। Host names की अनुमति नहीं है। केवल SSU address के लिए।

• ikey[0-2]: Introducer का Base 64 introduction key। केवल तभी मौजूद होती है जब firewalled हो, और introducers आवश्यक हों। केवल SSU address के लिए।

• iport[0-2]: Introducer का port 1024 - 65535। केवल तभी उपस्थित होता है जब firewalled हो, और introducers आवश्यक हों। केवल SSU address।

• itag[0-2]: Introducer का tag 1 - (2**32 - 1) ASCII digits। केवल तभी उपस्थित होता है जब firewalled हो, और introducers की आवश्यकता हो।

• key: Base 64 परिचय कुंजी।

• mtu: वैकल्पिक। ऊपर MTU अनुभाग देखें।

• port: 1024 - 65535 यदि firewalled है तो यह उपस्थित हो भी सकता है और नहीं भी।

Published Addresses

प्रकाशित RouterAddress (RouterInfo का हिस्सा) में “SSU” या “SSU2” में से कोई एक protocol identifier होगा।

RouterAddress में SSU2 support को indicate करने के लिए तीन options होने चाहिए:

• s=(Base64 key) इस RouterAddress के लिए वर्तमान Noise static public key (s)। मानक I2P Base 64 alphabet का उपयोग करके Base 64 encoded। binary में 32 bytes, Base 64 encoded के रूप में 44 bytes, little-endian X25519 public key।

• i=(Base64 key) इस RouterAddress के लिए headers को encrypt करने के लिए वर्तमान introduction key। मानक I2P Base 64 alphabet का उपयोग करके Base 64 encoded। binary में 32 bytes, Base 64 encoded के रूप में 44 bytes, big-endian ChaCha20 key।

• v=2 वर्तमान संस्करण (2)। जब “SSU” के रूप में प्रकाशित किया जाता है, तो संस्करण 1 के लिए अतिरिक्त समर्थन निहित होता है। भविष्य के संस्करणों के लिए समर्थन कॉमा-अलग किए गए मानों के साथ होगा, जैसे v=2,3 Implementation को संगतता सत्यापित करनी चाहिए, यदि कॉमा मौजूद है तो कई संस्करणों सहित। कॉमा-अलग किए गए संस्करण संख्यात्मक क्रम में होने चाहिए।

Alice को SSU2 protocol का उपयोग करके कनेक्ट करने से पहले यह सत्यापित करना होगा कि सभी तीन विकल्प मौजूद और वैध हैं।

जब “SSU” के रूप में “s”, “i”, और “v” विकल्पों के साथ, और “host” और “port” विकल्पों के साथ प्रकाशित किया जाता है, तो router को उस host और port पर SSU और SSU2 दोनों protocols के लिए आने वाले connections को स्वीकार करना चाहिए, और protocol version का स्वचालित रूप से पता लगाना चाहिए।

जब “s”, “i”, और “v” विकल्पों के साथ “SSU2” के रूप में प्रकाशित किया जाता है, और “host” और “port” विकल्पों के साथ, router केवल SSU2 protocol के लिए उस host और port पर आने वाले connections को स्वीकार करता है।

यदि कोई router SSU1 और SSU2 दोनों connections को support करता है लेकिन incoming connections के लिए automatic version detection implement नहीं करता, तो उसे “SSU” और “SSU2” दोनों addresses को advertise करना चाहिए, और SSU2 options को केवल “SSU2” address में include करना चाहिए। Router को “SSU2” address में “SSU” address की तुलना में कम cost value (उच्च priority) set करनी चाहिए, ताकि SSU2 को प्राथमिकता मिले।

यदि एक ही RouterInfo में कई SSU2 RouterAddresses (“SSU” या “SSU2” के रूप में) प्रकाशित किए जाते हैं (अतिरिक्त IP addresses या ports के लिए), तो समान port को निर्दिष्ट करने वाले सभी addresses में समान SSU2 options और values होने चाहिए। विशेष रूप से, सभी में समान static key “s” और introduction key “i” होनी चाहिए।

Introducers

जब SSU या SSU2 के रूप में introducers के साथ प्रकाशित किया जाता है, तो निम्नलिखित विकल्प उपलब्ध होते हैं:

• ih[0-2]=(Base64 hash) एक introducer के लिए router hash। मानक I2P Base 64 alphabet का उपयोग करके Base 64 encoded। binary में 32 bytes, Base 64 encoded के रूप में 44 bytes

• iexp[0-2]: इस introducer की समाप्ति। SSU 1 से अपरिवर्तित।

• itag[0-2]: Introducer का tag 1 - (2**32 - 1) SSU 1 से अपरिवर्तित।

निम्नलिखित विकल्प केवल SSU के लिए हैं और SSU2 के लिए उपयोग नहीं होते हैं। SSU2 में, Alice यह जानकारी Charlie के RI से प्राप्त करती है।

• ihost[0-2]
• ikey[0-2]
• itag[0-2]

एक router को introducers प्रकाशित करते समय address में host या port प्रकाशित नहीं करना चाहिए। एक router को introducers प्रकाशित करते समय address में 4 और/या 6 caps प्रकाशित करना चाहिए ताकि IPv4 और/या IPv6 के लिए समर्थन का संकेत मिल सके। यह हाल के SSU 1 addresses के लिए वर्तमान प्रथा के समान है।

नोट: यदि SSU के रूप में प्रकाशित किया गया है, और SSU 1 और SSU2 introducers का मिश्रण है, तो पुराने routers के साथ संगतता के लिए SSU 1 introducers निम्न indexes पर होने चाहिए और SSU2 introducers उच्च indexes पर होने चाहिए।

Unpublished SSU2 Address

यदि Alice अपना SSU2 पता incoming connections के लिए (“SSU” या “SSU2” के रूप में) publish नहीं करती है, तो उसे एक “SSU2” router address publish करना चाहिए जिसमें केवल उसकी static key और SSU2 version हो, ताकि Bob, Session Confirmed part 2 में Alice का RouterInfo प्राप्त करने के बाद key को validate कर सके।

• s=(Base64 key) जैसा कि ऊपर प्रकाशित पतों के लिए परिभाषित किया गया है।

• i=(Base64 key) जैसा कि ऊपर प्रकाशित पतों के लिए परिभाषित किया गया है।

• v=2 जैसा कि ऊपर प्रकाशित पतों के लिए परिभाषित किया गया है।

इस router address में “host” या “port” विकल्प नहीं होंगे, क्योंकि ये outbound SSU2 connections के लिए आवश्यक नहीं हैं। इस address के लिए published cost का वास्तव में कोई सख्त महत्व नहीं है, क्योंकि यह केवल inbound है; हालांकि, यह अन्य routers के लिए सहायक हो सकता है यदि cost को अन्य addresses की तुलना में अधिक (कम priority) सेट किया जाए। सुझाया गया मान 14 है।

Alice एक मौजूदा प्रकाशित “SSU” address में “i” “s” और “v” options को भी बस जोड़ सकती है।

पैकेट अखंडता

NTCP2 और SSU2 के लिए समान static keys का उपयोग करने की अनुमति है, लेकिन इसकी अनुशंसा नहीं की जाती है।

RouterInfos की caching के कारण, router को static public key या IV को rotate नहीं करना चाहिए जब तक router चालू है, चाहे वह published address में हो या न हो। Router को इस key और IV को persistent रूप से store करना चाहिए ताकि तत्काल restart के बाद पुन: उपयोग किया जा सके, जिससे incoming connections काम करते रहें, और restart times expose न हों। Router को last-shutdown time को persistently store करना चाहिए, या अन्यथा निर्धारित करना चाहिए, ताकि startup पर पिछले downtime की गणना की जा सके।

रीस्टार्ट समय के एक्सपोज़ होने की चिंताओं के अधीन, router इस key या IV को स्टार्टअप पर rotate कर सकते हैं यदि router पहले कुछ समय (कम से कम कई दिन) के लिए डाउन था।

यदि router के पास कोई प्रकाशित SSU2 RouterAddresses हैं (SSU या SSU2 के रूप में), तो rotation से पहले न्यूनतम downtime बहुत लंबा होना चाहिए, उदाहरण के लिए एक महीना, जब तक कि स्थानीय IP address बदल न गया हो या router “rekeys” न हो।

यदि router के पास कोई published SSU RouterAddresses हैं, लेकिन SSU2 नहीं (SSU या SSU2 के रूप में) तो rotation से पहले minimum downtime अधिक होना चाहिए, उदाहरण के लिए एक दिन, जब तक कि local IP address नहीं बदला हो या router “rekeys” न हो। यह तब भी लागू होता है जब published SSU address में introducers हों।

यदि router के पास कोई प्रकाशित RouterAddresses (SSU, SSU2, या SSU) नहीं हैं, तो rotation से पहले न्यूनतम downtime केवल दो घंटे तक कम हो सकता है, भले ही IP address बदल जाए, जब तक कि router “rekeys” न करे।

यदि router किसी अलग Router Hash में “rekeys” करता है, तो उसे एक नई noise key और intro key भी generate करनी चाहिए।

कार्यान्वयन को यह जानना चाहिए कि static public key या IV को बदलने से उन routers से आने वाले SSU2 connections रुक जाएंगे जिन्होंने पुराना RouterInfo cache किया हुआ है। RouterInfo publishing, tunnel peer selection (OBGW और IB closest hop दोनों सहित), zero-hop tunnel selection, transport selection, और अन्य implementation रणनीतियों को इसे ध्यान में रखना चाहिए।

Intro key rotation वही नियमों के अधीन है जो key rotation के हैं।

नोट: rekeying से पहले न्यूनतम डाउनटाइम को नेटवर्क स्वास्थ्य सुनिश्चित करने के लिए संशोधित किया जा सकता है, और मध्यम समय तक बंद रहे router द्वारा reseeding को रोकने के लिए।

Identity Hiding

इनकार (Deniability) कोई लक्ष्य नहीं है। ऊपर दिया गया अवलोकन देखें।

प्रत्येक pattern को properties असाइन किए जाते हैं जो initiator की static public key और responder की static public key को प्रदान की जाने वाली confidentiality का वर्णन करती हैं। मूलभूत assumptions यह हैं कि ephemeral private keys सुरक्षित हैं, और यदि parties को दूसरी party से कोई static public key प्राप्त होती है जिस पर वे भरोसा नहीं करते तो वे handshake को abort कर देते हैं।

यह सेक्शन केवल handshakes में static public key fields के माध्यम से identity leakage पर विचार करता है। निश्चित रूप से, Noise participants की identities अन्य माध्यमों से भी expose हो सकती हैं, जिसमें payload fields, traffic analysis, या IP addresses जैसे metadata शामिल हैं।

Alice: (8) प्रामाणिक पार्टी के लिए forward secrecy के साथ एन्क्रिप्टेड।

Bob: (3) प्रसारित नहीं किया गया, लेकिन एक passive attacker responder की private key के लिए candidates की जांच कर सकता है और निर्धारित कर सकता है कि candidate सही है या नहीं।

Bob अपनी static public key को netDb में publish करता है। Alice ऐसा नहीं कर सकती, लेकिन उसे इसे Bob को भेजे गए RI में शामिल करना होगा।

Packet Guidelines

प्रमाणित एन्क्रिप्शन

Handshake संदेश (Session Request/Created/Confirmed, Retry) मूलभूत चरण, क्रम में:

• 16 या 32 बाइट हेडर बनाएं
• पेलोड बनाएं
• हेडर को mixHash() करें (Retry को छोड़कर)
• Noise का उपयोग करके पेलोड को एन्क्रिप्ट करें (Retry को छोड़कर, हेडर को AD के रूप में उपयोग करके ChaChaPoly का उपयोग करें)
• हेडर को एन्क्रिप्ट करें, और Session Request/Created के लिए, ephemeral key को

डेटा फेज संदेशों के बुनियादी चरण, क्रम में:

• 16-बाइट हेडर बनाएं
• पेलोड बनाएं
• हेडर को AD के रूप में उपयोग करके ChaChaPoly का उपयोग करके पेलोड को एन्क्रिप्ट करें
• हेडर को एन्क्रिप्ट करें

Inbound Packet Handling

पेलोड

सभी inbound संदेशों की प्रारंभिक प्रसंस्करण:

• हेडर के पहले 8 bytes (Destination Connection ID) को intro key के साथ decrypt करें
• Destination Connection ID द्वारा connection को lookup करें
• यदि connection मिल जाती है और data phase में है, तो data phase section में जाएं
• यदि connection नहीं मिलती है, तो handshake section में जाएं
• नोट: Peer Test और Hole Punch messages को भी test या relay nonce से बनाए गए Destination Connection ID द्वारा lookup किया जा सकता है।

Handshake संदेश (Session Request/Created/Confirmed, Retry, Token Request) और अन्य out-of-session संदेश (Peer Test, Hole Punch) प्रसंस्करण:

• header के bytes 8-15 को decrypt करें (packet type, version, और net ID) intro key के साथ। यदि यह एक valid Session Request, Token Request, Peer Test, या Hole Punch है, तो continue करें
• यदि valid message नहीं है, तो packet source IP/port द्वारा pending outbound connection को lookup करें, packet को Session Created या Retry के रूप में treat करें। Header के पहले 8 bytes को सही key के साथ re-decrypt करें, और header के bytes 8-15 को (packet type, version, और net ID)। यदि यह एक valid Session Created या Retry है, तो continue करें
• यदि valid message नहीं है, तो fail करें, या possible out-of-order data phase packet के रूप में queue करें
• Session Request/Created, Retry, Token Request, Peer Test, और Hole Punch के लिए, header के bytes 16-31 को decrypt करें
• Session Request/Created के लिए, ephemeral key को decrypt करें
• सभी header fields को validate करें, यदि valid नहीं है तो stop करें
• Header को mixHash() करें
• Session Request/Created/Confirmed के लिए, Noise का उपयोग करके payload को decrypt करें
• Retry और data phase के लिए, ChaChaPoly का उपयोग करके payload को decrypt करें
• Header और payload को process करें

डेटा चरण संदेश प्रसंस्करण:

• हेडर के bytes 8-15 को decrypt करें (packet type, version, और net ID) सही key के साथ
• Header को AD के रूप में उपयोग करके ChaChaPoly का उपयोग करके payload को decrypt करें
• Header और payload को process करें

Details

SSU 1 में, inbound packet classification कठिन है, क्योंकि session number को इंगित करने के लिए कोई header नहीं है। Routers को पहले source IP और port को किसी मौजूदा peer state के साथ match करना होता है, और यदि नहीं मिलता है, तो उपयुक्त peer state खोजने या नया शुरू करने के लिए विभिन्न keys के साथ कई decryptions का प्रयास करना पड़ता है। यदि किसी मौजूदा session के लिए source IP या port बदल जाता है, संभवतः NAT behavior के कारण, तो router packet को किसी मौजूदा session के साथ match करने और contents को recover करने के लिए महंगे heuristics का उपयोग कर सकता है।

SSU 2 को DPI प्रतिरोध और अन्य on-path खतरों को बनाए रखते हुए inbound packet classification प्रयास को न्यूनतम करने के लिए डिज़ाइन किया गया है। Connection ID नंबर सभी message प्रकारों के लिए header में शामिल है, और ज्ञात key और nonce के साथ ChaCha20 का उपयोग करके encrypted (obfuscated) है। इसके अतिरिक्त, message प्रकार भी header में शामिल है (header protection के साथ ज्ञात key के लिए encrypted और फिर ChaCha20 के साथ obfuscated) और अतिरिक्त classification के लिए उपयोग किया जा सकता है। किसी भी स्थिति में packet को classify करने के लिए trial DH या अन्य asymmetric crypto ऑपरेशन आवश्यक नहीं है।

लगभग सभी peers के सभी संदेशों के लिए, Connection ID encryption के लिए ChaCha20 key, destination router की introduction key होती है जैसा कि netDb में प्रकाशित है।

केवल अपवाद वे पहले संदेश हैं जो Bob से Alice को भेजे जाते हैं (Session Created या Retry) जहाँ Alice की introduction key अभी तक Bob को पता नहीं है। इन मामलों में, Bob की introduction key को key के रूप में उपयोग किया जाता है।

प्रोटोकॉल को packet classification प्रोसेसिंग को कम करने के लिए डिज़ाइन किया गया है जिसके लिए कई fallback steps या जटिल heuristics में अतिरिक्त crypto operations की आवश्यकता हो सकती है। इसके अतिरिक्त, प्राप्त packets की विशाल बहुमत के लिए source IP/port द्वारा (संभावित रूप से महंगी) fallback lookup और दूसरी header decryption की आवश्यकता नहीं होगी। केवल Session Created और Retry (और संभावित रूप से अन्य TBD) के लिए fallback processing की आवश्यकता होगी। यदि session creation के बाद endpoint IP या port बदलता है, तो भी connection ID का उपयोग session को lookup करने के लिए किया जाता है। session खोजने के लिए heuristics का उपयोग करना कभी आवश्यक नहीं होता, उदाहरण के लिए समान IP लेकिन अलग port के साथ अलग session की तलाश करके।

इसलिए, receiver loop logic में अनुशंसित प्रसंस्करण चरण हैं:

1. स्थानीय introduction key का उपयोग करके ChaCha20 के साथ पहले 8 bytes को decrypt करें, Destination Connection ID को recover करने के लिए। यदि Connection ID किसी मौजूदा या pending inbound session से match करता है:

a) उपयुक्त key का उपयोग करके, header bytes 8-15 को decrypt करें

  to recover the version, net ID, and message type.

b) यदि 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.

c) यदि message type वैध है लेकिन 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.

d) (वैकल्पिक) यदि connection ID एक pending inbound session है

  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.

e) यदि b) या c) विफल हो जाता है, तो संदेश को छोड़ दें।

2. यदि connection ID वर्तमान session से मेल नहीं खाता है: जांचें कि bytes 8-15 पर plaintext header वैध है (बिना कोई header protection ऑपरेशन किए)। सत्यापित करें कि net ID और protocol version वैध हैं, और message type Session Request है, या अन्य message type जो out-of-session अनुमतित है (TBD)।

a) यदि सब कुछ वैध है और message type Session Request है,

  decrypt bytes 16-31 of the header and the 32-byte X value
  with ChaCha20 using the local intro key.

• यदि header bytes 24-31 पर token को स्वीकार किया जाता है, तो decrypted 32 byte header को MixHash() करें और message को Noise के साथ decrypt करें। जवाब में एक Session Created भेजें।
  • यदि token को स्वीकार नहीं किया जाता है, तो source IP/port पर एक token के साथ Retry message भेजें। DDoS attacks से बचने के लिए message को Noise के साथ decrypt करने का प्रयास न करें।

b) यदि message type कोई अन्य message है जो valid है

  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.

c) यदि a) या b) असफल हो जाता है, तो चरण 3) पर जाएं

3. पैकेट के source IP/port द्वारा एक pending outbound session को lookup करें।

a) यदि मिल जाए, तो Bob की introduction key का उपयोग करके ChaCha20 के साथ पहले 8 bytes को पुनः decrypt करें

  to recover the Destination Connection ID.

b) यदि कनेक्शन ID pending session से मेल खाता है:

  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).

• यदि सब कुछ मान्य है और message type Session Created है, header के अगले 16 bytes और 32-byte Y value को Bob की intro key का उपयोग करके ChaCha20 से decrypt करें। फिर decrypted 32 byte header को MixHash() करें और message को Noise से decrypt करें। response में Session Confirmed भेजें।

  • यदि सब कुछ मान्य है और message type Retry है, header के bytes 16-31 को Bob की intro key का उपयोग करके ChaCha20 से decrypt करें। TBD को key के रूप में और TBD को nonce के रूप में तथा decrypted 32-byte header को AD के रूप में उपयोग करके ChaCha20/Poly1305 का उपयोग करके message को decrypt और validate करें। response में प्राप्त token के साथ Session Request को resend करें।
  • यदि message type कोई अन्य message है जो valid out-of-session है, संभवतः short header के साथ, intro key का उपयोग करके ChaCha20/Poly1305 से message के बाकी हिस्से को decrypt करें, और decrypted 16-byte header को AD के रूप में उपयोग करें। Message को process करें।

  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. यदि समान port पर SSU 1 चला रहे हैं, तो संदेश को SSU 1 packet के रूप में प्रोसेस करने का प्रयास करें।

Error Handling

सामान्यतः, एक session (handshake या data phase में) को अप्रत्याशित message type वाले packet प्राप्त करने के बाद कभी भी destroy नहीं किया जाना चाहिए। यह packet injection attacks को रोकता है। ये packets आमतौर पर handshake packet के retransmission के बाद भी प्राप्त होते हैं, जब header decryption keys अब valid नहीं रहती हैं।

अधिकांश मामलों में, बस packet को drop कर दें। एक implementation पिछले भेजे गए packet (handshake message या ACK 0) को response में retransmit कर सकती है, लेकिन यह आवश्यक नहीं है।

Bob के रूप में Session Created भेजने के बाद, अनपेक्षित packets आमतौर पर Data packets होते हैं जो decrypt नहीं हो सकते क्योंकि Session Confirmed packets खो गए या क्रम से बाहर हैं। packets को queue करें और Session Confirmed packets प्राप्त करने के बाद उन्हें decrypt करने का प्रयास करें।

Bob के रूप में Session Confirmed प्राप्त करने के बाद, अनपेक्षित packets आमतौर पर पुनः प्रेषित Session Confirmed packets होते हैं, क्योंकि Session Confirmed का ACK 0 खो गया था। अनपेक्षित packets को drop किया जा सकता है। एक implementation प्रतिक्रिया में ACK block युक्त Data packet भेज सकती है, लेकिन यह आवश्यक नहीं है।

Notes

Session Created और Session Confirmed के लिए, implementations को सभी decrypted header fields (Connection IDs, packet number, packet type, version, id, frag, और flags) को सावधानीपूर्वक validate करना चाहिए header पर mixHash() को call करने और Noise AEAD के साथ payload को decrypt करने का प्रयास करने से पहले। यदि Noise AEAD decryption विफल हो जाता है, तो कोई और processing नहीं की जा सकती, क्योंकि mixHash() handshake state को corrupt कर देगा, जब तक कि कोई implementation hash state को store और “back out” नहीं करता।

Version Detection

समान inbound port पर आने वाले packets version 1 या 2 के हैं, इसका कुशलतापूर्वक पता लगाना संभव नहीं हो सकता। उपरोक्त चरणों को SSU 1 processing से पहले करना समझदारी हो सकती है, ताकि दोनों protocol versions का उपयोग करके trial DH operations की कोशिश करने से बचा जा सके।

यदि आवश्यक हो तो TBD।

Recommended Constants

• Outbound handshake retransmission timeout: 1.25 सेकंड, exponential backoff के साथ (retransmissions 1.25, 3.75, और 8.75 सेकंड पर)
• Total outbound handshake timeout: 15 सेकंड
• Inbound handshake retransmission timeout: 1 सेकंड, exponential backoff के साथ (retransmissions 1, 3, और 7 सेकंड पर)
• Total inbound handshake timeout: 12 सेकंड
• Retry भेजने के बाद timeout: 9 सेकंड
• ACK delay: max(10, min(rtt/6, 150)) ms
• Immediate ACK delay: min(rtt/16, 5) ms
• Max ACK ranges: 256?
• Max ACK depth: 512?
• Padding distribution: 0-15 bytes, या अधिक

Variants, Fallbacks, and General Issues

TBD

Packet Overhead Analysis

IPv4 मानता है, अतिरिक्त padding शामिल नहीं, IP और UDP header आकार शामिल नहीं। Padding केवल SSU 1 के लिए mod-16 padding है।

SSU 1