I2P: إطار عمل قابل للتوسع للتواصل المجهول

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

مقدمة

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

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

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

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

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

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

التشغيل

نظرة عامة

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

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

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

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

• بوابة داخلة لـ 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 عنها عندما يريد الرد، لكن هذا اختياري.

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

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

Tunnels

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

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

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

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

باستخدام بيانات الملف الشخصي هذه، فإن أبسط استراتيجية معقولة لاختيار الأقران هي اختيار الأقران عشوائياً من المستوى الأعلى (سريع وعالي السعة)، وهذا مُطبق حالياً لأنفاق العملاء. الأنفاق الاستكشافية (المستخدمة لإدارة netDb والأنفاق) تختار الأقران عشوائياً من مستوى “غير الفاشل” (والذي يتضمن أيضاً routers في مستويات “أفضل”)، مما يسمح للقرين بأخذ عينات من routers على نطاق أوسع، مما يحسن بشكل فعال اختيار الأقران من خلال hill climbing العشوائي. هذه الاستراتيجيات وحدها تسرب معلومات حول الأقران في المستوى الأعلى للـ 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 تُسمى ‘floodfills’. يمكن تكوين routers كـ floodfills يدوياً، أو تصبح floodfill تلقائياً إذا كانت لديها سعة كافية وتلبي معايير أخرى للتشغيل الموثوق.

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

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

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

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

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

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

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

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

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

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

يدعم I2P حاليًا بروتوكولي نقل، NTCP2 عبر TCP، و SSU2 عبر UDP. لقد حلت هذه البروتوكولات محل الإصدارات السابقة من البروتوكولات، NTCP و SSU ، والتي أصبحت الآن مهجورة. كلا البروتوكولين يدعمان IPv4 و IPv6. من خلال دعم كل من نقل TCP و UDP، يستطيع I2P اجتياز معظم جدران الحماية بشكل فعال، بما في ذلك تلك المخصصة لحجب حركة البيانات في أنظمة الرقابة المقيدة. تم تصميم NTCP2 و SSU2 لاستخدام معايير التشفير الحديثة، وتحسين مقاومة تحديد حركة البيانات، وزيادة الكفاءة والأمان، وجعل اجتياز NAT أكثر قوة. تنشر router كل وسائل النقل المدعومة وعناوين IP في قاعدة بيانات الشبكة. عادةً ما تنشر router التي لديها وصول إلى شبكات 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 بمزايدات مختلفة، اعتماداً على ما إذا كان هناك اتصال مُنشأ بالفعل مع النظير.

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

علم التشفير

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

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

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

رسائل Garlic

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

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

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

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

ElGamal/AES+SessionTags

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

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

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

ECIES-X25519-AEAD-Ratchet

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

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

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

المستقبل

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

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

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

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

بالإضافة إلى التعامل الوظيفي مع المسارات المقيدة، هناك مستويان من العمليات المقيدة يمكن استخدامهما للحد من تعرض عنوان 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).

هناك مقايضات لأولئك الذين يقفون خلف المسارات المقيدة، حيث من المحتمل أن يشاركوا في tunnels الأشخاص الآخرين بشكل أقل تكراراً، والـ routers التي يتصلون بها ستكون قادرة على استنتاج أنماط حركة البيانات التي لن تكون مكشوفة بخلاف ذلك. من ناحية أخرى، إذا كانت تكلفة هذا الكشف أقل من تكلفة توفير عنوان 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 هذه الخدمات. لقد قررنا عدم السعي وراء هذا الهدف على مستوى I2P router.

أنظمة مشابهة

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

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

Tor

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

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

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

تنشأ قضية أخرى تتعلق بإخفاء الهوية في استخدام Tor لإنشاء tunnel تلسكوبي، حيث أن عد الحزم البسيط وقياسات التوقيت عندما تمر الخلايا في الدائرة عبر عقدة الخصم تكشف معلومات إحصائية حول موقع الخصم داخل الدائرة. يستخدم 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 الجهود في ذلك الاتجاه، إن لم يكن ببساطة إعادة استخدام (أو المساعدة في التحسين، حسب الضرورة) شبكات mixnet الموجودة مثل I2P أو Tor.

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

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

مكتبة البث

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

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

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

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

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

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

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

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

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

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

I2PSnark

I2PSnark طُور من قبل: jrandom وآخرين، مُحوّل من عميل Snark لـ mjw

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

I2Pmail / Susimail

طُور بواسطة: postman، susi23، mastiejaner

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