अवलोकन
यह प्रस्ताव एक प्रोटोकॉल के डिज़ाइन को रेखांकित करता है जो एक I2P क्लाइंट, सेवा या बाहरी बैलेंसर प्रक्रिया को एकल Destination की मेजबानी पारदर्शी रूप से कई राउटर्स के माध्यम से प्रबंधित करने में सक्षम बनाता है।
यह प्रस्ताव वर्तमान में कोई विशिष्ट कार्यान्वयन निर्दिष्ट नहीं करता है। इसे I2CP के एक एक्सटेंशन के रूप में या एक नए प्रोटोकॉल के रूप में लागू किया जा सकता है।
प्रेरणा
मल्टीहोमिंग वह स्थिति है जहाँ एक ही Destination की मेजबानी करने के लिए कई राउटर्स का उपयोग किया जाता है। I2P के साथ मल्टीहोम करने का वर्तमान तरीका यह है कि प्रत्येक राउटर पर स्वतंत्र रूप से उसी Destination को चलाया जाए; किसी विशेष समय में क्लाइंट द्वारा उपयोग किया जाने वाला राउटर वह होता है जिसने अंतिम LeaseSet प्रकाशित किया हो।
यह एक हैक है और बड़े पैमाने पर बड़ी वेबसाइटों के लिए काम नहीं करेगा। मान लीजिए हमारे पास 100 मल्टीहोमिंग राउटर्स हैं, जिनमें से प्रत्येक के पास 16 टनल हैं। इसका अर्थ है हर 10 मिनट में 1600 LeaseSet प्रकाशित हो रहे हैं, या लगभग प्रति सेकंड 3। फ्लडफिल्स अतिभारित हो जाएंगे और थ्रॉटल्स सक्रिय हो जाएंगे। और यह तब है जब हमने अभी तक लुकअप ट्रैफ़िक का उल्लेख भी नहीं किया है।
प्रस्ताव 123 एक मेटा-LeaseSet के साथ इस समस्या का समाधान करता है, जो 100 वास्तविक LeaseSet हैश को सूचीबद्ध करता है। एक लुकअप दो-चरणीय प्रक्रिया बन जाती है: पहले मेटा-LeaseSet की खोज करना, और फिर नामित LeaseSet में से एक की। यह लुकअप ट्रैफ़िक समस्या के लिए एक अच्छा समाधान है, लेकिन अकेले यह एक महत्वपूर्ण गोपनीयता लीक पैदा करता है: यह निर्धारित करना संभव है कि कौन से मल्टीहोमिंग राउटर्स ऑनलाइन हैं, यदि प्रकाशित मेटा-LeaseSet की निगरानी की जाए, क्योंकि प्रत्येक वास्तविक LeaseSet का संबंध एकल राउटर से होता है।
हमें I2P क्लाइंट या सेवा के लिए एक ऐसा तरीका चाहिए जो एकल Destination को कई राउटर्स पर इस तरह फैलाए कि LeaseSet के दृष्टिकोण से एकल राउटर के उपयोग के समान ही लगे।
डिज़ाइन
परिभाषाएँ
User
वह व्यक्ति या संगठन जो अपने Destination(s) को मल्टीहोम करना चाहता है। यहाँ सामान्यीकृत रूप से (WLOG) एकल Destination पर विचार किया गया है।
Client
Destination के पीछे चलने वाला अनुप्रयोग या सेवा। यह क्लाइंट-साइड, सर्वर-साइड या पीयर-टू-पीयर अनुप्रयोग हो सकता है; हम इसे क्लाइंट के रूप में संदर्भित करते हैं क्योंकि यह I2P राउटर्स से जुड़ता है।
क्लाइंट तीन भागों से मिलकर बना होता है, जो सभी एक ही प्रक्रिया में हो सकते हैं या प्रक्रियाओं या मशीनों में विभाजित हो सकते हैं (मल्टी-क्लाइंट सेटअप में):
Balancer
क्लाइंट का वह भाग जो पीयर चयन और टनल निर्माण का प्रबंधन करता है। किसी एक समय में एकल बैलेंसर होता है, और यह सभी I2P राउटर्स के साथ संचार करता है। फेलओवर बैलेंसर्स भी हो सकते हैं।
Frontend
क्लाइंट का वह भाग जिसे समानांतर में संचालित किया जा सकता है। प्रत्येक फ्रंटएंड एकल I2P राउटर के साथ संचार करता है।
Backend
क्लाइंट का वह भाग जो सभी फ्रंटएंड्स के बीच साझा किया जाता है। इसका किसी भी I2P राउटर के साथ कोई सीधा संचार नहीं होता।
Router
उपयोगकर्ता द्वारा चलाया जाने वाला एक I2P राउटर जो I2P नेटवर्क और उपयोगकर्ता के नेटवर्क के बीच सीमा पर स्थित होता है (कॉर्पोरेट नेटवर्क में एज डिवाइस के समान)। यह बैलेंसर के निर्देश पर टनल बनाता है, और क्लाइंट या फ्रंटएंड के लिए पैकेट रूट करता है।
उच्च-स्तरीय अवलोकन
निम्नलिखित वांछित विन्यास की कल्पना करें:
- एक Destination के साथ एक क्लाइंट अनुप्रयोग।
- चार राउटर्स, जिनमें से प्रत्येक तीन आगमन टनल का प्रबंधन करता है।
- सभी बारह टनल एकल LeaseSet में प्रकाशित होने चाहिए।
सिंगल-क्लाइंट
-{ [Tunnel 1]===\
|-{ [Tunnel 2]====[Router 1]-----
|-{ [Tunnel 3]===/ \
| \
|-{ [Tunnel 4]===\ \
[Destination] |-{ [Tunnel 5]====[Router 2]----- \
\ |-{ [Tunnel 6]===/ \ \
[LeaseSet]--| [Client]
|-{ [Tunnel 7]===\ / /
|-{ [Tunnel 8]====[Router 3]----- /
|-{ [Tunnel 9]===/ /
| /
|-{ [Tunnel 10]==\ /
|-{ [Tunnel 11]===[Router 4]-----
-{ [Tunnel 12]==/
मल्टी-क्लाइंट
-{ [Tunnel 1]===\
|-{ [Tunnel 2]====[Router 1]---------[Frontend 1]
|-{ [Tunnel 3]===/ \ \
| \ \
|-{ [Tunnel 4]===\ \ \
[Destination] |-{ [Tunnel 5]====[Router 2]---\-----[Frontend 2] \
\ |-{ [Tunnel 6]===/ \ \ \ \
[LeaseSet]--| [Balancer] [Backend]
|-{ [Tunnel 7]===\ / / / /
|-{ [Tunnel 8]====[Router 3]---/-----[Frontend 3] /
|-{ [Tunnel 9]===/ / /
| / /
|-{ [Tunnel 10]==\ / /
|-{ [Tunnel 11]===[Router 4]---------[Frontend 4]
-{ [Tunnel 12]==/
सामान्य क्लाइंट प्रक्रिया
एक Destination लोड या उत्पन्न करें।
प्रत्येक राउटर के साथ एक सत्र खोलें, जो Destination से जुड़ा हो।
आवधिक रूप से (लगभग हर दस मिनट में, लेकिन टनल की जीवंतता के आधार पर अधिक या कम):
प्रत्येक राउटर से त्वरित टियर प्राप्त करें।
पीयर्स के सुपरसेट का उपयोग करके प्रत्येक राउटर के लिए टनल बनाएं।
- डिफ़ॉल्ट रूप से, किसी विशेष राउटर के लिए टनल उस राउटर के त्वरित टियर से पीयर्स का उपयोग करेंगे, लेकिन यह प्रोटोकॉल द्वारा लागू नहीं किया जाता है।
सभी सक्रिय राउटर्स से सक्रिय आगमन टनल का संग्रह करें, और एक LeaseSet बनाएं।
एक या अधिक राउटर्स के माध्यम से LeaseSet प्रकाशित करें।
I2CP से अंतर
इस विन्यास को बनाने और प्रबंधित करने के लिए, क्लाइंट को वर्तमान में I2CP द्वारा प्रदान किए जा रहे कार्यक्षमता से अधिक निम्नलिखित नई कार्यक्षमता की आवश्यकता होती है:
- उनके लिए एक LeaseSet बनाए बिना, एक राउटर को टनल बनाने के लिए कहें।
- आगमन पूल में वर्तमान टनल की सूची प्राप्त करें।
इसके अतिरिक्त, निम्नलिखित कार्यक्षमता क्लाइंट को अपने टनल के प्रबंधन में महत्वपूर्ण लचीलापन प्रदान करेगी:
- राउटर के त्वरित टियर की सामग्री प्राप्त करें।
- दिए गए पीयर्स की सूची का उपयोग करके एक आगमन या आउटगोइंग टनल बनाने के लिए राउटर को निर्देश दें।
प्रोटोकॉल रूपरेखा
Client Router
---------------------> Create Session
Session Status <---------------------
---------------------> Get Fast Tier
Peer List <---------------------
---------------------> Create Tunnel
Tunnel Status <---------------------
---------------------> Get Tunnel Pool
Tunnel List <---------------------
---------------------> Publish LeaseSet
---------------------> Send Packet
Send Status <---------------------
Packet Received <---------------------
संदेश
Create Session
- दिए गए Destination के लिए एक सत्र बनाएं।
Session Status
- पुष्टि कि सत्र स्थापित कर दिया गया है, और क्लाइंट अब टनल बनाना शुरू कर सकता है।
Get Fast Tier
- उन पीयर्स की सूची के लिए अनुरोध करें जिनके माध्यम से राउटर वर्तमान में टनल बनाने पर विचार करेगा।
Peer List
- राउटर को ज्ञात पीयर्स की सूची।
Create Tunnel
- राउटर से निर्दिष्ट पीयर्स के माध्यम से एक नया टनल बनाने का अनुरोध करें।
Tunnel Status
- एक विशेष टनल निर्माण का परिणाम, एक बार उपलब्ध होने पर।
Get Tunnel Pool
- Destination के लिए आगमन या आउटगोइंग पूल में वर्तमान टनल की सूची के लिए अनुरोध करें।
Tunnel List
- अनुरोधित पूल के लिए टनल की सूची।
Publish LeaseSet
- राउटर से Destination के लिए आउटगोइंग टनल में से एक के माध्यम से प्रदान किए गए LeaseSet को प्रकाशित करने का अनुरोध करें। कोई प्रतिक्रिया स्थिति की आवश्यकता नहीं है; राउटर को तब तक पुनः प्रयास करते रहना चाहिए जब तक कि यह संतुष्ट न हो जाए कि LeaseSet प्रकाशित हो चुका है।
Send Packet
- क्लाइंट से एक आउटगोइंग पैकेट। वैकल्पिक रूप से एक आउटगोइंग टनल को निर्दिष्ट करता है जिसके माध्यम से पैकेट भेजा जाना चाहिए (चाहिए?)।
Send Status
- क्लाइंट को पैकेट भेजने में सफलता या विफलता के बारे में सूचित करता है।
Packet Received
- क्लाइंट के लिए एक आगमन पैकेट। वैकल्पिक रूप से आगमन टनल को निर्दिष्ट करता है जिसके माध्यम से पैकेट प्राप्त हुआ था(?)
सुरक्षा प्रभाव
राउटर्स के दृष्टिकोण से, यह डिज़ाइन वर्तमान स्थिति के समार्थ है। राउटर अभी भी सभी टनल बनाता है, अपने स्वयं के पीयर प्रोफाइल बनाए रखता है, और राउटर और क्लाइंट संचालन के बीच अलगाव लागू करता है। डिफ़ॉल्ट विन्यास में यह पूरी तरह से समान है, क्योंकि उस राउटर के लिए टनल उसके स्वयं के त्वरित टियर से बनाए जाते हैं।
netDB के दृष्टिकोण से, इस प्रोटोकॉल के माध्यम से बनाया गया एकल LeaseSet वर्तमान स्थिति के समान है, क्योंकि यह पूर्व-मौजूद कार्यक्षमता का उपयोग करता है। हालाँकि, 16 लीज़ तक पहुँचने वाले बड़े LeaseSet के लिए, यह संभव हो सकता है कि एक पर्यवेक्षक निर्धारित कर सके कि LeaseSet मल्टीहोम्ड है:
त्वरित टियर का वर्तमान अधिकतम आकार 75 पीयर्स है। आगमन गेटवे (IBGW, वह नोड जो लीज़ में प्रकाशित होता है) टियर के एक अंश से चुना जाता है (हैश द्वारा प्रति-टनल पूल यादृच्छिक रूप से विभाजित, गिनती नहीं):
1 हॉप पूरा त्वरित टियर 2 हॉप्स त्वरित टियर का आधा भाग (मध्य-2014 तक डिफ़ॉल्ट) 3+ हॉप्स त्वरित टियर का एक चौथाई भाग (3 वर्तमान डिफ़ॉल्ट है)इसका अर्थ है कि औसतन IBGWs 20-30 पीयर्स के सेट से होंगे।
एकल-होम्ड सेटअप में, पूर्ण 16-टनल LeaseSet में 16 IBGWs होंगे जो अधिकतम (मान लीजिए) 20 पीयर्स के सेट से यादृच्छिक रूप से चुने गए होंगे।
4-राउटर मल्टीहोम्ड सेटअप में डिफ़ॉल्ट विन्यास का उपयोग करके, पूर्ण 16-टनल LeaseSet में 16 IBGWs होंगे जो अधिकतम 80 पीयर्स के सेट से यादृच्छिक रूप से चुने गए होंगे, हालाँकि राउटर्स के बीच सामान्य पीयर्स का एक अंश होने की संभावना है।
इस प्रकार डिफ़ॉल्ट विन्यास के साथ, यह संभव हो सकता है कि सांख्यिकीय विश्लेषण के माध्यम से यह पता लगाया जा सके कि LeaseSet इस प्रोटोकॉल द्वारा उत्पन्न किया जा रहा है। यह भी संभव हो सकता है कि यह पता लगाया जा सके कि कितने राउटर्स हैं, हालाँकि त्वरित टियर्स पर चरमराहट का प्रभाव इस विश्लेषण की प्रभावशीलता को कम कर देगा।
चूँकि क्लाइंट के पास वह पीयर्स चुनने पर पूर्ण नियंत्रण है जिन्हें यह चुनता है, इस सूचना लीक को कम या समाप्त किया जा सकता है यदि IBGWs को पीयर्स के कम किए गए सेट से चुना जाए।
संगतता
यह डिज़ाइन नेटवर्क के साथ पूरी तरह से पिछड़ा-संगत है, क्योंकि LeaseSet प्रारूप में कोई परिवर्तन नहीं है। सभी राउटर्स को नए प्रोटोकॉल के बारे में जागरूक होने की आवश्यकता होगी, लेकिन यह चिंता का विषय नहीं है क्योंकि वे सभी एक ही संस्था द्वारा नियंत्रित किए जाएंगे।
प्रदर्शन और स्केलेबिलिटी टिप्पणियाँ
LeaseSet प्रति 16 लीज़ की ऊपरी सीमा इस प्रस्ताव द्वारा अपरिवर्तित रहती है। उन Destination के लिए जिन्हें इससे अधिक टनल की आवश्यकता होती है, दो संभावित नेटवर्क संशोधन हैं:
LeaseSet के आकार पर ऊपरी सीमा बढ़ाएँ। इसे लागू करना सबसे सरल होगा (हालाँकि इसके व्यापक उपयोग से पहले यह अभी भी व्यापक नेटवर्क समर्थन की आवश्यकता होगी), लेकिन बड़े पैकेट आकार के कारण धीमे लुकअप का परिणाम हो सकता है। अधिकतम व्यवहार्य LeaseSet आकार अंतर्निहित ट्रांसपोर्ट्स के MTU द्वारा परिभाषित किया जाता है, और इसलिए लगभग 16kB है।
पदानुक्रमित LeaseSet के लिए प्रस्ताव 123 लागू करें। इस प्रस्ताव के संयोजन में, सब-LeaseSet के लिए Destination को कई राउटर्स पर फैलाया जा सकता है, प्रभावी रूप से क्लियरनेट सेवा के लिए कई IP पतों की तरह कार्य करते हुए।
स्वीकृति
इस प्रस्ताव के लिए चर्चा के लिए psi के प्रति धन्यवाद।