الخلاصة

  • يحمل SYN الخاص بـ MP_JOIN رمز المستقبِل كي يعثر على حالة MPTCP قائمة، بينما تفصل قيم nonce وHMAC وسياسة المستقبِل في قبول تدفق TCP فرعي جديد.
  • تطابق الرمز وصحة HMAC وإنشاء TCP ونجاح التطبيق أدلة مستقلة، ولا يصح تحويلها إلى ادعاء واحد عن الهوية أو السلطة.

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

لذلك يبدأ السجل من التدفق الأول. يضع RFC 8684 خيار MP_CAPABLE في SYN وSYN/ACK وACK الأولى. بهذه المفاوضة يعلن الطرفان القدرة على MPTCP في هذا الاتصال ويتبادلان مادة المفاتيح التي ستستخدم لاحقاً عند توثيق تدفق فرعي إضافي. إن لم يكتمل التبادل اللازم، يعود السلوك إلى TCP أحادي المسار. ظهور خيار في محاولة واحدة لا يثبت أن مساراً آخر سيحفظه، ولا يثبت هوية مستخدم أو تفويض تطبيق أو ملكية عنوان.

تاريخ المعيار له حد مماثل. كان RFC 6824 في 2013 بروتوكولاً تجريبياً للتنفيذ والتقييم. وسجل RFC 8041 في 2017 خبرات تشغيل وتنفيذ مؤرخة. ثم ألغى RFC 8684 النسخة v0 في 2020 بوصفه وثيقة Standards Track، وذكر أن خبرة النشر هي المصدر الرئيس للتوضيحات والتعديلات. هذا يثبت مسار مراجعة مبنياً على الخبرة، لا حصة انتشار راهنة أو سلوك منتج معين.

الرمز فهرس للحالة

بعد الاتصال الأول، يرسل MP_JOIN في SYN الأول Token الخاص بالمستقبِل وnonce جديداً من المرسل وAddress ID. مع اختيار SHA-256 في v1، يكون Token هو أعلى 32 بت من تجزئة SHA-256 لمفتاح المستقبِل الأصلي. يستخدمه المستقبِل للعثور على اتصال MPTCP المحلي الذي يقترح SYN الانضمام إليه.

هذا بحث عن حالة، لا تصريح قابل للحمل. عند وصول SYN لا يكون خماسي التدفق الجديد معروفاً بعد ضمن الاتصال القديم؛ لذا يستعمل Token في فك التعدد عند مرحلة الطلب. بعد إنشاء التدفق، تعود الحزم إلى فك التعدد العادي في TCP بخماسيتها. الرمز ليس اسماً دائماً لكل الحزم ولا بديلاً عن تحقق TCP.

ولـ Address ID وظيفة أخرى: يتيح ربط عنوان المصدر وحذفه حتى لو غيّر NAT ترويسة IP التي يراها الطرف الآخر. لا يجعل ذلك القيمة دليلاً على امتلاك IP أو على حق إعلان طريق أو على تفويض خارج حالة هذا الاتصال.

HMAC يثبت الاستمرار، لكن المضيف يظل صاحب القرار

لا يكفي العثور بالرمز. يرد المستقبِل بـ nonce خاص به وHMAC مقتطع، ثم يرد البادئ بـ HMAC. تعتمد الحسابات على مفاتيح MP_CAPABLE وعلى القيم العشوائية الجديدة من الطرفين، فلا تكفي إعادة رسالة قديمة لإثبات هذه المحاولة الجديدة.

إذا صحت HMACات، فالنتيجة التي يحددها RFC 8684 ضيقة: تحقق المضيفان من أنهما نفس نظيري MPTCP عند بدء الاتصال، واتفقا على الاتصال الذي سينضم إليه التدفق. لا يثبت ذلك شخصاً أو مؤسسة أو إذناً لطلب لاحق أو نجاح عملية تجارية.

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

بعد القبول، يمكن للأثر الشبكي أن يثبت مفاوضة أولى وبحث Token وHMACات صحيحة وخماسي تدفق قائماً. لكنه لا يثبت أن التطبيق قبل المحتوى، أو أن قاعدة بيانات حفظته، أو أن المستخدم خُوّل، أو أن الأثر المقصود تحقق. استمرارية البايتات لا تمنح طبقة النقل سلطة على معنى البايتات.

المصادر وحدود الإثبات

تدعم RFCs التالية البنية والسجل الوثائقي والسلوك المحدد. ولا تثبت انتشاراً حالياً أو انفصال مسارات حقيقية أو سلوك NAT معين أو توافق منتج أو هوية إنسان أو اكتمال تطبيق.