नोट
नेटवर्क परिनियोजन और परीक्षण प्रगति पर है। छोटे संशोधनों के अधीन।
अवलोकन
सारांश
ECIES मौजूदा सत्र (ES) संदेश ओवरहेड को लगभग 90 बाइट्स से कम करता है। इसलिए हम ECIES कनेक्शनों के लिए MTU को लगभग 90 बाइट्स तक बढ़ा सकते हैं। देखें the ECIES specification, Streaming specification, and Streaming API documentation।
MTU बढ़ाए बिना, कई मामलों में ओवरहेड बचत वास्तव में ‘बचत’ नहीं होती है, क्योंकि संदेश फिर भी दो पूर्ण टनल संदेशों का उपयोग करने के लिए पैड किए जाएंगे।
इस प्रस्ताव के लिए विनिर्देशों में किसी भी परिवर्तन की आवश्यकता नहीं है। यह प्रस्ताव केवल सिफारिश किए गए मूल्य और कार्यान्वयन विवरण के चर्चा और आम सहमति बनाने की सुविधा के लिए पोस्ट किया गया है।
लक्ष्य
- समुच्चयित MTU बढाएं
- 1 केबी टनल संदेशों का अधिकतम उपयोग
- स्ट्रीमिंग प्रोटोकॉल को न बदलें
डिजाइन
मौजूदा MAX_PACKET_SIZE_INCLUDED विकल्प और MTU समुच्चयन का उपयोग करें। स्ट्रीमिंग भेजे गए और प्राप्त MTU के न्यूनतम का उपयोग जारी रखती है। सभी कनेक्शनों के लिए डिफ़ॉल्ट 1730 बना रहता है, चाहे कौन सी कुंजियाँ उपयोग की जाएं।
कार्यान्वयन को सभी SYN पैकेटों में MAX_PACKET_SIZE_INCLUDED विकल्प शामिल करने के लिए प्रोत्साहित किया जाता है, दोनों दिशाओं में, हालांकि यह कोई आवश्यकता नहीं है।
यदि कोई गंतव्य केवल ECIES है, तो उच्च मूल्य का प्रयोग करें (या तो एलिस या बॉब के रूप में)। यदि कोई गंतव्य द्वय-कुंजी है, तो व्यवहार भिन्न हो सकता है:
यदि द्वय-कुंजी ग्राहक राउटर के बाहर है (एक बाहरी एप्लिकेशन में), तो उसे दूरसामी अंत में उपयोग की जा रही कुंजी के बारे में ‘पता नहीं’ हो सकता है, और एलिस SYN में उच्च मूल्य का अनुरोध कर सकती है, जबकि SYN में अधिकतम डेटा 1730 ही रहता है।
यदि द्वय-कुंजी ग्राहक राउटर के अंदर है, तो क्या कुंजी उपयोग की जा रही है की जानकारी उपयोगकर्ता को ज्ञात हो सकती है या नहीं। लीज़सेट अभी तक प्राप्त नहीं किया जा सकता है, या आंतरिक API इंटरफेसों द्वारा वह जानकारी उपयोगकर्ता को आसानी से उपलब्ध नहीं कराई जा सकती है। यदि जानकारी उपलब्ध है, तो एलिस उच्च मूल्य का उपयोग कर सकती है; अन्यथा, एलिस को 1730 के मानक मूल्य का उपयोग करना होगा जब तक कि समुच्चयन नहीं होता।
बॉब के रूप में द्वय-कुंजी ग्राहक उत्तर में उच्च मूल्य भेज सकता है, यहां तक कि अगर एलिस से कोई मूल्य या 1730 का मूल्य प्राप्त नहीं किया गया है; हालांकि, स्ट्रीमिंग में ऊपर की ओर समुच्चयन के प्रावधान नहीं हैं, इसलिए MTU को 1730 पर रहना चाहिए।
जैसा कि the Streaming API documentation में उल्लेख किया गया है, एलीस से बॉब को भेजे गए SYN पैकेटों में बॉब के MTU से अधिक डेटा हो सकता है। यह स्ट्रीमिंग प्रोटोकॉल में एक कमजोरी है। इसलिए, द्वय-कुंजी ग्राहकों को SYN पैकेटों में भेजे गए डेटा को 1730 बाइट्स तक सीमित करना होगा, जबकि एक उच्च MTU विकल्प भेजना होगा। एक बार जब बॉब से उच्च MTU प्राप्त हो जाता है, तब एलिस अधिकतम भेजे गए पेलोड को बढ़ा सकती है।
विश्लेषण
जैसा कि the ECIES specification में वर्णित है, मौजूदा सत्र संदेशों के लिए ElGamal ओवरहेड 151 बाइट्स है, और रैचेट ओवरहेड 69 बाइट्स है। इसलिए, हम रैचेट कनेक्शनों के लिए MTU को (151 - 69) = 82 बाइट्स तक बढ़ा सकते हैं, 1730 से 1812 तक।
विनिर्देश
MTU चयन और समुच्चयन अनुभाग में निम्नलिखित परिवर्तन और स्पष्टीकरण जोड़ें the Streaming API documentation। the Streaming specification में कोई परिवर्तन नहीं।
विकल्प i2p.streaming.maxMessageSize का डिफ़ॉल्ट मूल्य सभी कनेक्शनों के लिए 1730 बना रहता है, चाहे कौन सी कुंजियाँ उपयोग की जाती हैं। ग्राहकों को हमेशा की तरह भेजे और प्राप्त MTU के न्यूनतम का उपयोग करना होगा।
चार संबंधित MTU साधार और वेरियेबल्स हैं:
- DEFAULT_MTU: 1730, अ
परिवर्तित, सभी कनेक्शनों के लिए
- i2cp.streaming.maxMessageSize: डिफ़ॉल्ट 1730 या 1812, कॉन्फ़िगरेशन द्वारा बदला जा सकता है
- ALICE_SYN_MAX_DATA: वह अधिकतम डेटा जो एलिस SYN पैकेट में शामिल कर सकती है
- negotiated_mtu: एलीस और बॉब के MTU का न्यूनतम, ताकि SYN ACK से बॉब से एलिस तक, और सभी बाद के पैकेट्स में दोनों दिशाओं में अधिकतम डेटा आकार के रूप में उपयोग किया जा सके
पाँच मामलों पर विचार किया जाना चाहिए:
1) एलिस केवल ElGamal
कोई परिवर्तन नहीं, सभी पैकेटों में 1730 MTU।
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize डिफ़ॉल्ट: 1730
- एलिस SYN में MAX_PACKET_SIZE_INCLUDED भेज सकती है, आवश्यक नहीं जब तक != 1730
2) एलिस केवल ECIES
सभी पैकेटों में 1812 MTU।
- ALICE_SYN_MAX_DATA = 1812
- i2cp.streaming.maxMessageSize डिफ़ॉल्ट: 1812
- एलिस को SYN में MAX_PACKET_SIZE_INCLUDED भेजना होगा
3) एलिस द्वय-कुंजी और जानती है बॉब ElGamal है
सभी पैकेटों में 1730 MTU।
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize डिफ़ॉल्ट: 1812
- एलिस SYN में MAX_PACKET_SIZE_INCLUDED भेज सकती है, आवश्यक नहीं जब तक != 1730
4) एलिस द्वय-कुंजी और जानती है बॉब ECIES है
सभी पैकेटों में 1812 MTU।
- ALICE_SYN_MAX_DATA = 1812
- i2cp.streaming.maxMessageSize डिफ़ॉल्ट: 1812
- एलिस को SYN में MAX_PACKET_SIZE_INCLUDED भेजना होगा
5) एलिस द्वय-कुंजी और बॉब की कुंजी अज्ञात
SYN पैकेट में MAX_PACKET_SIZE_INCLUDED के रूप में 1812 भेजें लेकिन SYN पैकेट डेटा को 1730 तक सीमित करें।
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize डिफ़ॉल्ट: 1812
- एलिस को SYN में MAX_PACKET_SIZE_INCLUDED भेजना होगा
सभी मामलों के लिए
एलिस और बॉब negotiated_mtu की गणना करते हैं, एलीस और बॉब के MTU का न्यूनतम, ताकि अधिकतम डेटा आकार के रूप में SYN ACK से बॉब से एलिस तक, और सभी बाद के पैकेट्स में दोनों दिशाओं में उपयोग किया जा सके।
न्यायसंगतकरण
देखें the Java I2P source code वर्तमान मूल्य क्यों 1730 है। देखें the ECIES specification ECIES ओवरहेड क्यों ElGamal से 82 बाइट्स कम है।
कार्यान्वयन नोट्स
यदि स्ट्रीमिंग आदर्श आकार के संदेश बना रही है, तो यह बहुत महत्वपूर्ण है कि ECIES-Ratchet लेयर उस आकार से परे पैड न करे।
दो टनल संदेशों में फिट होने के लिए आदर्श गार्लिक संदेश आकार, 16 बाइट गार्लिक संदेश I2NP हेडर, 4 बाइट गार्लिक संदेश लंबाई, 8 बाइट ES टैग, और 16 बाइट MAC सहित, 1956 बाइट्स है।
ECIES में अनुशंसित पैडिंग एल्गोरिदम निम्नानुसार है:
- यदि गार्लिक संदेश की कुल लंबाई 1954-1956 बाइट्स होगी, तो कोई पैडिंग ब्लॉक न जोड़ें (कोई स्थान नहीं)
- यदि गार्लिक संदेश की कुल लंबाई 1938-1953 बाइट्स होगी, तो ठीक 1956 बाइट्स के लिए पैड के लिए एक पैडिंग ब्लॉक जोड़ें।
- अन्यथा, सामान्य रूप से पैड करें, उदाहरण के लिए 0-15 बाइट्स की यादृच्छिक मात्रा से।
इसी तरह की रणनीतियाँ आदर्श एक-टनल-संदेश आकार (964) और तीन-टनल-संदेश आकार (2952) पर उपयोग की जा सकती हैं, यद्यपि ये आकार व्यवहार में दुर्लभ होनी चाहिए।
मुद्दे
1812 मूल्य प्रारंभिक है। पुष्टि और संभवतः समायोजित किया जाना है।
प्रवास
कोई पिछड़ा संगतता मुद्दा नहीं। यह एक मौजूदा विकल्प है और MTU समुच्चयन पहले से ही विनिर्देश का हिस्सा है।
पुराने ECIES गंतव्य 1730 को समर्थन देंगे। कोई भी ग्राहक जो उच्च मूल्य प्राप्त करता है वह 1730 के साथ उत्तर देगा, और दूर का अंत नीचे की ओर समुच्चयन करेगा, जैसा कि हमेशा होता है।