नामकरण चर्चा

नोट: निम्नलिखित I2P नामकरण प्रणाली के पीछे के कारणों, सामान्य तर्कों और संभावित विकल्पों की चर्चा है। वर्तमान दस्तावेज़ीकरण के लिए नामकरण पृष्ठ देखें।

खारिज किए गए विकल्प

I2P के भीतर नामकरण शुरुआत से ही एक अक्सर बहस का विषय रहा है जिसमें संभावनाओं के पूरे स्पेक्ट्रम में समर्थक हैं। हालांकि, सुरक्षित संचार और विकेंद्रीकृत संचालन की I2P की अंतर्निहित मांग को देखते हुए, पारंपरिक DNS-शैली की नामकरण प्रणाली स्पष्ट रूप से बाहर है, जैसा कि “बहुमत का नियम” मतदान प्रणालियों के साथ है।

I2P DNS-जैसी सेवाओं के उपयोग को बढ़ावा नहीं देता, क्योंकि किसी साइट को hijack करने से हुआ नुकसान बहुत बड़ा हो सकता है - और असुरक्षित 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 mount करने की अनुमति देते हैं। responses को authenticate करने के लिए एक certificate जोड़ना, जो किसी centralized certificate authority द्वारा signed हो, कई hostile nameserver issues को संबोधित करेगा लेकिन replay attacks के साथ-साथ hostile certificate authority attacks के लिए भी रास्ता खुला रखेगा।

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

हालांकि इंटरनेट की तरह, I2P naming system के डिज़ाइन और संचालन को (IP-जैसी) communication layer से अलग रख रहा है। बंडल की गई naming library में एक सरल service provider interface शामिल है जिसमें वैकल्पिक naming systems plug in कर सकते हैं, जो अंतिम उपयोगकर्ताओं को यह तय करने की सुविधा देता है कि वे किस प्रकार के naming tradeoffs पसंद करते हैं।

चर्चा

यह भी देखें Names: Decentralized, Secure, Human-Meaningful: Choose Two ।

jrandom की टिप्पणियाँ

(पुराने Syndie में एक पोस्ट से अनुकूलित, 26 नवंबर, 2005)

प्रश्न: यदि कुछ hosts एक पते पर सहमत नहीं हैं और यदि कुछ पते काम कर रहे हैं, अन्य नहीं कर रहे हैं तो क्या करें? किसी नाम का सही स्रोत कौन है?

A: आप नहीं कर सकते। यह वास्तव में I2P पर नामों और DNS के काम करने के तरीके के बीच एक महत्वपूर्ण अंतर है - I2P में नाम मानव द्वारा पढ़े जा सकने वाले, सुरक्षित हैं, लेकिन विश्वव्यापी रूप से अद्वितीय नहीं हैं। यह जानबूझकर डिज़ाइन किया गया है, और हमारी सुरक्षा की आवश्यकता का एक अंतर्निहित हिस्सा है।

यदि मैं किसी तरह आपको किसी नाम से जुड़े destination को बदलने के लिए राजी कर सकूं, तो मैं सफलतापूर्वक उस साइट को “हाइजैक” कर लूंगा, और किसी भी परिस्थिति में यह स्वीकार्य नहीं है। इसके बजाय, हम नामों को स्थानीय रूप से अद्वितीय बनाते हैं: ये वह हैं जो आप किसी साइट को कहने के लिए उपयोग करते हैं, ठीक वैसे ही जैसे आप अपने ब्राउज़र के bookmarks में या अपने IM client की buddy list में चीजों को जो चाहें कह सकते हैं। जिसे आप “Boss” कहते हैं वह वही हो सकता है जिसे कोई और “Sally” कहता हो।

नाम कभी भी, सुरक्षित रूप से मानव-पठनीय और विश्वव्यापी रूप से अद्वितीय नहीं होंगे।

zzz की टिप्पणियां

निम्नलिखित zzz की ओर से I2P की naming system के बारे में कई सामान्य शिकायतों की समीक्षा है।

• अक्षमता: पूरी hosts.txt डाउनलोड की जाती है (यदि यह बदली गई है, क्योंकि eepget etag और last-modified headers का उपयोग करता है)। अभी लगभग 800 hosts के लिए यह करीब 400K है।

सच है, लेकिन I2P के संदर्भ में यह बहुत अधिक ट्रैफिक नहीं है, जो कि खुद ही बेहद अकुशल है (floodfill databases, विशाल encryption ओवरहेड और padding, garlic routing, आदि)। यदि आप हर 12 घंटे में किसी से hosts.txt फाइल डाउनलोड करते हैं तो यह औसतन लगभग 10 bytes/sec निकलता है।

जैसा कि I2P में आमतौर पर होता है, यहां गुमनामी और दक्षता के बीच एक मौलिक समझौता है। कुछ लोग कहेंगे कि etag और last-modified headers का उपयोग करना खतरनाक है क्योंकि यह यह उजागर करता है कि आपने डेटा के लिए अंतिम बार कब अनुरोध किया था। दूसरों ने केवल विशिष्ट keys के लिए पूछने का सुझाव दिया है (jump services जो करती हैं उसके समान, लेकिन अधिक स्वचालित तरीके से), संभावित रूप से गुमनामी में और भी अधिक लागत पर।

संभावित सुधार address book का प्रतिस्थापन या पूरक हो सकता है (देखें i2host.i2p), या कुछ सरल जैसे http://example.i 2p/hosts.txt के बजाय http://example.i 2p/cgi-bin/recenthosts.cgi को subscribe करना। यदि एक काल्पनिक recenthosts.cgi पिछले 24 घंटों के सभी hosts को वितरित करे, उदाहरण के लिए, तो यह last-modified और etag के साथ वर्तमान hosts.txt से अधिक कुशल और अधिक गुमनाम दोनों हो सकता है।

एक नमूना कार्यान्वयन stats.i2p पर http://stats.i 2p/cgi-bin/newhosts.txt पर उपलब्ध है। यह स्क्रिप्ट timestamp के साथ एक Etag वापस करती है। जब If-None-Match etag के साथ कोई अनुरोध आता है, तो स्क्रिप्ट केवल उस timestamp के बाद के नए hosts वापस करती है, या यदि कोई नहीं है तो 304 Not Modified। इस तरह से, स्क्रिप्ट कुशलतापूर्वक केवल उन hosts को वापस करती है जिनके बारे में subscriber को पता नहीं है, address book-compatible तरीके से।

इसलिए अक्षमता कोई बड़ी समस्या नहीं है और मौलिक बदलाव के बिना चीजों को सुधारने के कई तरीके हैं।

• स्केलेबल नहीं: 400K hosts.txt (लिनियर सर्च के साथ) इस समय उतना बड़ा नहीं है और हम शायद 10x या 100x तक बढ़ सकते हैं इससे पहले कि यह समस्या बने।

जहाँ तक नेटवर्क ट्रैफिक की बात है, ऊपर देखें। लेकिन जब तक आप किसी key के लिए नेटवर्क पर धीमी real-time query करने का इरादा नहीं रखते, आपको keys का पूरा सेट स्थानीय रूप से संग्रहीत करना होगा, जिसकी लागत प्रति key लगभग 500 bytes है।

• कॉन्फ़िगरेशन और “ट्रस्ट” की आवश्यकता: Out-of-the-box address book केवल http://www.i2p2.i 2p/hosts.txt को subscribe करती है, जो शायद ही कभी अपडेट होती है, जिससे नए उपयोगकर्ताओं का अनुभव खराब होता है।

यह बिल्कुल जानबूझकर किया गया है। jrandom चाहता है कि उपयोगकर्ता किसी hosts.txt प्रदाता पर “भरोसा” करे, और जैसा कि वह कहना पसंद करता है, “भरोसा कोई boolean नहीं है”। कॉन्फ़िगरेशन चरण उपयोगकर्ताओं को एक गुमनाम नेटवर्क में भरोसे के मुद्दों के बारे में सोचने पर मजबूर करने का प्रयास करता है।

एक और उदाहरण के रूप में, HTTP Proxy में “I2P Site Unknown” त्रुटि पृष्ठ कुछ jump सेवाओं की सूची देता है, लेकिन किसी विशेष सेवा की “सिफारिश” नहीं करता, और यह उपयोगकर्ता पर निर्भर करता है कि वे किसी को चुनें (या न चुनें)। jrandom कहेंगे कि हम सूचीबद्ध प्रदाताओं पर उन्हें सूचीबद्ध करने के लिए पर्याप्त भरोसा करते हैं लेकिन उनसे स्वचालित रूप से key प्राप्त करने के लिए पर्याप्त भरोसा नहीं करते।

यह कितना सफल है, मुझे यकीन नहीं है। लेकिन नेमिंग सिस्टम के लिए किसी न किसी प्रकार की विश्वसनीयता की पदानुक्रम होनी चाहिए। सभी के साथ समान व्यवहार करना हाईजैकिंग के जोखिम को बढ़ा सकता है।

• यह DNS नहीं है

दुर्भाग्य से I2P पर real-time lookups वेब ब्राउज़िंग को काफी धीमा कर देगा।

इसके अलावा, DNS सीमित caching और time-to-live के साथ lookups पर आधारित है, जबकि I2P keys स्थायी होती हैं।

हां, हम इसे काम करा सकते हैं, लेकिन क्यों? यह एक खराब फिट है।

• विश्वसनीय नहीं: यह address book subscriptions के लिए विशिष्ट servers पर निर्भर करता है।

हाँ यह कुछ servers पर निर्भर करता है जिन्हें आपने कॉन्फ़िगर किया है। I2P के भीतर, servers और services आते-जाते रहते हैं। किसी भी अन्य केंद्रीकृत सिस्टम (उदाहरण के लिए DNS root servers) में भी यही समस्या होगी। एक पूर्णतः विकेंद्रीकृत सिस्टम (हर कोई authoritative है) संभव है “हर कोई एक root DNS server है” समाधान को लागू करके, या कुछ और भी सरल तरीके से, जैसे कि एक script जो आपके hosts.txt में सभी को आपकी address book में जोड़ देती है।

हालांकि, सभी-प्राधिकरणिक समाधानों की वकालत करने वाले लोगों ने आमतौर पर संघर्षों और हाईजैकिंग के मुद्दों पर गहराई से विचार नहीं किया है।

• अजीब, वास्तविक समय नहीं: यह hosts.txt प्रदाताओं, key-add वेब फॉर्म प्रदाताओं, jump service प्रदाताओं, I2P Site स्थिति रिपोर्टरों का एक पैचवर्क है। Jump servers और subscriptions एक परेशानी हैं, इसे DNS की तरह काम करना चाहिए।

विश्वसनीयता और विश्वास अनुभाग देखें।

तो, संक्षेप में, वर्तमान सिस्टम भयानक रूप से टूटा हुआ, अकुशल, या गैर-स्केलेबल नहीं है, और “बस DNS का उपयोग करें” के प्रस्ताव अच्छी तरह से सोचे-समझे नहीं हैं।

विकल्प

I2P source में कई pluggable naming systems हैं और naming systems के साथ प्रयोग करने के लिए configuration options का समर्थन करता है।

• Meta - दो या अधिक अन्य naming systems को क्रम में कॉल करता है। डिफ़ॉल्ट रूप से, पहले PetName फिर HostsTxt को कॉल करता है।
• PetName - petnames.txt फ़ाइल में lookup करता है। इस फ़ाइल का format hosts.txt के समान नहीं है।
• HostsTxt - निम्नलिखित फ़ाइलों में क्रम से lookup करता है:
  1. privatehosts.txt
  2. userhosts.txt
  3. hosts.txt
• AddressDB - प्रत्येक host को addressDb/ directory में एक अलग फ़ाइल में listed किया गया है।
• Eepget - बाहरी server से HTTP lookup request करता है - यह Meta के साथ HostsTxt lookup के बाद stacked होना चाहिए। यह jump system को बढ़ा या replace कर सकता है। इसमें in-memory caching शामिल है।
• Exec - lookup के लिए बाहरी program को कॉल करता है, java से स्वतंत्र रूप से lookup schemes में अतिरिक्त experimentation की अनुमति देता है। HostsTxt के बाद या sole naming system के रूप में उपयोग किया जा सकता है। इसमें in-memory caching शामिल है।
• Dummy - Base64 names के लिए fallback के रूप में उपयोग किया जाता है, अन्यथा fail हो जाता है।

वर्तमान naming system को advanced config विकल्प i2p.naming.impl के साथ बदला जा सकता है (restart आवश्यक)। विवरण के लिए core/java/src/net/i2p/client/naming देखें।

किसी भी नए सिस्टम को HostsTxt के साथ स्टैक किया जाना चाहिए, या स्थानीय स्टोरेज और/या address book सब्सक्रिप्शन फ़ंक्शन को implement करना चाहिए, क्योंकि address book केवल hosts.txt फाइलों और फॉर्मेट के बारे में जानता है।

प्रमाणपत्र

I2P destinations में एक certificate होता है, हालांकि इस समय वह certificate हमेशा null होता है। null certificate के साथ, base64 destinations हमेशा 516 bytes के होते हैं जो “AAAA” पर समाप्त होते हैं, और यह address book merge mechanism में जांचा जाता है, और संभवतः अन्य स्थानों पर भी। साथ ही, certificate generate करने या इसे destination में जोड़ने के लिए कोई method उपलब्ध नहीं है। इसलिए certificates को implement करने के लिए इन्हें अपडेट करना होगा।

प्रमाणपत्रों का एक संभावित उपयोग proof of work के लिए है।

दूसरा “subdomains” के लिए है (उद्धरण चिह्नों में क्योंकि वास्तव में ऐसी कोई चीज नहीं है, I2P एक flat naming system का उपयोग करता है) जो 2nd level domain की keys द्वारा sign किए जाते हैं।

किसी भी certificate implementation के साथ certificates को verify करने की method भी आनी चाहिए। संभावना यह है कि यह address book merge code में होगा। क्या multiple types के certificates के लिए, या multiple certificates के लिए कोई method है?

प्रतिक्रियाओं को किसी केंद्रीकृत certificate authority द्वारा हस्ताक्षरित के रूप में प्रमाणित करने वाला certificate जोड़ना कई शत्रुतापूर्ण nameserver समस्याओं को हल कर देगा लेकिन replay attacks के साथ-साथ शत्रुतापूर्ण certificate authority attacks को खुला छोड़ देगा।