نظرة عامة
يغطي هذا الاقتراح تحسينين لتحسين أداء الشبكة:
تفويض اختيار IBGW إلى OBEP من خلال تزويده بقائمة من البدائل بدلاً من خيار واحد فقط.
تمكين توجيه الحزم متعددة البث (multicast) في OBEP.
الدوافع
في حالة الاتصال المباشر، الفكرة هي تقليل ازدحام الاتصال، من خلال منح OBEP مرونة في كيفية اتصاله بـ IBGWs. القدرة على تحديد نفق متعدد تمكننا أيضًا من تنفيذ البث المتعدد في OBEP (من خلال توصيل الرسالة إلى جميع الأنفاق المحددة).
بديل للجزء المتعلق بالتفويض في هذا الاقتراح هو إرسال عبر تجزئة LeaseSet، مشابهًا للقدرة الحالية على تحديد هوية الراوتر المستهدف RouterIdentity . سيؤدي هذا إلى رسالة أصغر وربما LeaseSet أحدث. ولكن:
سيُجبر OBEP على إجراء بحث.
قد لا يتم نشر LeaseSet إلى خادم floodfill، وبالتالي سيفشل البحث.
قد يكون LeaseSet مشفرًا، وبالتالي لا يستطيع OBEP الحصول على العقود الإيجارية (leases).
تحديد LeaseSet يكشف لـ OBEP الوجهة الخاصة بالرسالة، والتي لا يمكنه اكتشافها بخلاف ذلك إلا من خلال فحص جميع LeaseSets في الشبكة والبحث عن تطابق في العقدة (Lease).
التصميم
سيضع المُرسِل (OBGW) بعض (أو كل) عقود Leases الوجهة في تعليمات التسليم TUNNEL-DELIVERY بدلًا من اختيار واحدة فقط.
سيختار OBEP واحدة من هذه العقود للتسليم إليها. سيختار OBEP، إن أمكن، واحدة يكون متصلًا بها بالفعل أو يعرفها مسبقًا. هذا سيجعل المسار بين OBEP و IBGW أسرع وأكثر موثوقية، ويقلل من إجمالي الاتصالات في الشبكة.
لدينا نوع تسليم غير مستخدم (0x03) ونقطتان متبقيتان (0 و 1) في علمات TUNNEL-DELIVERY، يمكننا الاستفادة منهما لتنفيذ هذه الميزات.
الآثار الأمنية
هذا الاقتراح لا يغير كمية المعلومات المُسربة حول وجهة OBGW أو رؤيته لقاعدة البيانات الشبكية (NetDB):
المهاجم الذي يتحكم في OBEP ويقوم بجمع LeaseSets من NetDB يمكنه بالفعل تحديد ما إذا كانت رسالة تُرسل إلى وجهة معينة، من خلال البحث عن زوج TunnelId / RouterIdentity. في أسوأ الأحوال، وجود عقود إيجارية متعددة في TMDI قد يجعل العثور على تطابق في قاعدة بيانات المهاجم أسرع.
المهاجم الذي يدير وجهة خبيثة يمكنه بالفعل الحصول على معلومات حول رؤية الضحية للـ NetDB، من خلال نشر LeaseSets تحتوي على أنفاق دخول مختلفة إلى floodfills مختلفة، ومراقبة الأنفاق التي يتصل من خلالها OBGW. من وجهة نظرهم، اختيار OBEP للنفق المستخدم مماثل وظيفيًا لاختيار OBGW للنفق.
علم البث المتعدد (multicast flag) يُسرب حقيقة أن OBGW يقوم بالبث المتعدد إلى OBEPs. هذا يخلق مفاضلة بين الأداء والخصوصية يجب أخذها بعين الاعتبار عند تنفيذ بروتوكولات المستوى الأعلى. وبما أن العلم اختياري، يمكن للمستخدمين اتخاذ القرار المناسب لتطبيقهم. قد يكون هناك فوائد لجعل هذا السلوك الافتراضي للتطبيقات المتوافقة، لأن الاستخدام الواسع من قبل مجموعة متنوعة من التطبيقات سيقلل من تسرب المعلومات حول التطبيق المحدد الذي أتت منه الرسالة.
المواصفات
سيتم تعديل تعليمات تسليم الجزء الأول (First Fragment Delivery Instructions) على النحو التالي:
+----+----+----+----+----+----+----+----+
|flag| Tunnel ID (opt) | |
+----+----+----+----+----+ +
| |
+ +
| To Hash (optional) |
+ +
| |
+ +----+----+----+
| |dly | Message
+----+----+----+----+----+----+----+----+
ID (opt) |extended opts (opt)|cnt | (o)
+----+----+----+----+----+----+----+----+
Tunnel ID N | |
+----+----+----+ +
| |
+ +
| To Hash N (optional) |
+ +
| |
+ +----+----+----+----+----+
| | Tunnel ID N+1 (o) | |
+----+----+----+----+----+----+----+ +
| |
+ +
| To Hash N+1 (optional) |
+ +
| |
+ +----+
| | sz
+----+----+----+----+----+----+----+----+
|
+----+
flag ::
1 بايت
ترتيب البتات: 76543210
البتات 6-5: نوع التسليم
0x03 = TUNNELS
البت 0: بث متعدد؟ إذا كان 0، قم بالتسليم إلى أحد الأنفاق
إذا كان 1، قم بالتسليم إلى جميع الأنفاق
يجب تعيينه إلى 0 للتوافق مع الاستخدامات المستقبلية إذا
كان نوع التسليم ليس TUNNELS
Count ::
1 بايت
اختياري، موجود إذا كان نوع التسليم هو TUNNELS
2-255 - عدد أزواج المعرف/التجزئة التي تلي
Tunnel ID :: TunnelId
To Hash ::
36 بايت لكل منها
اختياري، موجود إذا كان نوع التسليم هو TUNNELS
أزواج المعرف/التجزئة
الطول الكلي: الطول النموذجي هو:
75 بايت لتسليم TUNNELS بعدد 2 (رسالة نفق غير مجزأة);
79 بايت لتسليم TUNNELS بعدد 2 (الجزء الأول)
بقية تعليمات التسليم دون تغيير
التوافق
النُد الوحيدة التي تحتاج إلى فهم المواصفات الجديدة هي OBGWs و OBEPs. وبالتالي يمكننا جعل هذا التغيير متوافقًا مع الشبكة الحالية من خلال جعل استخدامه مشروطًا بإصدار I2P الهدف:
يجب على OBGWs اختيار OBEPs متوافقة عند بناء أنفاق صادرة، بناءً على إصدار I2P المعلن في RouterInfo .
يجب أن تدعم النُد التي تعلن عن الإصدار الهدف تحليل الأعلام الجديدة، وألا ترفض التعليمات باعتبارها غير صالحة.