I2P: तकनीकी परिचय

नोट: यह दस्तावेज़ मूल रूप से 2003 में jrandom द्वारा लिखा गया था। हालांकि हम इसे अद्यतन रखने का प्रयास करते हैं, कुछ जानकारी पुरानी या अधूरी हो सकती है। transport और cryptography अनुभाग 2025-01 तक अद्यतन हैं।

परिचय

I2P एक स्केलेबल, स्व-संगठित, लचीला packet switched गुमनाम नेटवर्क layer है, जिस पर कई अलग-अलग गुमनामता या सुरक्षा सचेत एप्लिकेशन काम कर सकते हैं। इनमें से प्रत्येक एप्लिकेशन free route mixnet के उचित कार्यान्वयन की चिंता किए बिना अपने स्वयं के गुमनामता, विलंबता, और throughput tradeoffs बना सकते हैं, जिससे वे अपनी गतिविधि को I2P के ऊपर पहले से चल रहे उपयोगकर्ताओं के बड़े गुमनामता समूह के साथ मिला सकते हैं।

उपलब्ध एप्लिकेशन पहले से ही सामान्य इंटरनेट गतिविधियों की पूरी श्रृंखला प्रदान करते हैं — गुमनाम वेब ब्राउजिंग, वेब होस्टिंग, चैट, फ़ाइल साझाकरण, ई-मेल, ब्लॉगिंग और कंटेंट सिंडिकेशन, साथ ही विकास के तहत कई अन्य एप्लिकेशन भी।

• वेब ब्राउज़िंग: किसी भी मौजूदा browser का उपयोग करके जो proxy का समर्थन करता है।
• चैट: IRC और अन्य protocols
• फ़ाइल साझाकरण: I2PSnark और अन्य applications
• ई-मेल: susimail और अन्य applications
• ब्लॉग: किसी भी local web server का उपयोग करके, या उपलब्ध plugins

Freenet या GNUnet जैसे content distribution networks के भीतर होस्ट की गई वेब साइटों के विपरीत, I2P पर होस्ट की गई सेवाएं पूर्णतः interactive हैं — यहां पारंपरिक वेब-शैली के search engines, bulletin boards, blogs हैं जिन पर आप comment कर सकते हैं, database driven साइटें हैं, और Freenet जैसे static systems को query करने के लिए bridges हैं जिन्हें स्थानीय रूप से install करने की आवश्यकता नहीं है।

इन सभी गुमनामी सक्षम अनुप्रयोगों के साथ, I2P संदेश उन्मुख मिडलवेयर की भूमिका निभाता है — अनुप्रयोग कहते हैं कि वे एक क्रिप्टोग्राफिक पहचानकर्ता (“destination”) को कुछ डेटा भेजना चाहते हैं और I2P यह सुनिश्चित करने का ख्याल रखता है कि यह सुरक्षित और गुमनाम रूप से वहां पहुंचे। I2P एक सरल streaming लाइब्रेरी भी बंडल करता है जो I2P के गुमनाम बेस्ट-एफर्ट संदेशों को विश्वसनीय, क्रम में स्ट्रीम के रूप में स्थानांतरित करने की अनुमति देता है, पारदर्शी रूप से नेटवर्क के हाई बैंडविड्थ डिले प्रोडक्ट के लिए ट्यून किए गए TCP आधारित कंजेस्शन कंट्रोल एल्गोरिदम की पेशकश करता है। जबकि मौजूदा अनुप्रयोगों को नेटवर्क में जोड़ने के लिए कई सरल SOCKS प्रॉक्सी उपलब्ध हैं, उनका महत्व सीमित रहा है क्योंकि लगभग हर अनुप्रयोग नियमित रूप से उस जानकारी को उजागर करता है जो गुमनाम संदर्भ में संवेदनशील जानकारी है। जाने का एकमात्र सुरक्षित तरीका यह है कि किसी अनुप्रयोग का पूरी तरह से ऑडिट किया जाए ताकि उचित संचालन सुनिश्चित हो सके और इसमें सहायता के लिए हम विभिन्न भाषाओं में APIs की एक श्रृंखला प्रदान करते हैं जिसका उपयोग नेटवर्क का अधिकतम लाभ उठाने के लिए किया जा सकता है।

I2P कोई अनुसंधान परियोजना नहीं है — न तो शैक्षणिक, न व्यावसायिक, और न ही सरकारी — बल्कि यह एक इंजीनियरिंग प्रयास है जिसका उद्देश्य उन लोगों को पर्याप्त स्तर की गुमनामी प्रदान करना है जिन्हें इसकी आवश्यकता है। यह 2003 की शुरुआत से एक पूर्णकालिक डेवलपर और दुनिया भर के समर्पित अंशकालिक योगदानकर्ताओं के समूह के साथ सक्रिय विकास में है। I2P पर किया गया सभी काम ओपन सोर्स है और वेबसाइट पर स्वतंत्र रूप से उपलब्ध है, अधिकांश कोड सीधे पब्लिक डोमेन में रिलीज़ किया गया है, हालांकि BSD-शैली के लाइसेंस के तहत कुछ क्रिप्टोग्राफिक रूटीन का उपयोग किया गया है। I2P पर काम करने वाले लोग यह नियंत्रित नहीं करते कि लोग client applications को किस लाइसेंस के तहत रिलीज़ करते हैं, और कई GPL applications उपलब्ध हैं (I2PTunnel , susimail , I2PSnark , I2P-Bote, I2Phex और अन्य)। I2P के लिए फंडिंग पूरी तरह से दान से आती है, और इस समय किसी भी क्षेत्राधिकार में कोई टैक्स छूट नहीं मिलती, क्योंकि कई डेवलपर स्वयं anonymous हैं।

संचालन

अवलोकन

I2P के संचालन को समझने के लिए, कुछ मुख्य अवधारणाओं को समझना आवश्यक है। पहले, I2P नेटवर्क में भाग लेने वाले software (एक “router”) और व्यक्तिगत applications से जुड़े anonymous endpoints (“destinations”) के बीच एक सख्त अलगाव करता है। यह तथ्य कि कोई I2P चला रहा है, आमतौर पर कोई रहस्य नहीं है। जो छुपाया जाता है वह यह जानकारी है कि उपयोगकर्ता क्या कर रहा है, यदि कुछ भी है, साथ ही यह कि कोई विशेष destination किस router से जुड़ा है। अंतिम उपयोगकर्ताओं के पास आमतौर पर अपने router पर कई स्थानीय destinations होते हैं — उदाहरण के लिए, एक IRC servers में proxying करने के लिए, दूसरा उपयोगकर्ता के anonymous webserver (“I2P Site”) का समर्थन करने के लिए, दूसरा I2Phex instance के लिए, दूसरा torrents के लिए, आदि।

समझने की एक और महत्वपूर्ण अवधारणा “tunnel” है। एक tunnel स्पष्ट रूप से चुने गए router की सूची के माध्यम से एक निर्देशित पथ है। स्तरित एन्क्रिप्शन का उपयोग किया जाता है, इसलिए प्रत्येक router केवल एक ही स्तर को डिक्रिप्ट कर सकता है। डिक्रिप्ट की गई जानकारी में अगले router का IP होता है, साथ ही फॉरवर्ड की जाने वाली एन्क्रिप्टेड जानकारी भी होती है। प्रत्येक tunnel का एक प्रारंभिक बिंदु (पहला router, जिसे “gateway” भी कहा जाता है) और एक अंत बिंदु होता है। संदेश केवल एक ही दिशा में भेजे जा सकते हैं। संदेश वापस भेजने के लिए, दूसरी tunnel की आवश्यकता होती है।

दो प्रकार के tunnel मौजूद हैं: “outbound” tunnels संदेशों को tunnel निर्माता से दूर भेजते हैं, जबकि “inbound” tunnels संदेशों को tunnel निर्माता के पास लाते हैं। इन दोनों tunnels को मिलाकर उपयोगकर्ता एक-दूसरे को संदेश भेज सकते हैं। भेजने वाला (“Alice” उपरोक्त चित्र में) एक outbound tunnel स्थापित करता है, जबकि प्राप्तकर्ता (“Bob” उपरोक्त चित्र में) एक inbound tunnel बनाता है। एक inbound tunnel का gateway किसी भी अन्य उपयोगकर्ता से संदेश प्राप्त कर सकता है और उन्हें endpoint (“Bob”) तक भेजता रहेगा। Outbound tunnel के endpoint को संदेश को inbound tunnel के gateway तक भेजना होगा। इसे करने के लिए, भेजने वाला (“Alice”) अपने एन्क्रिप्टेड संदेश में निर्देश जोड़ता है। जब outbound tunnel का endpoint संदेश को डिक्रिप्ट करता है, तो उसके पास संदेश को सही inbound gateway (“Bob” के gateway) तक फॉरवर्ड करने के निर्देश होंगे।

समझने की तीसरी महत्वपूर्ण अवधारणा I2P का “network database” (या “netDb”) है — नेटवर्क मेटाडेटा साझा करने के लिए उपयोग किए जाने वाले एल्गोरिदम की एक जोड़ी। दो प्रकार के मेटाडेटा होते हैं “routerInfo” और “leaseSets” — routerInfo routers को किसी विशेष router से संपर्क करने के लिए आवश्यक डेटा प्रदान करता है (उनकी public keys, transport addresses, आदि), जबकि leaseSet routers को किसी विशेष destination से संपर्क करने के लिए आवश्यक जानकारी प्रदान करता है। एक leaseSet में कई “leases” होते हैं। इनमें से प्रत्येक lease एक tunnel gateway निर्दिष्ट करता है, जो एक विशिष्ट destination तक पहुंचने की अनुमति देता है। एक lease में निहित पूरी जानकारी:

• एक tunnel के लिए inbound gateway जो एक विशिष्ट गंतव्य तक पहुंचने की अनुमति देता है।
• वह समय जब एक tunnel समाप्त हो जाता है।
• संदेशों को encrypt करने के लिए public keys की जोड़ी (tunnel के माध्यम से भेजने और गंतव्य तक पहुंचने के लिए)।

Router स्वयं अपने routerInfo को netDb में सीधे भेजते हैं, जबकि leaseSet को outbound tunnel के माध्यम से भेजा जाता है (leaseSet को गुमनाम रूप से भेजना आवश्यक है, ताकि किसी router को उसके leaseSet के साथ जोड़ा न जा सके)।

हम नेटवर्क में सफल कनेक्शन बनाने के लिए उपरोक्त अवधारणाओं को मिला सकते हैं।

अपनी इनबाउंड और आउटबाउंड tunnels बनाने के लिए, Alice routerInfo एकत्र करने के लिए netDb में lookup करती है। इस तरह, वह उन peers की सूची इकट्ठा करती है जिन्हें वह अपनी tunnels में hops के रूप में उपयोग कर सकती है। फिर वह पहले hop को एक build message भेज सकती है, tunnel के निर्माण का अनुरोध करते हुए और उस router से कहते हुए कि वह construction message को आगे भेजे, जब तक कि tunnel का निर्माण नहीं हो जाता।

जब Alice Bob को एक संदेश भेजना चाहती है, तो वह पहले netDb में lookup करती है Bob का leaseSet खोजने के लिए, जो उसे Bob के वर्तमान inbound tunnel gateways देता है। फिर वह अपने outbound tunnels में से एक को चुनती है और उस tunnel के endpoint को निर्देश देकर संदेश भेजती है कि वह संदेश को Bob के inbound tunnel gateways में से किसी एक पर forward कर दे। जब outbound tunnel endpoint को ये निर्देश मिलते हैं, तो वह अनुरोध के अनुसार संदेश को forward कर देता है, और जब Bob के inbound tunnel gateway को यह मिलता है, तो यह tunnel के माध्यम से Bob के router तक forward हो जाता है। यदि Alice चाहती है कि Bob इस संदेश का जवाब दे सके, तो उसे अपना destination स्पष्ट रूप से संदेश के हिस्से के रूप में transmit करना होगा। यह एक higher-level layer को introduce करके किया जा सकता है, जो streaming library में किया गया है। Alice response time को कम करने के लिए अपना सबसे recent LeaseSet भी संदेश के साथ bundle कर सकती है ताकि जब Bob जवाब देना चाहे तो उसे इसके लिए netDb lookup न करना पड़े, लेकिन यह optional है।

जबकि tunnels में स्वयं layered encryption होता है जो network के अंदर peers को अनधिकृत disclosure से रोकता है (जैसे transport layer स्वयं network के बाहर peers को अनधिकृत disclosure से रोकता है), message को outbound tunnel endpoint और inbound tunnel gateway से छुपाने के लिए एक अतिरिक्त end to end encryption layer जोड़ना आवश्यक है। यह “garlic encryption ” Alice के router को कई messages को एक single “garlic message” में wrap करने देता है, जो एक विशेष public key से encrypt होता है ताकि intermediary peers यह निर्धारित न कर सकें कि garlic के अंदर कितने messages हैं, वे messages क्या कहते हैं, या वे individual cloves कहाँ जाने वाले हैं। Alice और Bob के बीच typical end to end communication के लिए, garlic को Bob के leaseSet में published public key से encrypt किया जाएगा, जिससे message को Bob के अपने router को public key दिए बिना encrypt करने की अनुमति मिलती है।

ध्यान रखने योग्य एक और महत्वपूर्ण तथ्य यह है कि I2P पूर्णतः message आधारित है और कुछ messages रास्ते में खो सकते हैं। I2P का उपयोग करने वाली applications message उन्मुख interfaces का उपयोग कर सकती हैं और अपनी congestion control और reliability आवश्यकताओं का स्वयं ध्यान रख सकती हैं, लेकिन अधिकांश के लिए I2P को streams आधारित network के रूप में देखने के लिए प्रदान की गई streaming library का पुन: उपयोग करना सबसे अच्छा होगा।

Tunnels

इनबाउंड और आउटबाउंड दोनों tunnel समान सिद्धांतों पर काम करते हैं। tunnel gateway कई tunnel संदेशों को संचित करता है, अंततः उन्हें tunnel डिलीवरी के लिए कुछ पूर्व-प्रक्रिया में बदल देता है। इसके बाद, gateway उस पूर्व-प्रक्रिया किए गए डेटा को एन्क्रिप्ट करता है और इसे पहले hop को भेजता है। वह peer और बाद के tunnel प्रतिभागी यह सत्यापित करने के बाद कि यह डुप्लिकेट नहीं है, एन्क्रिप्शन की एक परत जोड़ते हैं और इसे अगले peer को भेज देते हैं। अंततः, संदेश endpoint पर पहुंचता है जहां संदेशों को फिर से अलग किया जाता है और अनुरोध के अनुसार भेजा जाता है। अंतर इस बात में आता है कि tunnel का निर्माता क्या करता है — inbound tunnel के लिए, निर्माता endpoint होता है और वे केवल जोड़ी गई सभी परतों को decrypt करते हैं, जबकि outbound tunnel के लिए, निर्माता gateway होता है और वे सभी परतों को पूर्व-decrypt करते हैं ताकि प्रति-hop एन्क्रिप्शन की सभी परतों को जोड़े जाने के बाद, संदेश tunnel endpoint पर स्पष्ट रूप से पहुंचे।

संदेशों को आगे भेजने के लिए विशिष्ट peers का चुनाव और उनका विशेष क्रम I2P की गुमनामी और प्रदर्शन विशेषताओं दोनों को समझने के लिए महत्वपूर्ण है। जबकि network database (नीचे) के पास यह तय करने के लिए अपने स्वयं के मापदंड हैं कि कौन से peers से पूछताछ करनी है और कहाँ entries को store करना है, tunnel creators नेटवर्क में किसी भी peer का उपयोग किसी भी क्रम में (और यहाँ तक कि किसी भी संख्या में बार) एक ही tunnel में कर सकते हैं। यदि परफेक्ट latency और capacity डेटा विश्व स्तर पर ज्ञात होता, तो selection और ordering client की विशेष आवश्यकताओं के साथ-साथ उनके threat model के अनुसार संचालित होता। दुर्भाग्य से, latency और capacity डेटा को गुमनाम रूप से एकत्रित करना तुच्छ नहीं है, और इस जानकारी को प्रदान करने के लिए अविश्वसनीय peers पर निर्भर रहने के अपने गंभीर गुमनामी निहितार्थ हैं।

गुमनामी के दृष्टिकोण से, सबसे सरल तकनीक यह होगी कि पूरे नेटवर्क से peers को बेतरतीब ढंग से चुना जाए, उन्हें बेतरतीब क्रम में व्यवस्थित किया जाए और उस क्रम में उन peers का हमेशा के लिए उपयोग किया जाए। प्रदर्शन के दृष्टिकोण से, सबसे सरल तकनीक यह होगी कि आवश्यक अतिरिक्त क्षमता वाले सबसे तेज़ peers को चुना जाए, पारदर्शी failover को संभालने के लिए विभिन्न peers के बीच लोड को फैलाया जाए, और जब भी क्षमता की जानकारी बदले तो tunnel को फिर से बनाया जाए। जहाँ पहला तरीका भंगुर और अक्षम दोनों है, वहीं बाद वाला दुर्गम जानकारी की आवश्यकता रखता है और अपर्याप्त गुमनामी प्रदान करता है। इसके बजाय I2P peer selection रणनीतियों की एक श्रृंखला प्रदान करने पर काम कर रहा है, जो गुमनामी-जागरूक मापन कोड के साथ मिलकर peers को उनके प्रोफाइल के अनुसार व्यवस्थित करती है।

एक आधार के रूप में, I2P लगातार उन peers की प्रोफाइलिंग करता है जिनके साथ यह बातचीत करता है, उनके अप्रत्यक्ष व्यवहार को मापकर — उदाहरण के लिए, जब कोई peer netDb lookup का जवाब 1.3 सेकंड में देता है, तो उस round trip latency को उन सभी routers की profiles में रिकॉर्ड किया जाता है जो दोनों tunnels (inbound और outbound) में शामिल हैं जिनके माध्यम से request और response गुजरे, साथ ही queried peer के profile में भी। प्रत्यक्ष माप, जैसे transport layer latency या congestion, profile के हिस्से के रूप में उपयोग नहीं किया जाता है, क्योंकि इसे manipulate किया जा सकता है और measuring router के साथ जोड़ा जा सकता है, जिससे उन्हें trivial attacks का सामना करना पड़ सकता है। इन profiles को इकट्ठा करते समय, प्रत्येक पर एक श्रृंखला की गणना चलाई जाती है ताकि इसके प्रदर्शन का सारांश निकाला जा सके — इसकी latency, बहुत सारी गतिविधि को संभालने की क्षमता, क्या वे वर्तमान में overloaded हैं, और वे network में कितनी अच्छी तरह integrated लगते हैं। इन गणनाओं की तुलना active peers के लिए की जाती है ताकि routers को चार tiers में व्यवस्थित किया जा सके — fast और high capacity, high capacity, not failing, और failing। इन tiers के लिए thresholds गतिशील रूप से निर्धारित किए जाते हैं, और जबकि वे वर्तमान में काफी सरल algorithms का उपयोग करते हैं, विकल्प मौजूद हैं।

इस profile डेटा का उपयोग करते हुए, सबसे सरल उचित peer selection रणनीति top tier (तेज़ और उच्च क्षमता वाले) से peers को यादृच्छिक रूप से चुनना है, और यह वर्तमान में client tunnels के लिए तैनात है। Exploratory tunnels (जो netDb और tunnel management के लिए उपयोग किए जाते हैं) “not failing” tier से peers को यादृच्छिक रूप से चुनते हैं (जिसमें ‘बेहतर’ tiers के routers भी शामिल हैं), जो peer को routers को अधिक व्यापक रूप से sample करने की अनुमति देता है, वास्तव में randomized hill climbing के माध्यम से peer selection को अनुकूलित करता है। हालांकि ये रणनीतियाँ अकेली predecessor और netDb harvesting attacks के माध्यम से router के top tier में peers के बारे में जानकारी लीक करती हैं। बदले में, कई विकल्प मौजूद हैं जो, भले ही load को उतनी समान रूप से संतुलित न करें, लेकिन विशेष वर्गों के adversaries द्वारा किए गए attacks को संबोधित करेंगे।

एक यादृच्छिक key चुनकर और peers को उससे उनकी XOR दूरी के अनुसार क्रमबद्ध करके, predecessor और harvesting attacks में लीक होने वाली जानकारी को peers की विफलता दर और tier के churn के अनुसार कम किया जा सकता है। netDb harvesting attacks से निपटने के लिए एक और सरल रणनीति यह है कि inbound tunnel gateway(s) को स्थिर रखा जाए लेकिन tunnels में आगे के peers को यादृच्छिक बनाया जाए। उन adversaries के लिए predecessor attacks से निपटने के लिए जिनसे client संपर्क करता है, outbound tunnel endpoints भी स्थिर रहेंगे। सबसे अधिक exposed point पर किस peer को स्थिर करना है इसके चयन की अवधि की सीमा होनी चाहिए, क्योंकि सभी peers अंततः विफल हो जाते हैं, इसलिए इसे या तो प्रतिक्रियात्मक रूप से समायोजित किया जा सकता है या अन्य routers की मापी गई औसत विफलता समय की नकल करने के लिए पूर्वव्यापी रूप से टाला जा सकता है। इन दोनों रणनीतियों को एक साथ मिलाया जा सकता है, एक स्थिर exposed peer का उपयोग करते हुए और tunnels के भीतर XOR आधारित क्रमबद्धता का। एक अधिक कठोर रणनीति एक संभावित tunnel के सटीक peers और क्रमबद्धता को स्थिर करेगी, केवल व्यक्तिगत peers का उपयोग करेगी यदि वे सभी हर बार समान तरीके से भाग लेने के लिए सहमत होते हैं। यह XOR आधारित क्रमबद्धता से भिन्न है कि प्रत्येक peer का predecessor और successor हमेशा समान होता है, जबकि XOR केवल यह सुनिश्चित करता है कि उनका क्रम न बदले।

जैसा कि पहले उल्लेख किया गया है, I2P वर्तमान में (release 0.8) में XOR-आधारित क्रम के साथ ऊपर वर्णित tiered random strategy शामिल है। tunnel संचालन, प्रबंधन, और peer चयन में शामिल mechanics की अधिक विस्तृत चर्चा tunnel spec में मिल सकती है।

Network Database (netDb)

जैसा कि पहले उल्लेख किया गया है, I2P का netDb नेटवर्क के metadata को साझा करने का काम करता है। इसका विस्तृत विवरण network database पेज में उपलब्ध है, लेकिन एक बुनियादी स्पष्टीकरण नीचे दिया गया है।

सभी I2P router में एक local netDb होता है, लेकिन सभी router DHT में भाग नहीं लेते या leaseset lookups का जवाब नहीं देते। जो router DHT में भाग लेते हैं और leaseset lookups का जवाब देते हैं उन्हें ‘floodfill’ कहा जाता है। Router को manually floodfill के रूप में configure किया जा सकता है, या यदि उनके पास पर्याप्त क्षमता है और विश्वसनीय संचालन के लिए अन्य मानदंडों को पूरा करते हैं तो वे स्वचालित रूप से floodfill बन सकते हैं।

अन्य I2P router अपना डेटा स्टोर करेंगे और floodfill को सरल ‘store’ और ’lookup’ queries भेजकर डेटा खोजेंगे। यदि कोई floodfill router को ‘store’ query मिलती है, तो वह Kademlia algorithm का उपयोग करके अन्य floodfill router में जानकारी फैलाएगा। ’lookup’ queries वर्तमान में एक महत्वपूर्ण सुरक्षा समस्या से बचने के लिए अलग तरीके से काम करती हैं। जब lookup की जाती है, तो floodfill router lookup को अन्य peers को forward नहीं करेगा, बल्कि हमेशा खुद ही उत्तर देगा (यदि उसके पास अनुरोधित डेटा है)।

नेटवर्क डेटाबेस में दो प्रकार की जानकारी संग्रहीत की जाती है।

• एक RouterInfo किसी विशिष्ट I2P router की जानकारी संग्रहीत करता है और इससे कैसे संपर्क करना है
• एक LeaseSet किसी विशिष्ट destination की जानकारी संग्रहीत करता है (जैसे I2P वेबसाइट, ई-मेल सर्वर…)

यह सारी जानकारी प्रकाशित करने वाली पार्टी द्वारा हस्ताक्षरित होती है और इस जानकारी का उपयोग या भंडारण करने वाले किसी भी I2P router द्वारा सत्यापित होती है। इसके अतिरिक्त, डेटा में समय की जानकारी होती है, ताकि पुराने entries के भंडारण और संभावित हमलों से बचा जा सके। यही कारण है कि I2P में सही समय बनाए रखने के लिए आवश्यक कोड शामिल है, जो कभी-कभार कुछ SNTP servers से पूछताछ करता है (डिफ़ॉल्ट रूप से pool.ntp.org round robin) और transport layer पर routers के बीच समय की विसंगति का पता लगाता है।

कुछ अतिरिक्त टिप्पणियां भी महत्वपूर्ण हैं।

• अप्रकाशित और एन्क्रिप्टेड leasesets: हो सकता है कि आप चाहें कि केवल विशिष्ट लोग ही किसी गंतव्य तक पहुंच सकें। यह netDb में गंतव्य को प्रकाशित नहीं करके संभव है। हालांकि, आपको अन्य माध्यमों से गंतव्य को प्रसारित करना होगा। यह ’encrypted leaseSets’ द्वारा समर्थित है। इन leaseSets को केवल उन लोगों द्वारा डिकोड किया जा सकता है जिनके पास decryption key तक पहुंच है।

• Bootstrapping: netDb को bootstrap करना काफी सरल है। जब एक router किसी पहुंचने योग्य peer की एक routerInfo प्राप्त करने में सफल हो जाता है, तो वह उस router से network में अन्य routers के references के लिए query कर सकता है। वर्तमान में, कई users अपनी routerInfo files को एक website पर post करते हैं ताकि यह जानकारी उपलब्ध हो सके। I2P स्वचालित रूप से इनमें से किसी एक website से जुड़कर routerInfo files एकत्र करता है और bootstrap करता है। I2P इस bootstrap प्रक्रिया को “reseeding” कहता है।

• Lookup scalability: I2P नेटवर्क में lookups iterative होते हैं, recursive नहीं। यदि एक floodfill से lookup विफल हो जाता है, तो lookup को अगले सबसे नजदीकी floodfill के लिए दोहराया जाएगा। floodfill recursively किसी अन्य floodfill से डेटा नहीं मांगता है। Iterative lookups बड़े DHT नेटवर्क के लिए scalable होते हैं।

ट्रांसपोर्ट प्रोटोकॉल

Routers के बीच संचार में बाहरी विरोधियों के खिलाफ गोपनीयता और अखंडता प्रदान करने की आवश्यकता होती है, जबकि यह प्रमाणित करना होता है कि संपर्क किया गया router वही है जिसे दिया गया संदेश प्राप्त करना चाहिए। Routers अन्य routers के साथ कैसे संचार करते हैं इसकी विशिष्टताएं महत्वपूर्ण नहीं हैं — इन मूलभूत आवश्यकताओं को प्रदान करने के लिए अलग-अलग समय पर तीन अलग protocols का उपयोग किया गया है।

I2P वर्तमान में दो transport protocols का समर्थन करता है, TCP पर NTCP2 और UDP पर SSU2 । इन्होंने protocols के पिछले versions, NTCP और SSU को बदल दिया है, जो अब deprecated हैं। दोनों protocols IPv4 और IPv6 दोनों का समर्थन करते हैं। TCP और UDP transports दोनों का समर्थन करके, I2P प्रभावी रूप से अधिकांश firewalls को पार कर सकता है, जिसमें प्रतिबंधात्मक censorship शासन में traffic को block करने के लिए बनाए गए firewalls भी शामिल हैं। NTCP2 और SSU2 को आधुनिक encryption मानकों का उपयोग करने, traffic identification प्रतिरोध में सुधार करने, दक्षता और सुरक्षा बढ़ाने, और NAT traversal को अधिक मजबूत बनाने के लिए डिज़ाइन किया गया था। Router प्रत्येक समर्थित transport और IP address को network database में प्रकाशित करते हैं। सार्वजनिक IPv4 और IPv6 networks तक पहुंच वाले router आमतौर पर चार addresses प्रकाशित करते हैं, NTCP2/SSU2 और IPv4/IPv6 के प्रत्येक combination के लिए एक।

SSU2 SSU के लक्ष्यों का समर्थन और विस्तार करता है। SSU2 की अन्य आधुनिक UDP-आधारित प्रोटोकॉल जैसे Wireguard और QUIC से कई समानताएं हैं। UDP पर नेटवर्क संदेशों के विश्वसनीय परिवहन के अतिरिक्त, SSU2 peer-to-peer के लिए विशेषीकृत सुविधाएं प्रदान करता है, सहकारी IP address detection, firewall detection, और NAT traversal। जैसा कि SSU spec में वर्णित है:

इस protocol का लक्ष्य सुरक्षित, प्रमाणित, अर्ध-विश्वसनीय और अव्यवस्थित message delivery प्रदान करना है, जो तीसरे पक्षों के लिए आसानी से पहचाने जा सकने वाले डेटा की केवल न्यूनतम मात्रा को उजागर करे। इसे उच्च डिग्री संचार के साथ-साथ TCP-friendly congestion control का समर्थन करना चाहिए और इसमें PMTU detection शामिल हो सकता है। यह घरेलू उपयोगकर्ताओं के लिए पर्याप्त दरों पर bulk data को कुशलतापूर्वक स्थानांतरित करने में सक्षम होना चाहिए। इसके अतिरिक्त, इसे network बाधाओं से निपटने की तकनीकों का समर्थन करना चाहिए, जैसे अधिकांश NATs या firewalls।

NTCP2 NTCP के लक्ष्यों का समर्थन और विस्तार करता है। यह TCP पर नेटवर्क संदेशों का एक कुशल और पूर्ण रूप से एन्क्रिप्टेड परिवहन प्रदान करता है, और आधुनिक एन्क्रिप्शन मानकों का उपयोग करके ट्रैफिक पहचान के खिलाफ प्रतिरोध प्रदान करता है।

I2P एक साथ कई transports का समर्थन करता है। एक outbound connection के लिए किसी विशेष transport का चयन “bids” के साथ किया जाता है। प्रत्येक transport connection के लिए bid लगाता है और इन bids के सापेक्ष मूल्य से प्राथमिकता निर्धारित होती है। Transports अलग-अलग bids के साथ जवाब दे सकते हैं, यह इस बात पर निर्भर करता है कि peer के साथ पहले से कोई स्थापित connection है या नहीं।

बिड (प्राथमिकता) मान implementation-dependent होते हैं और ट्रैफिक स्थितियों, कनेक्शन संख्या, और अन्य कारकों के आधार पर भिन्न हो सकते हैं। Router भी network database में inbound कनेक्शन के लिए अपनी transport प्राथमिकताओं को प्रत्येक transport और पते के लिए transport “costs” के रूप में प्रकाशित करते हैं।

क्रिप्टोग्राफी

I2P एन्क्रिप्शन, प्रमाणीकरण और सत्यापन के लिए कई प्रोटोकॉल परतों पर क्रिप्टोग्राफी का उपयोग करता है। मुख्य प्रोटोकॉल परतें हैं: ट्रांसपोर्ट, tunnel build संदेश, tunnel परत एन्क्रिप्शन, netDb संदेश, और end-to-end (garlic) संदेश। I2P के मूल डिज़ाइन में क्रिप्टोग्राफिक प्राइमिटिव्स का एक छोटा सेट का उपयोग किया गया था जो उस समय सुरक्षित माने जाते थे। इनमें ElGamal असिमेट्रिक एन्क्रिप्शन, DSA-SHA1 हस्ताक्षर, AES256/CBC सिमेट्रिक एन्क्रिप्शन, और SHA-256 हैश शामिल थे। जैसे-जैसे उपलब्ध कम्प्यूटिंग पावर बढ़ी और वर्षों में क्रिप्टोग्राफिक अनुसंधान में पर्याप्त विकास हुआ, I2P को अपने प्राइमिटिव्स और प्रोटोकॉल को अपग्रेड करने की आवश्यकता हुई। इसलिए, हमने “एन्क्रिप्शन टाइप्स” और “सिग्नेचर टाइप्स” की अवधारणा जोड़ी, और इन आइडेंटिफायर को शामिल करने और समर्थन का संकेत देने के लिए अपने प्रोटोकॉल का विस्तार किया। यह हमें आधुनिक क्रिप्टोग्राफी के लिए नेटवर्क समर्थन को समय-समय पर अपडेट और विस्तारित करने और नए प्राइमिटिव्स के लिए नेटवर्क को भविष्य-सुरक्षित बनाने की अनुमति देता है, बिना बैकवर्ड कंपैटिबिलिटी को तोड़े या नेटवर्क अपडेट के लिए “फ्लैग डे” की आवश्यकता के। कुछ सिग्नेचर और एन्क्रिप्शन टाइप्स प्रयोगात्मक उपयोग के लिए भी आरक्षित हैं।

अधिकांश प्रोटोकॉल स्तरों में उपयोग किए जाने वाले वर्तमान primitives हैं X25519 key exchange, EdDSA signatures, ChaCha20/Poly1305 authenticated symmetric encryption, और SHA-256 hashes। tunnel layer encryption के लिए अभी भी AES256 का उपयोग किया जाता है। ये आधुनिक प्रोटोकॉल नेटवर्क संचार के विशाल बहुमत के लिए उपयोग किए जाते हैं। पुराने primitives जिनमें ElGamal, ECDSA, और DSA-SHA1 शामिल हैं, अधिकांश implementations द्वारा पुराने routers के साथ संचार करते समय backward compatibility के लिए समर्थित होते रहते हैं। कुछ पुराने प्रोटोकॉल को deprecated किया गया है और/या पूर्णतः हटा दिया गया है। निकट भविष्य में हम अपने मजबूत सुरक्षा मानकों को बनाए रखने के लिए post-quantum (PQ) या hybrid-PQ encryption और signatures में माइग्रेशन पर अनुसंधान शुरू करेंगे।

ये क्रिप्टोग्राफिक प्रिमिटिव्स मिलकर I2P की स्तरित सुरक्षा प्रदान करते हैं जो विभिन्न प्रकार के विरोधियों से बचाव करती है। सबसे निचले स्तर पर, router-से-router संचार को transport layer security द्वारा सुरक्षित किया जाता है। transport के माध्यम से भेजे गए Tunnel संदेशों की अपनी स्तरित एन्क्रिप्शन होती है। अन्य विभिन्न संदेशों को “garlic messages” के अंदर भेजा जाता है, जो भी encrypted होते हैं।

Garlic Messages

Garlic messages “onion” layered encryption का एक विस्तार हैं, जो एक single message की सामग्री में कई “cloves” शामिल करने की अनुमति देता है — ये पूर्ण रूप से निर्मित messages हैं जो अपने delivery के instructions के साथ आते हैं। Messages को garlic message में तब wrap किया जाता है जब message अन्यथा किसी ऐसे peer के through cleartext में pass हो रहा होता है जिसके पास उस information तक access नहीं होना चाहिए — उदाहरण के लिए, जब एक router किसी दूसरे router से tunnel में participate करने के लिए कहना चाहता है, तो वे request को garlic के अंदर wrap करते हैं, उस garlic को receiving router की public key से encrypt करते हैं, और इसे tunnel के through forward करते हैं। दूसरा उदाहरण यह है जब कोई client किसी destination को message भेजना चाहता है — sender का router उस data message को (कुछ अन्य messages के साथ) garlic में wrap करेगा, उस garlic को recipient के leaseSet में published public key से encrypt करेगा, और इसे appropriate tunnels के through forward करेगा।

encryption layer के अंदर प्रत्येक clove के साथ संलग्न “instructions” में यह क्षमता शामिल है कि clove को स्थानीय रूप से, किसी remote router पर, या किसी remote router पर remote tunnel पर forward करने का अनुरोध किया जा सकता है। उन instructions में ऐसे fields हैं जो एक peer को यह अनुरोध करने की अनुमति देते हैं कि delivery को तब तक delay किया जाए जब तक कोई निश्चित समय या शर्त पूरी नहीं हो जाती, हालांकि वे तब तक honored नहीं होंगे जब तक nontrivial delays deploy नहीं हो जाते। garlic messages को बिना tunnel बनाए किसी भी संख्या में hops के लिए explicitly route करना संभव है, या यहां तक कि tunnel messages को garlic messages में wrap करके और tunnel में अगली hop पर deliver करने से पहले उन्हें कई hops तक forward करके reroute करना भी संभव है, लेकिन ये techniques वर्तमान में existing implementation में उपयोग नहीं की जा रहीं।

सेशन टैग्स

एक अविश्वसनीय, अव्यवस्थित, संदेश आधारित प्रणाली के रूप में, I2P garlic messages को डेटा गोपनीयता और अखंडता प्रदान करने के लिए असममित और सममित एन्क्रिप्शन एल्गोरिदम का एक सरल संयोजन उपयोग करता है। मूल संयोजन को ElGamal/AES+SessionTags के नाम से जाना जाता था, लेकिन यह 2048bit ElGamal, AES256, SHA256 और 32 byte nonces के सरल उपयोग का वर्णन करने का एक अत्यधिक विस्तृत तरीका है। जबकि यह प्रोटोकॉल अभी भी समर्थित है, अधिकांश नेटवर्क एक नए प्रोटोकॉल, ECIES-X25519-AEAD-Ratchet में स्थानांतरित हो गया है। यह प्रोटोकॉल X25519, ChaCha20/Poly1305, और 32 byte nonces उत्पन्न करने के लिए एक सिंक्रोनाइज़्ड PRNG को जोड़ता है। दोनों प्रोटोकॉल का संक्षिप्त विवरण नीचे दिया गया है।

ElGamal/AES+SessionTags

पहली बार जब कोई router किसी दूसरे router को garlic message encrypt करना चाहता है, तो वे AES256 session key के लिए keying material को ElGamal के साथ encrypt करते हैं और उस encrypted ElGamal block के बाद AES256/CBC encrypted payload को जोड़ते हैं। encrypted payload के अतिरिक्त, AES encrypted section में payload length, unencrypted payload का SHA256 hash, और कई “session tags” शामिल होते हैं — random 32 byte nonces। अगली बार जब sender किसी दूसरे router को garlic message encrypt करना चाहता है, तो नई session key को ElGamal encrypt करने के बजाय वे पहले से delivered session tags में से एक को चुनते हैं और पहले की तरह payload को AES encrypt करते हैं, उस session tag के साथ उपयोग की गई session key का उपयोग करते हुए, session tag के साथ prepend करके। जब कोई router garlic encrypted message प्राप्त करता है, तो वे पहले 32 bytes की जांच करते हैं कि यह किसी उपलब्ध session tag से मेल खाता है या नहीं — यदि मेल खाता है, तो वे बस message को AES decrypt करते हैं, लेकिन यदि नहीं, तो वे पहले block को ElGamal decrypt करते हैं।

प्रत्येक session tag का उपयोग केवल एक बार ही किया जा सकता है ताकि आंतरिक विरोधियों को अलग-अलग संदेशों को एक ही router के बीच होने के रूप में अनावश्यक रूप से सहसंबंधित करने से रोका जा सके। ElGamal/AES+SessionTag एन्क्रिप्टेड संदेश का भेजने वाला तय करता है कि कब और कितने tags देने हैं, संदेशों की एक पूरी श्रृंखला को कवर करने के लिए प्राप्तकर्ता के पास पर्याप्त tags का भंडार कर देता है। Garlic संदेश एक छोटे अतिरिक्त संदेश को clove के रूप में बंडल करके (“delivery status message”) सफल tag वितरण का पता लगा सकते हैं — जब garlic संदेश अपने इच्छित प्राप्तकर्ता तक पहुंचता है और सफलतापूर्वक decrypt हो जाता है, तो यह छोटा delivery status संदेश उजागर होने वाले clove में से एक होता है और इसमें प्राप्तकर्ता को clove को वापस मूल भेजने वाले को भेजने के निर्देश होते हैं (निश्चित रूप से एक inbound tunnel के माध्यम से)। जब मूल भेजने वाला यह delivery status संदेश प्राप्त करता है, तो वे जान जाते हैं कि garlic संदेश में बंडल किए गए session tags सफलतापूर्वक वितरित हो गए थे।

Session tags का जीवनकाल बहुत छोटा होता है, जिसके बाद यदि वे उपयोग नहीं होते तो उन्हें त्याग दिया जाता है। इसके अतिरिक्त, प्रत्येक key के लिए संग्रहीत मात्रा सीमित होती है, और keys की संख्या भी सीमित होती है — यदि बहुत सारी आती हैं, तो या तो नए या पुराने संदेश छोड़ दिए जा सकते हैं। भेजने वाला इस बात पर नज़र रखता है कि क्या session tags का उपयोग करने वाले संदेश पहुंच रहे हैं, और यदि पर्याप्त संचार नहीं है तो वह पहले से सही तरीके से वितरित मान लिए गए संदेशों को छोड़ सकता है, और वापस पूर्ण महंगे ElGamal encryption की ओर लौट सकता है।

ECIES-X25519-AEAD-Ratchet

ElGamal/AES+SessionTags को कई तरीकों से काफी अधिक ओवरहेड की आवश्यकता थी। CPU का उपयोग अधिक था क्योंकि ElGamal काफी धीमा है। बैंडविड्थ अत्यधिक था क्योंकि बड़ी संख्या में session tags को पहले से ही भेजना पड़ता था, और क्योंकि ElGamal public keys बहुत बड़ी होती हैं। मेमोरी का उपयोग अधिक था क्योंकि बड़ी मात्रा में session tags को स्टोर करने की आवश्यकता थी। विश्वसनीयता session tag delivery के खो जाने से बाधित होती थी।

ECIES-X25519-AEAD-Ratchet को इन समस्याओं को हल करने के लिए डिज़ाइन किया गया था। X25519 का उपयोग key exchange के लिए किया जाता है। ChaCha20/Poly1305 का उपयोग authenticated symmetric encryption के लिए किया जाता है। Encryption keys को “double ratcheted” किया जाता है या समय-समय पर rotate किया जाता है। Session tags को 32 bytes से कम करके 8 bytes कर दिया गया है और ये PRNG के साथ generate किए जाते हैं। इस protocol की Signal और WhatsApp में उपयोग होने वाले signal protocol के साथ कई समानताएं हैं। यह protocol CPU, RAM, और bandwidth में काफी कम overhead प्रदान करता है।

session tags एक deterministic synchronized PRNG से generate किए जाते हैं जो session के दोनों ends पर चलता है ताकि session tags और session keys generate कर सके। PRNG एक HKDF है जो SHA-256 HMAC का उपयोग करता है, और X25519 DH परिणाम से seeded होता है। Session tags कभी भी advance में transmit नहीं किए जाते; वे केवल message के साथ include किए जाते हैं। Receiver सीमित संख्या में session keys store करता है, जो session tag द्वारा indexed होती हैं। Sender को कोई session tags या keys store करने की आवश्यकता नहीं होती क्योंकि वे advance में send नहीं किए जाते; वे on-demand generate किए जा सकते हैं। इस PRNG को sender और recipient के बीच लगभग synchronized रखकर (recipient अगले उदाहरण के लिए 50 tags की एक window को precompute करता है), बड़ी संख्या में tags को periodically bundle करने का overhead हटा दिया जाता है।

भविष्य

I2P के protocols अधिकांश platforms पर कुशल हैं, जिनमें cell phones भी शामिल हैं, और अधिकांश threat models के लिए सुरक्षित हैं। हालांकि, कई क्षेत्र हैं जिनमें उन लोगों की आवश्यकताओं को पूरा करने के लिए और सुधार की आवश्यकता है जो शक्तिशाली राज्य-प्रायोजित विरोधियों का सामना कर रहे हैं, और निरंतर cryptographic प्रगति और लगातार बढ़ती computing power के खतरों से निपटने के लिए। दो संभावित सुविधाओं, restricted routes और variable latency, को jrandom द्वारा 2003 में प्रस्तावित किया गया था। जबकि हमारी अब इन सुविधाओं को implement करने की योजना नहीं है, वे नीचे वर्णित हैं।

प्रतिबंधित मार्ग संचालन

I2P एक overlay network है जो एक कार्यशील packet switched network के ऊपर चलाने के लिए डिज़ाइन किया गया है, जो anonymity और security प्रदान करने के लिए end to end principle का उपयोग करता है। जबकि Internet अब पूरी तरह से end to end principle को नहीं अपनाता (NAT के उपयोग के कारण), I2P को network के एक महत्वपूर्ण हिस्से के reachable होने की आवश्यकता होती है — किनारों पर restricted routes का उपयोग करने वाले कई peers हो सकते हैं, लेकिन I2P में उस degenerate case के लिए उपयुक्त routing algorithm शामिल नहीं है जहाँ अधिकांश peers unreachable हों। हालांकि, यह ऐसे algorithm का उपयोग करने वाले network के ऊपर काम कर सकता है।

प्रतिबंधित route संचालन, जहाँ सीधे पहुंच योग्य peers की सीमाएं होती हैं, के कई अलग-अलग कार्यात्मक और गुमनामी निहितार्थ हैं, जो इस बात पर निर्भर करता है कि प्रतिबंधित routes को कैसे संभाला जाता है। सबसे बुनियादी स्तर पर, प्रतिबंधित routes तब मौजूद होती हैं जब कोई peer NAT या firewall के पीछे होता है जो inbound connections की अनुमति नहीं देता। इसे transport layer में distributed hole punching को एकीकृत करके काफी हद तक हल किया गया, जिससे अधिकांश NATs और firewalls के पीछे के लोग बिना किसी कॉन्फ़िगरेशन के unsolicited connections प्राप्त कर सकें। हालांकि, यह network के अंदर routers के लिए peer के IP address के exposure को सीमित नहीं करता, क्योंकि वे published introducer के माध्यम से peer से परिचय प्राप्त कर सकते हैं।

प्रतिबंधित routes की कार्यात्मक handling के अलावा, प्रतिबंधित संचालन के दो स्तर हैं जो किसी के IP address के exposure को सीमित करने के लिए उपयोग किए जा सकते हैं — संचार के लिए router-विशिष्ट tunnels का उपयोग करना, और ‘client routers’ प्रदान करना। पूर्व के लिए, routers या तो tunnels का एक नया pool बना सकते हैं या अपने exploratory pool का पुन: उपयोग कर सकते हैं, उनमें से कुछ के inbound gateways को अपने transport addresses के स्थान पर अपने routerInfo के हिस्से के रूप में प्रकाशित करते हैं। जब कोई peer उनसे संपर्क करना चाहता है, तो वे netDb में उन tunnel gateways को देखते हैं और केवल प्रकाशित tunnels में से एक के माध्यम से संबंधित संदेश भेजते हैं। यदि प्रतिबंधित route के पीछे का peer उत्तर देना चाहता है, तो वह या तो प्रत्यक्ष रूप से (यदि वे peer को अपना IP expose करने को तैयार हैं) या अपने outbound tunnels के माध्यम से अप्रत्यक्ष रूप से ऐसा कर सकता है। जब routers जिनके साथ peer के प्रत्यक्ष connections हैं, उस तक पहुंचना चाहते हैं (उदाहरण के लिए, tunnel messages को forward करने के लिए), वे केवल प्रकाशित tunnel gateway पर अपने प्रत्यक्ष connection को प्राथमिकता देते हैं। ‘Client routers’ की अवधारणा केवल कोई भी router addresses प्रकाशित नहीं करके प्रतिबंधित route को विस्तृत करती है। ऐसे router को netDb में अपना routerInfo प्रकाशित करने की भी आवश्यकता नहीं होगी, केवल उन peers को अपना self signed routerInfo प्रदान करना होगा जिनसे वह संपर्क करता है (router की public keys पास करने के लिए आवश्यक)।

प्रतिबंधित routes के पीछे वाले लोगों के लिए trade-offs हैं, क्योंकि वे अन्य लोगों के tunnels में कम बार भाग लेंगे, और जिन routers से वे जुड़े हैं वे उन traffic patterns का अनुमान लगा सकेंगे जो अन्यथा exposed नहीं होते। दूसरी ओर, यदि उस exposure की cost एक IP उपलब्ध कराने की cost से कम है, तो यह सार्थक हो सकता है। यह, निश्चित रूप से, यह मानता है कि प्रतिबंधित route के पीछे का router जिन peers से संपर्क करता है वे शत्रुतापूर्ण नहीं हैं — या तो network इतना बड़ा है कि जुड़ने के लिए शत्रुतापूर्ण peer का उपयोग करने की संभावना पर्याप्त रूप से कम है, या इसके बजाय विश्वसनीय (और शायद अस्थायी) peers का उपयोग किया जाता है।

Restricted routes जटिल हैं, और समग्र लक्ष्य को काफी हद तक छोड़ दिया गया है। कई संबंधित सुधारों ने उनकी आवश्यकता को काफी कम कर दिया है। हम अब firewall ports को स्वचालित रूप से खोलने के लिए UPnP का समर्थन करते हैं। हम IPv4 और IPv6 दोनों का समर्थन करते हैं। SSU2 ने address detection, firewall state determination, और cooperative NAT hole punching में सुधार किया है। SSU2, NTCP2, और address compatibility checks यह सुनिश्चित करती हैं कि tunnel बनाने से पहले tunnel hops connect हो सकें। GeoIP और country identification हमें restrictive firewalls वाले देशों में peers से बचने की अनुमति देता है। उन firewalls के पीछे “hidden” routers के लिए समर्थन में सुधार हुआ है। कुछ implementations Yggdrasil जैसे overlay networks पर peers से connections का भी समर्थन करती हैं।

परिवर्तनशील विलंबता

भले ही I2P के प्रारंभिक प्रयासों का मुख्य भाग कम विलंबता संचार पर रहा है, लेकिन इसे शुरुआत से ही परिवर्तनीय विलंबता सेवाओं को ध्यान में रखते हुए डिज़ाइन किया गया था। सबसे बुनियादी स्तर पर, I2P के ऊपर चलने वाले एप्लिकेशन मध्यम और उच्च विलंबता संचार की गुमनामी प्रदान कर सकते हैं, जबकि फिर भी अपने ट्रैफिक पैटर्न को कम विलंबता ट्रैफिक के साथ मिलाते रहते हैं। हालांकि आंतरिक रूप से, I2P garlic encryption के माध्यम से अपना स्वयं का मध्यम और उच्च विलंबता संचार प्रदान कर सकता है — यह निर्दिष्ट करते हुए कि संदेश को एक निश्चित देरी के बाद भेजा जाना चाहिए, एक निश्चित समय पर, एक निश्चित संख्या में संदेश भेजे जाने के बाद, या किसी अन्य मिश्रण रणनीति के साथ। स्तरित एन्क्रिप्शन के साथ, केवल वह router जिसके लिए clove ने देरी अनुरोध को उजागर किया है, यह जान सकता है कि संदेश को उच्च विलंबता की आवश्यकता है, जिससे ट्रैफिक को कम विलंबता ट्रैफिक के साथ और भी बेहतर तरीके से मिलाने की अनुमति मिलती है। एक बार ट्रांसमिशन की पूर्व शर्त पूरी हो जाने पर, clove को पकड़े रखने वाला router (जो स्वयं संभवतः एक garlic message होगा) बस इसे अनुरोधित तरीके से आगे भेज देता है — एक router को, एक tunnel को, या सबसे अधिक संभावना है कि एक दूरस्थ client destination को।

परिवर्तनीय विलंबता सेवाओं का लक्ष्य इसे समर्थन देने के लिए store-and-forward तंत्रों के लिए पर्याप्त संसाधनों की आवश्यकता होती है। ये तंत्र विभिन्न मैसेजिंग एप्लिकेशन में समर्थित हो सकते हैं और होते हैं, जैसे कि i2p-bote। नेटवर्क स्तर पर, वैकल्पिक नेटवर्क जैसे Freenet ये सेवाएं प्रदान करते हैं। हमने I2P router स्तर पर इस लक्ष्य को आगे नहीं बढ़ाने का निर्णय लिया है।

समान सिस्टम

I2P की आर्किटेक्चर message oriented middleware की अवधारणाओं, DHTs की टोपोलॉजी, free route mixnets की anonymity और cryptography, और packet switched networking की अनुकूलनशीलता पर आधारित है। मूल्य नवीन अवधारणाओं या algorithms से नहीं आता, बल्कि मौजूदा सिस्टम और papers के research परिणामों को मिलाकर सावधानीपूर्वक इंजीनियरिंग से आता है। जबकि technical और functional तुलना के लिए कुछ समान प्रयास समीक्षा के योग्य हैं, दो विशेष रूप से यहाँ निकाले गए हैं — Tor और Freenet।

नेटवर्क तुलना पृष्ठ भी देखें। ध्यान दें कि ये विवरण jrandom द्वारा 2003 में लिखे गए थे और हो सकता है कि वर्तमान में सटीक न हों।

Tor

वेबसाइट

पहली नज़र में, Tor और I2P में कई कार्यात्मक और गुमनामी संबंधी समानताएं हैं। जबकि I2P का विकास हमारे द्वारा Tor के प्रारंभिक चरण के प्रयासों के बारे में जानने से पहले शुरू हुआ था, मूल onion routing और ZKS प्रयासों के कई सबक I2P के डिज़ाइन में एकीकृत किए गए थे। directory servers के साथ एक अनिवार्य रूप से विश्वसनीय, केंद्रीकृत प्रणाली बनाने के बजाय, I2P में एक स्व-संगठित network database है जिसमें प्रत्येक peer अन्य routers की प्रोफाइलिंग की जिम्मेदारी लेता है ताकि यह निर्धारित किया जा सके कि उपलब्ध संसाधनों का सबसे अच्छा उपयोग कैसे करना है। एक अन्य मुख्य अंतर यह है कि जबकि I2P और Tor दोनों स्तरित और क्रमबद्ध पथ (tunnels और circuits/streams) का उपयोग करते हैं, I2P मौलिक रूप से एक packet switched network है, जबकि Tor मौलिक रूप से एक circuit switched network है, जो I2P को भीड़भाड़ या अन्य network failures के आसपास पारदर्शी रूप से रूट करने, redundant pathways संचालित करने, और उपलब्ध संसाधनों में डेटा को load balance करने की अनुमति देता है। जबकि Tor एकीकृत outproxy खोज और चयन प्रदान करके उपयोगी outproxy कार्यक्षमता प्रदान करता है, I2P ऐसे application layer के निर्णय I2P के ऊपर चलने वाले applications पर छोड़ देता है — वास्तव में, I2P ने TCP-like streaming library को भी application layer में बाहरी कर दिया है, जिससे developers को अलग-अलग रणनीतियों के साथ प्रयोग करने, बेहतर प्रदर्शन प्रदान करने के लिए अपने domain specific ज्ञान का दोहन करने की अनुमति मिलती है।

गुमनामी के दृष्टिकोण से, मुख्य networks की तुलना करने पर बहुत समानता है। हालांकि, कुछ प्रमुख अंतर हैं। जब internal adversary या अधिकांश external adversaries के साथ निपटने की बात आती है, तो I2P के simplex tunnels केवल flows को देखकर ही Tor के duplex circuits की तुलना में आधा traffic data expose करते हैं — एक HTTP request और response Tor में समान path का पालन करेंगे, जबकि I2P में request बनाने वाले packets एक या अधिक outbound tunnels के माध्यम से बाहर जाएंगे और response बनाने वाले packets एक या अधिक अलग inbound tunnels के माध्यम से वापस आएंगे। जबकि I2P की peer selection और ordering strategies को predecessor attacks को पर्याप्त रूप से संबोधित करना चाहिए, यदि bidirectional tunnels पर स्विच करना आवश्यक हो, तो हम समान routers के साथ एक inbound और outbound tunnel का निर्माण कर सकते हैं।

Tor के telescopic tunnel निर्माण के उपयोग में एक और गुमनामी की समस्या आती है, क्योंकि जब cells एक circuit से होकर विरोधी के node से गुजरते हैं तो सरल packet counting और timing measurements सांख्यिकीय जानकारी को उजागर करते हैं कि विरोधी circuit के भीतर कहाँ स्थित है। I2P का एकदिशीय tunnel निर्माण एक single message के साथ होता है ताकि यह डेटा उजागर न हो। tunnel में स्थिति की सुरक्षा महत्वपूर्ण है, क्योंकि अन्यथा एक विरोधी शक्तिशाली predecessor, intersection, और traffic confirmation attacks की एक श्रृंखला माउंट करने में सक्षम होगा।

समग्र रूप से, Tor और I2P अपने फोकस में एक-दूसरे के पूरक हैं — Tor उच्च गति गुमनाम इंटरनेट outproxying प्रदान करने की दिशा में काम करता है, जबकि I2P स्वयं में एक विकेंद्रीकृत लचीला नेटवर्क प्रदान करने की दिशा में काम करता है। सिद्धांत रूप में, दोनों का उपयोग दोनों उद्देश्यों को प्राप्त करने के लिए किया जा सकता है, लेकिन सीमित विकास संसाधनों को देखते हुए, दोनों की अपनी शक्तियां और कमजोरियां हैं। I2P डेवलपर्स ने I2P के डिज़ाइन का फायदा उठाने के लिए Tor को संशोधित करने हेतु आवश्यक कदमों पर विचार किया है, लेकिन संसाधन की कमी के तहत Tor की व्यवहार्यता की चिंताओं से पता चलता है कि I2P की packet switching आर्किटेक्चर दुर्लभ संसाधनों का अधिक प्रभावी रूप से दोहन कर सकेगी।

Freenet

वेबसाइट

Freenet ने I2P के डिज़ाइन के प्रारंभिक चरणों में एक बड़ी भूमिका निभाई — network के भीतर पूरी तरह से समाहित एक जीवंत छद्म नाम समुदाय की व्यवहार्यता का प्रमाण देते हुए, यह प्रदर्शित किया कि outproxies में निहित खतरों से बचा जा सकता है। I2P का पहला बीज Freenet के लिए एक प्रतिस्थापन संचार परत के रूप में शुरू हुआ, जो एक स्केलेबल, गुमनाम और सुरक्षित point to point संचार की जटिलताओं को एक सेंसरशिप प्रतिरोधी वितरित डेटा store की जटिलताओं से अलग करने का प्रयास कर रहा था। समय के साथ हालांकि, Freenet के algorithms में निहित कुछ anonymity और scalability समस्याओं ने यह स्पष्ट कर दिया कि I2P का फोकस Freenet के एक घटक के बजाय एक सामान्य गुमनाम संचार परत प्रदान करने पर कड़ाई से रहना चाहिए। वर्षों के दौरान, Freenet developers ने पुराने डिज़ाइन की कमजोरियों को देखा है, जिससे उन्हें यह सुझाना पड़ा कि उन्हें पर्याप्त anonymity प्रदान करने के लिए एक “premix” परत की आवश्यकता होगी। दूसरे शब्दों में, Freenet को I2P या Tor जैसे mixnet के ऊपर चलने की आवश्यकता है, जहां “client nodes” mixnet के माध्यम से “server nodes” से डेटा का अनुरोध और प्रकाशन करते हैं जो फिर Freenet के heuristic वितरित डेटा storage algorithms के अनुसार डेटा को fetch और store करते हैं।

Freenet की कार्यक्षमता I2P के साथ बहुत पूरक है, क्योंकि Freenet मध्यम और उच्च विलंबता प्रणालियों के संचालन के लिए कई उपकरण मूल रूप से प्रदान करता है, जबकि I2P मूल रूप से कम विलंबता mix network प्रदान करता है जो पर्याप्त गुमनामी प्रदान करने के लिए उपयुक्त है। mixnet को सेंसरशिप-प्रतिरोधी वितरित डेटा स्टोर से अलग करने का तर्क अभी भी इंजीनियरिंग, गुमनामी, सुरक्षा और संसाधन आवंटन के दृष्टिकोण से स्वयं-स्पष्ट लगता है, इसलिए उम्मीद है कि Freenet टीम उस दिशा में प्रयास जारी रखेगी, यदि केवल I2P या Tor जैसे मौजूदा mixnets का पुन: उपयोग नहीं कर रही (या आवश्यकतानुसार सुधार में मदद नहीं कर रही) है।

परिशिष्ट A: एप्लिकेशन लेयर

I2P स्वयं वास्तव में ज्यादा कुछ नहीं करता — यह केवल दूरस्थ गंतव्यों को संदेश भेजता है और स्थानीय गंतव्यों को लक्षित संदेश प्राप्त करता है — अधिकांश दिलचस्प कार्य इसके ऊपरी परतों में होता है। अपने आप में, I2P को एक गुमनाम और सुरक्षित IP परत के रूप में देखा जा सकता है, और बंडल किया गया streaming library इसके ऊपर एक गुमनाम और सुरक्षित TCP परत के कार्यान्वयन के रूप में। इससे आगे, I2PTunnel I2P network में प्रवेश करने या बाहर निकलने के लिए एक सामान्य TCP proxying सिस्टम उजागर करता है, साथ ही विभिन्न नेटवर्क एप्लिकेशन अंतिम उपयोगकर्ताओं के लिए और भी कार्यक्षमता प्रदान करते हैं।

स्ट्रीमिंग लाइब्रेरी

I2P streaming library को एक generic streaming interface के रूप में देखा जा सकता है (TCP sockets को दर्शाते हुए), और implementation एक sliding window protocol का समर्थन करता है जिसमें कई optimizations हैं, I2P पर high delay को ध्यान में रखते हुए। अलग-अलग streams अधिकतम packet size और अन्य options को समायोजित कर सकते हैं, हालांकि 4KB compressed का default खोए गए messages को retransmit करने की bandwidth costs और multiple messages की latency के बीच एक उचित tradeoff लगता है।

इसके अतिरिक्त, बाद के संदेशों की अपेक्षाकृत उच्च लागत को देखते हुए, streaming library के संदेश शेड्यूलिंग और वितरण के प्रोटोकॉल को अनुकूलित किया गया है ताकि पारित किए गए व्यक्तिगत संदेशों में उपलब्ध अधिकतम जानकारी हो सके। उदाहरण के लिए, streaming library के माध्यम से प्रॉक्सी किया गया एक छोटा HTTP ट्रांजेक्शन एक ही राउंड ट्रिप में पूरा हो सकता है — पहला संदेश SYN, FIN और छोटे payload (एक HTTP अनुरोध आम तौर पर फिट हो जाता है) को बंडल करता है और उत्तर SYN, FIN, ACK और छोटे payload (कई HTTP प्रतिक्रियाएं फिट हो जाती हैं) को बंडल करता है। जबकि HTTP सर्वर को बताने के लिए एक अतिरिक्त ACK भेजना होगा कि SYN/FIN/ACK प्राप्त हो गया है, स्थानीय HTTP प्रॉक्सी तुरंत ब्राउज़र को पूर्ण प्रतिक्रिया वितरित कर सकता है।

हालांकि, कुल मिलाकर streaming library TCP के abstraction से बहुत मिलती-जुलती है, अपनी sliding windows, congestion control algorithms (slow start और congestion avoidance दोनों), और सामान्य packet behavior (ACK, SYN, FIN, RST, आदि) के साथ।

नामकरण लाइब्रेरी और पता पुस्तिका

अधिक जानकारी के लिए नामकरण और पता पुस्तिका पृष्ठ देखें।

डेवलपर्स: mihi, Ragnarok

I2P के भीतर नामकरण शुरुआत से ही एक बहुत बहस का विषय रहा है जिसमें संभावनाओं के पूरे स्पेक्ट्रम में समर्थक हैं। हालांकि, सुरक्षित संचार और विकेंद्रीकृत संचालन की I2P की अंतर्निहित मांग को देखते हुए, पारंपरिक DNS-शैली का नामकरण सिस्टम स्पष्ट रूप से बाहर है, जैसे कि “बहुमत नियम” मतदान सिस्टम भी हैं। इसके बजाय, I2P एक सामान्य नामकरण लाइब्रेरी और एक आधार कार्यान्वयन के साथ आता है जो स्थानीय नाम से destination मैपिंग पर काम करने के लिए डिज़ाइन किया गया है, साथ ही “Address Book” नामक एक वैकल्पिक ऐड-ऑन एप्लिकेशन भी है। address book एक web-of-trust-संचालित सुरक्षित, वितरित, और मानव-पठनीय नामकरण सिस्टम है, जो केवल स्थानीय विशिष्टता को अनिवार्य बनाकर सभी मानव-पठनीय नामों के विश्व स्तर पर अद्वितीय होने की मांग का त्याग करता है। जबकि I2P में सभी संदेश उनके destination द्वारा क्रिप्टोग्राफिक रूप से संबोधित होते हैं, विभिन्न लोगों के पास “Alice” के लिए स्थानीय address book प्रविष्टियां हो सकती हैं जो विभिन्न destinations को संदर्भित करती हैं। लोग अभी भी अपने web of trust में निर्दिष्ट साथियों की प्रकाशित address books आयात करके, किसी तीसरे पक्ष के माध्यम से प्रदान की गई प्रविष्टियों को जोड़कर, या (यदि कुछ लोग पहले आओ पहले पाओ पंजीकरण सिस्टम का उपयोग करके प्रकाशित address books की एक श्रृंखला आयोजित करते हैं) लोग इन address books को name servers के रूप में मानने का चुनाव कर सकते हैं, पारंपरिक DNS का अनुकरण करते हुए, नए नाम खोज सकते हैं।

I2P DNS-जैसी सेवाओं के उपयोग को बढ़ावा नहीं देता, क्योंकि किसी साइट को हाइजैक करने से होने वाला नुकसान बहुत भयानक हो सकता है — और असुरक्षित destinations का कोई मूल्य नहीं है। DNSsec स्वयं भी registrars और certificate authorities पर निर्भर रहता है, जबकि I2P के साथ, किसी destination को भेजे गए requests को intercept नहीं किया जा सकता या reply को spoof नहीं किया जा सकता, क्योंकि वे destination की public keys से encrypted होते हैं, और एक destination स्वयं केवल public keys की एक जोड़ी और एक certificate है। दूसरी ओर DNS-style systems lookup path पर किसी भी name server को सरल denial of service और spoofing attacks करने की अनुमति देते हैं। किसी centralized certificate authority द्वारा signed के रूप में responses को प्रमाणित करने वाला certificate जोड़ना कई hostile nameserver समस्याओं को हल कर देगा लेकिन replay attacks के साथ-साथ hostile certificate authority attacks के लिए खुला छोड़ देगा।

वोटिंग स्टाइल नेमिंग भी खतरनाक है, विशेष रूप से anonymous systems में Sybil attacks की प्रभावशीलता को देखते हुए — आक्रमणकारी केवल मनमानी उच्च संख्या में peers बना सकता है और किसी दिए गए नाम पर कब्जा करने के लिए प्रत्येक के साथ “वोट” कर सकता है। Proof-of-work methods का उपयोग identity को non-free बनाने के लिए किया जा सकता है, लेकिन जैसे-जैसे network बढ़ता है, online voting आयोजित करने के लिए सभी से संपर्क करने के लिए आवश्यक load अव्यावहारिक है, या यदि पूरे network से query नहीं की जाती है, तो अलग-अलग उत्तर sets पहुँचने योग्य हो सकते हैं।

हालांकि इंटरनेट की तरह, I2P एक नेमिंग सिस्टम के डिज़ाइन और संचालन को (IP-जैसी) संचार परत से बाहर रख रहा है। बंडल की गई नेमिंग लाइब्रेरी में एक सरल सेवा प्रदाता इंटरफेस शामिल है जिसमें वैकल्पिक नेमिंग सिस्टम प्लग इन कर सकते हैं, जिससे अंतिम उपयोगकर्ता यह तय कर सकते हैं कि वे किस प्रकार के नेमिंग ट्रेडऑफ पसंद करते हैं।

I2PTunnel

द्वारा विकसित: mihi

I2PTunnel संभवतः I2P का सबसे लोकप्रिय और बहुमुखी client application है, जो I2P network के अंदर और बाहर दोनों तरफ generic proxying की सुविधा प्रदान करता है। I2PTunnel को चार अलग proxying applications के रूप में देखा जा सकता है — एक “client” जो inbound TCP connections प्राप्त करता है और उन्हें एक दिए गए I2P destination पर forward करता है, एक “httpclient” (जिसे “eepproxy” भी कहा जाता है) जो HTTP proxy की तरह काम करता है और requests को उपयुक्त I2P destination पर forward करता है (यदि आवश्यक हो तो naming service से query करने के बाद), एक “server” जो एक destination पर inbound I2P streaming connections प्राप्त करता है और उन्हें एक दिए गए TCP host+port पर forward करता है, और एक “httpserver” जो “server” को extend करता है HTTP request और responses को parse करके safer operation की अनुमति देता है। एक अतिरिक्त “socksclient” application भी है, लेकिन पहले बताए गए कारणों से इसके उपयोग को प्रोत्साहित नहीं किया जाता।

I2P अपने आप में एक outproxy नेटवर्क नहीं है — एक mix net में निहित गुमनामी और सुरक्षा चिंताएं जो mix के अंदर और बाहर डेटा को forward करता है, ने I2P के डिज़ाइन को एक गुमनाम नेटवर्क प्रदान करने पर केंद्रित रखा है जो बाहरी संसाधनों की आवश्यकता के बिना उपयोगकर्ता की जरूरतों को पूरा करने में सक्षम है। हालांकि, I2PTunnel “httpclient” एप्लिकेशन outproxying के लिए एक hook प्रदान करता है — यदि अनुरोधित hostname “.i2p” के साथ समाप्त नहीं होता है, तो यह उपयोगकर्ता द्वारा प्रदान किए गए outproxies के सेट से एक यादृच्छिक destination चुनता है और अनुरोध को उनके पास forward करता है। ये destinations केवल स्वयंसेवकों द्वारा चलाए गए I2PTunnel “server” instances हैं जिन्होंने स्पष्ट रूप से outproxies चलाने का विकल्प चुना है — कोई भी डिफ़ॉल्ट रूप से outproxy नहीं है, और एक outproxy चलाना स्वचालित रूप से अन्य लोगों को आपके माध्यम से proxy करने के लिए नहीं कहता है। जबकि outproxies में अंतर्निहित कमजोरियां होती हैं, वे I2P का उपयोग करने के लिए एक सरल proof of concept प्रदान करते हैं और एक threat model के तहत कुछ कार्यक्षमता प्रदान करते हैं जो कुछ उपयोगकर्ताओं के लिए पर्याप्त हो सकती है।

I2PTunnel अधिकांश उपयोग में आने वाले एप्लिकेशन को सक्षम बनाता है। एक वेबसर्वर की ओर इशारा करने वाला “httpserver” किसी भी व्यक्ति को अपनी गुमनाम वेबसाइट (या “I2P Site”) चलाने की अनुमति देता है — इस उद्देश्य के लिए I2P के साथ एक वेबसर्वर बंडल किया गया है, लेकिन कोई भी वेबसर्वर उपयोग किया जा सकता है। कोई भी व्यक्ति गुमनाम रूप से होस्ट किए गए IRC सर्वर में से किसी एक की ओर इशारा करने वाला “client” चला सकता है, जिनमें से प्रत्येक अपने स्थानीय IRCd की ओर इशारा करने वाला “server” चला रहा है और अपनी स्वयं की “client” tunnels पर IRCds के बीच संवाद कर रहा है। अंतिम उपयोगकर्ताओं के पास I2Pmail के POP3 और SMTP गंतव्यों की ओर इशारा करने वाली “client” tunnels भी हैं (जो बदले में केवल POP3 और SMTP सर्वर की ओर इशारा करने वाले “server” instances हैं), साथ ही I2P के CVS सर्वर की ओर इशारा करने वाली “client” tunnels भी हैं, जो गुमनाम विकास की अनुमति देती हैं। कई बार लोगों ने NNTP सर्वर की ओर इशारा करने वाले “server” instances तक पहुंचने के लिए “client” proxies भी चलाए हैं।

I2PSnark

I2PSnark विकसित: jrandom, et al, mjw के Snark क्लाइंट से पोर्ट किया गया

I2P इंस्टाल के साथ बंडल किया गया, I2PSnark एक सरल anonymous BitTorrent क्लाइंट प्रदान करता है जिसमें multitorrent क्षमताएं हैं, और यह सभी कार्यक्षमता को एक सादे HTML वेब इंटरफ़ेस के माध्यम से उपलब्ध कराता है।

I2Pmail / Susimail

द्वारा विकसित: postman, susi23, mastiejaner

I2Pmail एक एप्लिकेशन से अधिक एक सेवा है — postman POP3 और SMTP सेवा के साथ आंतरिक और बाहरी ईमेल दोनों प्रदान करता है I2PTunnel instances के माध्यम से mastiejaner के साथ विकसित components की एक श्रृंखला तक पहुंच बनाकर, जो लोगों को अपने पसंदीदा mail clients का उपयोग करके छद्म नाम से मेल भेजने और प्राप्त करने की अनुमति देता है। हालांकि, चूंकि अधिकांश mail clients काफी पहचानने योग्य जानकारी उजागर करते हैं, I2P में susi23 का web आधारित susimail client bundled है जो विशेष रूप से I2P की anonymity आवश्यकताओं को ध्यान में रखकर बनाया गया है। I2Pmail/mail.i2p सेवा transparent virus filtering के साथ-साथ hashcash augmented quotas के साथ denial of service prevention प्रदान करती है। इसके अलावा, प्रत्येक user का mail.i2p outproxies के माध्यम से delivery से पहले अपनी batching strategy पर नियंत्रण है, जो mail.i2p SMTP और POP3 servers से अलग हैं — outproxies और inproxies दोनों I2P के माध्यम से mail.i2p SMTP और POP3 servers के साथ communicate करते हैं, इसलिए उन non-anonymous locations से समझौता करना user के mail accounts या activity patterns तक पहुंच नहीं देता।