ملاحظة: تحتوي هذه الوثيقة على معلومات قديمة حول البدائل للتطبيق الحالي للـ tunnel في I2P، وتكهنات حول الإمكانيات المستقبلية. للحصول على المعلومات الحالية انظر صفحة الـ tunnel .
تلك الصفحة توثق التنفيذ الحالي لبناء tunnel كما هو في الإصدار 0.6.1.10. طريقة بناء tunnel الأقدم، المستخدمة قبل الإصدار 0.6.1.10، موثقة في صفحة tunnel القديمة .
بدائل التكوين
بالإضافة إلى طولها، قد تكون هناك معاملات إضافية قابلة للتكوين لكل tunnel يمكن استخدامها، مثل تحكم في تردد الرسائل المرسلة، وكيفية استخدام الحشو، وكم من الوقت يجب أن يكون tunnel في حالة تشغيل، وما إذا كان يجب حقن رسائل وهمية، وما هي استراتيجيات المجمعة، إن وجدت، التي يجب استخدامها. لا يتم تنفيذ أي من هذه الميزات حالياً.
بدائل الحشو
عدة استراتيجيات لحشو tunnel ممكنة، كل منها لها مزاياها الخاصة:
- بدون حشو
- حشو إلى حجم عشوائي
- حشو إلى حجم ثابت
- حشو إلى أقرب كيلوبايت
- حشو إلى أقرب حجم أسي (2^n بايت)
يمكن استخدام استراتيجيات الحشو هذه على مستويات متنوعة، للتعامل مع تعرض معلومات حجم الرسائل لخصوم مختلفين. بعد جمع ومراجعة بعض الإحصائيات من شبكة 0.4، بالإضافة إلى استكشاف المقايضات المتعلقة بعدم الكشف عن الهوية، نبدأ بحجم ثابت لرسائل tunnel يبلغ 1024 بايت. ومع ذلك، داخل هذا الحجم، الرسائل المجزأة نفسها لا يتم حشوها بواسطة tunnel على الإطلاق (رغم أنه بالنسبة للرسائل من طرف إلى طرف، قد يتم حشوها كجزء من garlic wrapping).
بدائل التجزئة
لمنع الخصوم من وضع علامات على الرسائل على طول المسار عن طريق تعديل حجم الرسائل، جميع رسائل tunnel لها حجم ثابت قدره 1024 بايت. لاستيعاب رسائل I2NP الأكبر وكذلك لدعم الرسائل الأصغر بكفاءة أكبر، يقوم gateway بتقسيم رسائل I2NP الأكبر إلى أجزاء موجودة داخل كل رسالة tunnel. سيحاول endpoint إعادة بناء رسالة I2NP من الأجزاء لفترة قصيرة من الوقت، لكنه سيتخلص منها عند الضرورة.
تتمتع أجهزة router بمرونة كبيرة في كيفية ترتيب الأجزاء، سواء تم حشوها بشكل غير فعال كوحدات منفصلة، أو تجميعها لفترة وجيزة لتناسب المزيد من البيانات في رسائل tunnel البالغ حجمها 1024 بايت، أو حشوها انتهازياً برسائل أخرى أراد البوابة إرسالها.
المزيد من البدائل
تعديل معالجة Tunnel في منتصف المسار
بينما يجب أن تكون خوارزمية توجيه tunnel البسيطة كافية لمعظم الحالات، هناك ثلاثة بدائل يمكن استكشافها:
- جعل نظير آخر غير نقطة النهاية يعمل مؤقتاً كنقطة إنهاء للـ tunnel من خلال تعديل التشفير المستخدم في البوابة لإعطائهم النص الواضح لرسائل I2NP المعالجة مسبقاً. يمكن لكل نظير التحقق مما إذا كان لديهم النص الواضح، ومعالجة الرسالة عند استلامها كما لو كانت لديهم.
- السماح للـ routers المشاركة في tunnel بإعادة مزج الرسالة قبل إعادة توجيهها - ارتدادها عبر أحد tunnels الصادرة الخاصة بذلك النظير، حاملة تعليمات للتسليم إلى القفزة التالية.
- تنفيذ كود لمنشئ tunnel لإعادة تعريف “القفزة التالية” للنظير في tunnel، مما يسمح بإعادة توجيه ديناميكية إضافية.
استخدام الأنفاق ثنائية الاتجاه
الاستراتيجية الحالية لاستخدام نفقين منفصلين للاتصال الداخل والخارج ليست التقنية الوحيدة المتاحة، ولها تداعيات على إخفاء الهوية. من الناحية الإيجابية، باستخدام tunnels منفصلة فإنها تقلل من بيانات حركة البيانات المكشوفة للتحليل للمشاركين في tunnel - على سبيل المثال، الأقران في tunnel خارج من متصفح ويب سيرون فقط حركة بيانات HTTP GET، بينما الأقران في tunnel الداخل سيرون الحمولة المرسلة عبر tunnel. مع tunnels ثنائية الاتجاه، سيكون لدى جميع المشاركين إمكانية الوصول إلى حقيقة أنه تم إرسال 1KB في اتجاه واحد مثلاً، ثم 100KB في الاتجاه الآخر. من الناحية السلبية، استخدام tunnels أحادية الاتجاه يعني أن هناك مجموعتين من الأقران التي تحتاج إلى تحليل شخصي ومحاسبة، ويجب اتخاذ عناية إضافية لمعالجة السرعة المتزايدة لهجمات المتقدم. عملية تجميع وبناء tunnel المحددة أدناه يجب أن تقلل من مخاوف هجوم المتقدم، رغم أنه إذا كان مرغوباً، فلن تكون مشكلة كبيرة لبناء tunnels الداخل والخارج على نفس الأقران.
التواصل عبر القناة الخلفية
في الوقت الحالي، قيم IV المستخدمة هي قيم عشوائية. ومع ذلك، من الممكن استخدام تلك القيمة المكونة من 16 بايت لإرسال رسائل تحكم من gateway إلى endpoint، أو في الأنفاق الصادرة، من gateway إلى أي من النظراء. يمكن لـ inbound gateway أن يقوم بترميز قيم معينة في IV مرة واحدة، والتي سيتمكن endpoint من استرجاعها (نظراً لأنه يعلم أن endpoint هو أيضاً المُنشئ). بالنسبة للأنفاق الصادرة، يمكن للمُنشئ تسليم قيم معينة للمشاركين أثناء إنشاء tunnel (مثل “إذا رأيت 0x0 كـ IV، فهذا يعني X”، “0x1 يعني Y”، إلخ). نظراً لأن gateway في outbound tunnel هو أيضاً المُنشئ، يمكنهم بناء IV بحيث يتلقى أي من النظراء القيمة الصحيحة. يمكن لمُنشئ tunnel حتى إعطاء inbound tunnel gateway سلسلة من قيم IV التي يمكن لذلك gateway استخدامها للتواصل مع المشاركين الفرديين مرة واحدة تماماً (رغم أن هذا سيكون له مشاكل فيما يتعلق بكشف التواطؤ).
يمكن استخدام هذه التقنية لاحقًا لتسليم الرسائل في منتصف التدفق، أو للسماح لـ gateway الوارد بإخبار النقطة النهائية بأنها تتعرض لهجوم DoS أو أنها ستفشل قريبًا لأسباب أخرى. في الوقت الحالي، لا توجد خطط لاستغلال هذه القناة الخلفية.
رسائل tunnel متغيرة الحجم
بينما قد يكون لطبقة النقل حجم رسائل ثابت أو متغير خاص بها، باستخدام تجزئتها الخاصة، قد تستخدم طبقة tunnel بدلاً من ذلك رسائل tunnel متغيرة الحجم. الفرق هو مسألة نماذج التهديد - الحجم الثابت في طبقة النقل يساعد في تقليل المعلومات المكشوفة للخصوم الخارجيين (رغم أن تحليل التدفق العام ما زال يعمل)، ولكن بالنسبة للخصوم الداخليين (أي مشاركي tunnel) فإن حجم الرسالة يكون مكشوفاً. رسائل tunnel ثابتة الحجم تساعد في تقليل المعلومات المكشوفة لمشاركي tunnel، ولكنها لا تخفي المعلومات المكشوفة لنقاط نهاية tunnel والبوابات. الرسائل ثابتة الحجم من النهاية إلى النهاية تخفي المعلومات المكشوفة لجميع النظراء في الشبكة.
كما هو الحال دائماً، إنها مسألة تحديد من يحاول I2P حمايته. رسائل tunnel بأحجام متغيرة خطيرة، حيث تسمح للمشاركين باستخدام حجم الرسالة نفسه كقناة خلفية للمشاركين الآخرين - على سبيل المثال، إذا رأيت رسالة بحجم 1337 بايت، فأنت على نفس tunnel مع نظير متواطئ آخر. حتى مع مجموعة ثابتة من الأحجام المسموحة (1024، 2048، 4096، إلخ)، فإن تلك القناة الخلفية لا تزال موجودة حيث يمكن للأنظار استخدام تكرار كل حجم كحامل (مثلاً رسالتان بحجم 1024 بايت متبوعتان برسالة 8192). الرسائل الأصغر تتكبد عبء الرؤوس (IV، tunnel ID، جزء hash، إلخ)، لكن الرسائل الأكبر ذات الحجم الثابت إما تزيد زمن الاستجابة (بسبب التجميع) أو تزيد العبء بشكل كبير (بسبب الحشو). التجزئة تساعد في توزيع العبء، مقابل احتمالية فقدان الرسالة بسبب فقدان الأجزاء.
هجمات التوقيت ذات صلة أيضاً عند مراجعة فعالية الرسائل ذات الحجم الثابت، رغم أنها تتطلب رؤية شاملة لأنماط نشاط الشبكة لتكون فعالة. سيتم اكتشاف التأخير الاصطناعي المفرط في tunnel من قبل منشئ tunnel، بسبب الاختبار الدوري، مما يؤدي إلى إلغاء tunnel بأكمله وتعديل ملفات التعريف للنظراء داخله.
بناء البدائل
المرجع: Hashing it out in Public
طريقة بناء tunnel القديمة
طريقة بناء tunnel القديمة، المستخدمة قبل الإصدار 0.6.1.10، موثقة في صفحة tunnel القديمة . كانت هذه طريقة “الكل في وقت واحد” أو “متوازية”، حيث كانت الرسائل ترسل بشكل متوازي إلى كل من المشاركين.
البناء التلسكوبي أحادي الطلقة
ملاحظة: هذه هي الطريقة الحالية.
إحدى الأسئلة التي نشأت بخصوص استخدام tunnels الاستكشافية لإرسال واستقبال رسائل إنشاء tunnel هي كيف يؤثر ذلك على قابلية tunnel للتعرض لهجمات المتقدم. بينما ستكون نقاط النهاية والبوابات لتلك tunnels موزعة عشوائياً عبر الشبكة (ربما حتى تتضمن منشئ tunnel في تلك المجموعة)، هناك بديل آخر وهو استخدام مسارات tunnel نفسها لتمرير الطلب والاستجابة، كما يتم في Tor . هذا، مع ذلك، قد يؤدي إلى تسريبات أثناء إنشاء tunnel، مما يسمح للأقران باكتشاف عدد القفزات الموجودة لاحقاً في tunnel من خلال مراقبة التوقيت أو عدد الحزم أثناء بناء tunnel.
البناء التلسكوبي “التفاعلي”
بناء القفزات (hops) واحدة تلو الأخرى مع رسالة عبر الجزء الموجود من النفق لكل منها. لديه مشاكل كبيرة حيث يمكن للأقران عد الرسائل لتحديد موقعهم في النفق.
tunnels غير الاستكشافية للإدارة
البديل الثاني لعملية بناء tunnel هو إعطاء router مجموعة إضافية من pools الواردة والصادرة غير الاستكشافية، واستخدامها لطلب tunnel والاستجابة. بافتراض أن router لديه رؤية متكاملة للشبكة، فإن هذا لا يجب أن يكون ضرورياً، ولكن إذا تم تقسيم router بطريقة ما، فإن استخدام pools غير استكشافية لإدارة tunnel سيقلل من تسرب المعلومات حول الأقران الموجودين في قسم router.
تسليم الطلب الاستكشافي
البديل الثالث، المستخدم حتى I2P 0.6.1.10، يشفر رسائل طلب tunnel الفردية باستخدام garlic encryption ويوصلها إلى النقاط بشكل منفرد، وينقلها عبر tunnels استكشافية مع عودة الرد في tunnel استكشافي منفصل. تم التخلي عن هذه الاستراتيجية لصالح الاستراتيجية الموضحة أعلاه.
المزيد من التاريخ والنقاش
قبل إدخال رسالة البناء المتغيرة للنفق، كانت هناك مشكلتان على الأقل:
- حجم الرسائل (الناجم عن الحد الأقصى 8 قفزات، بينما الطول النموذجي للـ tunnel هو 2 أو 3 قفزات… والبحوث الحالية تشير إلى أن أكثر من 3 قفزات لا يعزز إخفاء الهوية)؛
- معدل فشل البناء العالي، خاصة للـ tunnels الطويلة (والاستكشافية)، لأن جميع القفزات يجب أن توافق وإلا يتم التخلص من الـ tunnel.
قام VTBM بإصلاح #1 وتحسين #2.
اقترح Welterde تعديلات على الطريقة المتوازية للسماح بإعادة التكوين. اقترح Sponge استخدام ‘رموز مميزة’ من نوع ما.
يجب على أي طلاب لبناء الـ tunnel دراسة السجل التاريخي المؤدي إلى الطريقة الحالية، خاصة نقاط الضعف المختلفة في إخفاء الهوية التي قد توجد في طرق مختلفة. أرشيف البريد من أكتوبر 2005 مفيد بشكل خاص. كما هو مذكور في مواصفات إنشاء الـ tunnel ، جاءت الاستراتيجية الحالية خلال نقاش في قائمة I2P البريدية بين مايكل روجرز، وماثيو توسلاند (toad), وjrandom بخصوص هجوم الـ predecessor.
بدائل ترتيب الأقران
ترتيب أقل صرامة ممكن أيضاً، مما يضمن أنه بينما قد يكون القفز بعد A هو B، فإن B لا يمكن أن يكون أبداً قبل A. خيارات التكوين الأخرى تشمل القدرة على تثبيت بوابات tunnel الداخلة ونقاط نهاية tunnel الخارجة فقط، أو تدويرها بمعدل MTBF.
الخلط/التجميع
ما هي الاستراتيجيات التي يجب استخدامها في gateway وعند كل hop لتأخير أو إعادة ترتيب أو إعادة توجيه أو حشو الرسائل؟ إلى أي مدى يجب أن يتم هذا تلقائياً، وكم يجب تكوينه كإعداد لكل tunnel أو لكل hop، وكيف يجب على منشئ tunnel (وبالتالي المستخدم) التحكم في هذه العملية؟ كل هذا يبقى مجهولاً، ليتم حله في إصدار مستقبلي.