I2P: مقدمة تقنية

ملاحظة: تم كتابة هذا المستند في الأصل من قبل jrandom في عام 2003. بينما نسعى للحفاظ على تحديثه، قد تكون بعض المعلومات قديمة أو غير مكتملة. أقسام النقل والتشفير محدثة اعتباراً من يناير 2025.

مقدمة

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

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

• تصفح الويب: باستخدام أي متصفح موجود يدعم استخدام البروكسي.
• المحادثة: IRC والبروتوكولات الأخرى
• مشاركة الملفات: I2PSnark والتطبيقات الأخرى
• البريد الإلكتروني: susimail والتطبيقات الأخرى
• المدونة: باستخدام أي خادم ويب محلي، أو الإضافات المتاحة

على عكس المواقع الإلكترونية المستضافة ضمن شبكات توزيع المحتوى مثل Freenet أو GNUnet ، فإن الخدمات المستضافة على I2P تفاعلية بالكامل — هناك محركات بحث تقليدية على غرار الويب، ولوحات إعلانات، ومدونات يمكنك التعليق عليها، ومواقع تعتمد على قواعد البيانات، وجسور للاستعلام من الأنظمة الثابتة مثل Freenet دون الحاجة لتثبيتها محلياً.

مع كل هذه التطبيقات التي تدعم إخفاء الهوية، يتولى I2P دور الوسطاء الموجهة للرسائل — التطبيقات تقول أنها تريد إرسال بعض البيانات إلى معرف تشفيري (“destination”) ويتولى I2P مهمة التأكد من وصولها بشكل آمن ومجهول الهوية. كما يحزم I2P مكتبة streaming بسيطة للسماح لرسائل I2P المجهولة ذات الجهد الأفضل بالنقل كتدفقات موثوقة ومرتبة، مما يوفر بشكل شفاف خوارزمية التحكم في الازدحام القائمة على TCP والمضبوطة لناتج التأخير عالي النطاق الترددي للشبكة. بينما كانت هناك عدة بروكسيات SOCKS بسيطة متاحة لربط التطبيقات الموجودة بالشبكة، كانت قيمتها محدودة حيث أن تقريباً كل تطبيق يكشف بانتظام ما يُعتبر، في سياق مجهول الهوية، معلومات حساسة. الطريقة الآمنة الوحيدة هي المراجعة الشاملة للتطبيق لضمان التشغيل السليم ولمساعدة في ذلك نوفر سلسلة من واجهات برمجة التطبيقات بلغات مختلفة يمكن استخدامها لتحقيق أقصى استفادة من الشبكة.

I2P ليس مشروع بحثي — أكاديمي أو تجاري أو حكومي — بل هو جهد هندسي يهدف إلى فعل كل ما هو ضروري لتوفير مستوى كافٍ من إخفاء الهوية لأولئك الذين يحتاجونه. وهو في طور التطوير النشط منذ أوائل عام 2003 مع مطور واحد بدوام كامل ومجموعة مخصصة من المساهمين بدوام جزئي من جميع أنحاء العالم. جميع الأعمال المنجزة على I2P مفتوحة المصدر ومتاحة مجاناً على الموقع الإلكتروني ، حيث تم إصدار غالبية الكود مباشرة إلى النطاق العام، رغم استخدام بعض الروتينات التشفيرية تحت تراخيص بنمط BSD. الأشخاص العاملون على I2P لا يتحكمون في التراخيص التي يصدر تحتها الناس تطبيقات العميل، وهناك عدة تطبيقات متاحة تحت ترخيص GPL (I2PTunnel ، susimail ، I2PSnark ، I2P-Bote، I2Phex وغيرها). تأتي التمويل لـ I2P بالكامل من التبرعات، ولا يتلقى أي إعفاءات ضريبية في أي ولاية قضائية في الوقت الحالي، حيث أن العديد من المطورين أنفسهم مجهولي الهوية.

التشغيل

نظرة عامة

لفهم طريقة عمل I2P، من الضروري فهم بعض المفاهيم الأساسية. أولاً، يقوم I2P بفصل صارم بين البرنامج المشارك في الشبكة (“router”) والنقاط النهائية المجهولة (“destinations”) المرتبطة بالتطبيقات الفردية. حقيقة أن شخصاً ما يشغل I2P ليست سراً عادة. ما يتم إخفاؤه هو المعلومات حول ما يفعله المستخدم، إن كان يفعل شيئاً على الإطلاق، بالإضافة إلى أي router متصل بوجهة معينة. عادة ما يكون لدى المستخدمين النهائيين عدة destinations محلية على router الخاص بهم — على سبيل المثال، واحدة تعمل كوسيط للدخول إلى خوادم IRC، وأخرى تدعم الخادم الشبكي المجهول للمستخدم (“I2P Site”)، وأخرى لمثيل I2Phex، وأخرى للتورنت، إلخ.

مفهوم آخر بالغ الأهمية يجب فهمه هو “tunnel”. tunnel هو مسار موجه عبر قائمة محددة صراحة من routers. يُستخدم التشفير الطبقي، بحيث يمكن لكل router فك تشفير طبقة واحدة فقط. تحتوي المعلومات المفكوكة التشفير على عنوان IP للـ router التالي، مع المعلومات المشفرة التي يجب إعادة توجيهها. كل tunnel له نقطة بداية (أول router، والمعروف أيضاً باسم “gateway”) ونقطة نهاية. يمكن إرسال الرسائل في اتجاه واحد فقط. لإرسال الرسائل في الاتجاه المعاكس، يكون tunnel آخر مطلوباً.

يوجد نوعان من الـ tunnels: الـ “outbound” tunnels ترسل الرسائل بعيداً عن منشئ الـ tunnel، بينما الـ “inbound” tunnels تجلب الرسائل إلى منشئ الـ tunnel. دمج هذين النوعين من الـ tunnels يسمح للمستخدمين بإرسال الرسائل لبعضهم البعض. المرسل (“أليس” في الصورة أعلاه) ينشئ outbound tunnel، بينما المستقبل (“بوب” في الصورة أعلاه) ينشئ inbound tunnel. البوابة (gateway) الخاصة بـ inbound tunnel يمكنها استقبال الرسائل من أي مستخدم آخر وسترسلها حتى النقطة النهائية (endpoint) (“بوب”). النقطة النهائية للـ outbound tunnel ستحتاج لإرسال الرسالة إلى بوابة الـ inbound tunnel. للقيام بذلك، المرسل (“أليس”) يضيف تعليمات لرسالتها المشفرة. بمجرد أن تقوم النقطة النهائية للـ outbound tunnel بفك تشفير الرسالة، ستحصل على تعليمات لتوجيه الرسالة إلى البوابة الصحيحة للـ inbound (البوابة المؤدية إلى “بوب”).

المفهوم الحاسم الثالث الذي يجب فهمه هو “network database” (أو “netDb”) في I2P — وهو زوج من الخوارزميات المستخدمة لمشاركة البيانات الوصفية للشبكة. النوعان من البيانات الوصفية المحمولة هما “routerInfo” و “leaseSets” — فـ routerInfo يعطي الـ routers البيانات اللازمة للاتصال بـ router معين (مفاتيحهم العامة، عناوين النقل، إلخ)، بينما يعطي الـ leaseSet الـ routers المعلومات اللازمة للاتصال بوجهة معينة. يحتوي الـ leaseSet على عدد من “leases”. كل واحد من هذه الـ leases يحدد بوابة tunnel، مما يسمح بالوصول إلى وجهة محددة. المعلومات الكاملة الموجودة في الـ lease:

• البوابة الواردة لـ tunnel الذي يسمح بالوصول إلى وجهة محددة.
• الوقت الذي ينتهي فيه صلاحية tunnel.
• زوج من المفاتيح العامة لتتمكن من تشفير الرسائل (للإرسال عبر tunnel والوصول إلى الوجهة).

ترسل أجهزة router بنفسها معلومات routerInfo الخاصة بها إلى netDb مباشرة، بينما يتم إرسال leaseSets من خلال الأنفاق الصادرة (حيث يجب إرسال leaseSets بشكل مجهول لتجنب ربط جهاز router بـ leaseSets الخاصة به).

يمكننا دمج المفاهيم المذكورة أعلاه لبناء اتصالات ناجحة في الشبكة.

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

عندما تريد Alice إرسال رسالة إلى Bob، تقوم أولاً بالبحث في netDb للعثور على leaseSet الخاص بـ Bob، مما يعطيها بوابات tunnel الواردة الحالية الخاصة به. ثم تختار إحدى tunnels الصادرة الخاصة بها وترسل الرسالة عبرها مع تعليمات لنقطة نهاية tunnel الصادرة لتوجيه الرسالة إلى إحدى بوابات tunnel الواردة الخاصة بـ Bob. عندما تتلقى نقطة نهاية tunnel الصادرة تلك التعليمات، تقوم بتوجيه الرسالة كما هو مطلوب، وعندما تتلقاها بوابة tunnel الواردة الخاصة بـ Bob، يتم توجيهها عبر tunnel إلى router الخاص بـ Bob. إذا كانت Alice تريد أن يكون Bob قادراً على الرد على الرسالة، فهي بحاجة إلى نقل وجهتها الخاصة بشكل صريح كجزء من الرسالة نفسها. يمكن القيام بذلك من خلال إدخال طبقة أعلى مستوى، وهو ما يتم في مكتبة streaming . قد تقوم Alice أيضاً بتقليل وقت الاستجابة من خلال تجميع LeaseSet الأحدث الخاص بها مع الرسالة بحيث لا يحتاج Bob للقيام ببحث في netDb عندما يريد الرد، ولكن هذا اختياري.

بينما تحتوي الأنفاق نفسها على تشفير متعدد الطبقات لمنع الكشف غير المصرح به للأقران داخل الشبكة (كما يفعل طبقة النقل نفسها لمنع الكشف غير المصرح به للأقران خارج الشبكة)، من الضروري إضافة طبقة تشفير إضافية من النهاية إلى النهاية لإخفاء الرسالة من نقطة نهاية tunnel الصادر وبوابة tunnel الوارد. يتيح “garlic encryption ” هذا لـ router أليس أن يلف عدة رسائل في “رسالة garlic” واحدة، مشفرة لمفتاح عام معين بحيث لا يمكن للأقران الوسطاء تحديد عدد الرسائل داخل garlic، أو ما تقوله تلك الرسائل، أو إلى أين تتجه تلك الفصوص الفردية. للتواصل النموذجي من النهاية إلى النهاية بين أليس وبوب، سيتم تشفير garlic بالمفتاح العام المنشور في leaseSet بوب، مما يتيح تشفير الرسالة دون الكشف عن المفتاح العام لـ router بوب نفسه.

حقيقة مهمة أخرى يجب وضعها في الاعتبار هي أن I2P يعتمد بالكامل على الرسائل وأن بعض الرسائل قد تضيع في الطريق. يمكن للتطبيقات التي تستخدم I2P استخدام واجهات الرسائل والاهتمام باحتياجات التحكم في الازدحام والموثوقية الخاصة بها، ولكن معظمها ستكون أفضل خدمة من خلال إعادة استخدام مكتبة streaming المقدمة لعرض I2P كشبكة قائمة على التدفقات.

Tunnels

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

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

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

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

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

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

كما ذُكر من قبل، يتضمن I2P حالياً (الإصدار 0.8) الاستراتيجية العشوائية المتدرجة أعلاه، مع ترتيب قائم على XOR. يمكن العثور على مناقشة أكثر تفصيلاً لآليات العمل المتضمنة في تشغيل tunnel وإدارته واختيار النظراء في مواصفات tunnel .

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

كما ذُكر سابقاً، يعمل netDb الخاص بـ I2P على مشاركة البيانات الوصفية للشبكة. يتم تفصيل هذا في صفحة قاعدة بيانات الشبكة ، ولكن يتوفر شرح أساسي أدناه.

جميع routers الخاصة بـ I2P تحتوي على netDb محلية، لكن ليس جميع routers تشارك في DHT أو تستجيب لعمليات البحث عن leaseSet. تلك routers التي تشارك في DHT وتستجيب لعمليات البحث عن leaseSet تُسمى ‘floodfill’. يمكن تكوين routers يدوياً كـ floodfill، أو قد تصبح floodfill تلقائياً إذا كانت لديها سعة كافية وتستوفي معايير أخرى للتشغيل الموثوق.

ستقوم routers I2P الأخرى بتخزين بياناتها والبحث عن البيانات عن طريق إرسال استعلامات بسيطة ‘store’ و ’lookup’ إلى floodfills. إذا تلقى floodfill router استعلام ‘store’، فسيقوم بنشر المعلومات إلى floodfill routers أخرى باستخدام خوارزمية Kademlia . تعمل استعلامات ’lookup’ حالياً بشكل مختلف، لتجنب مشكلة أمنية مهمة. عند إجراء lookup، لن يقوم floodfill router بتمرير الـ lookup إلى أقران آخرين، ولكن سيجيب دائماً بنفسه (إذا كان يملك البيانات المطلوبة).

يتم تخزين نوعين من المعلومات في قاعدة بيانات الشبكة.

• RouterInfo يخزن معلومات حول router I2P محدد وكيفية الاتصال به
• LeaseSet يخزن معلومات حول وجهة محددة (مثل موقع I2P، خادم البريد الإلكتروني…)

جميع هذه المعلومات موقعة من قبل الطرف الناشر ومتحققة من قبل أي I2P router يستخدم أو يخزن المعلومات. بالإضافة إلى ذلك، تحتوي البيانات على معلومات توقيت، لتجنب تخزين الإدخالات القديمة والهجمات المحتملة. هذا هو السبب أيضًا في أن I2P يحتوي على الكود الضروري للحفاظ على الوقت الصحيح، حيث يستعلم أحيانًا بعض خوادم SNTP (مجموعة pool.ntp.org الدورية افتراضيًا) ويكتشف الانحراف بين الـ routers على طبقة النقل.

هناك أيضاً بعض الملاحظات الإضافية المهمة.

• leasesets غير منشورة ومشفرة: قد يرغب المرء في أن يتمكن أشخاص محددون فقط من الوصول إلى وجهة معينة. هذا ممكن عن طريق عدم نشر الوجهة في netDb. ومع ذلك، ستحتاج إلى نقل الوجهة بوسائل أخرى. هذا مدعوم بواسطة ’leaseSets المشفرة’. يمكن فك تشفير هذه leaseSets فقط من قبل الأشخاص الذين لديهم حق الوصول إلى مفتاح فك التشفير.

• Bootstrapping: إن عملية bootstrapping لـ netDb بسيطة جداً. بمجرد أن ينجح router في استقبال routerInfo واحد لنظير يمكن الوصول إليه، يمكنه الاستعلام من ذلك الـ router عن مراجع لـ routers أخرى في الشبكة. حالياً، يقوم عدد من المستخدمين بنشر ملفات routerInfo الخاصة بهم على موقع ويب لإتاحة هذه المعلومات. يتصل I2P تلقائياً بأحد هذه المواقع لجمع ملفات routerInfo والقيام بعملية bootstrap. يطلق I2P على عملية bootstrap هذه اسم “reseeding”.

• قابلية توسيع البحث: عمليات البحث في شبكة I2P تكرارية وليست تراجعية. إذا فشل البحث من floodfill، سيتم تكرار البحث إلى أقرب floodfill تالي. لا يطلب floodfill بشكل تراجعي من floodfill آخر للحصول على البيانات. عمليات البحث التكرارية قابلة للتوسع في شبكات DHT الكبيرة.

بروتوكولات النقل

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

يدعم I2P حاليًا بروتوكولي نقل، NTCP2 عبر TCP، و SSU2 عبر UDP. وقد حلت هذه البروتوكولات محل الإصدارات السابقة من البروتوكولات، NTCP و SSU ، والتي أصبحت الآن مهجورة. يدعم كلا البروتوكولين كل من IPv4 و IPv6. من خلال دعم نقل TCP و UDP، يمكن لـ I2P اختراق معظم جدران الحماية بشكل فعال، بما في ذلك تلك المصممة لحجب حركة المرور في أنظمة الرقابة التقييدية. تم تصميم NTCP2 و SSU2 لاستخدام معايير التشفير الحديثة، وتحسين مقاومة تحديد حركة المرور، وزيادة الكفاءة والأمان، وجعل اجتياز NAT أكثر قوة. تنشر routers كل بروتوكول نقل وعنوان IP مدعوم في netDb. عادة ما تنشر routers التي لديها وصول إلى شبكات IPv4 و IPv6 العامة أربعة عناوين، واحد لكل مجموعة من NTCP2/SSU2 مع IPv4/IPv6.

SSU2 يدعم ويوسع أهداف SSU. يحتوي SSU2 على العديد من أوجه التشابه مع البروتوكولات الحديثة الأخرى المعتمدة على UDP مثل Wireguard و QUIC. بالإضافة إلى النقل الموثوق لرسائل الشبكة عبر UDP، يوفر SSU2 تسهيلات متخصصة لكشف عناوين IP التعاونية من نظير إلى نظير، وكشف جدار الحماية، واجتياز NAT. كما هو موضح في مواصفات SSU :

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

NTCP2 يدعم ويوسع أهداف NTCP. يوفر نقل فعال ومشفر بالكامل لرسائل الشبكة عبر TCP، ومقاومة لتحديد هوية الحركة، باستخدام معايير التشفير الحديثة.

يدعم I2P عدة transports في وقت واحد. يتم اختيار transport معين للاتصال الصادر باستخدام “المناقصات”. كل transport يقدم مناقصة للاتصال والقيمة النسبية لهذه المناقصات تحدد الأولوية. قد ترد Transports بمناقصات مختلفة، اعتماداً على ما إذا كان هناك اتصال مُنشأ بالفعل مع النظير.

قيم المزايدة (الأولوية) تعتمد على التطبيق وقد تختلف بناءً على ظروف حركة المرور وأعداد الاتصالات وعوامل أخرى. كما ينشر الـ routers تفضيلاتهم للنقل للاتصالات الواردة في قاعدة بيانات الشبكة كـ “تكاليف” نقل لكل وسيلة نقل وعنوان.

التشفير

يستخدم I2P التشفير في عدة طبقات بروتوكول للتشفير والمصادقة والتحقق. طبقات البروتوكول الرئيسية هي: النقل، رسائل بناء tunnel، تشفير طبقة tunnel، رسائل قاعدة بيانات الشبكة، ورسائل من النهاية إلى النهاية (garlic). استخدم التصميم الأصلي لـ I2P مجموعة صغيرة من البدائيات التشفيرية التي كانت تعتبر آمنة في ذلك الوقت. شملت هذه التشفير غير المتماثل ElGamal، وتوقيعات DSA-SHA1، والتشفير المتماثل AES256/CBC، وخلاصات SHA-256. مع ازدياد القوة الحاسوبية المتاحة وتطور البحث التشفيري بشكل كبير على مر السنين، احتاج I2P إلى ترقية بدائياته وبروتوكولاته. لذلك، أضفنا مفهوم “أنواع التشفير” و"أنواع التوقيع"، ووسعنا بروتوكولاتنا لتشمل هذه المعرفات وتشير إلى الدعم. يتيح لنا هذا تحديث وتوسيع دعم الشبكة للتشفير الحديث بشكل دوري وحماية الشبكة للمستقبل للبدائيات الجديدة، دون كسر التوافق مع الإصدارات السابقة أو الحاجة إلى “يوم العلم” لتحديثات الشبكة. كما أن بعض أنواع التوقيع والتشفير محجوزة للاستخدام التجريبي.

البدائيات الحالية المستخدمة في معظم طبقات البروتوكول هي X25519 key exchange، وتوقيعات EdDSA، والتشفير المتماثل المصادق عليه ChaCha20/Poly1305، وخوارزميات التجميع SHA-256. لا يزال AES256 يُستخدم لتشفير طبقة tunnel. تُستخدم هذه البروتوكولات الحديثة للغالبية العظمى من الاتصالات الشبكية. البدائيات الأقدم بما في ذلك ElGamal و ECDSA و DSA-SHA1 تستمر في كونها مدعومة من معظم التطبيقات للتوافق مع الإصدارات السابقة عند التواصل مع أجهزة router الأقدم. بعض البروتوكولات القديمة تم إهمالها و/أو إزالتها بالكامل. في المستقبل القريب سنبدأ البحث حول الانتقال إلى التشفير والتوقيعات ما بعد الكمية (PQ) أو الهجينة-PQ للحفاظ على معايير الأمان القوية لدينا.

يتم دمج هذه العناصر الأساسية التشفيرية معًا لتوفير دفاعات I2P متعددة الطبقات ضد مجموعة متنوعة من الخصوم. في المستوى الأدنى، يتم حماية الاتصال بين أجهزة router من خلال أمان طبقة النقل. رسائل Tunnel التي تُمرر عبر وسائل النقل لها تشفير متعدد الطبقات خاص بها. يتم تمرير رسائل أخرى متنوعة داخل “garlic messages”، والتي تكون مُشفرة أيضًا.

رسائل Garlic

رسائل garlic هي امتداد للتشفير الطبقي “onion”، مما يسمح لمحتوى رسالة واحدة بأن تحتوي على عدة “cloves” — رسائل مكتملة التكوين إلى جانب تعليماتها الخاصة للتسليم. يتم تغليف الرسائل في رسالة garlic كلما كانت الرسالة ستمر بخلاف ذلك كنص واضح عبر نظير لا يجب أن يحصل على الوصول للمعلومات — على سبيل المثال، عندما يريد router أن يطلب من router آخر المشاركة في tunnel، فإنهم يغلفون الطلب داخل garlic، ويشفرون ذلك garlic بالمفتاح العام للـ router المستقبل، ويقومون بإرساله عبر tunnel. مثال آخر هو عندما يريد عميل إرسال رسالة إلى وجهة — فإن router المرسل سيغلف رسالة البيانات تلك (إلى جانب بعض الرسائل الأخرى) في garlic، ويشفر ذلك garlic بالمفتاح العام المنشور في leaseSet المستقبل، ويرسله عبر الـ tunnels المناسبة.

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

علامات الجلسة

كنظام غير موثوق وغير مرتب قائم على الرسائل، يستخدم I2P مزيجاً بسيطاً من خوارزميات التشفير المتماثلة وغير المتماثلة لتوفير سرية البيانات وسلامتها لرسائل garlic. المزيج الأصلي كان يُشار إليه باسم ElGamal/AES+SessionTags، لكن هذه طريقة مطولة بشكل مفرط لوصف الاستخدام البسيط لـ ElGamal بطول 2048 بت، وAES256، وSHA256، والـ nonces بطول 32 بايت. بينما لا يزال هذا البروتوكول مدعوماً، فقد هاجرت معظم الشبكة إلى بروتوكول جديد، ECIES-X25519-AEAD-Ratchet. يجمع هذا البروتوكول بين X25519، وChaCha20/Poly1305، ومولد أرقام عشوائية زائفة متزامن لتوليد nonces بطول 32 بايت. سيتم وصف كلا البروتوكولين بإيجاز أدناه.

ElGamal/AES+SessionTags

في المرة الأولى التي يريد فيها router تشفير رسالة garlic إلى router آخر، يقوم بتشفير مواد المفاتيح لمفتاح جلسة AES256 باستخدام ElGamal ويضيف الحمولة المشفرة بـ AES256/CBC بعد ذلك الكتلة المشفرة بـ ElGamal. بالإضافة إلى الحمولة المشفرة، يحتوي القسم المشفر بـ AES على طول الحمولة، وقيمة hash SHA256 للحمولة غير المشفرة، بالإضافة إلى عدد من “session tags” — وهي قيم nonce عشوائية بحجم 32 بايت. في المرة التالية التي يريد فيها المرسل تشفير رسالة garlic إلى router آخر، بدلاً من تشفير مفتاح جلسة جديد باستخدام ElGamal، يختار ببساطة أحد session tags المُرسلة مسبقاً ويشفر الحمولة بـ AES كما فعل من قبل، مستخدماً مفتاح الجلسة المستخدم مع ذلك session tag، مُسبقاً بـ session tag نفسه. عندما يستقبل router رسالة مشفرة بـ garlic encryption، يتحقق من الـ 32 بايت الأولى لمعرفة ما إذا كانت تطابق session tag متاح — إذا كانت كذلك، يقوم ببساطة بفك تشفير الرسالة باستخدام AES، ولكن إذا لم تكن كذلك، يقوم بفك التشفير باستخدام ElGamal للكتلة الأولى.

كل علامة جلسة يمكن استخدامها مرة واحدة فقط لمنع الخصوم الداخليين من ربط رسائل مختلفة بشكل غير ضروري كونها بين نفس الموجهات. مرسل الرسالة المشفرة بـ ElGamal/AES+SessionTag يختار متى وكم عدد العلامات التي سيتم تسليمها، مخزناً لدى المستقبل علامات كافية لتغطية دفعة من الرسائل. رسائل garlic قد تكتشف نجاح تسليم العلامة من خلال تجميع رسالة إضافية صغيرة كفص (رسالة “حالة التسليم”) — عندما تصل رسالة garlic إلى المستقبل المقصود ويتم فك تشفيرها بنجاح، فإن رسالة حالة التسليم الصغيرة هذه تكون أحد الفصوص المكشوفة وتحتوي على تعليمات للمستقبل لإرسال الفص إلى المرسل الأصلي (عبر tunnel داخلي، بالطبع). عندما يتلقى المرسل الأصلي رسالة حالة التسليم هذه، يعلم أن علامات الجلسة المجمعة في رسالة garlic تم تسليمها بنجاح.

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

ECIES-X25519-AEAD-Ratchet

تطلب ElGamal/AES+SessionTags عبئاً إضافياً كبيراً بعدة طرق. كان استخدام وحدة المعالجة المركزية مرتفعاً لأن ElGamal بطيء جداً. كان استهلاك النطاق الترددي مفرطاً بسبب الحاجة لتسليم أعداد كبيرة من session tags مسبقاً، ولأن المفاتيح العامة لـ ElGamal كبيرة جداً. كان استخدام الذاكرة مرتفعاً بسبب متطلبات تخزين كميات كبيرة من session tags. تأثرت الموثوقية بسبب فقدان تسليم session tags.

تم تصميم ECIES-X25519-AEAD-Ratchet لمعالجة هذه المشاكل. يُستخدم X25519 لتبادل المفاتيح. يُستخدم ChaCha20/Poly1305 للتشفير المتماثل المُصادق عليه. يتم “تدوير مزدوج” أو تدوير مفاتيح التشفير بشكل دوري. تم تقليل علامات الجلسة من 32 بايت إلى 8 بايت ويتم توليدها باستخدام PRNG. يحتوي البروتوكول على أوجه تشابه كثيرة مع بروتوكول signal المستخدم في Signal و WhatsApp. يوفر هذا البروتوكول انخفاضاً كبيراً في استهلاك المعالج والذاكرة وعرض النطاق الترددي.

يتم إنشاء علامات الجلسة من مولد أرقام عشوائي زائف متزامن ومحدد يعمل في كلا طرفي الجلسة لإنشاء علامات الجلسة ومفاتيح الجلسة. مولد الأرقام العشوائي الزائف هو HKDF يستخدم SHA-256 HMAC، ويتم إعداده من نتيجة X25519 DH. لا يتم إرسال علامات الجلسة مسبقاً أبداً؛ بل يتم تضمينها فقط مع الرسالة. يحتفظ المستقبل بعدد محدود من مفاتيح الجلسة، مفهرسة بواسطة علامة الجلسة. لا يحتاج المرسل إلى تخزين أي علامات جلسة أو مفاتيح لأنها لا يتم إرسالها مسبقاً؛ يمكن إنشاؤها عند الطلب. من خلال الحفاظ على هذا مولد الأرقام العشوائي الزائف متزامناً تقريباً بين المرسل والمستقبل (يقوم المستقبل بحساب مسبق لنافذة من العلامات التالية مثل 50 علامة)، يتم إزالة العبء الإضافي لتجميع عدد كبير من العلامات بشكل دوري.

المستقبل

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

تشغيل المسار المقيد

I2P هي شبكة تراكبية مصممة للعمل فوق شبكة تبديل حزم وظيفية، مستغلة مبدأ النهاية إلى النهاية لتوفير إخفاء الهوية والأمان. بينما لم تعد الإنترنت تتبنى بالكامل مبدأ النهاية إلى النهاية (بسبب استخدام NAT)، فإن I2P تتطلب أن يكون جزء كبير من الشبكة قابلاً للوصول — قد يكون هناك عدد من الأقران على الحواف يعملون باستخدام مسارات مقيدة، لكن I2P لا تتضمن خوارزمية توجيه مناسبة للحالة المتدهورة حيث معظم الأقران غير قابلين للوصول. ومع ذلك، يمكن أن تعمل فوق شبكة تستخدم مثل هذه الخوارزمية.

تشغيل المسارات المقيدة، حيث توجد قيود على النظراء التي يمكن الوصول إليها مباشرة، له عدة تداعيات وظيفية ومتعلقة بإخفاء الهوية مختلفة، تعتمد على كيفية التعامل مع المسارات المقيدة. على أبسط مستوى، تنشأ المسارات المقيدة عندما يكون النظير خلف NAT أو جدار حماية لا يسمح بالاتصالات الواردة. تم التعامل مع هذا إلى حد كبير من خلال دمج تقنية distributed hole punching في طبقة النقل، مما يسمح للأشخاص خلف معظم NATs وجدران الحماية بتلقي اتصالات غير مطلوبة دون أي تكوين. ومع ذلك، هذا لا يحد من تعرض عنوان IP الخاص بالنظير لـ routers داخل الشبكة، حيث يمكنها ببساطة التعرف على النظير من خلال المُقدِم المنشور.

بالإضافة إلى المعالجة الوظيفية للمسارات المقيدة، هناك مستويان من العمليات المقيدة يمكن استخدامهما للحد من تعرض عنوان IP الخاص بالمستخدم — استخدام tunnels خاصة بـ router معين للتواصل، وتقديم ‘client routers’. بالنسبة للأول، يمكن للـ routers إما بناء مجموعة جديدة من tunnels أو إعادة استخدام مجموعة الاستكشاف الخاصة بهم، ونشر البوابات الداخلة لبعضها كجزء من routerInfo الخاص بهم بدلاً من عناوين النقل الخاصة بهم. عندما يريد peer التواصل معهم، يرى تلك بوابات tunnel في netDb ويرسل ببساطة الرسالة ذات الصلة إليهم من خلال أحد tunnels المنشورة. إذا أراد peer خلف المسار المقيد الرد، فقد يفعل ذلك إما مباشرة (إذا كان مستعداً لكشف IP الخاص به للـ peer) أو بشكل غير مباشر من خلال tunnels الصادرة الخاصة به. عندما تريد routers التي لديها اتصالات مباشرة مع peer الوصول إليه (لتوجيه رسائل tunnel، على سبيل المثال)، فإنها تعطي الأولوية ببساطة لاتصالها المباشر على بوابة tunnel المنشورة. مفهوم ‘client routers’ يوسع ببساطة المسار المقيد بعدم نشر أي عناوين router. مثل هذا router لن يحتاج حتى إلى نشر routerInfo الخاص به في netDb، مجرد توفير routerInfo الموقع ذاتياً للـ peers التي يتصل بها (ضروري لتمرير المفاتيح العامة للـ router).

هناك مقايضات للذين يقعون خلف المسارات المقيدة، حيث من المحتمل أن يشاركوا في أنفاق الآخرين بشكل أقل تكراراً، وستكون أجهزة router التي يتصلون بها قادرة على استنتاج أنماط حركة البيانات التي لن تكون مكشوفة بطريقة أخرى. من ناحية أخرى، إذا كانت تكلفة هذا الكشف أقل من تكلفة إتاحة عنوان IP، فقد يكون الأمر يستحق العناء. هذا، بطبيعة الحال، يفترض أن النظراء الذين يتصل بهم router الموجود خلف مسار مقيد ليسوا معاديين — إما أن تكون الشبكة كبيرة بما فيه الكفاية بحيث يكون احتمال استخدام نظير معادٍ للاتصال صغيراً بما فيه الكفاية، أو يتم استخدام نظراء موثوقين (وربما مؤقتين) بدلاً من ذلك.

المسارات المقيدة معقدة، وقد تم التخلي عن الهدف العام إلى حد كبير. عدة تحسينات ذات صلة قللت بشكل كبير من الحاجة إليها. نحن ندعم الآن UPnP لفتح منافذ الجدار الناري تلقائياً. ندعم كلاً من IPv4 و IPv6. حسّن SSU2 اكتشاف العناوين وتحديد حالة الجدار الناري وثقب NAT التعاوني. SSU2 و NTCP2 وفحوصات توافق العناوين تضمن أن قفزات tunnel يمكنها الاتصال قبل بناء tunnel. GeoIP وتحديد الهوية القطرية يتيح لنا تجنب النظراء في البلدان ذات الجدران النارية المقيدة. تحسن الدعم لـ router المخفية خلف تلك الجدران النارية. بعض التطبيقات تدعم أيضاً الاتصالات بالنظراء على الشبكات المتراكبة مثل Yggdrasil.

زمن الاستجابة المتغير

على الرغم من أن معظم الجهود الأولية لـ I2P كانت مركزة على الاتصالات منخفضة زمن التأخير، فقد تم تصميمه منذ البداية مع وضع خدمات زمن التأخير المتغير في الاعتبار. على المستوى الأساسي، يمكن للتطبيقات التي تعمل على I2P أن تقدم إخفاء الهوية للاتصالات متوسطة وعالية زمن التأخير بينما لا تزال تدمج أنماط حركة المرور الخاصة بها مع حركة المرور منخفضة زمن التأخير. داخلياً مع ذلك، يمكن لـ I2P أن يقدم اتصالات متوسطة وعالية زمن التأخير الخاصة به من خلال garlic encryption - عبر تحديد أن الرسالة يجب إرسالها بعد تأخير معين، في وقت معين، بعد مرور عدد معين من الرسائل، أو استراتيجية خلط أخرى. مع التشفير الطبقي، فقط الـ router الذي كشف clove طلب التأخير سيعرف أن الرسالة تتطلب زمن تأخير عالي، مما يسمح لحركة المرور بالاندماج أكثر مع حركة المرور منخفضة زمن التأخير. بمجرد استيفاء شرط الإرسال المسبق، يقوم الـ router الذي يحتفظ بالـ clove (والذي من المحتمل أن يكون نفسه رسالة garlic) بتوجيهها ببساطة كما هو مطلوب - إلى router، إلى tunnel، أو، على الأرجح، إلى وجهة عميل بعيدة.

هدف خدمات الكمون المتغير يتطلب موارد كبيرة لآليات التخزين والإرسال لدعمه. هذه الآليات يمكن دعمها وتُدعم فعلاً في تطبيقات المراسلة المختلفة، مثل i2p-bote. على مستوى الشبكة، الشبكات البديلة مثل Freenet توفر هذه الخدمات. لقد قررنا عدم السعي وراء هذا الهدف على مستوى router الخاص بـ I2P.

أنظمة مشابهة

تعتمد بنية I2P على مفاهيم البرمجيات الوسيطة الموجهة للرسائل، وطوبولوجيا جداول التجزئة الموزعة (DHTs)، وإخفاء الهوية والتشفير لشبكات المزج ذات المسارات الحرة، وقابلية التكيف لشبكات تبديل الحزم. القيمة لا تأتي من مفاهيم أو خوارزميات جديدة، بل من الهندسة الدقيقة التي تجمع نتائج البحث من الأنظمة والأوراق البحثية الموجودة. بينما هناك بضعة جهود مماثلة تستحق المراجعة، سواء للمقارنات التقنية أو الوظيفية، يتم تسليط الضوء على اثنين منها بشكل خاص هنا — Tor و Freenet.

انظر أيضاً صفحة مقارنات الشبكة . لاحظ أن هذه الأوصاف كتبها jrandom في عام 2003 وقد لا تكون دقيقة حالياً.

Tor

موقع الويب

للوهلة الأولى، يبدو أن Tor و I2P لديهما العديد من أوجه التشابه الوظيفية والمتعلقة بإخفاء الهوية. بينما بدأ تطوير I2P قبل أن نكون على علم بالجهود المبكرة لـ Tor، تم دمج العديد من دروس جهود onion routing الأصلية و ZKS في تصميم I2P. بدلاً من بناء نظام موثوق ومركزي بشكل أساسي مع directory servers، يمتلك I2P شبكة قاعدة بيانات ذاتية التنظيم حيث يتولى كل peer مسؤولية تحليل routers الأخرى لتحديد أفضل طريقة لاستغلال الموارد المتاحة. الاختلاف الرئيسي الآخر هو أنه بينما يستخدم كل من I2P و Tor مسارات طبقية ومرتبة (tunnels و circuits/streams)، فإن I2P هو شبكة packet switched بشكل أساسي، بينما Tor هو شبكة circuit switched بشكل أساسي، مما يسمح لـ I2P بالتوجيه الشفاف حول الازدحام أو فشل الشبكة الأخرى، وتشغيل مسارات متكررة، وتوزيع الحمولة عبر الموارد المتاحة. بينما يوفر Tor وظيفة outproxy المفيدة من خلال توفير اكتشاف واختيار outproxy متكامل، يترك I2P مثل هذه القرارات على طبقة التطبيق للتطبيقات التي تعمل فوق I2P — في الواقع، لقد أخرج I2P حتى مكتبة streaming الشبيهة بـ TCP نفسها إلى طبقة التطبيق، مما يسمح للمطورين بتجربة استراتيجيات مختلفة، واستغلال معرفتهم الخاصة بالمجال لتقديم أداء أفضل.

من منظور إخفاء الهوية، هناك تشابه كبير عند مقارنة الشبكات الأساسية. ومع ذلك، هناك بعض الاختلافات الرئيسية. عند التعامل مع خصم داخلي أو معظم الخصوم الخارجيين، فإن أنفاق simplex الخاصة بـ I2P تكشف نصف كمية بيانات الحركة مقارنة بما قد تكشفه دوائر duplex الخاصة بـ Tor من خلال النظر إلى التدفقات نفسها ببساطة — طلب HTTP والاستجابة سيتبعان نفس المسار في Tor، بينما في I2P ستخرج الحزم التي تشكل الطلب عبر نفق أو أكثر من أنفاق outbound وستعود الحزم التي تشكل الاستجابة عبر نفق أو أكثر من أنفاق inbound مختلفة. بينما يجب أن تتعامل استراتيجيات اختيار وترتيب النظراء في I2P بشكل كافٍ مع هجمات السلف، إذا كان التحول إلى أنفاق ثنائية الاتجاه ضرورياً، يمكننا ببساطة بناء نفق inbound و outbound على نفس أجهزة router.

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

بشكل عام، يكمل Tor و I2P بعضهما البعض في تركيزهما — يعمل Tor على توفير وكيل إنترنت خارجي مجهول عالي السرعة، بينما يعمل I2P على توفير شبكة لامركزية مرنة في حد ذاتها. من الناحية النظرية، يمكن استخدام كليهما لتحقيق كلا الغرضين، ولكن نظراً لمحدودية موارد التطوير، لكل منهما نقاط قوة وضعف. لقد درس مطوروا I2P الخطوات اللازمة لتعديل Tor للاستفادة من تصميم I2P، ولكن المخاوف حول قابلية Tor للعمل في ظل ندرة الموارد تشير إلى أن معمارية تبديل الحزم في I2P ستكون قادرة على استغلال الموارد الشحيحة بفعالية أكبر.

Freenet

الموقع الإلكتروني

لعبت Freenet دورًا كبيرًا في المراحل الأولى من تصميم I2P — حيث قدمت دليلاً على قابلية مجتمع مستعار نشط محتوى بالكامل داخل الشبكة، مما أثبت أن المخاطر الكامنة في outproxies يمكن تجنبها. بدأت البذرة الأولى لـ I2P كطبقة اتصال بديلة لـ Freenet، في محاولة لفصل تعقيدات التواصل القابل للتوسع والمجهول والآمن من نقطة إلى نقطة عن تعقيدات مخزن البيانات الموزع المقاوم للرقابة. مع مرور الوقت، جعلت بعض مسائل إخفاء الهوية وقابلية التوسع الكامنة في خوارزميات Freenet من الواضح أن تركيز I2P يجب أن يبقى بدقة على توفير طبقة اتصال مجهولة عامة، بدلاً من أن يكون مكونًا في Freenet. على مر السنين، أدرك مطورو Freenet نقاط الضعف في التصميم الأقدم، مما دفعهم لاقتراح أنهم سيحتاجون إلى طبقة “premix” لتقديم إخفاء هوية كبير. بعبارة أخرى، تحتاج Freenet للعمل فوق mixnet مثل I2P أو Tor، مع “عقد العميل” التي تطلب وتنشر البيانات من خلال mixnet إلى “عقد الخادم” التي تجلب وتخزن البيانات وفقًا لخوارزميات تخزين البيانات الموزعة الاستكشافية الخاصة بـ Freenet.

وظائف Freenet تكمل وظائف I2P بشكل كبير، حيث يوفر Freenet بشكل أصلي العديد من الأدوات لتشغيل الأنظمة متوسطة وعالية زمن الاستجابة، بينما يوفر I2P بشكل أصلي شبكة الخلط منخفضة زمن الاستجابة المناسبة لتوفير إخفاء هوية كافٍ. منطق فصل mixnet عن مخزن البيانات الموزع المقاوم للرقابة لا يزال يبدو واضحاً من ناحية الهندسة وإخفاء الهوية والأمان وتخصيص الموارد، لذا نأمل أن يواصل فريق Freenet الجهود في هذا الاتجاه، إن لم يكن ببساطة إعادة استخدام (أو المساعدة في تحسين، حسب الضرورة) mixnets الموجودة مثل I2P أو Tor.

الملحق أ: طبقة التطبيق

I2P نفسه لا يقوم بالكثير في الواقع — إنه ببساطة يرسل الرسائل إلى الوجهات البعيدة ويستقبل الرسائل المستهدفة للوجهات المحلية — معظم العمل المثير للاهتمام يحدث في الطبقات الموجودة فوقه. بحد ذاته، يمكن النظر إلى I2P كطبقة IP مجهولة وآمنة، ومكتبة streaming المرفقة كتطبيق لطبقة TCP مجهولة وآمنة فوقها. وبعد ذلك، يعرض I2PTunnel نظام وكيل TCP عام إما للدخول إلى شبكة I2P أو الخروج منها، بالإضافة إلى مجموعة متنوعة من تطبيقات الشبكة التي توفر وظائف إضافية للمستخدمين النهائيين.

مكتبة البث

يمكن النظر إلى مكتبة streaming الخاصة بـ I2P كواجهة streaming عامة (تحاكي TCP sockets)، والتنفيذ يدعم بروتوكول النافذة المنزلقة مع عدة تحسينات، لأخذ التأخير العالي عبر I2P في الاعتبار. قد تقوم التدفقات الفردية بتعديل الحد الأقصى لحجم الحزمة وخيارات أخرى، رغم أن الافتراضي وهو 4KB مضغوط يبدو توازناً معقولاً بين تكاليف عرض النطاق الترددي لإعادة إرسال الرسائل المفقودة وزمن الاستجابة للرسائل المتعددة.

بالإضافة إلى ذلك، مع مراعاة التكلفة العالية نسبياً للرسائل اللاحقة، تم تحسين بروتوكول مكتبة الـ streaming لجدولة وتسليم الرسائل للسماح للرسائل الفردية الممررة بأن تحتوي على أكبر قدر ممكن من المعلومات المتاحة. على سبيل المثال، يمكن إكمال معاملة HTTP صغيرة تم توجيهها عبر مكتبة الـ streaming في رحلة ذهاب وإياب واحدة — تجمع الرسالة الأولى SYN و FIN والحمولة الصغيرة (طلب HTTP عادة ما يناسب) والرد يجمع SYN و FIN و ACK والحمولة الصغيرة (العديد من ردود HTTP تناسب). بينما يجب إرسال ACK إضافي لإخبار خادم HTTP أنه تم استلام SYN/FIN/ACK، يمكن لـ proxy HTTP المحلي تسليم الاستجابة الكاملة إلى المتصفح فوراً.

بشكل عام، تتشابه مكتبة البث (streaming library) إلى حد كبير مع تجريد لبروتوكول TCP، مع نوافذها المنزلقة وخوارزميات التحكم في الازدحام (كل من البدء البطيء وتجنب الازدحام)، وسلوك الحزم العام (ACK، SYN، FIN، RST، إلخ).

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

لمزيد من المعلومات راجع صفحة التسمية ودفتر العناوين .

طُوّر من قِبل: mihi، Ragnarok

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

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

نمط التسمية بالتصويت خطير أيضاً، خاصة بالنظر إلى فعالية هجمات Sybil في الأنظمة المجهولة — حيث يمكن للمهاجم ببساطة إنشاء عدد عالٍ تعسفياً من النظراء و"التصويت" مع كل منهم للاستيلاء على اسم معين. يمكن استخدام طرق proof-of-work لجعل الهوية غير مجانية، ولكن مع نمو الشبكة فإن الحمولة المطلوبة للاتصال بالجميع لإجراء التصويت عبر الإنترنت غير قابلة للتطبيق، أو إذا لم يتم الاستعلام عن الشبكة الكاملة، فقد تكون مجموعات مختلفة من الإجابات قابلة للوصول.

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

I2PTunnel

طُوّر بواسطة: mihi

I2PTunnel هو على الأرجح تطبيق العميل الأكثر شعبية وتنوعاً في I2P، والذي يتيح الوكالة العامة للدخول إلى شبكة I2P والخروج منها. يمكن النظر إلى I2PTunnel كأربعة تطبيقات وكالة منفصلة — “client” الذي يستقبل اتصالات TCP الواردة ويوجهها إلى وجهة I2P محددة، و “httpclient” (المعروف أيضاً باسم “eepproxy”) الذي يعمل كوكيل HTTP ويوجه الطلبات إلى وجهة I2P المناسبة (بعد الاستعلام من خدمة التسمية إذا لزم الأمر)، و “server” الذي يستقبل اتصالات I2P streaming الواردة على وجهة معينة ويوجهها إلى مضيف+منفذ TCP محدد، و “httpserver” الذي يوسع “server” من خلال تحليل طلبات واستجابات HTTP للسماح بتشغيل أكثر أماناً. يوجد تطبيق إضافي “socksclient”، لكن استخدامه غير مُشجع للأسباب المذكورة سابقاً.

I2P نفسها ليست شبكة outproxy — مخاوف إخفاء الهوية والأمان الكامنة في شبكة مزج تقوم بإعادة توجيه البيانات إلى داخل وخارج المزج جعلت تصميم I2P مركزًا على توفير شبكة مجهولة قادرة على تلبية احتياجات المستخدم دون الحاجة إلى موارد خارجية. ومع ذلك، فإن تطبيق I2PTunnel “httpclient” يوفر خطافًا لـ outproxying — إذا كان اسم المضيف المطلوب لا ينتهي بـ “.i2p”، فإنه يختار وجهة عشوائية من مجموعة outproxies مقدمة من المستخدم ويعيد توجيه الطلب إليها. هذه الوجهات هي ببساطة حالات I2PTunnel “server” يديرها متطوعون اختاروا صراحة تشغيل outproxies — لا أحد يعتبر outproxy افتراضيًا، وتشغيل outproxy لا يخبر الآخرين تلقائيًا بالتوكيل من خلالك. بينما تحتوي outproxies على نقاط ضعف كامنة، إلا أنها تقدم إثباتًا بسيطًا للمفهوم لاستخدام I2P وتوفر بعض الوظائف في إطار نموذج تهديد قد يكون كافيًا لبعض المستخدمين.

I2PTunnel يُمكّن معظم التطبيقات المستخدمة. “httpserver” يشير إلى خادم ويب يتيح لأي شخص تشغيل موقعه الإلكتروني المجهول الخاص به (أو “موقع I2P”) — خادم ويب مُدمج مع I2P لهذا الغرض، لكن يمكن استخدام أي خادم ويب. يمكن لأي شخص تشغيل “client” يشير إلى أحد خوادم IRC المستضافة بشكل مجهول، كل منها يشغل “server” يشير إلى IRCd المحلي الخاص به ويتواصل بين IRCds عبر أنفاق “client” الخاصة بها. المستخدمون النهائيون لديهم أيضاً أنفاق “client” تشير إلى وجهات POP3 و SMTP الخاصة بـ I2Pmail (والتي هي ببساطة مثيلات “server” تشير إلى خوادم POP3 و SMTP)، بالإضافة إلى أنفاق “client” تشير إلى خادم CVS الخاص بـ I2P، مما يتيح التطوير المجهول. أحياناً يشغل الناس حتى وكلاء “client” للوصول إلى مثيلات “server” التي تشير إلى خادم NNTP.

I2PSnark

I2PSnark تم تطويره من قبل: jrandom وآخرين، منقول من عميل Snark الخاص بـ mjw

مُرفق مع تثبيت I2P، يوفر I2PSnark عميل BitTorrent مجهول بسيط مع إمكانيات متعددة التورنت، يعرض جميع الوظائف من خلال واجهة ويب HTML بسيطة.

I2Pmail / Susimail

تم التطوير بواسطة: postman، susi23، mastiejaner

I2Pmail هو أكثر خدمة من كونه تطبيقاً — يوفر postman البريد الإلكتروني الداخلي والخارجي مع خدمة POP3 و SMTP من خلال I2PTunnel instances التي تصل إلى سلسلة من المكونات المطورة مع mastiejaner، مما يتيح للأشخاص استخدام عملاء البريد المفضلين لديهم لإرسال واستقبال البريد بشكل مستعار. ومع ذلك، نظراً لأن معظم عملاء البريد تكشف معلومات تعريفية كبيرة، يحزم I2P عميل susimail الويب الخاص بـ susi23 والذي تم بناؤه خصيصاً مع وضع احتياجات إخفاء الهوية في I2P في الاعتبار. تقدم خدمة I2Pmail/mail.i2p تصفية فيروسات شفافة بالإضافة إلى منع هجمات رفض الخدمة مع حصص معززة بـ hashcash. بالإضافة إلى ذلك، يتحكم كل مستخدم في استراتيجية التجميع الخاصة به قبل التسليم من خلال outproxies الخاصة بـ mail.i2p، والتي تكون منفصلة عن خوادم SMTP و POP3 الخاصة بـ mail.i2p — كلٌ من outproxies و inproxies يتواصل مع خوادم SMTP و POP3 الخاصة بـ mail.i2p من خلال I2P نفسه، لذا فإن اختراق تلك المواقع غير المجهولة لا يعطي الوصول إلى حسابات البريد أو أنماط النشاط الخاصة بالمستخدم.