أعطى DHCP عنوان PAA، فتعاملت العمليات معه كأنه سلطة موثوقة

الخلاصة

• يعرّف RFC 5192 خيارات DHCP لتزويد العميل بعناوين PAA، ويعرّف RFC 6345 عنصر ترحيل. هذه الآليات تحدد أين تبدأ المحاولة؛ ولا تستبدل أدلة جلسة PANA وEAP التي تليها.
• اكتشاف الوجهة، مصادقة الطرف، تخويل الخدمة، تركيب مرشح EP، إنشاء حماية الرزم، ثم رصد التسليم هي طبقات مستقلة. منح أول طبقة سلطة البقية يجعل إشارة الشبكة قرار ثقة.

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

PANA ينقل EAP فوق IP بين PANA Client وPANA Authentication Agent. وقد ترك RFC 5191 الاكتشاف الديناميكي للـPAA لآليات أخرى. جاء RFC 5192 بخيارات DHCP للعناوين، ثم أضاف RFC 6345 relay عندما لا يكون التواصل المباشر مناسباً.

كل ذلك يجيب عن سؤال الوصول: إلى أي عنوان أو وسيط تُرسل الرسالة؟ أما من يملك المفتاح، وما نتيجة EAP، وهل سمحت السياسة، وهل نفذ EP القرار، فهي أسئلة لاحقة.

سجل الاكتشاف يجب أن يبقى مرشحاً

يحتاج سجل الاكتشاف إلى خادم DHCP، الخيار المستلم، العنوان، مدة lease، الواجهة، relay إن وجد، ووقت الاستلام. ثم يُربط بمحاولة PANA التي استخدمته وبنتيجة التحقق منها.

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

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

EAP Success لا يساوي تخويلاً

حتى بعد تجاوز الاكتشاف، لا تختصر EAP السلسلة. يذكر RFC 5191 حالة تنتج فيها EAP رسالة Success، بينما يرفض AAA أو PAA محلياً تخويل الوصول. عندها يحمل آخر PANA-Auth الرمز PANA_AUTHORIZATION_REJECTED وتنتهي الجلسة.

قد تكون بيانات الاعتماد صحيحة والسياسة رافضة. وقد يتولد MSK وتحصل الرسائل الأخيرة على حماية AUTH، لكن الرسالة المحمية ما زالت تحمل رفضاً.

يسجل object الدليل طريقة EAP والهوية والنتيجة والمادة المصدّرة، ثم يسجل قرار التخويل ومصدره والخدمة والمدة والسبب. لا يحق لحقل EAP Success أن يكتب فوق قرار الوصول.

بهذا الفصل يعرف المحقق هل يعود إلى discovery، أو credentials، أو AAA policy، بدلاً من وضع كل حالات «لا توجد شبكة» في طابور واحد.

Complete لا يقرأ جدول EP

ينتهي طور المصادقة والتخويل بتبادل PANA-Auth ذي Complete bit. في النجاح يحمل أيضاً Session-Lifetime، ومع EAP مولّدة للمفاتيح يظهر Key-Id وAUTH.

هذا يثبت إغلاق التبادل بين PaC وPAA ضمن حدوده. لكن Enforcement Point هو الذي يطبق الفلاتر على الرزم، ويمكن أن يكون منفصلاً عن PAA. ويضع RFC 5191 بروتوكول PAA–EP وإنشاء access-control filters خارج نطاقه.

يشترط النص حماية provisioning بين PAA وEP بالمصادقة والسلامة ومنع replay. الشرط يحمي الأمر؛ ولا يثبت أن كل EP استلمه وثبته.

يجب حفظ مجموعة EP المستهدفة، policy version، ربط PaC والواجهة، transaction، ack، بصمة المرشح والقراءة اللاحقة. النجاح في PAA لا يتحول إلى نجاح في أربعة EPs ما لم توجد أربعة أدلة أو quorum معلن يناسب المسار.

AUTH يحمي إشارات PANA

عندما تنتج EAP مفتاح MSK، تنشأ PANA SA ويُشتق PANA_AUTH_KEY. يستخدم AUTH لحماية رأس PANA وحمولته ورسالة EAP المنقولة. هذا دليل قوي ضد الحقن والتعديل وإعادة الإرسال في قناة التحكم.

أما حماية data traffic لكل رزمة فهي خطوة أخرى. يمكن اشتقاق مفاتيح واستخدامها مع secure association protocol على طبقة الربط أو IPsec، لكن كيفية ذلك خارج RFC 5191.

لذلك لا يثبت AUTH أن بيانات المستخدم مشفرة. يحتفظ النظام بكائن PANA SA يحوي Session ID وKey-Id والتحقق والمدة، وبكائن data SA يحوي الأطراف والـselectors والخوارزميات وحالة التركيب والعدادات. تربطهما علاقة اشتقاق دون أن تمحو اختلافهما.

إذا كانت الطبقة السفلى توفر الحماية، يجب أن يكون هذا قرار policy صريحاً. غياب data SA بلا سياق ليس دليلاً على الأمان ولا على الفشل.

قد يلزم عنوان جديد بعد النجاح

يسمح RFC 5191 بأن يطلب PAA من PaC إعادة إعداد عنوان IP بعد نجاح المصادقة والتخويل، لأن العنوان المستخدم أثناء PANA قد لا يصلح لتبادل البيانات عبر EP. يحمل الطلب IP Reconfiguration bit، بينما تبقى آلية الإعداد خارج الوثيقة.

وهذا يعني أن نجاح control exchange لا يثبت lease جديداً ولا neighbor ولا route ولا تحديث filter. يجب الاحتفاظ بعنوان ما قبل المصادقة والواجهة وتعليمة التغيير والعنوان الجديد ومصدره وحالة الطريق وأول رزمة مرصودة.

استبدال العنوان القديم في database يجعل سجل PANA يبدو منفصلاً عن capture اللاحق. كما قد يترك EP مرتبطاً بالtuple القديم بينما يستخدم العميل الجديد، فتبدو الجلسة مخولة بلا مرور.

Ping يثبت حياة peer لا حياة الخدمة

في access phase يمكن استخدام PANA Notification مع Ping bit لاختبار liveness. answer صالح لطلب حديث يثبت أن PANA peer حي.

لا يسأل الاختبار EP المنفصل عن مرشحه، ولا يختبر route أو data SA أو التطبيق. قد يجيب PAA بينما فقد EP السياسة. وقد يفشل keepalive بسبب congestion مع بقاء data path عاملاً؛ ويحذر RFC من الإنذارات الكاذبة عند الاستخدام الدوري غير المنضبط.

التعبير الدقيق هو «استجاب PAA لطلب PANA محمي في T». عبارة «الخدمة سليمة» تحتاج قياساً آخر يمر بالمسار المقصود.

Lifetime هو عمر التخويل

يرتبط PANA session lifetime بعمر التخويل الحالي، ويمكن إعادة المصادقة لتمديده. وتتبع PANA SA عمر الجلسة.

هذه ساعة للpermission وcontrol state، لا وعداً باستمرار lease أو filter أو ciphering أو application. يجب حفظ أعمار التخويل والجلسة والمفتاح والعنوان وقاعدة EP وdata SA وفترة الخدمة المرصودة كلٌّ على حدة.

الاختلاف بينها ليس خطأ في العرض؛ إنه الدليل الذي يحدد أين انقطعت السلسلة. نسخ lifetime إلى SLA يحول قيمة سياسة إلى قياس لم يحدث.

الإنهاء يحتاج إثبات حذف

يمكن لـPaC أو PAA إنهاء الجلسة. يفترض أن يزيل ذلك state الجلسة ويوقف accounting ويحذف state الخاص بالعميل من EPs. في البنية المنفصلة تبقى termination رسالة تحكم صحيحة، وليست قراءة بعد الحذف من كل executor.

قاعدة allow متبقية تترك وصولاً غير مقصود، وقاعدة deny متبقية تمنع جلسة جديدة. يحفظ receipt سبب الإنهاء والرسالة المحمية وإغلاق الحساب وقائمة EP وdelete acknowledgements وpost-delete queries.

اختفاء session من PAA لا يثبت اختفاء projections. كما أن expiry أو liveness failure يفسر سبب التنظيف المتوقع، لا نتيجته الفعلية.

سلسلة دليل لا تختصر السلطة

يبدأ السجل بالـPaC والواجهة ومصدر discovery والخدمة المطلوبة. يحفظ رسائل PANA وتسلسلها وإعادة إرسالها والتحقق. يفصل EAP result عن authorization result.

ثم يثبت Result-Code وComplete وKey-Id وAUTH وlifetime. يسجل انتقال العنوان إن طلب. بعد ذلك يتابع provisioning إلى كل EP والمرشحات المقروءة وdata SA عند الحاجة. وأخيراً يضيف packet capture وremote receipt وapplication outcome.

بهذه السلسلة يمكن أن يكون DHCP صحيحاً من دون أن يكون authority مصادقاً، وأن تكون المصادقة صحيحة مع رفض التخويل، وأن يكون التخويل صحيحاً مع EP غير متقارب. لا يوجد تناقض. هناك فقط حدود لم يحترمها الملخص.

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

المصادر

1. RFC 5191 HTML
2. RFC 5191 النص
3. سجل RFC 5191
4. Datatracker RFC 5191
5. تاريخ RFC 5191
6. مراجع RFC 5191
7. تصحيحات RFC 5191
8. RFC 5192
9. سجل RFC 5192
10. RFC 5193
11. سجل RFC 5193
12. RFC 4058
13. RFC 4016
14. RFC 3748
15. RFC 4137
16. RFC 5247
17. RFC 6345
18. Heng Lu — On Reality Layers
19. Heng Lu — Minimum Initial Specification
20. Heng Lu — Running-Code Primacy