Garlic Routing

Garlic Routing ومصطلحات “Garlic”

غالباً ما تُستخدم مصطلحات “garlic routing” و “garlic encryption” بشكل فضفاض عند الإشارة إلى تقنية I2P. هنا، نوضح تاريخ هذه المصطلحات ومعانيها المختلفة واستخدام طرق “garlic” في I2P.

تم صياغة مصطلح “Garlic routing” لأول مرة من قِبل Michael J. Freedman في رسالة الماجستير الخاصة بـ Roger Dingledine في Free Haven، القسم 8.1.1 (يونيو 2000)، كمشتق من Onion Routing .

قد يكون مطورو I2P استخدموا مصطلح “garlic” في الأصل لأن I2P ينفذ شكلاً من أشكال التجميع كما يصف فريدمان، أو ببساطة للتأكيد على الاختلافات العامة عن Tor. قد يكون السبب المحدد قد ضاع في التاريخ. عموماً، عند الإشارة إلى I2P، قد يعني مصطلح “garlic” واحداً من ثلاثة أشياء:

1. التشفير الطبقي
2. تجميع رسائل متعددة معاً
3. تشفير ElGamal/AES

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

التشفير الطبقي

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

هذا مشابه للطريقة التي يرسل بها Mixmaster الرسائل (راجع مقارنات الشبكات ) - أخذ رسالة، وتشفيرها بالمفتاح العام للمستقبل، ثم أخذ تلك الرسالة المشفرة وتشفيرها (مع التعليمات التي تحدد القفزة التالية)، ثم أخذ تلك الرسالة المشفرة الناتجة وهكذا، حتى تصبح هناك طبقة تشفير واحدة لكل قفزة على طول المسار.

في هذا المعنى، “garlic routing” كمفهوم عام مطابق لـ “onion routing”. كما هو مُطبق في I2P، بالطبع، هناك عدة اختلافات عن التطبيق في Tor؛ انظر أدناه. ومع ذلك، هناك تشابهات جوهرية بحيث يستفيد I2P من كمية كبيرة من البحوث الأكاديمية حول onion routing ، Tor، وmixnets مماثلة .

تجميع رسائل متعددة

عرّف مايكل فريدمان “garlic routing” كامتداد لـ onion routing، حيث يتم تجميع رسائل متعددة معاً. أطلق على كل رسالة اسم “bulb”. جميع الرسائل، كل منها بتعليمات التسليم الخاصة بها، يتم كشفها في نقطة النهاية. هذا يسمح بالتجميع الفعال لـ “reply block” الخاص بـ onion routing مع الرسالة الأصلية.

هذا المفهوم مُطبق في I2P، كما هو موضح أدناه. مصطلحنا لـ garlic “bulbs” هو “cloves”. يمكن أن تحتوي على أي عدد من الرسائل، بدلاً من رسالة واحدة فقط. هذا تمييز مهم عن onion routing المُطبق في Tor. ومع ذلك، إنه واحد فقط من العديد من الاختلافات المعمارية الرئيسية بين I2P و Tor؛ ربما لا يكون، بحد ذاته، كافياً لتبرير تغيير في المصطلحات.

اختلاف آخر عن الطريقة التي وصفها فريدمان هو أن المسار أحادي الاتجاه - لا توجد “نقطة عطف” كما هو موجود في onion routing أو mixmaster reply blocks، مما يبسط الخوارزمية بشكل كبير ويسمح بتسليم أكثر مرونة وموثوقية.

تشفير ElGamal/AES

في بعض الحالات، قد يعني “garlic encryption” ببساطة تشفير ElGamal/AES+SessionTag (بدون طبقات متعددة).

طرق “Garlic” في I2P

الآن بعد أن عرّفنا مصطلحات “garlic” المختلفة، يمكننا القول أن I2P يستخدم garlic routing والتجميع والتشفير في ثلاثة أماكن:

1. لبناء وتوجيه المرور عبر tunnels (التشفير الطبقي)
2. لتحديد نجاح أو فشل تسليم الرسائل من النهاية للنهاية (التجميع)
3. لنشر بعض إدخالات قاعدة بيانات الشبكة (تقليل احتمالية نجاح هجمات تحليل حركة المرور) (ElGamal/AES)

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

بناء وتوجيه الأنفاق (Tunnel Building and Routing)

في I2P، تكون الـ tunnels أحادية الاتجاه. كل طرف ينشئ نفقين، واحد للحركة الصادرة وآخر للحركة الواردة. لذلك، مطلوب أربعة أنفاق لرسالة واحدة ذهاب وإياب مع الرد.

يتم بناء الأنفاق (tunnels) واستخدامها مع التشفير متعدد الطبقات. هذا موصوف في صفحة تنفيذ الأنفاق . نحن نستخدم ElGamal/AES+SessionTag للتشفير.

tunnels هي آلية عامة الغرض لنقل جميع رسائل I2NP ، ولا تُستخدم رسائل Garlic لبناء tunnels. نحن لا نجمع رسائل I2NP متعددة في رسالة Garlic واحدة لفكها في نقطة نهاية tunnel الصادرة؛ تشفير tunnel كافٍ.

تجميع الرسائل من النهاية إلى النهاية

في الطبقة الموجودة فوق tunnels، يقوم I2P بتسليم الرسائل من طرف إلى طرف بين Destinations . تماماً كما هو الحال داخل tunnel واحد، نستخدم ElGamal/AES+SessionTag للتشفير. كل رسالة عميل يتم تسليمها إلى router عبر واجهة I2CP تصبح Garlic Clove واحدة مع تعليمات التسليم الخاصة بها، داخل Garlic Message. قد تحدد تعليمات التسليم Destination أو Router أو Tunnel.

بشكل عام، ستحتوي رسالة Garlic Message على clove واحد فقط. ومع ذلك، سيقوم الـ router بشكل دوري بتجميع clove إضافيين في رسالة Garlic Message:

1. رسالة حالة التسليم، مع تعليمات التسليم التي تحدد أن يتم إرسالها مرة أخرى إلى router المصدر كإقرار استلام. هذا مشابه لـ “reply block” أو “reply onion” الموصوف في المراجع. يُستخدم لتحديد نجاح أو فشل تسليم الرسائل من طرف إلى طرف. قد يقوم router المصدر، عند فشل استلام رسالة حالة التسليم خلال الفترة الزمنية المتوقعة، بتعديل التوجيه إلى الوجهة البعيدة، أو اتخاذ إجراءات أخرى.

2. رسالة تخزين قاعدة بيانات، تحتوي على LeaseSet للوجهة المُرسِلة، مع تعليمات التسليم التي تحدد router الوجهة البعيدة. من خلال تجميع LeaseSet بشكل دوري، يضمن الـ router أن الطرف البعيد سيكون قادراً على الحفاظ على الاتصالات. وإلا فإن الطرف البعيد سيضطر إلى الاستعلام من router floodfill عن إدخال قاعدة بيانات الشبكة، وسيتعين نشر جميع LeaseSets إلى قاعدة بيانات الشبكة، كما هو موضح في صفحة قاعدة بيانات الشبكة .

افتراضياً، يتم تجميع رسائل حالة التسليم وتخزين قاعدة البيانات عند تغيير LeaseSet المحلي، أو عند تسليم Session Tags إضافية، أو إذا لم يتم تجميع الرسائل في الدقيقة السابقة.

من الواضح أن الرسائل الإضافية مجمعة حالياً لأغراض محددة، وليست جزءاً من نظام توجيه عام الغرض.

اعتباراً من الإصدار 0.9.12، يتم تغليف رسالة حالة التسليم في رسالة Garlic Message أخرى من قبل المرسل الأصلي بحيث يتم تشفير المحتويات وتصبح غير مرئية للموجهات على مسار الإرجاع.

التخزين إلى قاعدة بيانات شبكة Floodfill

كما هو موضح في صفحة قاعدة بيانات الشبكة ، يتم إرسال leaseSet المحلية إلى floodfill routers في رسالة Database Store Message ملفوفة في رسالة Garlic Message بحيث لا تكون مرئية لبوابة tunnel الصادرة.

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

آلية رسائل Garlic مرنة جداً وتوفر هيكلاً لتنفيذ أنواع متعددة من طرق التسليم في الشبكات المختلطة (mixnet). مع خيار التأخير غير المستخدم في تعليمات التسليم لرسائل النفق، يصبح من الممكن تطبيق طيف واسع من استراتيجيات التجميع والتأخير والخلط والتوجيه.

على وجه الخصوص، هناك إمكانية لمرونة أكبر بكثير عند نقطة نهاية tunnel الصادر. يمكن توجيه الرسائل من هناك إلى واحد من عدة tunnels (وبالتالي تقليل الاتصالات من نقطة إلى نقطة)، أو البث المتعدد إلى عدة tunnels للتكرار، أو بث الصوت والفيديو.

قد تتعارض مثل هذه التجارب مع الحاجة لضمان الأمان وإخفاء الهوية، مثل تقييد مسارات توجيه معينة، وتقييد أنواع رسائل I2NP التي يمكن توجيهها عبر مسارات مختلفة، وفرض أوقات انتهاء صلاحية معينة للرسائل.

كجزء من تشفير ElGamal/AES، تحتوي رسالة garlic على كمية محددة من المرسل من بيانات الحشو، مما يسمح للمرسل باتخاذ تدابير مضادة فعالة ضد تحليل حركة البيانات. هذا غير مستخدم حالياً، باستثناء متطلب الحشو إلى مضاعف من 16 بايت.

تشفير الرسائل الإضافية من وإلى floodfill routers .

المراجع

• مصطلح garlic routing تم صياغته لأول مرة في رسالة الماجستير لروجر دينجليدين في Free Haven (يونيو 2000)، انظر القسم 8.1.1 من تأليف Michael J. Freedman .
• منشورات Onion Router
• Onion Routing (ويكيبيديا)
• Garlic Routing (ويكيبيديا)
• مشروع Tor
• Free Haven Anonbib
• تم وصف Onion routing لأول مرة في إخفاء معلومات التوجيه من قبل David M. Goldschlag وMichael G. Reed وPaul F. Syverson في عام 1996.