الخلاصة

  • ألزم RFC 3193 حماية رسائل التحكم والبيانات في L2TP بواسطة ESP، لكن محددات IPsec كان عليها أن تتغير حين يختار L2TP عنواناً أو منفذ UDP جديداً أثناء إنشاء النفق.
  • قد يثبت IKE امتلاك الجهاز للمفتاح في كل حزمة، بينما يثبت PPP هوية مستخدم عند بدء الجلسة فقط؛ من دون عزل محلي للحركة لا تصبح هوية الجهاز دليلاً على المستخدم.

لا يبدأ النفق الآمن لحظة ظهور رمز القفل. يبدأ حين تكون السياسة الأمنية موجودة قبل أول رسالة تنشئ العلاقة التي ستدّعي السياسة حمايتها. لهذا اشترط RFC 3193 وجود مرشح IPsec قبل إرسال SCCRQ، وهي رسالة Start-Control-Connection-Request. إذا لم يوجد ارتباط أمان مناسب، كان إرسال الرسالة يفترض أن يحفز IKE لإنشائه، وإذا فشل الإنشاء وجب إسقاط الحزمة.

هذا الترتيب الزمني هو جوهر الوثيقة. لو خرجت أول رسالة تحكم مكشوفة ثم بدأت الحماية بعد ذلك، لكان الفعل الذي أنشأ النفق خارج حدوده الأمنية. لم تكن عبارة «سنشفر الحزم التالية» بديلاً عن حماية القرار الأول.

غير أن L2TP لم يكن يملك منذ البداية كل الحقائق التي يحتاج إليها IPsec. حمل L2TP جلسات PPP وله حالة خاصة به: نفق، جلسة، رسائل تحكم، keep-alive، وإنهاء. كان المنفذ 1701 نقطة التقاء معروفة، لكن المستجيب استطاع اختيار منفذ مصدر آخر. وأجازت مواصفة L2TP للمستجيب أن يقترح عنوان IP آخر أيضاً. كانت هذه حرية مفيدة لتوزيع الحمل أو اختيار الطرف، لكنها جعلت مجموعة الحزم المحمية هدفاً متحركاً.

رأى IPsec الحركة عبر محددات: عنوانا الطرفين، البروتوكول، والمنافذ. لا يعني ارتباط الأمان «احم أي شيء يقرره التطبيق لاحقاً». إنه يجيز مجموعة تفاوض عليها الطرفان. لذلك كان على L2TP، عندما يعرف منفذاً ديناميكياً، أن يحقن هذه الحقيقة في قاعدة مرشحات IPsec. وبعد Quick Mode يستطيع IKE تثبيت مرشح أضيق مرتبط بارتباط الأمان المكتمل.

عالج RFC تغير العنوان وتغير المنفذ بطريقتين مختلفتين. إذا اختار المستجيب عنوان IP جديداً، لم يكن مسموحاً له الانتقال بصمت. كان عليه أن يرسل عبر المسار الأصلي المحمي رسالة StopCCN تحمل خطأً عاماً وعبارة «Try Another» مع العنوان الجديد. يتحقق المبادر من العنوان، يثبت سياسة جديدة، وينشئ Phase 1 وPhase 2 جديدتين قبل SCCRQ جديدة. تغير العنوان أصبح إعادة بدء معلنة بحالة تشفير جديدة، لا افتراض استمرارية.

أما تغير المنفذ فكان انتقالاً داخل العنوان نفسه. يستطيع المستجيب اختيار منفذ مصدر جديد قبل SCCRP، ثم يضيف L2TP المرشحات ويبدأ المستجيب تفاوض Phase 2 آخر. كان مرشح الإعداد الوارد أوسع مؤقتاً كي يسمح بهذا الاختيار؛ وبعد اكتمال التفاوض يمكن إزالة مرشحات وارتباطات الإعداد الزائدة. السلطة الواسعة كانت جسراً زمنياً، لا حقاً دائماً.

لهذا لم تكن وصفة «UDP 1701 مع IPsec» كافية. انتقل الكائن المحمي من رباعية التقاء أولية إلى رباعية نفق متفاوض عليها. امتلك L2TP معلومات لم يكن من حق IKE اختراعها. وامتلك IKE نتيجة مصادقة لم يكن من حق L2TP افتراضها. ربط RFC النظامين بإخطارات صريحة وحقن للمرشحات.

بقيت دورات الحياة منفصلة أيضاً. يستطيع PPP إنهاء جلسته عبر LCP. يستطيع L2TP إغلاق اتصال التحكم أو استنتاج موت النظير. ويستطيع IKE حذف Phase 1 أو Phase 2. عند زوال نفق L2TP ينبغي حذف ارتباطات الأمان التي أنشئت له وإرسال رسائل الحذف. وعندما يرى IKE أن النظير حذف الحالة الأمنية ينبغي أن يخطر L2TP. لا تكفي إزالة سجل واحد لإثبات اختفاء كل ما تعلق به.

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

حتى الحجم كشف حدود الاستقلال. أضاف L2TP وIPsec رؤوساً فوق PPP الذي افترض غالباً MRU قدره 1500 بايت. اقترح RFC تمرير MTU الواجهة ناقص كلفة التغليف إلى PPP قبل تفاوض LCP. وإذا تعلم IPsec قيمة Path MTU أصغر عبر ICMP، كان يخزنها في ارتباط الأمان ويبلغ L2TP. لم تكن ملاحظة طبقة الأمن مفيدة للطبقة المحمولة إلا بعد عبورها واجهة صريحة.

وكان الضغط ذا الحالة خطراً لسبب مشابه. L2TP اتصال منطقي، لكن IP لا يضمن ترتيب الحزم. فقد حزمة واحدة يمكن أن يفسد حالة الضغط أو التشفير للحزم التالية. لذلك فضلت الوثيقة آليات بلا حالة. كلمة «نفق» لم تحول الشبكة إلى تيار مرتب وموثوق.

الحد الأشد أهمية كان الهوية. أجاب PPP وIKE عن سؤالين مختلفين. قد يصادق PPP على مستخدم في بداية الجلسة. وقد يصادق IKE على جهاز يملك شهادة أو مفتاحاً ثم تستخدم المفاتيح المشتقة لتوثيق كل حزمة ESP. هذا أقوى في إثبات استمرار امتلاك مفتاح IKE، لكنه لا يرث هوية لم يثبتها IKE أصلاً.

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

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

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

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

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

وأخيراً، توقفت الحماية عند حدود النفق. في compulsory tunneling يرسل العميل PPP إلى LAC وقد لا يعرف أن LAC غلفه لاحقاً في L2TP وIPsec. يستطيع LNS فحص ارتباط LAC–LNS، أما العميل فلا يملك دليلاً على حماية المقطع بينه وبين LAC. في voluntary tunneling ينشئ العميل L2TP بنفسه ويستطيع فحص الارتباط إلى LNS، لكن الطريق بعد LNS يظل مقطعاً آخر.

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