ملاحظة
يتم حاليًا نشر الشبكة وإجراء الاختبارات. قد تخضع لتعديلات طفيفة.
نظرة عامة
الملخص
يقلل ECIES من الحمل الزائد لرسائل الجلسات القائمة (ES) بحوالي 90 بايت. لذلك يمكننا زيادة الـ MTU بحوالي 90 بايت للاتصالات بـ ECIES. انظر the ECIES specification, Streaming specification, and Streaming API documentation.
دون زيادة الـ MTU، في العديد من الحالات لا يتم “توفير” المدخرات فعليًا، حيث سيتم تعبئة الرسائل لاستخدام رسائل النفق الكاملة على أي حال.
هذا الاقتراح لا يتطلب أي تغيير في المواصفات. تم نشره كاقتراح فقط لتسهيل المناقشة وبناء التوافق حول القيمة الموصى بها وتفاصيل التنفيذ.
الأهداف
- زيادة الـ MTU المتفاوض عليها
- تعظيم استخدام رسائل النفق 1 كيلوبايت
- عدم تغيير بروتوكول البث
التصميم
استخدام خيار MAX_PACKET_SIZE_INCLUDED القائم والتفاوض على الـ MTU. يستمر البث في استخدام الحد الأدنى من الـ MTU المرسلة والمستلمة. يبقى الإعداد الافتراضي 1730 لجميع الاتصالات، بغض النظر عن المفاتيح المستخدمة.
ينصح بالتنفيذات أن تدرج خيار MAX_PACKET_SIZE_INCLUDED في جميع حزم SYN، في كلا الاتجاهين، على الرغم من أن ذلك ليس مطلوبًا.
إذا كانت الوجهة ECIES فقط، استخدم القيمة الأعلى (سواء كـ Alice أو Bob). إذا كانت الوجهة ثنائية المفتاح، قد يختلف السلوك:
إذا كان العميل ثنائي المفتاح خارج الموجه (في تطبيق خارجي)، قد لا “يعرف” المفتاح المستخدم في النهاية البعيدة، وقد تطلب Alice قيمة أعلى في الـ SYN، بينما يبقى الحد الأقصى للبيانات في الـ SYN 1730.
إذا كان العميل ثنائي المفتاح داخل الموجه، قد يكون أو قد لا يكون معلومات عن المفتاح المستخدم معروفة للعميل. قد لم يتم جلب الـ leaseset بعد، أو قد لا تجعل الواجهات الخارجية لهذه المعلومات بسهولة العميل. إذا كانت المعلومات متاحة، قد تستخدم Alice القيمة الأعلى؛ وإلا، يجب أن تستخدم Alice القيمة القياسية 1730 حتى يتم التفاوض عليها.
قد يرسل العميل ثنائي المفتاح كـ Bob القيمة الأعلى كاستجابة، حتى لو لم يتم استلام قيمة أو تم استلام قيمة 1730 من Alice؛ لكن، لا يوجد بند للتفاوض نحو الأعلى في البث، لذلك يجب أن يبقى الـ MTU عند 1730.
كما هو مذكور في the Streaming API documentation, قد تتجاوز البيانات في حزم SYN المرسلة من Alice إلى Bob الحد الأقصى لـ MTU الخاص بـ Bob. هذه نقطة ضعف في بروتوكول البث. لذلك، يجب على العملاء ثنائي المفتاح أن يقتصروا البيانات في حزم SYN المرسلة إلى 1730 بايت، أثناء إرسال خيار MTU أعلى. بمجرد استلام MTU الأعلى من Bob، قد تزيد Alice الحد الأقصى الفعلي للحمولة المرسلة.
التحليل
كما هو موضح في the ECIES specification, فإن الحمل الزائد لـ ElGamal لرسائل الجلسات القائمة هو 151 بايت، والحمل الزائد لـ Ratchet هو 69 بايت. لذلك، يمكننا زيادة الـ MTU لروابط Ratchet بمقدار (151 - 69) = 82 بايت، من 1730 إلى 1812.
المواصفات
أضف التغييرات والتوضيحات التالية إلى قسم اختيار وتفاوض الـ MTU في the Streaming API documentation. لا تغيير في the Streaming specification.
تظل القيمة الافتراضية للخيار 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 فقط
لا تغيير، 1730 MTU في جميع الحزم.
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize الافتراضي: 1730
- قد ترسل Alice MAX_PACKET_SIZE_INCLUDED في SYN، ليس مطلوبًا إلا إذا كان != 1730
2) Alice ECIES فقط
1812 MTU في جميع الحزم.
- ALICE_SYN_MAX_DATA = 1812
- i2cp.streaming.maxMessageSize الافتراضي: 1812
- يجب على Alice إرسال MAX_PACKET_SIZE_INCLUDED في SYN
3) Alice ثنائي المفتاح و تعرف أن Bob هو ElGamal
1730 MTU في جميع الحزم.
- ALICE_SYN_MAX_DATA = 1730
- i2cp.streaming.maxMessageSize الافتراضي: 1812
- قد ترسل Alice MAX_PACKET_SIZE_INCLUDED في SYN، ليس مطلوبًا إلا إذا كان != 1730
4) Alice ثنائي المفتاح و تعرف أن Bob هو ECIES
1812 MTU في جميع الحزم.
- 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، وفي جميع الحزم اللاحقة المرسلة في كلا الاتجاهين.
التبرير
انظر إلى the Java I2P source code لمعرفة لماذا القيمة الحالية هي 1730. انظر إلى the ECIES specification لمعرفة لماذا الحمل الزائد لـ ECIES أقل بـ 82 بايت من ElGamal.
ملاحظات التنفيذ
إذا كان البث ينشئ رسائل بحجم مثالي، فمن المهم جدًا أن لا تضيف طبقة ECIES-Ratchet حشوًا يتجاوز هذا الحجم.
الحجم المثالي لرسالة الثوم لتتناسب مع رسالتي نفق، بما في ذلك رأس رسالة الثوم I2NP بحجم 16 بايت، طول رسالة الثوم بحجم 4 بايت، وسم ES بحجم 8 بايت، و MAC بحجم 16 بايت، هو 1956 بايت.
الخوارزمية الموصى بها للحشو في ECIES هي كما يلي:
- إذا كان الطول الإجمالي لرسالة الثوم سيكون بين 1954-1956 بايت، لا تضف كتلة حشو (لا توجد مساحة).
- إذا كان الطول الإجمالي لرسالة الثوم سيكون بين 1938-1953 بايت، أضف كتلة حشو لتوصيل الطول إلى 1956 بايت بالضبط.
- خلاف ذلك، قم بالحشو كما هو معتاد، على سبيل المثال مع كمية عشوائية بين 0-15 بايت.
يمكن استخدام استراتيجيات مماثلة بالنسبة للحجم المثالي لرسالة النفق الواحدة (964) وحجم رسالة النفق الثلاثة (2952)، على الرغم من أن هذه الأحجام ينبغي أن تكون نادرة في الممارسة.
المشكلات
القيمة 1812 أولية. ليتم تأكيدها وربما تعديلها.
الهجرة
لا توجد مشكلات في التوافق العكسي. هذا الخيار موجود بالفعل والتفاوض على MTU هو بالفعل جزء من المواصفات.
ستدعم الوجهات القديمة لـ ECIES القيمة 1730. أي عميل يتلقى قيمة أعلى سيرد بقيمة 1730، وسوف يتفاوض الطرف البعيد للأسفل، كما هو معتاد.