قاعدة بيانات الشبكة

نظرة عامة

قاعدة بيانات netDb الخاصة بـ I2P هي قاعدة بيانات موزعة متخصصة، تحتوي على نوعين فقط من البيانات - معلومات الاتصال بالـ router (RouterInfos) ومعلومات الاتصال بالوجهة (LeaseSets). كل قطعة من البيانات موقعة من قبل الطرف المناسب ومُتحقق منها من قبل أي شخص يستخدمها أو يخزنها. بالإضافة إلى ذلك، تحتوي البيانات على معلومات الحيوية بداخلها، مما يسمح بإسقاط الإدخالات غير ذات الصلة، واستبدال الإدخالات الأحدث بالأقدم، والحماية ضد فئات معينة من الهجمات.

يتم توزيع netDb باستخدام تقنية بسيطة تُسمى “floodfill”، حيث تحتفظ مجموعة فرعية من جميع الـ routers، تُسمى “floodfill routers”، بقاعدة البيانات الموزعة.

RouterInfo

عندما يريد router I2P الاتصال بـ router آخر، يحتاج إلى معرفة بعض البيانات الأساسية المهمة - والتي يتم تجميعها وتوقيعها من قبل الـ router في هيكل يُسمى “RouterInfo”، والذي يتم توزيعه مع SHA256 لهوية الـ router كمفتاح. يحتوي الهيكل نفسه على:

• هوية الـ router (مفتاح تشفير، مفتاح توقيع، وشهادة)
• عناوين الاتصال التي يمكن الوصول إليه من خلالها
• متى تم نشر هذا
• مجموعة من خيارات النص التعسفية
• توقيع ما سبق، المُولد بواسطة مفتاح التوقيع الخاص بالهوية

الخيارات المتوقعة

خيارات النص التالية، رغم أنها ليست مطلوبة بشكل صارم، من المتوقع أن تكون موجودة:

• caps (أعلام القدرات - تستخدم للإشارة إلى مشاركة floodfill وعرض النطاق التقريبي وقابلية الوصول المتصورة)
  • D: ازدحام متوسط (اعتباراً من الإصدار 0.9.58)
  • E: ازدحام عالي (اعتباراً من الإصدار 0.9.58)
  • f: Floodfill
  • G: رفض جميع الأنفاق (اعتباراً من الإصدار 0.9.58)
  • H: مخفي
  • K: أقل من 12 KBps عرض نطاق مشترك
  • L: 12 - 48 KBps عرض نطاق مشترك (افتراضي)
  • M: 48 - 64 KBps عرض نطاق مشترك
  • N: 64 - 128 KBps عرض نطاق مشترك
  • O: 128 - 256 KBps عرض نطاق مشترك
  • P: 256 - 2000 KBps عرض نطاق مشترك (اعتباراً من الإصدار 0.9.20، انظر الملاحظة أدناه)
  • R: قابل للوصول
  • U: غير قابل للوصول
  • X: أكثر من 2000 KBps عرض نطاق مشترك (اعتباراً من الإصدار 0.9.20، انظر الملاحظة أدناه)

“عرض النطاق المُشارك” == (نسبة المشاركة %) * min(عرض النطاق الداخل، عرض النطاق الخارج)

للتوافق مع أجهزة router الأقدم، يمكن لجهاز router أن ينشر عدة أحرف لعرض النطاق الترددي، على سبيل المثال “PO”.

ملاحظة: قد تكون الحدود بين فئتي النطاق الترددي P و X إما 2000 أو 2048 KBps، حسب اختيار المطور.

• netId = 2 (التوافق الأساسي للشبكة - سيرفض الـ router التواصل مع نظير له netId مختلف)
• router.version (يُستخدم لتحديد التوافق مع الميزات والرسائل الأحدث)

ملاحظات حول قدرات R/U: يجب على الـ router عادةً نشر قدرة R أو U، إلا إذا كانت حالة إمكانية الوصول غير معروفة حالياً. R تعني أن الـ router قابل للوصول إليه مباشرة (لا يتطلب introducers، غير محجوب بجدار حماية) على عنوان نقل واحد على الأقل. U تعني أن الـ router غير قابل للوصول إليه مباشرة على أي عنوان نقل.

الخيارات المُهملة: - coreVersion (لم يُستخدم مطلقاً، تم حذفه في الإصدار 0.9.24) - stat_uptime = 90m (غير مُستخدم منذ الإصدار 0.7.9، تم حذفه في الإصدار 0.9.24)

تُستخدم هذه القيم من قبل routers أخرى لاتخاذ قرارات أساسية. هل يجب أن نتصل بهذا router؟ هل يجب أن نحاول توجيه tunnel عبر هذه router؟ علامة قدرة عرض النطاق، على وجه الخصوص، تُستخدم فقط لتحديد ما إذا كان router يلبي الحد الأدنى المطلوب لتوجيه tunnels. فوق الحد الأدنى، لا يتم استخدام عرض النطاق المعلن عنه أو الوثوق به في أي مكان في router، باستثناء العرض في واجهة المستخدم ولأغراض التصحيح وتحليل الشبكة.

أرقام NetID الصالحة:

خيارات إضافية

تشمل خيارات النص الإضافية عددًا صغيرًا من الإحصائيات حول صحة router، والتي يتم تجميعها من قبل مواقع مثل stats.i2p لتحليل أداء الشبكة واستكشاف الأخطاء. تم اختيار هذه الإحصائيات لتوفير بيانات حاسمة للمطورين، مثل معدلات نجاح بناء tunnel، مع موازنة الحاجة لهذه البيانات مع الآثار الجانبية التي قد تنتج عن الكشف عن هذه البيانات. الإحصائيات الحالية مقتصرة على:

• معدلات نجاح ورفض وانتهاء مهلة بناء الأنفاق الاستكشافية
• متوسط عدد الأنفاق المشاركة لمدة ساعة واحدة

هذه اختيارية، ولكن إذا تم تضمينها، فإنها تساعد في تحليل الأداء على نطاق الشبكة. اعتباراً من API 0.9.58، تم تبسيط هذه الإحصائيات وتوحيدها، كما يلي:

• مفاتيح الخيارات هي stat_(statname).(statperiod)
• قيم الخيارات مفصولة بـ ‘;’
• الإحصائيات لعداد الأحداث أو النسب المعيارية تستخدم القيمة الرابعة؛ القيم الثلاث الأولى غير مستخدمة لكن يجب أن تكون موجودة
• الإحصائيات للقيم المتوسطة تستخدم القيمة الأولى، ولا يتطلب فاصل ‘;’
• للحصول على وزن متساوٍ لجميع routers في تحليل الإحصائيات، وللحصول على إخفاء هوية إضافي، يجب على routers تضمين هذه الإحصائيات فقط بعد وقت تشغيل لساعة واحدة أو أكثر، ومرة واحدة فقط كل 16 مرة يتم نشر RI فيها.

مثال:

stat_tunnel.buildExploratoryExpire.60m = 0;0;0;53.14
stat_tunnel.buildExploratoryReject.60m = 0;0;0;15.51
stat_tunnel.buildExploratorySuccess.60m = 0;0;0;31.35
stat_tunnel.participatingTunnels.60m = 289.20

قد تنشر floodfill routers بيانات إضافية حول عدد الإدخالات في قاعدة بيانات الشبكة الخاصة بها. هذه البيانات اختيارية، ولكن في حالة تضمينها، فإنها تساعد في تحليل الأداء على مستوى الشبكة.

يجب أن تتضمن خيارات floodfill routers التاليان في كل RI منشور:

• netdb.knownLeaseSets
• netdb.knownRouters

مثال:

netdb.knownLeaseSets = 158
netdb.knownRouters = 11374

يمكن رؤية البيانات المنشورة في واجهة المستخدم الخاصة بالـ router، ولكن لا يتم استخدامها أو الوثوق بها من قبل أي router آخر.

خيارات العائلة

اعتباراً من الإصدار 0.9.24، قد تعلن أجهزة router أنها جزء من “عائلة”، تُشغَّل من قبل نفس الكيان. لن يتم استخدام عدة أجهزة router من نفس العائلة في tunnel واحد.

خيارات العائلة هي:

• family (اسم العائلة)
• family.key رمز نوع التوقيع الخاص بـ Signing Public Key للعائلة (بأرقام ASCII) مُتَّصل مع ‘:’ مُتَّصل مع Signing Public Key في base 64
• family.sig توقيع ((اسم العائلة في UTF-8) مُتَّصل مع (32 بايت router hash)) في base 64

انتهاء صلاحية RouterInfo

RouterInfos ليس لديها وقت انتهاء صلاحية محدد. كل router حر في الحفاظ على سياسته المحلية الخاصة للموازنة بين تكرار عمليات البحث عن RouterInfo واستخدام الذاكرة أو القرص. في التنفيذ الحالي، هناك السياسات العامة التالية:

• لا توجد انتهاء صلاحية خلال الساعة الأولى من وقت التشغيل، حيث قد تكون البيانات المخزنة بشكل دائم قديمة.
• لا توجد انتهاء صلاحية إذا كان هناك 25 RouterInfo أو أقل.
• مع نمو عدد RouterInfos المحلية، يقل وقت انتهاء الصلاحية، في محاولة للحفاظ على عدد معقول من RouterInfos. وقت انتهاء الصلاحية مع أقل من 120 router هو 72 ساعة، بينما وقت انتهاء الصلاحية مع 300 router يكون حوالي 30 ساعة.
• RouterInfos التي تحتوي على مقدمي SSU تنتهي صلاحيتها في حوالي ساعة واحدة، حيث أن قائمة المقدمين تنتهي صلاحيتها في حوالي ذلك الوقت.
• Floodfills تستخدم وقت انتهاء صلاحية قصير (ساعة واحدة) لجميع RouterInfos المحلية، حيث أن RouterInfos الصالحة سيتم إعادة نشرها إليها بشكل متكرر.

تخزين معلومات RouterInfo بشكل دائم

يتم كتابة RouterInfos على القرص بشكل دوري بحيث تكون متاحة بعد إعادة التشغيل.

قد يكون من المرغوب فيه تخزين Meta LeaseSets بشكل دائم مع انتهاء صلاحية طويلة. هذا يعتمد على التنفيذ.

انظر أيضاً

• مواصفات RouterInfo
• وثائق RouterInfo Javadoc

LeaseSet

الجزء الثاني من البيانات الموزعة في netDb هو “LeaseSet” - الذي يوثق مجموعة من نقاط دخول tunnel (leases) لوجهة عميل معينة. كل من هذه الـ leases تحدد المعلومات التالية:

• router بوابة النفق (عن طريق تحديد هويته)
• معرف النفق على ذلك الـ router لإرسال الرسائل معه (رقم من 4 بايت)
• متى سينتهي ذلك النفق.

يتم تخزين LeaseSet نفسه في netDb تحت المفتاح المشتق من SHA256 للوجهة. هناك استثناء واحد وهو Encrypted LeaseSets (LS2)، اعتباراً من الإصدار 0.9.38. يتم استخدام SHA256 لبايت النوع (3) متبوعاً بالمفتاح العام المعمى لمفتاح DHT، ثم يتم تدويره كالمعتاد. راجع قسم Kademlia Closeness Metric أدناه.

بالإضافة إلى هذه الـ leases، يتضمن الـ LeaseSet:

• الوجهة نفسها (مفتاح تشفير، مفتاح توقيع وشهادة)

• مفتاح تشفير عام إضافي: يُستخدم للتشفير من الطرف إلى الطرف لرسائل garlic

• مفتاح توقيع عام إضافي: مخصص لإلغاء leaseSet، ولكنه غير مستخدم حالياً.

• توقيع جميع بيانات leaseSet، للتأكد من أن الوجهة قد نشرت leaseSet.

• مواصفات Lease

• مواصفات LeaseSet

• Lease Javadoc

• LeaseSet Javadoc

اعتباراً من الإصدار 0.9.38، تم تعريف ثلاثة أنواع جديدة من LeaseSets؛ LeaseSet2 و MetaLeaseSet و EncryptedLeaseSet. انظر أدناه.

LeaseSets غير المنشورة

إن leaseSet للوجهة المستخدمة فقط للاتصالات الصادرة غير منشور. لا يتم إرساله أبداً للنشر إلى router floodfill. أنفاق “العميل”، مثل تلك المخصصة لتصفح الويب وعملاء IRC، غير منشورة. ستظل الخوادم قادرة على إرسال رسائل عائدة إلى تلك الوجهات غير المنشورة، وذلك بسبب رسائل تخزين I2NP .

LeaseSets المسحوبة

يمكن إلغاء LeaseSet عن طريق نشر LeaseSet جديد بدون أي leases. يجب أن تكون الإلغاءات موقعة بواسطة مفتاح التوقيع الإضافي في LeaseSet. الإلغاءات غير مُنفذة بالكامل، وليس من الواضح ما إذا كان لها أي استخدام عملي. هذا هو الاستخدام المخطط الوحيد لمفتاح التوقيع هذا، لذلك فهو غير مستخدم حالياً.

LeaseSet2 (LS2)

اعتباراً من الإصدار 0.9.38، تدعم floodfills بنية LeaseSet2 جديدة. هذه البنية تشبه إلى حد كبير بنية LeaseSet القديمة، وتخدم نفس الغرض. توفر البنية الجديدة المرونة المطلوبة لدعم أنواع التشفير الجديدة، وأنواع التشفير المتعددة، والخيارات، ومفاتيح التوقيع غير المتصلة، وميزات أخرى. راجع الاقتراح 123 للتفاصيل.

Meta LeaseSet (LS2)

اعتباراً من الإصدار 0.9.38، تدعم floodfills بنية Meta LeaseSet جديدة. توفر هذه البنية هيكلاً شجرياً في DHT، للإشارة إلى LeaseSets أخرى. باستخدام Meta LeaseSets، يمكن للموقع تنفيذ خدمات متعددة المواقع كبيرة، حيث يتم استخدام عدة Destinations مختلفة لتوفير خدمة مشتركة. الإدخالات في Meta LeaseSet هي Destinations أو Meta LeaseSets أخرى، وقد تحتوي على انتهاءات صالحية طويلة، تصل إلى 18.2 ساعة. باستخدام هذه الميزة، يجب أن يكون من الممكن تشغيل مئات أو آلاف من Destinations التي تستضيف خدمة مشتركة. انظر الاقتراح 123 للتفاصيل.

LeaseSets مشفرة (LS1)

يصف هذا القسم الطريقة القديمة وغير الآمنة لتشفير LeaseSets باستخدام مفتاح متماثل ثابت. انظر أدناه لإصدار LS2 من Encrypted LeaseSets.

في leaseSet مشفر، يتم تشفير جميع الـ Leases بمفتاح منفصل. لا يمكن فك تشفير الـ leases، وبالتالي لا يمكن الاتصال بالوجهة، إلا من قبل أولئك الذين يملكون المفتاح. لا يوجد علم أو إشارة مباشرة أخرى تدل على أن الـ LeaseSet مشفر. الـ LeaseSets المشفرة غير مستخدمة على نطاق واسع، وهو موضوع للعمل المستقبلي لبحث ما إذا كان بإمكان تحسين واجهة المستخدم وتنفيذ الـ LeaseSets المشفرة.

LeaseSets المشفرة (LS2)

اعتباراً من الإصدار 0.9.38، تدعم floodfills بنية EncryptedLeaseSet جديدة. يكون الـ Destination مخفياً، وفقط المفتاح العام المحجوب وتاريخ انتهاء الصلاحية مرئيان لـ floodfill. فقط أولئك الذين لديهم الـ Destination الكامل يمكنهم فك تشفير البنية. يتم تخزين البنية في موقع DHT بناءً على hash المفتاح العام المحجوب، وليس hash الـ Destination. راجع المقترح 123 للتفاصيل.

انتهاء صلاحية LeaseSet

بالنسبة لـ LeaseSets العادية، فإن انتهاء الصلاحية هو وقت آخر انتهاء صلاحية لعقود الإيجار الخاصة بها. بالنسبة لهياكل البيانات الجديدة LeaseSet2، يتم تحديد انتهاء الصلاحية في الرأس. بالنسبة لـ LeaseSet2، يجب أن يطابق انتهاء الصلاحية آخر انتهاء صلاحية لعقود الإيجار الخاصة بها. بالنسبة لـ EncryptedLeaseSet و MetaLeaseSet، قد يختلف انتهاء الصلاحية، وقد يتم فرض حد أقصى لانتهاء الصلاحية، وهذا ما سيتم تحديده.

تخزين leaseSet الدائم

لا يُطلب تخزين دائم لبيانات LeaseSet، نظراً لانتهاء صلاحيتها بسرعة. ومع ذلك، قد يكون من المستحسن التخزين الدائم لبيانات EncryptedLeaseSet و MetaLeaseSet التي لها فترات انتهاء صلاحية طويلة.

اختيار مفتاح التشفير (LS2)

قد يحتوي LeaseSet2 على مفاتيح تشفير متعددة. المفاتيح مرتبة حسب تفضيل الخادم، والأكثر تفضيلاً أولاً. السلوك الافتراضي للعميل هو اختيار المفتاح الأول بنوع تشفير مدعوم. قد يستخدم العملاء خوارزميات اختيار أخرى بناءً على دعم التشفير والأداء النسبي وعوامل أخرى.

البدء الأولي

netDb لامركزي، لكنك تحتاج إلى مرجع واحد على الأقل لنظير حتى تربطك عملية التكامل. يتم تحقيق ذلك من خلال “إعادة البذر” لجهاز router الخاص بك باستخدام RouterInfo لنظير نشط - تحديداً، من خلال استرجاع ملف routerInfo-$hash.dat الخاص بهم وتخزينه في دليل netDb/ الخاص بك. يمكن لأي شخص تزويدك بتلك الملفات - يمكنك حتى تقديمها للآخرين عن طريق كشف دليل netDb الخاص بك. لتبسيط العملية، يقوم المتطوعون بنشر أدلة netDb الخاصة بهم (أو جزء منها) على الشبكة العادية (غير i2p)، ويتم ترميز عناوين URL لهذه الأدلة بشكل ثابت في I2P. عندما يبدأ تشغيل router لأول مرة، فإنه يجلب تلقائياً من أحد عناوين URL هذه، المختار عشوائياً.

Floodfill

floodfill netDb هو آلية تخزين موزعة بسيطة. خوارزمية التخزين بسيطة: إرسال البيانات إلى أقرب نظير أعلن عن نفسه كـ floodfill router. عندما يستقبل النظير في floodfill netDb عملية تخزين netDb من نظير ليس في floodfill netDb، فإنه يرسلها إلى مجموعة فرعية من أنظار floodfill netDb. الأنظار المختارة هي الأقرب (وفقاً لـ XOR-metric ) لمفتاح محدد.

تحديد من هو جزء من floodfill netDb أمر بسيط - حيث يتم الكشف عنه في routerInfo المنشور لكل router كقدرة.

لا تملك عقد Floodfill سلطة مركزية ولا تشكل “إجماعاً” - فهي تنفذ فقط طبقة DHT بسيطة.

الاشتراك في floodfill router

على عكس Tor، حيث خوادم الدليل مُبرمجة مسبقاً وموثوقة، ويديرها كيانات معروفة، فإن أعضاء مجموعة floodfill peers في I2P ليس بحاجة إلى أن تكون موثوقة، وتتغير مع مرور الوقت.

لزيادة موثوقية netDb، وتقليل تأثير حركة مرور netDb على router، يتم تفعيل floodfill تلقائياً فقط على routers التي تم تكوينها بحدود عرض النطاق الترددي العالية. routers التي لديها حدود عرض النطاق الترددي العالية (والتي يجب تكوينها يدوياً، حيث أن الإعداد الافتراضي أقل بكثير) يُفترض أنها على اتصالات ذات زمن استجابة أقل، ومن المرجح أكثر أن تكون متاحة على مدار الساعة طوال أيام الأسبوع. الحد الأدنى الحالي لعرض النطاق الترددي المشارك لـ floodfill router هو 128 كيلوبايت/ثانية.

بالإضافة إلى ذلك، يجب على الموجه اجتياز عدة اختبارات إضافية للصحة (وقت قائمة انتظار الرسائل الصادرة، تأخر المهام، إلخ) قبل تفعيل عملية floodfill تلقائياً.

مع القواعد الحالية للانضمام التلقائي، حوالي 6% من routers في الشبكة هي floodfill routers.

بينما يتم تكوين بعض النظراء يدوياً لتكون floodfill، فإن البعض الآخر هم ببساطة routers عالية النطاق الترددي الذين يتطوعون تلقائياً عندما ينخفض عدد نظراء floodfill تحت عتبة معينة. هذا يمنع أي ضرر طويل المدى للشبكة من فقدان معظم أو جميع floodfills بسبب هجوم. في المقابل، ستلغي هذه النظراء وضع floodfill عن نفسها عندما يكون هناك الكثير من floodfills النشطة.

أدوار floodfill router

الخدمات الوحيدة لـ floodfill router التي تُضاف إلى خدمات الـ routers غير الـ floodfill هي قبول عمليات تخزين netDb والاستجابة لاستعلامات netDb. نظراً لأنها تتمتع عموماً بعرض نطاق عالي، فهي أكثر عرضة للمشاركة في عدد كبير من الـ tunnels (أي تكون “مُرحّل” للآخرين)، لكن هذا لا يرتبط مباشرة بخدمات قاعدة البيانات الموزعة الخاصة بها.

مقياس القرب في Kademlia

يستخدم netDb مقياس XOR بسيط على طراز Kademlia لتحديد القرب. لإنشاء مفتاح Kademlia، يتم حساب hash SHA256 الخاص بـ RouterIdentity أو Destination. هناك استثناء واحد وهو Encrypted LeaseSets (LS2)، اعتباراً من الإصدار 0.9.38. يتم استخدام SHA256 لبايت النوع (3) متبوعاً بالمفتاح العام المخفي لمفتاح DHT، ثم يتم تدويره كالمعتاد.

يتم إجراء تعديل على هذه الخوارزمية لزيادة تكاليف هجمات Sybil . بدلاً من hash SHA256 للمفتاح المطلوب البحث عنه أو المخزن، يتم أخذ hash SHA256 لمفتاح البحث الثنائي المكون من 32 بايت مُلحق بالتاريخ UTC ممثلاً كسلسلة ASCII مكونة من 8 بايت بصيغة yyyyMMdd، أي SHA256(key + yyyyMMdd). هذا يُسمى “مفتاح التوجيه”، وهو يتغير كل يوم عند منتصف الليل UTC. فقط مفتاح البحث يتم تعديله بهذه الطريقة، وليس hash الخاص بـ floodfill router. التحويل اليومي لـ DHT يُسمى أحياناً “دوران keyspace”، رغم أنه ليس دوراناً بالمعنى الدقيق.

مفاتيح التوجيه لا يتم إرسالها أبداً عبر الشبكة في أي رسالة I2NP، وتُستخدم محلياً فقط لتحديد المسافة.

تقسيم قاعدة بيانات الشبكة - قواعد البيانات الفرعية

تقليدياً، جداول التجزئة الموزعة (DHT) من نمط Kademlia لا تهتم بالحفاظ على عدم إمكانية ربط المعلومات المخزنة على أي عقدة معينة في الـ DHT. على سبيل المثال، قد يتم تخزين جزء من المعلومات على عقدة واحدة في الـ DHT، ثم طلبها مرة أخرى من تلك العقدة دون قيود. داخل I2P وباستخدام netDb، هذا ليس هو الحال، فالمعلومات المخزنة في الـ DHT قد تُشارك فقط في ظروف معروفة معينة حيث يكون من “الآمن” القيام بذلك. هذا لمنع فئة من الهجمات حيث يمكن لجهة فاعلة خبيثة محاولة ربط tunnel عميل مع router من خلال إرسال تخزين إلى tunnel العميل، ثم طلبها مرة أخرى مباشرة من “المضيف” المشتبه به لـ tunnel العميل.

هيكل التجزئة

يمكن لموجهات I2P تنفيذ دفاعات فعالة ضد فئة الهجوم هذه شريطة استيفاء عدة شروط. يجب أن يكون تطبيق قاعدة بيانات الشبكة قادراً على تتبع ما إذا كان إدخال قاعدة البيانات قد تم استلامه عبر tunnel عميل أم مباشرة. إذا تم استلامه عبر tunnel عميل، فيجب أيضاً تتبع tunnel العميل الذي تم الاستلام من خلاله، باستخدام الوجهة المحلية للعميل. إذا تم استلام الإدخال عبر عدة tunnels عملاء، فيجب على netDb تتبع جميع الوجهات التي لوحظ فيها الإدخال. يجب أيضاً تتبع ما إذا كان الإدخال قد تم استلامه كرد على استعلام، أم كعملية تخزين.

في كلا التنفيذين Java و C++، يتم تحقيق ذلك باستخدام netDb رئيسية واحدة “Main” للبحثات المباشرة وعمليات floodfill أولاً. هذه الـ netDb الرئيسية موجودة في سياق الـ router. ثم، يتم إعطاء كل client نسخته الخاصة من الـ netDb، والتي تُستخدم لالتقاط إدخالات قاعدة البيانات المرسلة إلى tunnels العميل والاستجابة للبحثات المرسلة عبر tunnels العميل. نسمي هذه “Client Network Databases” أو “Sub-Databases” وهي موجودة في سياق العميل. الـ netDb التي يديرها العميل موجودة فقط طوال فترة حياة العميل وتحتوي فقط على الإدخالات التي يتم التواصل معها عبر tunnels العميل. هذا يجعل من المستحيل أن تتداخل الإدخالات المرسلة عبر tunnels العميل مع الإدخالات المرسلة مباشرة إلى الـ router.

بالإضافة إلى ذلك، يحتاج كل netDb إلى أن يكون قادراً على تذكر ما إذا كان إدخال قاعدة البيانات قد تم استلامه لأنه تم إرساله إلى إحدى وجهاتنا، أو لأنه تم طلبه من قبلنا كجزء من عملية بحث. إذا كان إدخال قاعدة البيانات قد تم استلامه كتخزين، كما لو أن router آخر قد أرسله إلينا، فيجب على netDb الاستجابة للطلبات الخاصة بالإدخال عندما يبحث router آخر عن المفتاح. ومع ذلك، إذا تم استلامه كرد على استعلام، فيجب على netDb الرد على استعلام الإدخال فقط إذا كان الإدخال قد تم تخزينه بالفعل في نفس الوجهة. يجب ألا يجيب العميل أبداً على الاستعلامات بإدخال من netDb الرئيسي، بل فقط من قاعدة بيانات الشبكة الخاصة بالعميل.

يجب تطبيق هذه الاستراتيجيات معاً بحيث يتم استخدام كلاهما. عند دمجهما معاً، فإنهما “يقسمان” قاعدة بيانات الشبكة (netDb) ويؤمنانها ضد الهجمات.

آليات التخزين والتحقق والبحث

تخزين RouterInfo للأقران

يتم تبادل I2NP DatabaseStoreMessages التي تحتوي على RouterInfo المحلي مع الأطراف النظيرة كجزء من تهيئة اتصال النقل NTCP أو SSU .

تخزين LeaseSet للأقران

يتم تبادل I2NP DatabaseStoreMessages التي تحتوي على LeaseSet المحلي بشكل دوري مع الأقران عن طريق تجميعها في رسالة garlic مع حركة المرور العادية من Destination ذي الصلة. يتيح هذا إرسال استجابة أولية، واستجابات لاحقة، إلى Lease مناسب، دون الحاجة إلى أي عمليات بحث LeaseSet، أو مطالبة Destinations المتصلة بنشر LeaseSets على الإطلاق.

اختيار Floodfill

يجب إرسال DatabaseStoreMessage إلى floodfill الأقرب إلى مفتاح التوجيه الحالي للـ RouterInfo أو LeaseSet الذي يتم تخزينه. حالياً، يتم العثور على أقرب floodfill من خلال البحث في قاعدة البيانات المحلية. حتى لو لم يكن ذلك floodfill الأقرب فعلياً، فسيقوم بإغراقه “بشكل أقرب” عن طريق إرساله إلى عدة floodfills أخرى. هذا يوفر درجة عالية من تحمل الأخطاء.

في Kademlia التقليدي، سيقوم النظير بعملية بحث “العثور على الأقرب” قبل إدراج عنصر في DHT إلى الهدف الأقرب. نظراً لأن عملية التحقق ستميل إلى اكتشاف floodfills أقرب إذا كانت موجودة، فإن router سيحسن بسرعة معرفته بـ “الحي” DHT الخاص بـ RouterInfo و LeaseSets التي ينشرها بانتظام. بينما I2NP لا يحدد رسالة “العثور على الأقرب”، إذا أصبح ذلك ضرورياً، قد يقوم router ببساطة بإجراء بحث تكراري عن مفتاح مع قلب البت الأقل أهمية (أي key ^ 0x01) حتى لا يتم تلقي أي نظراء أقرب في DatabaseSearchReplyMessages. هذا يضمن العثور على النظير الأقرب الحقيقي حتى لو كان لدى نظير أكثر بُعداً عنصر netdb.

تخزين RouterInfo في Floodfills

ينشر router معلومات RouterInfo الخاصة به عن طريق الاتصال مباشرة بـ floodfill router وإرسال رسالة I2NP DatabaseStoreMessage مع Reply Token غير صفري. الرسالة ليست مشفرة garlic encryption من طرف إلى طرف، حيث أن هذا اتصال مباشر، لذا لا توجد routers وسيطة (ولا حاجة لإخفاء هذه البيانات على أي حال). يرد floodfill router برسالة I2NP DeliveryStatusMessage، مع تعيين Message ID إلى قيمة Reply Token.

في بعض الظروف، قد يرسل router أيضاً رسالة RouterInfo DatabaseStoreMessage عبر نفق استكشافي؛ على سبيل المثال، بسبب قيود الاتصال، أو عدم توافق الاتصال، أو الرغبة في إخفاء عنوان IP الفعلي من floodfill. قد لا يقبل floodfill مثل هذا التخزين في أوقات الحمولة الزائدة أو بناءً على معايير أخرى؛ ما إذا كان يجب إعلان التخزين غير المباشر لـ RouterInfo غير قانوني بشكل صريح هو موضوع للدراسة الإضافية.

تخزين LeaseSet في عقد Floodfill

تخزين LeaseSets أكثر حساسية بكثير من RouterInfos، حيث يجب على الـ router أن يتأكد من عدم إمكانية ربط الـ LeaseSet بالـ router.

ينشر router محلي LeaseSet عن طريق إرسال I2NP DatabaseStoreMessage مع Reply Token غير صفري عبر tunnel صادر للعميل لذلك Destination. يتم تشفير الرسالة من طرف إلى طرف باستخدام garlic encryption مع Session Key Manager الخاص بـ Destination، لإخفاء الرسالة عن نقطة النهاية الصادرة للـ tunnel. يرد router الـ floodfill برسالة I2NP DeliveryStatusMessage، مع تعيين Message ID لقيمة Reply Token. يتم إرسال هذه الرسالة مرة أخرى إلى أحد tunnels الواردة للعميل.

الإغراق

مثل أي router، يستخدم floodfill معايير متنوعة للتحقق من صحة LeaseSet أو RouterInfo قبل تخزينها محلياً. قد تكون هذه المعايير قابلة للتكيف وتعتمد على الظروف الحالية بما في ذلك الحمولة الحالية وحجم netDb وعوامل أخرى. يجب إجراء جميع عمليات التحقق قبل الإغراق.

بعد أن يتلقى router الـ floodfill رسالة DatabaseStoreMessage تحتوي على RouterInfo أو LeaseSet صالح وأحدث من المخزن مسبقاً في NetDb المحلي، يقوم بـ “flood” (إغراق) هذه البيانات. لإغراق إدخال NetDb، يبحث عن عدة routers من نوع floodfill (حالياً 3) الأقرب لمفتاح التوجيه الخاص بإدخال NetDb. (مفتاح التوجيه هو SHA256 Hash للـ RouterIdentity أو Destination مع إضافة التاريخ (yyyyMMdd).) من خلال الإغراق إلى الأقرب للمفتاح وليس الأقرب لنفسه، يضمن الـ floodfill أن التخزين يصل للمكان الصحيح، حتى لو لم يكن لدى router التخزين معرفة جيدة بـ “الحي” الخاص بـ DHT لمفتاح التوجيه.

يقوم floodfill بعد ذلك بالاتصال مباشرة بكل من هؤلاء النظراء وإرسال رسالة I2NP DatabaseStoreMessage مع Reply Token صفري. الرسالة ليست مشفرة بـ garlic encryption من طرف إلى طرف، حيث أن هذا اتصال مباشر، لذلك لا توجد routers وسطية (ولا حاجة لإخفاء هذه البيانات على أي حال). الـ routers الأخرى لا ترد أو تعيد الإرسال، حيث أن Reply Token يساوي صفر.

يجب على floodfills عدم إرسال البيانات عبر tunnels؛ يجب إرسال DatabaseStoreMessage عبر اتصال مباشر.

يجب على floodfills ألا تغمر أبداً LeaseSet منتهي الصلاحية أو RouterInfo تم نشره منذ أكثر من ساعة واحدة.

البحث عن RouterInfo و LeaseSet

يُستخدم I2NP DatabaseLookupMessage لطلب إدخال netDb من router floodfill. يتم إرسال الاستعلامات عبر أحد الـ tunnel الاستكشافية الصادرة للـ router. يُحدد أن الردود ترجع عبر أحد الـ tunnel الاستكشافية الواردة للـ router.

يتم إرسال عمليات البحث عمومًا إلى أقرب اثنين من floodfill routers “الجيدة” (التي لا تفشل في الاتصال) للمفتاح المطلوب، بشكل متوازي.

إذا تم العثور على المفتاح محلياً بواسطة floodfill router، فإنه يستجيب برسالة I2NP DatabaseStoreMessage. إذا لم يتم العثور على المفتاح محلياً بواسطة floodfill router، فإنه يستجيب برسالة I2NP DatabaseSearchReplyMessage تحتوي على قائمة من floodfill routers أخرى قريبة من المفتاح.

عمليات البحث في leaseSet مُشفرة بـ garlic encryption من طرف إلى طرف اعتباراً من الإصدار 0.9.5. عمليات البحث في RouterInfo غير مُشفرة وبالتالي فهي عرضة للتنصت من قبل نقطة النهاية الصادرة (OBEP) لنفق العميل. وهذا يرجع إلى التكلفة العالية لتشفير ElGamal. قد يتم تمكين تشفير البحث في RouterInfo في إصدار مستقبلي.

اعتباراً من الإصدار 0.9.7، ستكون الردود على البحث عن LeaseSet (رسالة DatabaseStoreMessage أو DatabaseSearchReplyMessage) مشفرة من خلال تضمين مفتاح الجلسة والعلامة في البحث. هذا يخفي الرد عن البوابة الواردة (IBGW) لنفق الرد. ستكون الاستجابات لعمليات البحث عن RouterInfo مشفرة إذا قمنا بتمكين تشفير البحث.

(المرجع: Hashing it out in Public الأقسام 2.2-2.3 للمصطلحات أدناه بالخط المائل)

نظراً للحجم الصغير نسبياً للشبكة وتكرار flooding، عادة ما تكون عمليات البحث O(1) بدلاً من O(log n). من المحتمل جداً أن يعرف router أحد floodfill routers قريب بما فيه الكفاية من المفتاح للحصول على الإجابة في المحاولة الأولى. في الإصدارات السابقة لـ 0.8.9، استخدمت routers تكراراً في البحث قدره اثنين (أي تم تنفيذ عمليتي بحث بالتوازي إلى peers مختلفين)، ولم يتم تنفيذ التوجيه التكراري ولا التدريجي لعمليات البحث. تم إرسال الاستعلامات عبر مسارات متعددة في الوقت نفسه لـتقليل فرصة فشل الاستعلام.

اعتباراً من الإصدار 0.8.9، تم تنفيذ عمليات البحث التكرارية بدون تكرار في البحث. هذا بحث أكثر كفاءة وموثوقية سيعمل بشكل أفضل بكثير عندما لا تكون جميع عقد floodfill معروفة، ويزيل قيداً خطيراً على نمو الشبكة. مع نمو الشبكة ومعرفة كل router لمجموعة فرعية صغيرة فقط من عقد floodfill، ستصبح عمليات البحث O(log n). حتى لو لم تُرجع العقدة مراجع أقرب إلى المفتاح، فإن البحث يستمر مع العقدة الأقرب التالية، للحصول على مزيد من القوة، ولمنع floodfill خبيث من إنشاء ثقب أسود في جزء من مساحة المفاتيح. تستمر عمليات البحث حتى يتم الوصول إلى مهلة البحث الإجمالية، أو يتم الاستعلام عن العدد الأقصى من العقد.

معرفات العقد قابلة للتحقق حيث نستخدم router hash مباشرة كمعرف العقدة ومفتاح Kademlia في آن واحد. الاستجابات غير الصحيحة التي لا تكون أقرب إلى مفتاح البحث يتم تجاهلها عموماً. بالنظر إلى الحجم الحالي للشبكة، فإن router لديه معرفة تفصيلية بحي مساحة معرف الوجهة.

التحقق من تخزين RouterInfo

ملاحظة: تم تعطيل التحقق من RouterInfo اعتباراً من الإصدار 0.9.7.1 لمنع الهجوم الموصوف في الورقة البحثية Practical Attacks Against the I2P Network . ليس من الواضح ما إذا كان يمكن إعادة تصميم التحقق ليتم بشكل آمن.

للتحقق من نجاح عملية التخزين، ينتظر الموجه حوالي 10 ثوانٍ ببساطة، ثم يرسل استعلام إلى موجه floodfill آخر قريب من المفتاح (وليس نفس الموجه الذي تم إرسال التخزين إليه). يتم إرسال الاستعلامات عبر أحد أنفاق الاستكشاف الصادرة للموجه. يتم تشفير الاستعلامات من طرف إلى طرف بـ garlic encryption لمنع التجسس من قبل نقطة النهاية الصادرة (OBEP).

التحقق من تخزين LeaseSet

للتحقق من نجاح عملية التخزين، ينتظر الـ router ببساطة حوالي 10 ثوانٍ، ثم يرسل طلب بحث إلى floodfill router آخر قريب من المفتاح (ولكن ليس نفس الـ router الذي تم إرسال التخزين إليه). يتم إرسال طلبات البحث عبر أحد أنفاق العميل الصادرة للوجهة الخاصة بـ LeaseSet الذي يتم التحقق منه. لمنع التنصت من قبل OBEP الخاص بالنفق الصادر، يتم تشفير طلبات البحث بـ garlic encryption من طرف إلى طرف. يتم تحديد إرجاع الردود عبر أحد أنفاق العميل الواردة.

اعتباراً من الإصدار 0.9.7، سيتم تشفير الردود لكل من عمليات البحث عن RouterInfo و LeaseSet (رسالة DatabaseStoreMessage أو DatabaseSearchReplyMessage) لإخفاء الرد عن البوابة الواردة (IBGW) لنفق الرد.

الاستكشاف

الاستكشاف هو شكل خاص من البحث في netDb، حيث يحاول router معرفة المزيد عن routers جديدة. يقوم بذلك عن طريق إرسال I2NP DatabaseLookup Message إلى floodfill router، بحثاً عن مفتاح عشوائي. نظراً لأن هذا البحث سيفشل، فإن floodfill عادة ما يرد برسالة I2NP DatabaseSearchReplyMessage تحتوي على hashes خاصة بـ floodfill routers القريبة من المفتاح. هذا لن يكون مفيداً، حيث أن router الطالب ربما يعرف بالفعل تلك floodfills، وسيكون من غير العملي إضافة جميع floodfill routers إلى حقل “عدم التضمين” في DatabaseLookup Message. بالنسبة لاستعلام الاستكشاف، يقوم router الطالب بتعيين علامة خاصة في DatabaseLookup Message. سيرد floodfill حينها فقط بـ routers غير floodfill القريبة من المفتاح المطلوب.

ملاحظات حول استجابات البحث

الاستجابة لطلب البحث هي إما رسالة تخزين قاعدة البيانات (عند النجاح) أو رسالة رد البحث في قاعدة البيانات (عند الفشل). تحتوي DSRM على حقل hash للـ router المصدر ‘from’ للإشارة إلى مصدر الرد؛ بينما DSM لا تحتوي على ذلك. حقل ‘from’ في DSRM غير مصدق عليه وقد يكون مزيفاً أو غير صحيح. لا توجد علامات استجابة أخرى. لذلك، عند تنفيذ طلبات متعددة بالتوازي، من الصعب مراقبة أداء الـ floodfill routers المختلفة.

MultiHoming

يمكن استضافة الوجهات على عدة routers في نفس الوقت، عن طريق استخدام نفس المفاتيح الخاصة والعامة (المخزنة تقليدياً في ملفات eepPriv.dat). نظراً لأن كلا المثيلين سينشر دورياً leaseSet الموقعة الخاصة بهما إلى peers من نوع floodfill، فإن leaseSet المنشورة مؤخراً ستُعاد إلى peer يطلب بحث قاعدة البيانات. نظراً لأن LeaseSets لديها (على الأكثر) مدة صالحية 10 دقائق، إذا تعطل مثيل معين، فإن الانقطاع سيكون 10 دقائق كحد أقصى، وعادة أقل من ذلك بكثير. تم التحقق من وظيفة الاستضافة المتعددة وهي مستخدمة من قبل عدة خدمات على الشبكة.

اعتبارًا من الإصدار 0.9.38، تدعم floodfills بنية Meta LeaseSet جديدة. توفر هذه البنية هيكلاً شبيهًا بالشجرة في DHT، للإشارة إلى LeaseSets أخرى. باستخدام Meta LeaseSets، يمكن للموقع تنفيذ خدمات كبيرة متعددة المنازل، حيث يتم استخدام عدة Destinations مختلفة لتوفير خدمة مشتركة. الإدخالات في Meta LeaseSet هي Destinations أو Meta LeaseSets أخرى، وقد يكون لها انتهاء صلاحية طويل، يصل إلى 18.2 ساعة. باستخدام هذه الإمكانية، يجب أن يكون من الممكن تشغيل المئات أو الآلاف من Destinations التي تستضيف خدمة مشتركة. انظر المقترح 123 للتفاصيل.

تحليل التهديدات

تمت مناقشة هذا أيضًا في صفحة نموذج التهديد .

قد يحاول مستخدم عدائي إلحاق الضرر بالشبكة من خلال إنشاء واحد أو أكثر من floodfill routers وتصميمها لتقديم استجابات سيئة أو بطيئة أو عدم تقديم استجابات على الإطلاق. يتم مناقشة بعض السيناريوهات أدناه.

التخفيف العام من خلال النمو

يوجد حاليًا حوالي 1700 floodfill router في الشبكة. معظم الهجمات التالية ستصبح أكثر صعوبة، أو ستكون لها تأثير أقل، مع زيادة حجم الشبكة وعدد floodfill routers.

التخفيف العام من خلال التكرار

عبر الفيضان، يتم تخزين جميع إدخالات netDb على أقرب 3 من floodfill routers إلى المفتاح.

التزوير

جميع إدخالات netdb موقعة من قبل منشئيها، لذلك لا يمكن لأي router تزوير RouterInfo أو LeaseSet.

بطيء أو غير مستجيب

يحتفظ كل router بمجموعة موسعة من الإحصائيات في ملف تعريف النظير لكل floodfill router، تغطي مقاييس جودة مختلفة لذلك النظير. تتضمن المجموعة:

• متوسط وقت الاستجابة
• نسبة الاستعلامات التي تم الإجابة عليها بالبيانات المطلوبة
• نسبة المخازن التي تم التحقق منها بنجاح
• آخر تخزين ناجح
• آخر بحث ناجح
• آخر استجابة

في كل مرة يحتاج فيها router إلى اتخاذ قرار حول أي floodfill router هو الأقرب إلى مفتاح معين، يستخدم هذه المقاييس لتحديد أي floodfill routers تعتبر “جيدة”. الطرق والعتبات المستخدمة لتحديد “الجودة” جديدة نسبياً، وهي عرضة للمزيد من التحليل والتحسين. بينما يمكن تحديد وتجنب router غير مستجيب تماماً بسرعة، فإن routers التي تكون خبيثة أحياناً فقط قد تكون أصعب بكثير في التعامل معها.

هجوم Sybil (المساحة الكاملة للمفاتيح)

قد يشن المهاجم هجوم Sybil من خلال إنشاء عدد كبير من floodfill routers موزعة في جميع أنحاء مساحة المفاتيح.

(في مثال ذي صلة، أنشأ باحث مؤخراً عدداً كبيراً من relays الخاصة بـ Tor .) إذا نجحت هذه المحاولة، فقد تكون هجوم حجب خدمة فعالاً على الشبكة بأكملها.

إذا لم تكن floodfills تسيء التصرف بشكل كافٍ لتُعلم كـ “سيئة” باستخدام مقاييس ملف تعريف النظير المذكورة أعلاه، فهذا سيناريو صعب التعامل معه. يمكن أن تكون استجابة Tor أكثر رشاقة في حالة المرحل، حيث يمكن إزالة المرحلات المشبوهة يدوياً من الإجماع. يتم سرد بعض الاستجابات المحتملة لشبكة I2P أدناه، ومع ذلك فإن أياً منها ليس مُرضياً تماماً:

• تجميع قائمة بـ router hashes سيئة أو عناوين IP، والإعلان عن القائمة من خلال وسائل مختلفة (أخبار وحدة التحكم، الموقع الإلكتروني، المنتدى، إلخ)؛ سيتعين على المستخدمين تنزيل القائمة يدوياً وإضافتها إلى “القائمة السوداء” المحلية لديهم.
• مطالبة الجميع في الشبكة بتمكين floodfill يدوياً (محاربة Sybil بـ Sybil أكثر)
• إصدار نسخة جديدة من البرنامج تتضمن القائمة “السيئة” مبرمجة مسبقاً
• إصدار نسخة جديدة من البرنامج تحسن مقاييس وعتبات ملف تعريف الأقران، في محاولة لتحديد الأقران “السيئين” تلقائياً.
• إضافة برنامج يلغي تأهيل floodfills إذا كان عدد كبير جداً منها في كتلة IP واحدة
• تنفيذ قائمة سوداء تلقائية قائمة على الاشتراك يتحكم بها فرد أو مجموعة واحدة. هذا سيطبق بشكل أساسي جزءاً من نموذج “الإجماع” في Tor. لسوء الحظ، سيعطي هذا أيضاً لفرد أو مجموعة واحدة القدرة على حظر مشاركة أي router معين أو IP في الشبكة، أو حتى إيقاف أو تدمير الشبكة بأكملها.

تصبح هذه الهجمة أكثر صعوبة مع نمو حجم الشبكة.

هجوم سيبيل (مساحة المفاتيح الجزئية)

قد يقوم مهاجم بشن هجوم سيبيل عبر إنشاء عدد صغير (8-15) من floodfill routers مجمعة بشكل وثيق في keyspace، وتوزيع RouterInfos لهذه الـ routers على نطاق واسع. حينها، ستوجه جميع عمليات البحث والتخزين لمفتاح في ذلك الـ keyspace إلى أحد routers المهاجم. في حال نجح ذلك، يمكن أن يكون هجوم DOS فعال على موقع I2P محدد، على سبيل المثال.

نظرًا لأن مساحة المفاتيح مفهرسة بواسطة Hash التشفيري (SHA256) للمفتاح، يجب على المهاجم استخدام طريقة القوة الغاشمة لتوليد router hashes بشكل متكرر حتى يحصل على عدد كافٍ منها قريب بما فيه الكفاية من المفتاح. كمية القوة الحاسوبية المطلوبة لهذا الأمر، والتي تعتمد على حجم الشبكة، غير معروفة.

كدفاع جزئي ضد هذا الهجوم، تتغير الخوارزمية المستخدمة لتحديد “القرب” في Kademlia عبر الزمن. بدلاً من استخدام Hash للمفتاح (أي H(k)) لتحديد القرب، نستخدم Hash للمفتاح مُلحق بنص التاريخ الحالي، أي H(k + YYYYMMDD). تقوم دالة تسمى “مولد مفتاح التوجيه” بهذا العمل، والتي تحول المفتاح الأصلي إلى “مفتاح توجيه”. بعبارة أخرى، تدور مساحة مفاتيح netdb بأكملها كل يوم عند منتصف الليل بتوقيت UTC. أي هجوم على مساحة مفاتيح جزئية سيحتاج إلى إعادة توليد كل يوم، لأنه بعد الدوران، لن تعود أجهزة router المهاجمة قريبة من المفتاح المستهدف، أو من بعضها البعض.

يصبح هذا الهجوم أكثر صعوبة مع نمو حجم الشبكة. ومع ذلك، تُظهر الأبحاث الحديثة أن دوران keyspace ليس فعالاً بشكل خاص. يمكن للمهاجم حساب العديد من router hashes مسبقاً، وتكفي بضعة routers فقط لـ “إخفاء” جزء من keyspace خلال نصف ساعة بعد الدوران.

إحدى نتائج التدوير اليومي لمساحة المفاتيح هي أن قاعدة بيانات الشبكة الموزعة قد تصبح غير موثوقة لعدة دقائق بعد التدوير – ستفشل عمليات البحث لأن router “الأقرب” الجديد لم يتلق تخزين بعد. مدى المشكلة وطرق التخفيف (على سبيل المثال “التمرير” في netDb عند منتصف الليل) هي موضوع للدراسة الإضافية.

هجمات Bootstrap

يمكن للمهاجم محاولة تشغيل routers جديدة في شبكة معزولة أو محكومة بالأغلبية من خلال السيطرة على موقع إعادة التوليد (reseed)، أو خداع المطورين لإضافة موقع إعادة التوليد الخاص به إلى القائمة المشفرة في router.

عدة دفاعات ممكنة، ومعظم هذه مخطط لها:

• منع الرجوع من HTTPS إلى HTTP عند إعادة البذر. يمكن لمهاجم MITM ببساطة حجب HTTPS، ثم الاستجابة لـ HTTP.
• تجميع بيانات إعادة البذر في برنامج التثبيت

الدفاعات المُطبقة:

• تغيير مهمة إعادة البذر لجلب مجموعة فرعية من RouterInfos من عدة مواقع إعادة بذر بدلاً من استخدام موقع واحد فقط
• إنشاء خدمة مراقبة إعادة البذر خارج الشبكة التي تستطلع دورياً مواقع إعادة البذر وتتحقق من أن البيانات ليست قديمة أو غير متسقة مع وجهات نظر أخرى للشبكة
• اعتباراً من الإصدار 0.9.14، يتم تجميع بيانات إعادة البذر في ملف zip موقع ويتم التحقق من التوقيع عند التحميل. راجع مواصفة su3 للتفاصيل.

التقاط الاستعلام

انظر أيضاً lookup (مرجع: Hashing it out in Public الأقسام 2.2-2.3 للمصطلحات أدناه بالخط المائل)

مشابهاً لهجوم bootstrap، يمكن لمهاجم يستخدم floodfill router أن يحاول “توجيه” النظراء إلى مجموعة فرعية من أجهزة router التي يسيطر عليها من خلال إرجاع مراجعها.

من غير المرجح أن يعمل هذا عبر الاستكشاف، لأن الاستكشاف مهمة منخفضة التكرار. تحصل أجهزة router على معظم مراجع النظراء من خلال نشاط بناء tunnel العادي. نتائج الاستكشاف محدودة عموماً ببضعة hashes لأجهزة router، وكل استعلام استكشاف موجه إلى router floodfill عشوائي.

اعتباراً من الإصدار 0.8.9، تم تنفيذ البحث التكراري. بالنسبة لمراجع floodfill router المُرجعة في استجابة I2NP DatabaseSearchReplyMessage لعملية البحث، يتم اتباع هذه المراجع إذا كانت أقرب (أو الأقرب التالية) إلى مفتاح البحث. router الطالب لا يثق في أن المراجع أقرب إلى المفتاح (أي أنها صحيحة قابلة للتحقق). البحث أيضاً لا يتوقف عند عدم العثور على مفتاح أقرب، بل يستمر بالاستعلام من العقدة الأقرب التالية، حتى انتهاء المهلة الزمنية أو الوصول إلى العدد الأقصى من الاستعلامات. هذا يمنع floodfill خبيث من إنشاء ثقب أسود في جزء من مساحة المفاتيح. كما أن التدوير اليومي لمساحة المفاتيح يتطلب من المهاجم إعادة توليد معلومات router ضمن منطقة مساحة المفاتيح المرغوبة. هذا التصميم يضمن أن هجوم التقاط الاستعلامات المُوصف في Hashing it out in Public أصبح أكثر صعوبة بكثير.

اختيار المرحل المبني على DHT

(المرجع: Hashing it out in Public القسم 3)

هذا لا يتعلق كثيراً بـ floodfill، ولكن راجع صفحة اختيار النظراء لمناقشة نقاط الضعف في اختيار النظراء للـ tunnels.

تسريبات المعلومات

(مرجع: البحث عن بحث مجهول وآمن القسم 3)

تتناول هذه الورقة نقاط الضعف في عمليات البحث في DHT “Finger Table” المستخدمة بواسطة Torsk و NISAN. للوهلة الأولى، لا يبدو أن هذه تنطبق على I2P. أولاً، استخدام DHT بواسطة Torsk و NISAN يختلف بشكل كبير عن ذلك في I2P. ثانياً، عمليات البحث في قاعدة بيانات الشبكة في I2P ترتبط بشكل فضفاض فقط بعمليات اختيار النظراء و بناء tunnel ؛ يتم استخدام النظراء المعروفين مسبقاً فقط للـ tunnels. كما أن اختيار النظراء لا يرتبط بأي مفهوم لقرب مفاتيح DHT.

قد يكون بعض هذا أكثر إثارة للاهتمام فعلياً عندما تصبح شبكة I2P أكبر بكثير. في الوقت الحالي، كل router يعرف نسبة كبيرة من الشبكة، لذا فإن البحث عن Router Info معين في قاعدة بيانات الشبكة ليس مؤشراً قوياً على نية مستقبلية لاستخدام ذلك الـ router في tunnel. ربما عندما تصبح الشبكة أكبر بـ 100 مرة، قد يصبح البحث أكثر ارتباطاً. بالطبع، الشبكة الأكبر تجعل هجوم Sybil أصعب بكثير.

ومع ذلك، فإن المسألة العامة لتسرب معلومات DHT في I2P تحتاج إلى مزيد من التحقيق. إن floodfill routers في موقع يمكنها من ملاحظة الاستعلامات وجمع المعلومات. بالتأكيد، عند مستوى f = 0.2 (20% من العقد الخبيثة، كما هو محدد في الورقة البحثية) نتوقع أن العديد من تهديدات Sybil التي نصفها (هنا ، هنا وهنا ) تصبح مشكلة لعدة أسباب.

التاريخ

تم النقل إلى صفحة مناقشة netdb .

العمل المستقبلي

التشفير من طرف إلى طرف لعمليات البحث والاستجابات الإضافية في netDb.

طرق أفضل لتتبع استجابات البحث.