ملاحظة
نشر الشبكة واختبارها قيد التقدم. خاضع لتعديلات طفيفة.
نظرة عامة
ملخص
تقلل ECIES تكلفة الرسائل في الجلسة الحالية (ES) بحوالي 90 بايت. وبالتالي يمكننا زيادة MTU بحوالي 90 بايت للاتصالات التي تستخدم ECIES. انظر مواصفات ECIES ، ومواصفات البث ، وتوثيق واجهة برمجة تطبيقات البث .
بدون زيادة MTU، في كثير من الحالات لن تكون وفورات التكلفة “موفرة فعليًا”، لأن الرسائل ستُملأ لتستخدم رسالتي نفق كاملتين على أي حال.
هذا الاقتراح لا يتطلب أي تغيير في المواصفات. تم نشره كاقتراح فقط لتيسير المناقشة وبناء توافق في الآراء حول القيمة الموصى بها وتفاصيل التنفيذ.
الأهداف
- زيادة MTU المتفاوض عليه
- تعظيم استخدام رسائل النفق بحجم 1 كيلوبايت
- عدم تغيير بروتوكول البث
التصميم
استخدم الخيار الموجود مسبقًا MAX_PACKET_SIZE_INCLUDED وتفاوض MTU. يستمر البث في استخدام الحد الأدنى من MTU المرسل والمستلم. تبقى القيمة الافتراضية 1730 لجميع الاتصالات، بغض النظر عن نوع المفاتيح المستخدمة.
يشجع على تضمين الخيار MAX_PACKET_SIZE_INCLUDED في جميع حزم SYN، في كلا الاتجاهين، رغم أن ذلك ليس إلزاميًا.
إذا كان الوجهة تستخدم ECIES فقط، استخدم القيمة الأعلى (سواء كـ Alice أو Bob). إذا كانت الوجهة تستخدم مفتاحين (dual-key)، فقد يختلف السلوك:
إذا كان العميل ذو المفتاح المزدوج خارج الراوتر (في تطبيق خارجي)، فقد لا “يعرف” نوع المفتاح المستخدم في الطرف البعيد، وقد تطلب Alice قيمة أعلى في حزمة SYN، بينما تبقى الحد الأقصى للبيانات في حزمة SYN عند 1730.
إذا كان العميل ذو المفتاح المزدوج داخليًا في الراوتر، فقد تكون معلومة نوع المفتاح المستخدم معروفة أو غير معروفة للعميل. ربما لم تُجلب قائمة العقود (leaseset) بعد، أو أن واجهات واجهة برمجة التطبيقات الداخلية قد لا تُتيح هذه المعلومة بسهولة للعميل. إذا كانت المعلومة متاحة، يمكن لـ Alice استخدام القيمة الأعلى؛ وإلا، يجب على Alice استخدام القيمة القياسية 1730 حتى يتم التفاوض.
قد يرسل العميل ذو المفتاح المزدوج كـ Bob قيمة أعلى في الرد، حتى لو لم تستلم Alice أي قيمة أو استلمت قيمة 1730 من Alice؛ مع ذلك، لا توجد آلية للتفاوض على زيادة MTU في بروتوكول البث، لذلك يجب أن يبقى MTU عند 1730.
كما هو مذكور في توثيق واجهة برمجة تطبيقات البث ، قد تتجاوز البيانات في حزم SYN المرسلة من Alice إلى Bob قيمة MTU الخاصة بـ Bob. وهذا يُعد نقطة ضعف في بروتوكول البث. لذلك، يجب على العملاء ذوي المفتاح المزدوج تقييد البيانات في حزم SYN المرسلة بـ 1730 بايت، مع إرسال خيار MTU أعلى. بمجرد استلام MTU الأعلى من Bob، يمكن لـ Alice زيادة الحمولة الفعلية القصوى المرسلة.
التحليل
كما هو موضح في مواصفات ECIES ، فإن تكلفة ElGamal للرسائل الحالية (ES) هي 151 بايت، وتكلفة Ratchet هي 69 بايت. وبالتالي، يمكننا زيادة MTU للاتصالات التي تستخدم Ratchet بمقدار (151 - 69) = 82 بايت، من 1730 إلى 1812.
المواصفات
أضف التغييرات والتوضيحات التالية إلى قسم اختيار وتفاوض MTU في توثيق واجهة برمجة تطبيقات البث . لا تغييرات على مواصفات البث .
تبقى القيمة الافتراضية للخيار i2p.streaming.maxMessageSize عند 1730 لجميع الاتصالات، بغض النظر عن نوع المفاتيح المستخدمة. يجب على العملاء استخدام الحد الأدنى من MTU المرسل والمستلم، كما هو معتاد.
توجد أربع ثوابت ومتغيرات MTU مرتبطة:
- DEFAULT_MTU: 1730، بدون تغيير، لجميع الاتصالات
- i2cp.streaming.maxMessageSize: افتراضيًا 1730 أو 1812، يمكن تغييره بالتكوين
- ALICE_SYN_MAX_DATA: الحد الأقصى للبيانات التي يمكن لـ Alice تضمينها في حزمة SYN
- negotiated_mtu: الحد الأدنى من MTU الخاص بـ Alice وBob، ويُستخدم كحد أقصى لحجم البيانات في حزمة SYN ACK من Bob إلى Alice، وفي جميع الحزم اللاحقة المرسلة في كلا الاتجاهين
توجد خمس حالات يجب أخذها بعين الاعتبار:
1) Alice تستخدم ElGamal فقط
لا تغيير، MTU 1730 في جميع الحزم.
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize الافتراضي: 1730
- يمكن لـ Alice إرسال MAX_PACKET_SIZE_INCLUDED في حزمة SYN، غير مطلوب إلا إذا كانت != 1730
2) Alice تستخدم ECIES فقط
MTU 1812 في جميع الحزم.
- ALICE_SYN_MAX_DATA = 1812
- i2cp.streaming.maxMessageSize الافتراضي: 1812
- يجب على Alice إرسال MAX_PACKET_SIZE_INCLUDED في حزمة SYN
3) Alice تستخدم مفتاحين وتعرف أن Bob يستخدم ElGamal
MTU 1730 في جميع الحزم.
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize الافتراضي: 1812
- يمكن لـ Alice إرسال MAX_PACKET_SIZE_INCLUDED في حزمة SYN، غير مطلوب إلا إذا كانت != 1730
4) Alice تستخدم مفتاحين وتعرف أن Bob يستخدم ECIES
MTU 1812 في جميع الحزم.
- ALICE_SYN_MAX_DATA = 1812
- i2cp.streaming.maxMessageSize الافتراضي: 1812
- يجب على Alice إرسال MAX_PACKET_SIZE_INCLUDED في حزمة SYN
5) Alice تستخدم مفتاحين ومفتاح Bob غير معروف
أرسل 1812 كقيمة MAX_PACKET_SIZE_INCLUDED في حزمة SYN ولكن قيّد بيانات حزمة SYN بـ 1730.
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize الافتراضي: 1812
- يجب على Alice إرسال MAX_PACKET_SIZE_INCLUDED في حزمة SYN
لجميع الحالات
تحسب Alice وBob negotiated_mtu، وهو الحد الأدنى من MTU الخاص بـ Alice وBob، ويُستخدم كحد أقصى لحجم البيانات في حزمة SYN ACK من Bob إلى Alice، وفي جميع الحزم اللاحقة المرسلة في كلا الاتجاهين.
التبرير
انظر كود Java I2P المصدر لمعرفة السبب في أن القيمة الحالية هي 1730. انظر مواصفات ECIES لمعرفة السبب في أن تكلفة ECIES أقل بـ 82 بايت من ElGamal.
ملاحظات التنفيذ
إذا كان البث ينشئ رسائل بحجم مثالي، فمن المهم جدًا أن طبقة ECIES-Ratchet لا تقوم بالتعبئة (padding) بما يتجاوز هذا الحجم.
الحجم الموصى به لرسالة Garlic كي تناسب رسالتي نفق، بما في ذلك رأس I2NP لرسالة Garlic بحجم 16 بايت، وطول رسالة Garlic 4 بايت، ووسم ES بحجم 8 بايت، وMAC بحجم 16 بايت، هو 1956 بايت.
خوارزمية التعبئة (padding) الموصى بها في ECIES هي كالتالي:
- إذا كان الطول الكلي لرسالة Garlic سيكون بين 1954-1956 بايت، فلا تُضف كتلة تعبئة (لا يوجد مكان)
- إذا كان الطول الكلي لرسالة Garlic سيكون بين 1938-1953 بايت، أضف كتلة تعبئة لتجعل الطول بالضبط 1956 بايت.
- وإلا، قم بالتعبئة كالمعتاد، مثلًا بإضافة كمية عشوائية بين 0-15 بايت.
يمكن استخدام استراتيجيات مشابهة عند الحجم الأمثل لرسالة نفق واحدة (964) وحجم ثلاث رسائل نفق (2952)، رغم أن هذه الأحجام يجب أن تكون نادرة في الممارسة العملية.
القضايا
القيمة 1812 أولية. يجب التأكيد عليها وربما تعديلها.
الهجرة
لا توجد مشكلات في التوافق العكسي. هذا خيار موجود مسبقًا، وتفاوض MTU جزء من المواصفات بالفعل.
ستدعم الوجهات القديمة التي تستخدم ECIES قيمة 1730. أي عميل يستلم قيمة أعلى سيُعيد 1730، وستتفاوض الطرف البعيد على تقليل القيمة، كما هو الحال عادةً.