ترحيل بلا ذاكرة لا يعني عبورا بلا كلفة

الخلاصة

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

دفتر لا يبقى عند الوسيط

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

تعالج RFC 6345 وضعا لا يستطيع فيه عميل PANA، أو PaC، التواصل مع وكيل المصادقة PAA عبر التوجيه العادي لحزم IP. يتدخل عنصر PRE لحمل الرسائل بينهما. ومن أمثلة الوثيقة جهاز IPv6 يريد الانضمام إلى الشبكة بعنوان محلي للوصلة؛ تتولى العقدة الأم ترحيل رسائله نحو وكيل عند موجه الحدود. هذا مثال يشرح التصميم، وليس وصفا لانتشار مقاس في شبكات اليوم.

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

تسجل صفحة RFC Editor الرسمية الوثيقة بوصفها Proposed Standard صدرت في أغسطس 2011. أهمية التاريخ أن القارئ يعرف نوع الدليل الذي بين يديه: مواصفة يمكن تحليل توزيع الوظائف فيها، لا شهادة حديثة بسلامة جهاز معين أو بحجم سوق. لا تتضمن المصادر المستخدمة هنا أرقاما عن الكلفة أو حوادث تشغيل أو اختبارات أداء. ما يمكن استخلاصه منها هو أين يقع العمل الذي يجب حسابه، لا مقدار فاتورته.

أين تحفظ إحداثيات الإياب؟

يحمل PRE الرسالة في غلاف PRY. يضع رسالة PANA الداخلية، من دون ترويستي IP وUDP الأصليتين، داخل الحقل Relayed-Message. أما عنوان العميل ومنفذ UDP الخاص به فيوضعان في PaC-Information. الفصل مقصود: محتوى المصادقة في موضع، والمعلومات اللازمة لإعادة التسليم إلى العميل في موضع آخر.

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

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

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

ولا تعد RFC 6345 بمنظومة وسطاء تتوسع تلقائيا. يختار PRE وكيلا من عناوين PAA معدة مسبقا؛ اكتشاف الوكلاء ديناميكيا بواسطة PRE خارج نطاق الوثيقة. وهي تفترض وسيطا واحدا على الأكثر، وتترك معالجة أغلفة ترحيل متداخلة خارج النطاق أيضا. عبارة «بلا حالة لكل عميل» لا تمنح وحدها اكتشافا تلقائيا أو ضمان تجاوز أعطال أو صلاحية لإضافة طبقات من الوسطاء.

تصحيح لا يغير الهوية، لكنه يغير فهم الرد

تكشف الاستدراكة التقنية 2996 عن خطأ صغير في الإحالة داخل وصف المسار العائد. المنفذ المقصود لتسليم رد UDP إلى العميل يؤخذ من PaC-Information، لا من Relayed-Message كما ورد في النص الأصلي. أبلغ عن التصحيح في 13 أكتوبر 2011، واعتمد في 7 سبتمبر 2012.

لم تضف الاستدراكة مفتاحا، ولم تبدل الجهة التي تصادق العميل، ولم تمنح الوسيط صلاحية جديدة. صححت موضع المعلومة التي يحتاجها لبناء الرد. ولأن الرسالة الداخلية لا تحمل ترويسة UDP الأصلية، فإن معرفة الحقل الصحيح جزء من فهم طريقة العمل نفسها.

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

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

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

غلاف لا يعيد الإرسال ليس حوارا بلا إعادة

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

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

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

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

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

ماذا يحمي التشفير، وماذا يترك؟

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

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

شرط توليد المفاتيح ليس تفصيلا يمكن إسقاطه من العرض الإداري. تربط RFC 5191 إنشاء الارتباط الأمني PANA SA بنجاح EAP مع الحصول على MSK. إذا لم تتوافر MSK فلا ينشأ ذلك الارتباط. لا يحق لنا تعميم حماية واحدة على كل اختيار لطريقة EAP، ولا تحويل التحليل المعياري إلى ضمان لكل تنفيذ.

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

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

الاختيار الأمني ليس إعفاء تشغيليا

تجعل RFC 6345 الحماية التشفيرية بين PRE وPAA اختيارية على مستوى البروتوكول. وفي الوقت نفسه تطلب التعامل مع المخاطر المتبقية، باستخدام حماية مادية أو تشفيرية وضوابط تقيد الأطراف المقبولة. الاختيار بين وسائل الحماية لا يعني أن تجاهل الخطر خيار مكافئ.

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

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

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

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

اختلاف العنوان يحتاج إلى تفسير

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

وتشير RFC 6345 إلى إمكان ظهور فرق مشابه مع PAA متعدد الواجهات حتى من دون ترحيل. لذلك لا يثبت اختلاف العنوان وحده وجود اختراق، كما لا يبرر تجاهل كل اختلاف. المطلوب معرفة مدلول العنوان عند كل طرف وكيف يدخل في التحقق. هذه كلفة معرفة وتشغيل لا تظهر في مواصفات الذاكرة.

لاحقا، عرضت RFC 7733، الصادرة في فبراير 2016، PANA وEAP-TLS ضمن ملف تقني لشبكات RPL في المنازل والمباني. تؤدي العقدة الأم دور PRE ما لم تكن هي نفسها خادم المصادقة. يقدم ذلك دليلا تاريخيا على موضع هذا التصميم في تركيب محدد.

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