التحقق من معرف شبكة النقل

نظرة عامة

لا يرفض NTCP2 (الاقتراح 111) اتصالات من معرفات شبكة مختلفة في مرحلة طلب الجلسة. يجب أن يتم رفض المرور حاليًا في مرحلة تأكيد الجلسة عندما يتحقق بوب من RI لأليس.

وبالمثل، لا يرفض SSU اتصالات من معرفات شبكة مختلفة في مرحلة طلب الجلسة. يجب أن يتم رفض المرور حاليًا بعد مرحلة تأكيد الجلسة عندما يتحقق بوب من RI لأليس.

يقوم هذا الاقتراح بتغيير مرحلة طلب الجلسة لكلا النقلين لتضمين معرف الشبكة بطريقة متوافقة مع الإصدارات السابقة.

الدافع

يجب رفض الاتصالات من الشبكة الخطأ، ويجب وضع النظير في قائمة سوداء في أقرب وقت ممكن.

الأهداف

• منع التداخل بين شبكات الاختبار والشبكات المنشطرة

• إضافة معرف شبكة إلى المصافحة NTCP2 وSSU

• بالنسبة لـ NTCP2، يجب أن يكون المتلقي (الاتصال الوارد) قادرًا على تحديد أن معرف الشبكة مختلف، حتى يتمكن من قائمة سوداء IP للنظير.

• بالنسبة لـ SSU، لا يمكن للمتلقي (الاتصال الوارد) وضع قائمة سوداء في مرحلة طلب الجلسة، لأن IP الوارد يمكن تزويره. يكفي تغيير التشفير الخاص بالمصافحة.

• منع إعادة التشجير من الشبكة الخطأ

• يجب أن يكون متوافقًا مع الإصدارات السابقة

الأهداف غير المطلوبة

• لم يعد يتم استخدام NTCP 1، لذلك لن يتم تغييره.

التصميم

بالنسبة لـ NTCP2، سيتسبب XORing في قيمة فقط في فشل التشفير ولن يكون لدى المتلقي معلومات كافية لوضع القائمة السوداء للمنشئ، لذلك لا يفضل هذه الطريقة.

بالنسبة لـ SSU، سوف نقوم بـ XOR في معرف الشبكة في مكان ما في طلب الجلسة. نظرًا لأن هذا يجب أن يكون متوافقًا مع الإصدارات السابقة، سنقوم بـ XOR في (id - 2) بحيث يكون لا تأثير له على معرف الشبكة الحالي بقيمة 2.

المواصفات

التوثيق

أضف المواصفات التالية لقيم معرف الشبكة الصالحة:

تكوين Java I2P لتغيير الافتراضي هو “router.networkID=nnn”. وثق هذا بشكل أفضل وشجع الانقسامات والشبكات التجريبية على إضافة هذا الإعداد إلى تكوينهم. شجع تطبيقات أخرى على تنفيذ وتوثيق هذا الخيار.

NTCP2

استخدام أول بايت محجوز من الخيارات (البايت 0) في رسالة طلب الجلسة لتحتوي على معرف الشبكة، والذي هو حاليًا 2. يحتوي على معرف الشبكة. إذا كان غير صفري، يجب على المتلقي التحقق منه مقابل أقل بايت هام من معرف الشبكة المحلي. إذا لم تتطابق، يجب على المتلقي قطع الاتصال فورًا ووضع IP للمنشئ في القائمة السوداء.

SSU

بالنسبة لـ SSU، أضف XOR لـ ((netid - 2) « 8) في حساب HMAC-MD5.

التواجد الحالي:

HMAC-MD5(encryptedPayload + IV + (payloadLength ^ protocolVersion), macKey)

  '+' تعني الإلحاق و '^' تعني XOR الحصري.
  payloadLength هو عدد صحيح غير موقع مكون من 2 بايت
  protocolVersion هو بايت واحد 0x00

الجديد:

HMAC-MD5(encryptedPayload + IV + (payloadLength ^ protocolVersion ^ ((netid - 2) << 8)), macKey)

  '+' تعني الإلحاق، '^' تعني XOR الحصرية، '<<' تعني إزاحة لليسار.
  payloadLength هو عدد صحيح غير موقع مكون من بايتين، big endian
  protocolVersion هو بايتين 0x0000، big endian
  netid هو عدد صحيح غير موقع مكون من بايتين، big endian، القيم القانونية هي 2-254

إعادة التشجير

أضف معلمة ؟netid=nnn إلى جلب ملف إعادة التشجير su3. قم بتحديث برامج إعادة التشجير للتحقق من netid. إذا كان موجودًا ولم يكن مساويًا لـ “2”، يجب رفض الجلب مع رمز خطأ، ربما 403. أضف خيار تكوين لبرامج إعادة التشجير بحيث يمكن تكوين NetID بديل للاختبار أو الشبكات المنشطرة.

ملاحظات

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

المشاكل

الترحيل

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