من يملك توقيت السؤال التالي؟

الخلاصة

• أضاف FORCERENEW في عام 2001 قدرة الخادم على دفع العميل المهيأ إلى إجراء تجديد عادي. كان التغيير في الجهة التي تبادر وفي موعد الطلب، لا في إلغاء الخطوات التي تثبت الإعداد الجديد.
• قدّم امتداد عام 2012 قيمة nonce تُسلَّم أثناء تبادل DHCP وتُستخدم مفتاحًا للتحقق من إشعارات لاحقة. خفّض ذلك الحاجة إلى توزيع السر مسبقًا بقناة منفصلة.
• استهدفت الحماية مهاجمًا خارجيًا لا يرى المحادثات الطبيعية. لم تمنح التبادل الأول مصدر ثقة مستقلًا، ولم تجعل كل خادم محلي مشروعًا أو كل تغيير آمنًا للتطبيقات.

جهاز لا يشكو، وخادم يريد أن يتكلم

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

في DHCP، كان التجديد جزءًا من العمل الطبيعي للعميل. وقد أجازت RFC 2131، المنشورة في مارس 1997، أن يحاول العميل التجديد قبل T1. لذلك لم تكن الإضافة اللاحقة اختراع التجديد المبكر ذاته، بل منح الخادم وسيلة للمبادرة به.

جاءت الوسيلة في RFC 3203 في ديسمبر 2001. يرسل الخادم FORCERENEW إرسالًا أحادي الوجهة إلى العميل. ينتقل العميل إلى حالة التجديد، ثم يرسل DHCPREQUEST وفق الإجراءات العادية. الإشعار لا ينهي المحادثة؛ إنه يدفع الطرف الآخر إلى بدء طلبها التالي.

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

ما الذي لا يفعله الاسم القوي؟

إذا أراد الخادم تغيير عنوان العميل، تصف RFC 3203 سلسلة لاحقة: يجيب عن الطلب برسالة DHCPNAK، فيعود العميل إلى البداية ويرسل DHCPDISCOVER، ثم يستطيع الخادم تقديم عنوان عبر DHCPOFFER. ليس FORCERENEW نفسه هو الرفض أو العرض أو تأكيد اكتمال التخصيص.

وقد ينتهي التجديد إلى الإبقاء على العنوان نفسه. لا يدل وصول الإشعار وحده على أن عنوانًا قد سُحب أو أن عنوانًا آخر أصبح صالحًا للاستخدام. الخلط بين هذه المراحل يحوّل سجل المحاولات إلى سجل نجاحات لم تقع بعد.

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

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

حتى الحقل الذي يعرّف الرسالة يعبّر عن إضافة محدودة. كانت RFC 2132 قد عرّفت الخيار 53 لنوع رسالة DHCP، ثم أضيفت إليه القيمة 9 لـ FORCERENEW. هذه قيمة لنوع رسالة، وليست رقم منفذ أو رقم خيار المصادقة. الاتفاق على معناها يسمح بالتعرّف على الإشعار، ولا يضمن استجابة كل جهاز له.

ثمن تحريك الموعد إلى الأمام

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

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

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

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

التحكم في الموعد يحتاج إلى قيد

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

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

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

في أغسطس 2012، قالت RFC 6704 إن المتطلب السابق أشد مما يلزم لحالة الاستخدام المحددة، وإنه حدّ من تبني FORCERENEW. هذه ملاحظة مؤلفي الوثيقة في ذلك الوقت، وليست إحصاءً معاصرًا. كان اقتراحهم خفض عبء البدء عبر حماية تهديد أضيق.

اتفاق أولًا، ثم سر، ثم استدعاء

استندت الفكرة إلى آلية Reconfigure Key التاريخية في DHCPv6، الواردة في RFC 3315 الصادرة في يوليو 2003. العلاقة هنا بين آليتين لاستدعاء العميل، لا بين البروتوكولين بكل تفاصيلهما. كما أن الاستشهاد بهذه الوثيقة القديمة لا يجعلها المرجع الحالي الشامل لـ DHCPv6.

لا تُستخدم طريقة nonce إلا عندما لا يكون الطرفان مستخدمين للمصادقة السابقة، ويكونان قد تفاوضا على الطريقة الجديدة. يعلن العميل قدرته في DISCOVER وREQUEST، ويشير الخادم إلى تفضيله في OFFER. إعلان القدرة ليس رمز مصادقة، والعميل لا يرسل خيار المصادقة الذي يحمل بروتوكول nonce هذا في رسائله الخاصة.

عندما يتطلب الإجراء ذلك، ينشئ الخادم قيمة عشوائية أو شبه عشوائية قوية بطول 128 بت، ويرسلها ضمن ACK في تبادل REQUEST–ACK. يحفظ العميل القيمة، ويحتفظ بها الخادم أيضًا. وعند الاستدعاء اللاحق يحسب الخادم رمز تحقق باستخدامها مفتاحًا، بدل أن يعرض السر من جديد في كل إشعار.

بهذا لم تعد هناك حاجة إلى تسليم ذلك السر مسبقًا في قناة مستقلة. لكن التسليم لم يختفِ؛ انتقل إلى داخل المحادثة التي ستستند إليها الحماية لاحقًا. وهذه نقطة مهمة عند تقييم ما حققته الآلية وما لم تحققه.

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

القيمة تبقى، أما الرسالة فلا ينبغي أن تعود جديدة

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

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

والخوارزمية التاريخية هنا هي HMAC-MD5. إنها رمز مصادقة للرسالة، وليست تشفيرًا للمحادثة، ولا يمثل وصفها توصية حديثة باختيار خوارزمية. هناك أيضًا معلومات منفصلة لكشف إعادة إرسال رسائل قديمة. وقد أوضح التصحيح الموثق 3474 في عام 2013 أن العداد يجب أن يزيد زيادة صارمة؛ لا يكفي إبقاء القيمة نفسها.

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

الحماية تتبع ما يستطيع الخصم رؤيته

ركزت RFC 6704 على مهاجم خارج الشبكة لا يرى التبادلات العادية بين العميل والخادم. لا يعرف هذا الطرف متى ستقع الاستشارات الطبيعية ولا يملك nonce الذي سُلّم في بدايتها. تمنعه الآلية من اصطناع استدعاء صحيح يجبر العميل على الاستشارة في توقيت يحدده هو، ضمن هذا النموذج.

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

كما أن رفض الرسائل المزورة بعد التحقق منها لا يلغي كلفة التحقق. قد تستنزف كثرتها موارد العميل. هذا حدّ تقني تقره النصوص، وليس ادعاءً بوقوع حادث محدد أو قياسًا لاحتمال الهجمات في شبكة بعينها.

يفصل سجل IANA لمعلمات BOOTP وDHCP بين نوع الرسالة 9 وخيار المصادقة 90 وخيار القدرة 145. الأرقام تنظم لغة مشتركة، لكنها لا تقول إن التنفيذ موجود في كل جهاز، أو إن التفاوض وقع، أو إن التغيير المطلوب مناسب الآن.

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