अप्रचलित - SSU को SSU2 द्वारा प्रतिस्थापित कर दिया गया है। SSU समर्थन को i2pd से रिलीज़ 2.44.0 (API 0.9.56) 2022-11 में हटा दिया गया था। SSU समर्थन को Java I2P से रिलीज़ 2.4.0 (API 0.9.61) 2023-12 में हटा दिया गया था।
SSU (जिसे I2P दस्तावेज और उपयोगकर्ता इंटरफेस में अक्सर “UDP” भी कहा जाता है) I2P में लागू किए गए दो transports में से एक था। दूसरा NTCP2 है। NTCP के लिए समर्थन हटा दिया गया है।
SSU को I2P रिलीज़ 0.6 में पेश किया गया था। एक मानक I2P इंस्टॉलेशन में, router आउटबाउंड कनेक्शन के लिए NTCP और SSU दोनों का उपयोग करता है। SSU-over-IPv6 का समर्थन संस्करण 0.9.8 से उपलब्ध है।
SSU को “अर्ध-विश्वसनीय” कहा जाता है क्योंकि यह अनुत्तरित संदेशों को बार-बार पुनः प्रसारित करता है, लेकिन केवल अधिकतम संख्या तक। उसके बाद, संदेश को छोड़ दिया जाता है।
SSU सेवाएं
NTCP transport की तरह, SSU विश्वसनीय, एन्क्रिप्टेड, connection-oriented, point-to-point डेटा transport प्रदान करता है। SSU की विशेषता यह है कि यह IP detection और NAT traversal services भी प्रदान करता है, जिनमें शामिल हैं:
- introducers का उपयोग करके सहकारी NAT/Firewall traversal
- आने वाले packets की जांच और peer testing द्वारा स्थानीय IP का पता लगाना
- firewall स्थिति और स्थानीय IP का संचार, और NTCP में किसी भी बदलाव का संचार
- firewall स्थिति और स्थानीय IP का संचार, और router और user interface में किसी भी बदलाव का संचार
Router Address विनिर्देश
निम्नलिखित गुण network database में संग्रहीत हैं।
- Transport name: SSU
- caps: [B,C,4,6] नीचे देखें ।
- host: IP (IPv4 या IPv6)। छोटा किया गया IPv6 पता ("::" के साथ) की अनुमति है। यदि firewalled है तो उपस्थित हो भी सकता है और नहीं भी। Host names पहले अनुमतित थे, लेकिन release 0.9.32 के बाद से deprecated हैं। प्रस्ताव 141 देखें।
- iexp[0-2]: इस introducer की समाप्ति। ASCII अंक, epoch के बाद से सेकंड में। केवल तभी उपस्थित जब firewalled हो, और introducers आवश्यक हों। वैकल्पिक (भले ही इस introducer के लिए अन्य properties उपस्थित हों)। Release 0.9.30 के अनुसार, प्रस्ताव 133।
- ihost[0-2]: Introducer का IP (IPv4 या IPv6)। Host names पहले अनुमतित थे, लेकिन release 0.9.32 के बाद से deprecated हैं। प्रस्ताव 141 देखें। छोटा किया गया IPv6 पता ("::" के साथ) की अनुमति है। केवल तभी उपस्थित जब firewalled हो, और introducers आवश्यक हों। नीचे देखें ।
- ikey[0-2]: Introducer की Base 64 introduction key। नीचे देखें । केवल तभी उपस्थित जब firewalled हो, और introducers आवश्यक हों। नीचे देखें ।
- iport[0-2]: Introducer का port 1024 - 65535। केवल तभी उपस्थित जब firewalled हो, और introducers आवश्यक हों। नीचे देखें ।
- itag[0-2]: Introducer का tag 1 - (2^32 - 1) ASCII अंक। केवल तभी उपस्थित जब firewalled हो, और introducers आवश्यक हों। नीचे देखें ।
- key: Base 64 introduction key। नीचे देखें ।
- mtu: वैकल्पिक। डिफ़ॉल्ट और अधिकतम 1484 है। न्यूनतम 620 है। IPv6 के लिए उपस्थित होना चाहिए, जहाँ न्यूनतम 1280 और अधिकतम 1488 है (version 0.9.28 से पहले अधिकतम 1472 था)। IPv6 MTU 16 का गुणांक होना चाहिए। (IPv4 MTU + 4) 16 का गुणांक होना चाहिए। नीचे देखें ।
- port: 1024 - 65535 यदि firewalled है तो उपस्थित हो भी सकता है और नहीं भी।
प्रोटोकॉल विवरण
भीड़भाड़ नियंत्रण
SSU की केवल अर्ध-विश्वसनीय डिलीवरी, TCP-अनुकूल संचालन, और उच्च थ्रूपुट की क्षमता की आवश्यकता कंजेशन कंट्रोल में बहुत लचीलापन प्रदान करती है। नीचे वर्णित कंजेशन कंट्रोल एल्गोरिदम का उद्देश्य बैंडविड्थ में कुशल होने के साथ-साथ कार्यान्वयन में सरल होना है।
पैकेट्स को router की नीति के अनुसार निर्धारित किया जाता है, ध्यान रखते हुए कि router की आउटबाउंड क्षमता से अधिक न हो या रिमोट peer की मापी गई क्षमता से अधिक न हो। मापी गई क्षमता TCP के slow start और congestion avoidance की तर्ज पर काम करती है, जिसमें भेजने की क्षमता में योजक वृद्धि और भीड़भाड़ के सामने गुणक कमी होती है। TCP के विपरीत, router एक निश्चित अवधि या पुनः प्रसारण की संख्या के बाद कुछ संदेशों को छोड़ सकते हैं जबकि अन्य संदेशों को भेजना जारी रख सकते हैं।
congestion detection तकनीकें TCP से भी भिन्न हैं, क्योंकि प्रत्येक संदेश का अपना अनूठा और गैर-क्रमिक identifier होता है, और प्रत्येक संदेश का आकार सीमित होता है - अधिकतम 32KB। इस feedback को sender को कुशलतापूर्वक प्रेषित करने के लिए, receiver समय-समय पर पूर्ण रूप से ACK किए गए संदेश identifiers की एक सूची शामिल करता है और आंशिक रूप से प्राप्त संदेशों के लिए bitfields भी शामिल कर सकता है, जहाँ प्रत्येक bit एक fragment के प्राप्त होने को दर्शाता है। यदि duplicate fragments आते हैं, तो संदेश को फिर से ACK करना चाहिए, या यदि संदेश अभी भी पूर्ण रूप से प्राप्त नहीं हुआ है, तो bitfield को किसी भी नए अपडेट के साथ पुनः प्रेषित करना चाहिए।
वर्तमान implementation packets को किसी विशेष आकार तक pad नहीं करती है, बल्कि केवल एक single message fragment को packet में रखती है और इसे भेज देती है (MTU से अधिक न होने का ध्यान रखते हुए)।
MTU
router संस्करण 0.8.12 के अनुसार, IPv4 के लिए दो MTU मान उपयोग किए जाते हैं: 620 और 1484। MTU मान को पुनः प्रेषित पैकेटों के प्रतिशत के आधार पर समायोजित किया जाता है।
दोनों MTU मानों के लिए, यह वांछनीय है कि (MTU % 16) == 12 हो, ताकि 28-बाइट IP/UDP हेडर के बाद payload भाग 16 बाइट्स का गुणज हो, encryption उद्देश्यों के लिए।
छोटे MTU value के लिए, यह वांछनीय है कि 2646-byte Variable Tunnel Build Message को कई packets में कुशलतापूर्वक pack किया जाए; 620-byte MTU के साथ, यह 5 packets में अच्छी तरह से fit हो जाता है।
मापों के आधार पर, 1492 लगभग सभी उचित रूप से छोटे I2NP संदेशों के लिए उपयुक्त है (बड़े I2NP संदेश 1900 से 4500 बाइट्स तक हो सकते हैं, जो वैसे भी लाइव नेटवर्क MTU में फिट नहीं होंगे)।
MTU मान रिलीज़ 0.8.9 - 0.8.11 के लिए 608 और 1492 थे। रिलीज़ 0.8.9 से पहले बड़ा MTU 1350 था।
अधिकतम प्राप्त पैकेट आकार रिलीज़ 0.8.12 के अनुसार 1571 बाइट्स है। रिलीज़ 0.8.9 - 0.8.11 के लिए यह 1535 बाइट्स था। रिलीज़ 0.8.9 से पहले यह 2048 बाइट्स था।
रिलीज 0.9.2 के अनुसार, यदि किसी router के network interface MTU 1484 से कम है, तो वह इसे network database में प्रकाशित करेगा, और जब connection स्थापित किया जाता है तो अन्य routers को इसका सम्मान करना चाहिए।
IPv6 के लिए, न्यूनतम MTU 1280 है। IPv6 IP/UDP header 48 bytes का है, इसलिए हम एक MTU का उपयोग करते हैं जहाँ (MTU % 16 == 0), जो 1280 के लिए सही है। अधिकतम IPv6 MTU 1488 है। (संस्करण 0.9.28 से पहले अधिकतम 1472 था)।
संदेश आकार सीमाएं
जबकि अधिकतम संदेश आकार नाममात्र में 32KB है, व्यावहारिक सीमा अलग है। प्रोटोकॉल fragments की संख्या को 7 bits, या 128 तक सीमित करता है। हालांकि, वर्तमान implementation प्रत्येक संदेश को अधिकतम 64 fragments तक सीमित करती है, जो 608 MTU का उपयोग करते समय 64 * 534 = 33.3 KB के लिए पर्याप्त है। bundled LeaseSets और session keys के overhead के कारण, application level पर व्यावहारिक सीमा लगभग 6KB कम है, या लगभग 26KB। UDP transport सीमा को 32KB से ऊपर बढ़ाने के लिए और काम आवश्यक है। बड़े MTU का उपयोग करने वाले connections के लिए, बड़े संदेश संभव हैं।
निष्क्रिय समयसीमा
निष्क्रिय समय सीमा और कनेक्शन बंद करना प्रत्येक endpoint के विवेक पर है और यह अलग-अलग हो सकता है। वर्तमान implementation में जब कनेक्शन की संख्या कॉन्फ़िगर की गई अधिकतम सीमा के पास पहुंचती है तो समय सीमा कम हो जाती है, और जब कनेक्शन की संख्या कम होती है तो समय सीमा बढ़ जाती है। अनुशंसित न्यूनतम समय सीमा दो मिनट या अधिक है, और अनुशंसित अधिकतम समय सीमा दस मिनट या अधिक है।
कुंजियाँ
उपयोग की जाने वाली सभी encryption AES256/CBC है जिसमें 32 byte keys और 16 byte IVs हैं। जब Alice, Bob के साथ एक session शुरू करती है, तो MAC और session keys को DH exchange के भाग के रूप में negotiate किया जाता है, और फिर इनका उपयोग क्रमशः HMAC और encryption के लिए किया जाता है। DH exchange के दौरान, Bob की publicly knowable introKey का उपयोग MAC और encryption के लिए किया जाता है।
प्रारंभिक संदेश और बाद के उत्तर दोनों में उत्तरदाता (Bob) का introKey उपयोग होता है - उत्तरदाता को अनुरोधकर्ता (Alice) का introKey जानने की आवश्यकता नहीं है। Bob द्वारा उपयोग की जाने वाली DSA signing key Alice को पहले से पता होनी चाहिए जब वह उससे संपर्क करती है, हालांकि Alice की DSA key Bob को पहले से पता नहीं हो सकती।
संदेश प्राप्त करने पर, प्राप्तकर्ता “from” IP पते और port की जांच सभी स्थापित sessions के साथ करता है - यदि मिलान होते हैं, तो उस session की MAC keys का परीक्षण HMAC में किया जाता है। यदि उनमें से कोई भी verify नहीं होती या यदि कोई मिलान करने वाले IP पते नहीं हैं, तो प्राप्तकर्ता MAC में अपनी introKey आज़माता है। यदि वह verify नहीं होती, तो packet को drop कर दिया जाता है। यदि यह verify हो जाती है, तो इसे message type के अनुसार interpret किया जाता है, हालांकि यदि प्राप्तकर्ता overloaded है, तो इसे फिर भी drop किया जा सकता है।
यदि Alice और Bob का एक स्थापित session है, लेकिन Alice किसी कारण से keys खो देती है और वह Bob से संपर्क करना चाहती है, तो वह किसी भी समय SessionRequest और संबंधित messages के माध्यम से एक नया session स्थापित कर सकती है। यदि Bob ने key खो दी है लेकिन Alice को यह पता नहीं है, तो वह पहले उसे reply करने के लिए प्रेरित करने का प्रयास करेगी, wantReply flag सेट के साथ DataMessage भेजकर, और यदि Bob लगातार reply करने में असफल रहता है, तो वह मान लेगी कि key खो गई है और एक नई को पुनः स्थापित करेगी।
DH key agreement के लिए, RFC3526 2048bit MODP group (#14) का उपयोग किया जाता है:
p = 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
g = 2
ये वही p और g हैं जो I2P के ElGamal encryption के लिए उपयोग किए जाते हैं।
रीप्ले रोकथाम
SSU layer पर replay prevention अत्यधिक पुराने timestamps वाले या IV को दोबारा उपयोग करने वाले packets को reject करके होती है। duplicate IVs का पता लगाने के लिए, Bloom filters का एक sequence उपयोग किया जाता है जो “decay” होते रहते हैं ताकि केवल हाल ही में जोड़े गए IVs का पता लगाया जा सके।
DataMessages में उपयोग किए जाने वाले messageIds SSU transport के ऊपरी layers पर परिभाषित होते हैं और पारदर्शी रूप से पास किए जाते हैं। ये IDs किसी विशेष क्रम में नहीं होते - वास्तव में, ये पूर्णतः random होने की संभावना है। SSU layer messageId replay prevention का कोई प्रयास नहीं करती - उच्च layers को इसे ध्यान में रखना चाहिए।
पता लगाना
SSU peer से संपर्क करने के लिए, दो प्रकार की जानकारी में से एक आवश्यक है: एक प्रत्यक्ष पता, जब peer सार्वजनिक रूप से पहुंच योग्य हो, या एक अप्रत्यक्ष पता, जब peer को introduce करने के लिए तीसरे पक्ष का उपयोग करना हो। एक peer के पास कितने पते हो सकते हैं इसकी कोई सीमा नहीं है।
Direct: host, port, introKey, options
Indirect: tag, relayhost, port, relayIntroKey, targetIntroKey, options
प्रत्येक पते में विकल्पों की एक श्रृंखला भी हो सकती है - उस विशेष peer की विशेष क्षमताएं। उपलब्ध क्षमताओं की सूची के लिए, नीचे देखें।
पते, विकल्प, और क्षमताएं network database में प्रकाशित की जाती हैं।
प्रत्यक्ष सत्र स्थापना
प्रत्यक्ष सत्र स्थापना का उपयोग तब किया जाता है जब NAT traversal के लिए किसी तीसरे पक्ष की आवश्यकता नहीं होती। संदेश अनुक्रम निम्नलिखित है:
कनेक्शन स्थापना (प्रत्यक्ष)
Alice सीधे Bob से जुड़ती है। IPv6 को संस्करण 0.9.8 से समर्थन प्राप्त है।
Alice Bob
SessionRequest --------------------->
<--------------------- SessionCreated
SessionConfirmed ------------------->
<--------------------- DeliveryStatusMessage
<--------------------- DatabaseStoreMessage
DatabaseStoreMessage --------------->
Data <--------------------------> Data
SessionConfirmed संदेश प्राप्त होने के बाद, Bob पुष्टि के रूप में एक छोटा DeliveryStatus message भेजता है। इस संदेश में, 4-byte message ID को एक यादृच्छिक संख्या पर सेट किया जाता है, और 8-byte “arrival time” को वर्तमान network-wide ID पर सेट किया जाता है, जो कि 2 है (यानी 0x0000000000000002)।
स्टेटस संदेश भेजे जाने के बाद, peers आमतौर पर अपने RouterInfos वाले DatabaseStore messages का आदान-प्रदान करते हैं, हालांकि यह आवश्यक नहीं है।
यह प्रतीत नहीं होता कि status message के प्रकार या इसकी सामग्री का कोई महत्व है। यह मूल रूप से इसलिए जोड़ा गया था क्योंकि DatabaseStore message में कई सेकंड की देरी हो रही थी; चूंकि store अब तुरंत भेजा जाता है, शायद status message को समाप्त किया जा सकता है।
परिचय
Introduction keys एक बाहरी चैनल (network database) के माध्यम से वितरित की जाती हैं, जहाँ वे पारंपरिक रूप से release 0.9.47 तक router Hash के समान थीं, लेकिन release 0.9.48 से यादृच्छिक (random) हो सकती हैं। session key स्थापित करते समय इनका उपयोग अनिवार्य है। अप्रत्यक्ष पते के लिए, peer को पहले relayhost से संपर्क करना होगा और उस relayhost पर दिए गए tag के तहत ज्ञात peer से परिचय के लिए कहना होगा। यदि संभव हो, तो relayhost पते वाले peer को एक संदेश भेजता है जिसमें उन्हें अनुरोधकर्ता peer से संपर्क करने को कहा जाता है, और अनुरोधकर्ता peer को उस IP और port की जानकारी भी देता है जहाँ पते वाला peer स्थित है। इसके अतिरिक्त, कनेक्शन स्थापित करने वाले peer को उस peer की public keys पहले से पता होनी चाहिए जिससे वे जुड़ रहे हैं (लेकिन किसी मध्यवर्ती relay peer की जानकारी आवश्यक नहीं है)।
तृतीय पक्ष परिचय के माध्यम से अप्रत्यक्ष session स्थापना कुशल NAT traversal के लिए आवश्यक है। Charlie, एक router जो NAT या firewall के पीछे है और जो अवांछित inbound UDP packets की अनुमति नहीं देता, पहले कुछ peers से संपर्क करता है, और उनमें से कुछ को introducers के रूप में काम करने के लिए चुनता है। इनमें से प्रत्येक peer (Bob, Bill, Betty, आदि) Charlie को एक introduction tag प्रदान करता है - एक 4 byte का यादृच्छिक संख्या - जिसे वह फिर सार्वजनिक रूप से उससे संपर्क करने के तरीकों के रूप में उपलब्ध कराता है। Alice, एक router जिसके पास Charlie के प्रकाशित संपर्क तरीके हैं, पहले एक या अधिक introducers को RelayRequest packet भेजती है, प्रत्येक से उसे Charlie से परिचय कराने का अनुरोध करती है (Charlie की पहचान करने के लिए introduction tag प्रदान करती है)। Bob फिर Charlie को Alice का सार्वजनिक IP और port संख्या सहित एक RelayIntro packet भेजता है, फिर Alice को Charlie का सार्वजनिक IP और port संख्या युक्त RelayResponse packet वापस भेजता है। जब Charlie को RelayIntro packet मिलता है, तो वह Alice के IP और port पर एक छोटा यादृच्छिक packet भेजता है (अपने NAT/firewall में एक छेद बनाकर), और जब Alice को Bob का RelayResponse packet मिलता है, तो वह निर्दिष्ट IP और port के साथ एक नया पूर्ण दिशा session स्थापना शुरू करती है।
कनेक्शन स्थापना (एक Introducer का उपयोग करके अप्रत्यक्ष)
Alice पहले introducer Bob से जुड़ती है, जो अनुरोध को Charlie तक पहुंचाता है।
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch (data ignored)
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
<-------------------------------------------- DeliveryStatusMessage
<-------------------------------------------- DatabaseStoreMessage
DatabaseStoreMessage -------------------------------------->
Data <--------------------------------------------------> Data
hole punch के बाद, सेशन Alice और Charlie के बीच उसी तरह स्थापित होता है जैसे direct establishment में होता है।
IPv6 नोट्स
IPv6 को संस्करण 0.9.8 से समर्थन प्राप्त है। प्रकाशित relay पते IPv4 या IPv6 हो सकते हैं, और Alice-Bob संचार IPv4 या IPv6 के माध्यम से हो सकता है। रिलीज़ 0.9.49 तक, Bob-Charlie और Alice-Charlie संचार केवल IPv4 के माध्यम से होता है। IPv6 के लिए relaying को रिलीज़ 0.9.50 से समर्थन प्राप्त है। विवरण के लिए specification देखें।
जबकि specification को version 0.9.8 के अनुसार बदला गया था, IPv6 के माध्यम से Alice-Bob communication वास्तव में version 0.9.50 तक supported नहीं था। Java routers के पुराने versions ने गलत तरीके से IPv6 addresses के लिए ‘C’ capability को publish किया, भले ही वे वास्तव में IPv6 के माध्यम से introducer के रूप में कार्य नहीं करते थे। इसलिए, routers को IPv6 address पर ‘C’ capability पर तभी भरोसा करना चाहिए जब router version 0.9.50 या उससे अधिक हो।
Peer Testing
पीयर्स के लिए सहयोगी पहुंच परीक्षण (collaborative reachability testing) का स्वचालन PeerTest संदेशों के एक क्रम द्वारा सक्षम होता है। इसके उचित निष्पादन के साथ, एक पीयर अपनी स्वयं की पहुंच निर्धारित करने में सक्षम होगा और तदनुसार अपने व्यवहार को अपडेट कर सकता है। परीक्षण प्रक्रिया काफी सरल है:
Alice Bob Charlie
PeerTest ------------------->
PeerTest-------------------->
<-------------------PeerTest
<-------------------PeerTest
<------------------------------------------PeerTest
PeerTest------------------------------------------>
<------------------------------------------PeerTest
प्रत्येक PeerTest संदेश में एक nonce होता है जो परीक्षण श्रृंखला की पहचान करता है, जैसा कि Alice द्वारा शुरू किया गया है। यदि Alice को कोई विशेष संदेश नहीं मिलता जिसकी वह अपेक्षा करती है, तो वह तदनुसार पुनः संचारित करेगी, और प्राप्त डेटा या गुम संदेशों के आधार पर, वह अपनी पहुंच योग्यता को जान जाएगी। विभिन्न अंतिम स्थितियां जो पहुंची जा सकती हैं वे निम्नलिखित हैं:
यदि उसे Bob से कोई प्रतिक्रिया नहीं मिलती है, तो वह एक निश्चित संख्या तक पुनः प्रसारण करेगी, लेकिन यदि कभी कोई प्रतिक्रिया नहीं आती है, तो वह जान जाएगी कि उसका firewall या NAT किसी तरह से गलत तरीके से कॉन्फ़िगर किया गया है, जो सभी inbound UDP packets को अस्वीकार कर रहा है, यहाँ तक कि outbound packet के प्रत्यक्ष उत्तर में भी। वैकल्पिक रूप से, Bob down हो सकता है या Charlie को जवाब देने में असमर्थ हो सकता है।
यदि Alice को तीसरे पक्ष (Charlie) से अपेक्षित nonce के साथ PeerTest संदेश प्राप्त नहीं होता है, तो वह Bob को अपना प्रारंभिक अनुरोध एक निश्चित संख्या तक पुनः प्रसारित करेगी, भले ही उसे Bob का उत्तर पहले से ही मिल गया हो। यदि Charlie का पहला संदेश अभी भी नहीं पहुंचता लेकिन Bob का पहुंच जाता है, तो वह जान जाती है कि वह एक NAT या firewall के पीछे है जो अवांछित कनेक्शन प्रयासों को अस्वीकार कर रहा है और port forwarding ठीक से काम नहीं कर रहा है (Bob द्वारा प्रदान किए गए IP और port को forward किया जाना चाहिए)।
यदि Alice को Bob का PeerTest संदेश और Charlie के दोनों PeerTest संदेश प्राप्त होते हैं लेकिन Bob और Charlie के दूसरे संदेशों में शामिल IP और port नंबर मेल नहीं खाते, तो वह जान जाती है कि वह एक symmetric NAT के पीछे है, जो उसके सभी outbound packets को प्रत्येक संपर्कित peer के लिए अलग-अलग ‘from’ ports के साथ फिर से लिख रहा है। उसे स्पष्ट रूप से एक port को forward करना होगा और हमेशा उस port को remote connectivity के लिए खुला रखना होगा, आगे के port discovery को अनदेखा करते हुए।
यदि Alice को Charlie का पहला संदेश मिलता है लेकिन उसका दूसरा संदेश नहीं मिलता, तो वह Charlie को अपना PeerTest संदेश एक निश्चित संख्या तक पुनः भेजेगी, लेकिन यदि कोई प्रतिक्रिया नहीं मिलती तो वह जान जाती है कि Charlie या तो भ्रमित है या अब ऑनलाइन नहीं है।
Alice को अपने ज्ञात peers में से Bob को मनमाने तरीके से चुनना चाहिए जो peer tests में भाग लेने में सक्षम लगते हैं। Bob को बदले में Charlie को उन peers में से मनमाने तरीके से चुनना चाहिए जिन्हें वह जानता है और जो peer tests में भाग लेने में सक्षम लगते हैं और जो Bob और Alice दोनों से अलग IP पर हैं। यदि पहली त्रुटि स्थिति होती है (Alice को Bob से PeerTest messages नहीं मिलते), तो Alice एक नए peer को Bob के रूप में नामित करने और एक अलग nonce के साथ फिर से कोशिश करने का निर्णय ले सकती है।
Alice की introduction key सभी PeerTest संदेशों में शामिल होती है ताकि Charlie बिना कोई अतिरिक्त जानकारी जाने उससे संपर्क कर सके। रिलीज़ 0.9.15 के अनुसार, spoofing attacks को रोकने के लिए Alice का Bob के साथ एक स्थापित session होना चाहिए। Peer test के वैध होने के लिए Alice का Charlie के साथ कोई स्थापित session नहीं होना चाहिए। Alice Charlie के साथ session स्थापित कर सकती है, लेकिन यह आवश्यक नहीं है।
IPv6 नोट्स
रिलीज 0.9.26 तक, केवल IPv4 पतों का परीक्षण समर्थित है। केवल IPv4 पतों का परीक्षण समर्थित है। इसलिए, सभी Alice-Bob और Alice-Charlie संचार IPv4 के माध्यम से होना चाहिए। हालांकि, Bob-Charlie संचार IPv4 या IPv6 के माध्यम से हो सकता है। Alice का पता, जब PeerTest संदेश में निर्दिष्ट किया जाता है, तो 4 बाइट का होना चाहिए। रिलीज 0.9.27 से, IPv6 पतों का परीक्षण समर्थित है, और Alice-Bob और Alice-Charlie संचार IPv6 के माध्यम से हो सकता है, यदि Bob और Charlie अपने प्रकाशित IPv6 पते में ‘B’ क्षमता के साथ समर्थन का संकेत देते हैं। विवरण के लिए Proposal 126 देखें।
रिलीज 0.9.50 से पहले, Alice अपनी जांच करने वाले transport (IPv4 या IPv6) पर मौजूदा session का उपयोग करके Bob को request भेजती है। जब Bob को Alice से IPv4 के माध्यम से request मिलती है, तो Bob को एक ऐसा Charlie चुनना चाहिए जो IPv4 address का विज्ञापन करता है। जब Bob को Alice से IPv6 के माध्यम से request मिलती है, तो Bob को एक ऐसा Charlie चुनना चाहिए जो IPv6 address का विज्ञापन करता है। वास्तविक Bob-Charlie संचार IPv4 या IPv6 के माध्यम से हो सकता है (यानी, Alice के address type से स्वतंत्र)।
रिलीज़ 0.9.50 के अनुसार, यदि संदेश IPv4 peer test के लिए IPv6 पर है, या (रिलीज़ 0.9.50 के अनुसार) IPv6 peer test के लिए IPv4 पर है, तो Alice को अपना introduction address और port शामिल करना होगा।
विवरण के लिए Proposal 158 देखें।
ट्रांसमिशन विंडो, ACKs और पुनः प्रसारण
DATA संदेश में पूरे संदेशों के ACK और किसी संदेश के व्यक्तिगत fragments के आंशिक ACK हो सकते हैं। विवरण के लिए the protocol specification page का data message अनुभाग देखें।
windowing, ACK, और retransmission रणनीतियों के विवरण यहाँ निर्दिष्ट नहीं हैं। वर्तमान implementation के लिए Java कोड देखें। establishment phase के दौरान, और peer testing के लिए, router को retransmission के लिए exponential backoff implement करना चाहिए। एक established connection के लिए, router को एक adjustable transmission window, RTT estimate और timeout implement करना चाहिए, TCP या streaming के समान। initial, min और max parameters के लिए कोड देखें।
सुरक्षा
UDP स्रोत पते निश्चित रूप से नकली हो सकते हैं। इसके अतिरिक्त, विशिष्ट SSU संदेशों (RelayRequest, RelayResponse, RelayIntro, PeerTest) के अंदर निहित IP और पोर्ट वैध नहीं हो सकते हैं। साथ ही, कुछ क्रियाओं और प्रतिक्रियाओं को दर-सीमित करने की आवश्यकता हो सकती है।
यहाँ validation के विवरण निर्दिष्ट नहीं हैं। implementers को जहाँ उपयुक्त हो वहाँ सुरक्षा उपाय जोड़ने चाहिए।
पीयर क्षमताएं
एक या अधिक capabilities को “caps” option में प्रकाशित किया जा सकता है। Capabilities किसी भी क्रम में हो सकती हैं, लेकिन implementations में consistency के लिए “BC46” अनुशंसित क्रम है।
B : यदि peer address में ‘B’ capability है, तो इसका मतलब है कि वे peer tests में ‘Bob’ या ‘Charlie’ के रूप में भाग लेने के लिए इच्छुक और सक्षम हैं। 0.9.26 तक, IPv6 addresses के लिए peer testing समर्थित नहीं था, और ‘B’ capability, यदि IPv6 address के लिए मौजूद है, तो उसे अनदेखा करना होगा। 0.9.27 से, IPv6 addresses के लिए peer testing समर्थित है, और IPv6 address में ‘B’ capability की उपस्थिति या अनुपस्थिति वास्तविक समर्थन (या समर्थन की कमी) को दर्शाती है।
C : यदि peer address में ‘C’ capability शामिल है, तो इसका मतलब है कि वे उस address के माध्यम से एक introducer के रूप में सेवा करने के लिए तैयार और सक्षम हैं - अन्यथा अपहुंचनीय Charlie के लिए introducer Bob के रूप में सेवा करना। रिलीज़ 0.9.50 से पहले, Java routers गलत तरीके से IPv6 addresses के लिए ‘C’ capability प्रकाशित करते थे, भले ही IPv6 introducers पूरी तरह से लागू नहीं था। इसलिए, routers को यह मान लेना चाहिए कि 0.9.50 से पहले के संस्करण IPv6 पर introducer के रूप में कार्य नहीं कर सकते, भले ही ‘C’ capability का विज्ञापन किया गया हो।
4 : 0.9.50 के अनुसार, outbound IPv4 capability को दर्शाता है। यदि host field में कोई IP प्रकाशित है, तो यह capability आवश्यक नहीं है। यदि यह IPv4 introductions के लिए introducers वाला पता है, तो ‘4’ को शामिल किया जाना चाहिए। यदि router छुपा हुआ है, तो ‘4’ और ‘6’ को एक ही पते में संयुक्त किया जा सकता है।
6 : 0.9.50 के अनुसार, outbound IPv6 क्षमता को दर्शाता है। यदि host field में कोई IP प्रकाशित है, तो यह क्षमता आवश्यक नहीं है। यदि यह IPv6 introductions के लिए introducers वाला पता है, तो ‘6’ शामिल होना चाहिए (वर्तमान में समर्थित नहीं)। यदि router छुपा हुआ है, तो ‘4’ और ‘6’ को एक ही पते में जोड़ा जा सकता है।
भविष्य का कार्य
नोट: इन समस्याओं को SSU2 के विकास में संबोधित किया जाएगा।
वर्तमान SSU प्रदर्शन का विश्लेषण, जिसमें window size समायोजन और अन्य parameters का मूल्यांकन शामिल है, और प्रदर्शन में सुधार के लिए protocol implementation का समायोजन, भविष्य के कार्य का विषय है।
वर्तमान कार्यान्वयन समान पैकेट्स के लिए बार-बार acknowledgments भेजता है, जो अनावश्यक रूप से overhead बढ़ाता है।
डिफ़ॉल्ट छोटे MTU मान 620 का विश्लेषण किया जाना चाहिए और संभवतः इसे बढ़ाया जाना चाहिए। वर्तमान MTU समायोजन रणनीति का मूल्यांकन किया जाना चाहिए। क्या एक streaming lib 1730-byte पैकेट 3 छोटे SSU पैकेट्स में फिट हो जाता है? शायद नहीं।
प्रोटोकॉल को सेटअप के दौरान MTUs का आदान-प्रदान करने के लिए विस्तारित किया जाना चाहिए।
Rekeying वर्तमान में अनुपलब्ध है और कभी उपलब्ध नहीं होगी।
RelayIntro और RelayResponse में ‘challenge’ फ़ील्ड के संभावित उपयोग, और SessionRequest और SessionCreated में padding फ़ील्ड का उपयोग, अप्रलेखित है।
बाहरी विरोधियों से डेटा विखंडन को और छुपाने के लिए निश्चित packet sizes का एक सेट उपयुक्त हो सकता है, लेकिन तब तक के लिए tunnel, garlic, और end to end padding अधिकांश आवश्यकताओं के लिए पर्याप्त होना चाहिए।
SessionCreated और SessionConfirmed में साइन-ऑन समय अप्रयुक्त या अत्यापित प्रतीत होते हैं।