ملاحظة: ما يلي هو مناقشة للأسباب وراء نظام التسمية في I2P، والحجج الشائعة والبدائل المحتملة. راجع صفحة التسمية للحصول على الوثائق الحالية.
البدائل المُستبعدة
كان التسمية داخل I2P موضوعاً كثير الجدل منذ البداية مع وجود مؤيدين عبر طيف الاحتماليات. ومع ذلك، نظراً لمتطلبات I2P الأساسية للتواصل الآمن والعمليات اللامركزية، فإن نظام التسمية التقليدي على غرار DNS مستبعد بوضوح، وكذلك أنظمة التصويت القائمة على “حكم الأغلبية”.
لا يشجع I2P على استخدام خدمات شبيهة بـ DNS رغم ذلك، حيث أن الضرر الناجم عن اختطاف موقع يمكن أن يكون هائلاً - والوجهات غير الآمنة لا قيمة لها. DNSsec نفسه لا يزال يعتمد على المسجلين وسلطات الشهادات، بينما مع I2P، الطلبات المرسلة إلى وجهة لا يمكن اعتراضها أو انتحال الرد، حيث يتم تشفيرها بالمفاتيح العامة للوجهة، والوجهة نفسها هي مجرد زوج من المفاتيح العامة وشهادة. الأنظمة من نمط DNS من ناحية أخرى تسمح لأي من خوادم الأسماء في مسار البحث بشن هجمات بسيطة لحرمان الخدمة والانتحال. إضافة شهادة تصادق على الردود كموقعة من قبل سلطة شهادات مركزية من شأنه أن يعالج العديد من مشاكل خوادم الأسماء العدائية ولكن سيترك مفتوحاً هجمات الإعادة بالإضافة إلى هجمات سلطات الشهادات العدائية.
نمط التسمية بالتصويت خطير أيضاً، خاصة بالنظر إلى فعالية هجمات Sybil في الأنظمة المجهولة - يمكن للمهاجم ببساطة إنشاء عدد عالٍ تعسفياً من النظراء و"التصويت" بكل منهم للسيطرة على اسم معين. يمكن استخدام طرق proof-of-work لجعل الهوية غير مجانية، ولكن مع نمو الشبكة فإن الحمولة المطلوبة للاتصال بالجميع لإجراء تصويت عبر الإنترنت غير قابلة للتطبيق، أو إذا لم يتم استعلام الشبكة الكاملة، فقد تكون مجموعات مختلفة من الإجابات قابلة للوصول.
مثل الإنترنت، يحافظ I2P على تصميم وتشغيل نظام الأسماء خارج طبقة الاتصال (الشبيهة بـ IP). تتضمن مكتبة الأسماء المرفقة واجهة موفر خدمة بسيطة يمكن لـ أنظمة الأسماء البديلة الاتصال بها، مما يسمح للمستخدمين النهائيين بتحديد نوع المقايضات في الأسماء التي يفضلونها.
المناقشة
انظر أيضاً الأسماء: لامركزية، آمنة، ذات معنى بشري: اختر اثنين .
تعليقات بواسطة jrandom
(مقتبس من منشور في Syndie القديم، 26 نوفمبر 2005)
س: ماذا نفعل إذا كانت بعض المضيفات لا تتفق على عنوان واحد وإذا كانت بعض العناوين تعمل والأخرى لا تعمل؟ من هو المصدر الصحيح للاسم؟
ج: لا يمكنك ذلك. هذا في الواقع اختلاف جوهري بين الأسماء على I2P وطريقة عمل DNS - الأسماء في I2P قابلة للقراءة البشرية وآمنة، ولكنها ليست فريدة عالمياً. هذا بالتصميم، وجزء جوهري من حاجتنا للأمان.
إذا تمكنت بطريقة ما من إقناعك بتغيير الوجهة المرتبطة ببعض الأسماء، فسأنجح في “الاستيلاء” على الموقع، وهذا غير مقبول تحت أي ظرف من الظروف. بدلاً من ذلك، ما نفعله هو جعل الأسماء فريدة محلياً: إنها ما تستخدمه أنت لاستدعاء موقع ما، تماماً كما يمكنك تسمية الأشياء بما تشاء عندما تضيفها إلى إشارات متصفحك المرجعية، أو قائمة الأصدقاء في عميل المراسلة الفورية الخاص بك. من تسميه “الرئيس” قد يكون هو من يسميه شخص آخر “سالي”.
الأسماء لن تكون أبداً قابلة للقراءة بشكل آمن من قبل البشر وفريدة عالمياً في نفس الوقت.
تعليقات من zzz
التالي من zzz هو مراجعة لعدة شكاوى شائعة حول نظام التسمية في I2P.
- عدم الكفاءة: يتم تنزيل ملف hosts.txt بالكامل (إذا تم تغييره، حيث أن eepget يستخدم رؤوس etag و last-modified). حجمه حوالي 400K حالياً لما يقارب 800 مضيف.
صحيح، لكن هذا ليس حجم كبير من البيانات في سياق I2P، والذي هو بحد ذاته غير فعال بشكل كبير (قواعد بيانات floodfill، حمولة تشفير ضخمة وحشو، garlic routing، إلخ). إذا قمت بتحميل ملف hosts.txt من شخص ما كل 12 ساعة، فإن المتوسط يصل إلى حوالي 10 بايت/ثانية.
كما هو الحال عادة في I2P، هناك مقايضة أساسية هنا بين إخفاء الهوية والكفاءة. يقول البعض أن استخدام رؤوس etag و last-modified أمر خطير لأنه يكشف متى طلبت البيانات آخر مرة. اقترح آخرون طلب مفاتيح محددة فقط (مشابه لما تفعله خدمات القفز، ولكن بطريقة أكثر أتمتة)، ربما على حساب إضافي في إخفاء الهوية.
التحسينات المحتملة ستكون استبدال أو إضافة مكملة لدفتر العناوين (راجع i2host.i2p)، أو شيء بسيط مثل الاشتراك في http://example.i 2p/cgi-bin/recenthosts.cgi بدلاً من http://example.i 2p/hosts.txt. إذا كان recenthosts.cgi الافتراضي يوزع جميع المضيفين من آخر 24 ساعة، على سبيل المثال، فقد يكون ذلك أكثر كفاءة وأكثر إخفاءً للهوية من hosts.txt الحالي مع last-modified و etag.
يتوفر مثال تطبيقي على stats.i2p في http://stats.i 2p/cgi-bin/newhosts.txt. يقوم هذا السكريبت بإرجاع Etag مع طابع زمني. عندما يأتي طلب مع etag If-None-Match، يقوم السكريبت بإرجاع المضيفين الجدد فقط منذ ذلك الطابع الزمني، أو 304 Not Modified إذا لم يكن هناك أي مضيفين جدد. بهذه الطريقة، يقوم السكريبت بكفاءة بإرجاع المضيفين الذين لا يعرفهم المشترك فقط، بطريقة متوافقة مع دفتر العناوين.
لذا فإن عدم الكفاءة ليس مشكلة كبيرة وهناك عدة طرق لتحسين الأمور دون تغيير جذري.
- غير قابل للتوسيع: ملف hosts.txt بحجم 400 ألف (مع البحث الخطي) ليس كبيراً جداً في الوقت الحالي ويمكننا على الأرجح النمو بمقدار 10 أضعاف أو 100 ضعف قبل أن يصبح مشكلة.
بالنسبة لحركة مرور الشبكة، انظر أعلاه. ولكن ما لم تكن ستقوم بعمل استعلام بطيء في الوقت الفعلي عبر الشبكة للحصول على مفتاح، فأنت بحاجة إلى تخزين مجموعة المفاتيح كاملة محلياً، بتكلفة حوالي 500 بايت لكل مفتاح.
- يتطلب تكوين و"ثقة": دفتر العناوين الافتراضي مشترك فقط في http://www.i2p2.i 2p/hosts.txt، والذي نادراً ما يتم تحديثه، مما يؤدي إلى تجربة سيئة للمستخدمين الجدد.
هذا مقصود جداً. يريد jrandom من المستخدم أن “يثق” بمزود hosts.txt، وكما يحب أن يقول، “الثقة ليست قيمة منطقية”. تهدف خطوة التكوين إلى إجبار المستخدمين على التفكير في قضايا الثقة في شبكة مجهولة الهوية.
كمثال آخر، صفحة خطأ “I2P Site Unknown” في HTTP Proxy تعرض قائمة ببعض خدمات القفز، لكنها لا “توصي” بأي واحدة منها على وجه التحديد، والأمر متروك للمستخدم لاختيار واحدة (أو عدم الاختيار). jrandom سيقول أننا نثق في مقدمي الخدمات المدرجين بما يكفي لإدراجهم في القائمة ولكن ليس بما يكفي لجلب المفتاح منهم تلقائياً.
لست متأكداً من مدى نجاح هذا الأمر. لكن يجب أن يكون هناك نوع من التسلسل الهرمي للثقة في نظام الأسماء. معاملة الجميع بالتساوي قد يزيد من خطر الاختطاف.
- ليس DNS
لسوء الحظ، فإن عمليات البحث في الوقت الفعلي عبر I2P ستؤدي إلى إبطاء تصفح الويب بشكل كبير.
أيضاً، يعتمد نظام DNS على عمليات البحث مع تخزين مؤقت محدود ومدة صلاحية، بينما مفاتيح I2P دائمة.
بالطبع، يمكننا جعله يعمل، لكن لماذا؟ إنه غير مناسب.
- غير موثوق: يعتمد على خوادم محددة لاشتراكات دفتر العناوين.
نعم، يعتمد ذلك على بعض الخوادم التي قمت بتكوينها. داخل I2P، تأتي الخوادم والخدمات وتذهب. أي نظام مركزي آخر (على سبيل المثال خوادم DNS الجذر) سيواجه نفس المشكلة. النظام اللامركزي بالكامل (الجميع له صلاحية) ممكن من خلال تنفيذ حل “الجميع خادم DNS جذر”، أو بشيء أبسط حتى، مثل سكريبت يضيف الجميع في ملف hosts.txt الخاص بك إلى دفتر العناوين الخاص بك.
الأشخاص الذين يدعون للحلول الشمولية السلطوية عمومًا لم يفكروا جيدًا في قضايا التعارضات والاختطاف.
- محرج، وليس في الوقت الفعلي: إنه خليط من مقدمي hosts.txt، ومقدمي نماذج الويب لإضافة المفاتيح، ومقدمي خدمات القفز، ومراسلي حالة مواقع I2P. خوادم القفز والاشتراكات مؤلمة، يجب أن تعمل مثل DNS فقط.
انظر أقسام الموثوقية والثقة.
إذن، باختصار، النظام الحالي ليس معطلاً بشكل فظيع أو غير فعال أو غير قابل للتوسع، والاقتراحات “لمجرد استخدام DNS” غير مدروسة جيداً.
البدائل
يحتوي مصدر I2P على عدة أنظمة تسمية قابلة للتوصيل ويدعم خيارات التكوين لتمكين التجريب مع أنظمة التسمية.
- Meta - يستدعي نظامين أو أكثر من أنظمة التسمية الأخرى بالترتيب. افتراضياً، يستدعي PetName ثم HostsTxt.
- PetName - يبحث في ملف petnames.txt. تنسيق هذا الملف ليس نفس تنسيق hosts.txt.
- HostsTxt - يبحث في الملفات التالية، بالترتيب:
- privatehosts.txt
- userhosts.txt
- hosts.txt
- AddressDB - كل مضيف مُدرج في ملف منفصل في دليل addressDb/.
- Eepget - يقوم بطلب بحث HTTP من خادم خارجي - يجب أن يكون مكدساً بعد بحث HostsTxt مع Meta. هذا يمكن أن يعزز أو يستبدل نظام القفز. يتضمن تخزين مؤقت في الذاكرة.
- Exec - يستدعي برنامج خارجي للبحث، يسمح بتجارب إضافية في مخططات البحث، مستقلة عن java. يمكن استخدامه بعد HostsTxt أو كنظام تسمية وحيد. يتضمن تخزين مؤقت في الذاكرة.
- Dummy - يُستخدم كبديل احتياطي لأسماء Base64، وإلا فإنه يفشل.
يمكن تغيير نظام التسمية الحالي باستخدام خيار الإعداد المتقدم i2p.naming.impl (مطلوب إعادة التشغيل). راجع core/java/src/net/i2p/client/naming للتفاصيل.
أي نظام جديد يجب أن يكون مكدسًا مع HostsTxt، أو يجب أن يطبق التخزين المحلي و/أو وظائف اشتراك دفتر العناوين، نظرًا لأن دفتر العناوين يعرف فقط ملفات hosts.txt وتنسيقها.
الشهادات
تحتوي وجهات I2P على شهادة، ولكن في الوقت الحالي تكون هذه الشهادة دائماً فارغة (null). مع وجود شهادة فارغة، تكون وجهات base64 دائماً بحجم 516 بايت وتنتهي بـ “AAAA”، ويتم التحقق من هذا في آلية دمج دفتر العناوين، وربما في أماكن أخرى أيضاً. كما أنه لا توجد طريقة متاحة لإنشاء شهادة أو إضافتها إلى وجهة. لذا سيتعين تحديث هذه العناصر لتنفيذ الشهادات.
إحدى الاستخدامات المحتملة للشهادات هي إثبات العمل .
والآخر هو أن “النطاقات الفرعية” (بين علامات اقتباس لأنه لا يوجد شيء كهذا حقاً، I2P يستخدم نظام تسمية مسطح) يتم توقيعها بواسطة مفاتيح النطاق من المستوى الثاني.
مع أي تطبيق للشهادات يجب أن تأتي الطريقة للتحقق من الشهادات. من المفترض أن يحدث هذا في كود دمج دفتر العناوين. هل توجد طريقة لأنواع متعددة من الشهادات، أو شهادات متعددة؟
إضافة شهادة تصادق على الاستجابات كموقعة من قبل سلطة شهادات مركزية من شأنه أن يعالج العديد من مشاكل خوادم الأسماء العدائية ولكن سيترك المجال مفتوحاً لهجمات الإعادة بالإضافة إلى هجمات سلطة الشهادات العدائية.