الخلاصة

  • استخدمت RFC 3336 تعدد الإرسال في AAL2 لنقل حمولات PPP الصغيرة بكفاءة، ومنها الصوت بعد ضغط ترويسات RTP.
  • ظل نطاق الثقة أضيق من اتصال ATM المشترك: مصادقة جلسة PPP لم تحمِ معرّفات القنوات غير التابعة لـPPP المجاورة، ولا شبكة التحويل في ATM.

القناة ليست هوية

بدأت المشكلة من اختلاف الحجم. كان PPP فوق AAL5 مناسباً لنقل IP، لكن RFC 3336 أوضحت أن الحشو والتأطير قد يهدران النطاق الترددي عندما تكون الحمولة صغيرة، ولا سيما في الصوت الذي ضُغطت ترويسات RTP الخاصة به. وقدّم AAL2 ترتيباً آخر: تستطيع طبقته الفرعية المشتركة (CPS) تعديد حمولات PPP متعددة داخل خلايا ATM، بدلاً من تحميل كل حزمة قصيرة كلفة إطار كامل.

لكن ذلك لم يحوّل الاتصال الافتراضي في ATM إلى وصلة PPP واحدة. وصفت RFC 3336 خدمة PPP/AAL2 بأنها اتصال افتراضي ثنائي الاتجاه ومن نقطة إلى نقطة، يمكن تخصيصه مسبقاً أو إنشاؤه عند الطلب. وداخله، يحدد معرّف قناة AAL2 (CID) تدفقاً فرعياً. يمكن لجلسة PPP أن تستخدم معرّفاً واحداً أو عدة معرّفات؛ وعلى الطرفين الاتفاق على عددها، وربطها بالطبقات الفرعية الخاصة بالخدمة، وقيمها. يوفر التخصيص الثابت هذه المعطيات للاتصال المخصص، بينما قد توفرها الإشارة للاتصال المحوّل.

كان من الممكن أن يحمل الاتصال الافتراضي نفسه أيضاً حركة AAL2 التقليدية ووظائف مختلفة للتقارب الخاص بالخدمة. لذلك يفصل CID بين التدفقات الفرعية، لكنه لا يشكل هوية تشفيرية. رسمت RFC 3336 حداً واضحاً هنا: لا تجيز مصادقة جلسة PPP وآلياتها المرتبطة افتراض أن معرّفات القنوات غير التابعة لـPPP على الاتصال نفسه محمية أيضاً. كما أن مصادقة PPP لا تؤمّن شبكة التحويل في ATM. وحذرت الوثيقة من أن اختراق بنية النقل قد يتيح هجوماً وسيطاً.

كانت هناك إشارات أخرى، لكنها لم تدمج تلك الحدود. يمكن اشتقاق حالة الوصلة، صعوداً أو هبوطاً، من حزم إدارة الأعطال من النوع 3 داخل تدفق CID المعني. كما أضاف التغليف CRC بطول 16 بت لكشف الأخطاء. لكن إشارة حالة الوصلة ولا CRC يثبتان من يسيطر على CID مجاور أو يحميان محتواه من خصم. وعندما تتطلب الحماية تجاوز جلسة PPP، تشير RFC 3336 إلى المصادقة أو التشفير في طبقة أعلى و/أو خدمات الأمن على طبقة ATM.

وتوضح RFC 3337، التي صدرت في الفترة نفسها، لماذا اجتذبت القنوات المتعددة مصممي التطبيقات الآنية: يمكن لجلسة PPP واحدة أن تمتد عبر عدة معرّفات CID لإدراج أجزاء من فئات مختلفة بالتناوب. لكن الوثيقة المرافقة تركت طريقة جدولة CPS رهناً بمتطلبات التطبيق. فمعرّف الفئة وحده لا يضمن زمناً محدداً للتأخير. أتاح التنسيق معالجة متمايزة، لكنه لم يثبت أن مجدولاً أو شبكة بعينها قدمتها.

ينبغي أن تظل الخلاصة ضمن حدود السجل الوثائقي. يسجل RFC Editor الوثيقة RFC 3336 بوصفها Proposed Standard، ويحدد نصها آلية. لكن أياً من ذلك لا يثبت أي الموردين نفذها، أو مدى انتشارها، أو وقوع حادث أمني بسبب هذا الاختيار. وتقدم Note 65 للـLu Heng انضباطاً تحريرياً مناسباً: المعيار اقتراح للأنظمة العاملة، لا دليل على أنها تبنته.

الدرس هنا معماري. قد يؤدي اشتراك الاتصالات في وصلة نقل إلى خفض كلفة الحزمة، مع بقاء نطاقات متعددة للتحكم والثقة داخلها. وإذا أظهر سجل مراجعة أن «PPP صودق عليه»، فينبغي السؤال عمّا تمت مصادقته تحديداً: طرفا PPP وحركة تلك الجلسة، أم كل CID ووظيفة خدمة ومحوّل عبره الاتصال الافتراضي؟ كانت إجابة RFC 3336 أن الأولى لا تستلزم الثانية.

المصادر

صفحة حالة RFC Editor

المصادر: RFC 3336 · RFC 3337 · PPP فوق AAL5، RFC 2364 · تعدد إرسال PPP، RFC 3153 · PPP، RFC 1661 · ضغط ترويسات RTP، RFC 2508 · الروابط منخفضة المعدل، RFC 2689 · ITU-T I.363.2 · ITU-T I.366.1 · Lu Heng، Note 65