الخلاصة

  • في 24 أغسطس 2026 أقر IESG المراجعة 16 من draft-ietf-masque-connect-udp-listen بصفتها Proposed Standard. وعند تثبيت الأدلة بقيت Internet-Draft في طابور RFC Editor؛ ويذكر الإعلان أن Google Quiche وquic-go متوافقان تشغيلياً.
  • يتيح الامتداد لطلب HTTP واحد الاحتفاظ بعنوان ومنفذ UDP عامين والتعامل مع عدة أزواج بعيدة من IP والمنفذ. هذا تخصيص لقابلية الوصول، لا إذن شامل؛ فالتفاوض وتسجيل Context ID وسياسة الهدف والتسليم المرصود أحكام منفصلة.

وصل الطرد إلى المنفذ الصحيح، من الطرف الخطأ

يطلب متصفح من وكيل HTTP عنوان UDP عاماً لمكالمة WebRTC. يربط الوكيل عنواناً ومنفذاً ويرسلهما إلى العميل. يصل طرد من الطرف الذي اختاره ICE، ثم يصل طرد ثان من ماسح لا علاقة له بالمكالمة اكتشف المنفذ مصادفة.

كلاهما بلغ المقبس. ولا يعني ذلك أن كليهما يملك حق الدخول إلى النفق.

هذه حالة توضيحية وليست حادثة معلنة. وهي تكشف وظيفة “Proxying Bound UDP in HTTP”: إنشاء نقطة لقاء مستقرة من دون تحويلها إلى relay مفتوح. بعد الوصول يبقى القرار مرتبطاً بالطلب الموثق، وزوج المصدر البعيد، وContext ID، وقواعد الوكيل، وخيار العميل بشأن المرسلين المجهولين.

قرار معياري له حدود زمنية

يسجل إعلان IESG أن المراجعة 16 أُقرت في 24 أغسطس عند 17:58 بالتوقيت العالمي بهدف Proposed Standard. النص من عمل مجموعة MASQUE.

يحدد RFC 9298 خط الأساس: طلب CONNECT-UDP واحد إلى مضيف ومنفذ ثابتين. يناسب ذلك حركة العميل والخادم مثل HTTP/3. أما WebRTC فيعتمد على ICE وقد يحتاج إلى اختبار أطراف متعددة. إنشاء طلبات منفصلة لا يضمن أن يعالجها خادم الوكيل نفسه أو أن تخرج من عنوان عام واحد، وهو ما قد يفشل الاتصال.

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

في 28 أغسطس ظل Datatracker يعرض النص كـ Internet-Draft نشط، وحالة IESG هي RFC Ed Queue. كان عمل IANA جارياً مع قبول مراجعات الخبراء، فيما انتظر RFC Editor فحص المراجع والتنسيق. تمت الموافقة، لكن رقم RFC واعتماد الأنظمة بقيَا مرحلتين لاحقتين.

الارتباط لا يقوم بإشارة من طرف واحد

يرسل العميل Connect-UDP-Bind: ?1، ويعيد الوكيل القيمة المنطقية الصحيحة نفسها إذا دعم الامتداد. لا يفعّل الطرف الآلية إلا بعد أن يرسل القيمة ويتلقاها. وأي نوع آخر للقيمة يعامل كما لو أن الحقل غائب.

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

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

العنوان المعلن سجل تخصيص

بعد القبول يختار الوكيل عنوان IP عاماً واحداً على الأقل ومنفذاً مفتوحاً، ويربطهما بالطلب ويعلنهما في Proxy-Public-Address. عند إعلان زوج واحد يجب إبقاؤه طوال عمر النفق. ومع عدة أزواج يُنصح بالثبات داخل كل عائلة عناوين. ولا يستطيع حقل الاستجابة نقل تغيير لاحق.

يوفر الثبات مرشحاً مفيداً لـ ICE، لكنه لا يوثق المرسل. قد يصل الطرف المقصود والماسح المجهول إلى المقبس نفسه.

ينبغي ألا تبالغ السجلات في معناها. حدث «تخصيص عنوان عام» يثبت حجز المورد، وحدث «استلام طرد» يثبت الوصول. ولا يثبت أي منهما قبول الاقتران أو مرور السياسة أو التحويل إلى العميل أو نجاح التطبيق.

Context ID يحول الطرف البعيد إلى حالة صريحة

يخصص العميل الأرقام الزوجية، ويخصص الوكيل الفردية. يُحظر الصفر في وضع الارتباط الخالص، ولا يحتفظ بمعنى RFC 9298 إلا عندما يوجد هدف احتياطي حقيقي.

تدير ثلاث Capsules دورة الحياة. يقترح COMPRESSION_ASSIGN (0x11) معنى المعرف. يؤكد COMPRESSION_ACK (0x12) أن المستقبِل حفظ الاقتران. ويرفض COMPRESSION_CLOSE (0x13) الاقتراح أو يغلق حالة قائمة.

نسخة IP صفر تنشئ سياقاً غير مضغوط، فيحمل كل datagram عنواناً ومنفذاً. من العميل إلى الوكيل هما الهدف، وفي الاتجاه الآخر هما مصدر الطرد المستلم. النسخة 4 أو 6 تنشئ سياقاً مضغوطاً: يُسجل الزوج مرة واحدة ثم يشير إليه المعرف.

لا يجوز تخصيص المعرف مرتين، ولا فتح معرفين للزوج نفسه، ولا إعادة استخدام معرف مغلق. وتُهمل البيانات المعاد ترتيبها إذا وصلت بعد الإغلاق. بهذه القيود لا يستعيد اسم قديم سلطة على علاقة جديدة.

يسمح بالإرسال قبل ACK لتقليل التأخير، مع قبول احتمال الفقد إن لم يصل التخصيص أو رُفض. استعمال المرسل للمعرف مبكراً ليس دليلاً على قبول الطرف المقابل.

مفتاح المرسل المجهول بيد العميل

العميل وحده يطلب السياق غير المضغوط، ولا يفتح إلا واحداً. قوته واسعة لأن كل datagram وارد يستطيع وصف زوج مصدر لم يظهر من قبل.

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

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

سياسة الهدف تتبع الهدف المتغير

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

يفحص الوكيل عنوان ومنفذ كل datagram غير مضغوط. وفي السياق المضغوط يفحص الزوج الوارد في COMPRESSION_ASSIGN ويرفض ما تحظره السياسة. يمكن للمشغل حماية loopback والعناوين الخاصة وlink-local وشبكات الإدارة وخدمات بعينها.

لا يقرر النص كل سياسة تشغيلية أو تجارية، لكنه يحدد الموضع الأدنى الذي يمنع الزوج المتغير من تجاوز الرقابة.

يقدم TURN مقارنة نافعة. تخصيص عنوان relay، وأذونات الأطراف، وchannel bindings حالات مختلفة. ليست الآليتان متطابقتين، لكنهما تفصلان معاً بين الحصول على عنوان وبين السماح غير المحدود للأطراف.

حدود الذاكرة جزء من الحماية

كل Context ID مقبول يستهلك ذاكرة. وكل ACK أو CLOSE يتأخر بسبب التحكم في التدفق أو الازدحام يستهلك مساحة انتظار. لذلك يفرض النص حداً للسياقات المفتوحة وحداً لاستجابات الضغط المعلقة. وإذا بلغ الوكيل الحد الثاني فعليه إنهاء مسار الطلب.

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

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

عنوان IP واحد لا يكفي للإسناد

يوضح RFC 6269 أن مشاركة IP تخلط السمعة وتضعف الإسناد وقد توسع الحظر. خلف عنوان الوكيل الواحد قد توجد منافذ وأنفاق وعملاء وسياقات وأطراف كثيرة.

يتطلب تحقيق إساءة الاستخدام المنفذ العام، وهوية النفق، والعميل الموثق، وحالة Context ID، والزوج البعيد، وقرار السياسة، ونتيجة التحويل. لا ينبغي أن يتحول طرد مسح أُسقط عند الحافة إلى ادعاء بأنه وصل إلى المستخدم.

سلسلة الإثبات لطرد واحد

يجب أن تربط السجلات على الأقل:

  1. الطلب الموثق وهوية النفق؛
  2. تفاوض الارتباط في الاتجاهين؛
  3. الهدف الاحتياطي أو وضع الارتباط الخالص؛
  4. الزوج العام ومدة حياته؛
  5. جهة تخصيص Context ID وقيمته الفريدة؛
  6. ASSIGN وACK وCLOSE؛
  7. المعنى المضغوط أو غير المضغوط؛
  8. زوج المصدر أو الهدف البعيد بدقة؛
  9. نسخة السياسة وحكمها؛
  10. ميزانية السياقات والاستجابات؛
  11. القبول أو الإسقاط أو التخزين المؤقت؛
  12. الإرسال أو الاستقبال على المقبس؛
  13. التسليم للعميل ونتيجة ICE أو التطبيق.

قد ينجح التسجيل ثم يفشل المسار أو اختبار ICE. تسمح حالة البروتوكول بالمعالجة، لكن السلوك الجاري المرصود وحده يثبت قابلية الاستعمال. هنا يظهر مبدأ Running-Code Primacy: تحدد الوثيقة الحد الأدنى المشترك، وتتحمل الأنظمة المحلية مسؤولية النتيجة الفعلية.

المصادر