الخلاصة

  • تجمع RFC 7474 بين boot count من 32 bit وpacket counter من 32 bit. يبقى الأول في non-volatile storage، ويزداد الثاني مع كل إرسال؛ ويرفض المستقبل لكل نوع OSPF قيمة لا تتجاوز آخر قيمة مقبولة.
  • حرر Acee Lindem المعيار الجماعي مع Manav Bhatia وSam Hartman وDacheng Zhang. وحدّه التشغيلي حاسم: إذا أضاع الإصلاح أو الاستبدال سجل الإقلاع الدائم، وجب تغيير المفاتيح؛ أما rollover العادي فيحتاج تداخلاً مثبتاً بين فترات الإرسال والقبول.

رسالة صحيحة تنتظر أن ينسى المستقبل

يسجل مهاجم OSPF Database Description packet محمياً بالمفتاح الصحيح. لا يعرف السر ولا يستطيع تغيير digest. ما دام الجار يحتفظ بقيمة sequence أحدث، لا يفيده التسجيل. ثم تسقط adjacency ويعاد تشغيل process ويبدأ neighbor state المؤقت من جديد. لم تحصل الرسالة على صلاحية جديدة؛ الذي تغير هو أن verifier فقد الدليل على عمرها.

تعالج RFC 7474، المنشورة على Standards Track في أبريل 2015، هذا الانقطاع بالذات. كانت أرقام sequence في آلية OSPFv2 السابقة جزءاً من حالة adjacency. وعندما تنتهي العلاقة يمكن إعادة تهيئة الأرقام، فيعود replay بين sessions ممكناً رغم صحة المصادقة.

الأسماء الكاملة هي Manav Bhatia وSam Hartman وDacheng Zhang وAcee Lindem بصفته editor. يثبت سجل IETF العام مشاركة Lindem وسجله الأوسع في routing، ولا يثبت اختراعاً فردياً أو ملكية OSPF أو جودة أي implementation. الدلالة الأضيق هي الصحيحة: شارك في معيار جماعي جعل chronology الأمن تعبر الحد الذي كان يمحوها.

الـ hash يثبت العلاقة بالمفتاح، لا الحداثة

كانت RFC 5709 قد أدخلت HMAC-SHA إلى OSPFv2. مؤلفوها Manav Bhatia وVishwas Manral وMichael Fanto وRuss White وMichael Barnes وTony Li وRandall Atkinson، وليس Lindem. تقلل الخوارزمية الأقوى احتمال التزوير، لكنها لا تجعل packet أُنشئ بصورة صحيحة في الماضي حديثاً اليوم.

وتصف RFC 6039، لمؤلفيها Vishwas Manral وManav Bhatia وJoel Jaeggli وRuss White، مخاطر manual keys في routing protocols: أسرار طويلة العمر، rollover صعب، replay، وسياق ناقص. تستخدم هنا كخلفية للتهديد لا كعمل منسوب إلى Lindem.

لذلك تجيب عبارة authentication succeeded عن تطابق bytes المحمية مع key. لا تقول إن الرسالة من boot epoch الحالية، ولا إن source address الذي يحدد neighbor محمي، ولا إن secret استُخدم في domain الخاص بـ OSPFv2. integrity وfreshness وcontext أدلة مستقلة.

حقبة تعبر انطفاء الجهاز

توسع RFC 7474 sequence إلى 64 bit. تحمل الـ32 العليا boot count، وتحمل الـ32 الدنيا counter متزايداً بصرامة. الأولى تسمي epoch، والثانية تحدد موقع packet داخلها.

يجب حفظ boot count في non-volatile storage طوال العمر التشغيلي للراوتر. كل فقدان لحالة sequence السابقة، بما فيه cold restart، يزيده. يمكن استخدام snmpEngineBoots، لكن المعيار يوصي بعداد مستقل لـ OSPF كي لا تربط إعادة تهيئة SNMP دورة حياة مختلفة بأمن routing.

يزداد الجزء الأدنى مع كل packet مرسل. يقارنه المستقبل بآخر قيمة مقبولة من النوع نفسه ومن ذلك الجار؛ إن لم يكن أكبر تُسقط الرسالة كـ replay. الفصل حسب packet type يسمح بترتيب وصول مختلف بسبب priority من دون اتهام Hello أو Link State Update الصحيح بأنه قديم.

إذا التف العداد الأدنى يمكن زيادة boot count للحفاظ على monotonicity الكاملة. لا يخفي التصميم reboot، بل يحوله إلى تغيير حقبة authenticated لا يستطيع capture أقدم تجاوزه.

توضع octets الثمانية بعد OSPF packet وتدخل في digest. يحدد Authentication type 3 الصيغة الجديدة، ويتسع Key ID إلى 32 bit. إذا بقيت epoch خارج الحماية أمكن للمهاجم تغيير الدليل نفسه الذي يثبت العمر.

عنوان IP المصدر يدخل في الإثبات

لم يكن الحساب السابق يحمي IPv4 header. لكن OSPF على broadcast وNBMA يستخدم source address ليقرر أي neighbor أرسل packet. وكان تغيير المصدر في رسالة مسجلة يسمح بالتأثير في sequence state لجار آخر من دون كسر digest.

تضع RFC 7474 عنوان IPv4 المصدر في أول أربعة octets من padding المستخدم في RFC 5709. يستخدم sender العنوان الذي سيرسل به، ويستخدم receiver العنوان الذي وصله. يؤدي التغيير إلى authentication failure، فيُحاصر reflection قد يوهم باتصال one-way أو يعطل Database Description exchange.

لا يجمد النص كل حقول IPv4. إنه يحمي الحقل الذي يعتمد عليه OSPF في نسبة الرسالة إلى الجار. هذه مواصفة دنيا تؤمن المعنى المشترك الضروري من دون التوسع إلى سيطرة لا يحتاجها البروتوكول.

حتى السر يحتاج اسماً للبروتوكول

قد تستخدم long-lived key database السر نفسه في أكثر من protocol. تمنع RFC 7474 replay العابر للمجالات بإضافة OSPFv2 Cryptographic Protocol ID من octetين إلى key قبل الحساب. قد تتطابق مادة التخزين بقرار محلي، لكن effective key context يقول OSPFv2.

لا يبرر ذلك sharing الواسع؛ تسريب underlying secret يظل مشتركاً، والمفاتيح المستقلة تضيق blast radius. Protocol ID حد دفاعي داخل بنية مشتركة، وليس شهادة على حسنها.

تدوير المفتاح مدة متداخلة

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

تضيق عملية الاختيار أيضاً بحسب algorithm وpeer أو area وinterface وdirection. يتقدم التطابق الصريح على all. وإذا بقيت مفاتيح إرسال عدة، يُختار الأحدث في بداية send lifetime. يقود Key ID المستقبل إلى symmetric key، لكنه لا يلغي فحص scope والوقت.

الترتيب إذن: توزيع الجديد، فتح قبوله، نقل الإرسال، مراقبة الطرفين، ثم إغلاق القديم. وجود مفتاحين في config لا يثبت overlap صحيحاً، ولا clock سليماً، ولا key الفعلي على wire.

الرفض الواضح أفضل من downgrade صامت

Authentication type 3 لا ينخفض بصمت إلى النوع القديم. إذا خالف النوع الوارد إعداد interface، يُسقط packet وفق قواعد OSPF. قد تفشل adjacency أثناء rollout جزئي، لكن ذلك أفضل من علاقة خضراء يعطي فيها كل طرف معنى مختلفاً للحداثة.

تشمل وحدة التغيير الطرفين: code وtype وalgorithm وKey ID وsecret وlifetimes وepoch. ليس النجاح حفظ الإعداد على جهاز واحد؛ بل قبول الجديد في الاتجاهين، ورفض capture القديم، وثبات adjacency وforwarding.

إذا ضاع تاريخ الإقلاع شاخ المفتاح أيضاً

أقسى قواعد RFC 7474 تخص repair وupgrade وreplacement. إذا فُقد boot count غير المتطاير، يجب تغيير authentication keys. استرجاع Router ID وareas وinterfaces وملف الأسرار يعيد المظهر الإداري، لا الحقبة التي فصلت اليوم عن الأمس.

المفتاح القديم مع epoch معاد ضبطها يسمح للcaptured packets بالعودة إلى فضاء sequence المنخفض. لذلك يكون استبدال الجهاز حدثاً في cryptographic lifecycle، لا مجرد restore للإعداد.

تبقى حدود معلنة. replay كامل ومطابق لإنشاء session لراوتر خرج نهائياً من الخدمة احتمال بعيد، وتغيّر key يوقفه أيضاً. وإذا استخدم رابطان unnumbered point-to-point نفس source وsequence مع تهديد tap نشط، توصى keys مختلفة لكل interface. Automatic key management خارج النطاق.

قاعدة مشتركة صغيرة وحراسة محلية كبيرة

يوفر نص Lu Heng اللاحق Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption إطاراً تحليلياً لـ Sofia Ren. يمكن مشاركة sequence format وauthenticated source وprotocol ID وKey ID وقاعدة الرفض؛ وتبقى generation وcustody وscope والتوقيت وrollout وrecovery محلية.

يرفع Running-Code Primacy معيار الدليل: boot count دائم، sequence مرسلة، key مختار، digest مربوط بالمصدر، قرار receiver، replay counters، adjacency وforwarding في chain واحدة. هذا تطبيق لاحق من Sofia Ren، وليس دليلاً على نية Lindem الخاصة أو نية IETF خارج RFCs.

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

المصادر