أُعلن المفتاح التالي لكنه لم يُسلَّم: TCP-AO وسلطة حقبة المفاتيح

الخلاصة

• يحدد KeyID الـMaster Key Tuple المستخدم لحماية المقطع المرسل، بينما يعلن RNextKeyID الـMKT الذي يفضله المرسل للتحقق من المقاطع الواردة مستقبلاً. لا يحمل أي منهما السر ولا يثبت أن النظير بدّل مفتاح الإرسال.
• الحالة اتجاهية: لكل طرف مفتاح إرسال حالي ومفتاح استقبال مفضل. خانة واحدة باسم «المفتاح النشط» تمحو أربع حقائق مستقلة لازمة للحكم على الجاهزية.
• لا يُزال المفتاح القديم إلا بعد ظهور الـKeyID الجديد والتحقق الصحيح من MAC في الاتجاهين، واستقرار BGP، ونجاح إعادة الاتصال، ووصول الاعتماد القديم إلى الصفر، وتجهيز تراجع كامل.

قد يقع الحادث رغم أن الفريقين استلما البايتات السرية نفسها عبر قناة خارجية سليمة. الاختلاف في الأسماء المحلية. يثبت الطرف A الـMKT الجديد بقيمتي SendID وRecvID تساويان 42. يخصص B قيمتي SendID وRecvID تساويان 43 وفق نظامه. في تذكرة التغيير يسمي الجميع الكائن «المفتاح 42»، أما البروتوكول فيرى الاتجاه والمعرف الفعلي.

يجعل A الـMKT الجديد مفضلاً للاستقبال. تظل مقاطعه موقعة تحت KeyID=17، لكنها تعلن RNextKeyID=42. يتحقق B من MAC بالمفتاح القديم ثم يبحث، ضمن زوج المقابس نفسه، عن MKT إرسال يحمل SendID 42. إن لم يكن ذلك الكائن موجوداً وجاهزاً فلا يبدل شيئاً وفق RFC 5925. يخص هذا الطلب الفاشل اتجاه B→A، لذلك يواصل B الإرسال بالمفتاح 17. وإذا أعلن B لاحقاً RNextKeyID=43 فلن يستطيع A أيضاً نقل A→B ما لم يملك MKT إرسال جاهزاً بقيمة SendID 43.

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

المعرفان يصفان اتجاهين مختلفين

يستخدم TCP-AO خيار TCP ذي Kind 29، ويحمل Length وKeyID وRNextKeyID وMAC. صغر البنية يدل على وظيفة ضيقة: تنسيق سياقات موجودة مسبقاً، لا توزيع الأسرار.

يصف KeyID المقطع الحالي. يضع المرسل SendID الخاص بالـMKT الجاري، ويجمع المستقبل ذلك البايت مع عناوين المصدر والوجهة والمنافذ ليبحث عن MKT ذي RecvID مطابق. يجب أن يلتقي SendID في طرف مع RecvID الخاص بذلك الاتجاه في الطرف الآخر.

أما RNextKeyID فيتعلق بحركة المستقبل في الاتجاه المعاكس. يعلن المرسل RecvID للـMKT الذي يريد استعماله للتحقق من المقاطع الواردة. لا يغير النظير current_key للإرسال إلا إذا وجد محلياً MKT متوافقاً مع الطلب.

لا تحمل القيم خاصية تشفيرية، ولا ترتيباً زمنياً، ولا معنى محجوزاً، ولا يلزم أن تكون عشوائية. ويمكن أن تختلف في الاتجاهين. تساوي الرقم 42 لا يثبت تساوي السر أو الخوارزمية أو طول MAC أو الصلاحية أو نطاق المقبس.

المعنى الدقيق لـRNextKeyID=42 هو: «أنا جاهز للاستقبال تحت RecvID هذا إذا كان لديك MKT الإرسال المقابل». ليس إيصالاً للمفتاح ولا إقراراً بتفعيله.

الـMKT هو الكائن التشغيلي الحقيقي

لا يقتصر Master Key Tuple على المادة السرية. يربطه RFC 5925 بمعرف اتصال TCP يشمل العناوين والمنافذ المحلية والبعيدة، وقد تدعم المنصة نطاقات أو أقنعة أو wildcards. ويحتوي كذلك SendID وRecvID والمفتاح الرئيسي وخوارزميتي الاشتقاق وMAC وسياسة إدخال خيارات TCP الأخرى في الحساب. ويمكن للإدارة إضافة فترات صلاحية.

يجب أن يطابق المقطع الوارد MKT واحداً بالضبط بواسطة زوج المقابس وKeyID. السر نفسه في VRF أو عائلة عناوين أو اتجاه أو نطاق نظير أو RecvID خاطئ لا يمثل القدرة التشغيلية نفسها.

وسياسة الخيارات حد ثنائي آخر. يحمي TCP-AO حقوله دائماً بعد تصفير حقل MAC أثناء الحساب، أما بقية الخيارات فتعتمد على MKT. اختلاف السياسة أو الخوارزمية أو طول MAC يفشل التحقق حتى مع تطابق البايتات الرئيسية.

لذلك يجب أن يسجل الجرد العناوين والمنافذ ومثيل التوجيه وSendID وRecvID والخوارزمية والطول وسياسة الخيارات والصلاحية ودور current/rnext وحقبة اتصال TCP. عبارة «42 مثبت» لا تكفي للسماح بحذف 17.

المفتاح الرئيسي لا يوقع الحركة مباشرة

يشتق TCP-AO مفاتيح الحركة من MKT وسياق الاتصال: العناوين والمنافذ، وبعد الإنشاء أرقام التسلسل الابتدائية في الاتجاهين. المفاتيح أحادية الاتجاه، ويفصل التصميم بين SYN والحركة اللاحقة.

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

تضيف Sequence Number Extensions حالة عليا عندما يلتف فضاء TCP ذي 32 بت، فتدعم مقاومة replay في الجلسات الطويلة. ولكل اتجاه SNE مستقل يبدأ عند إنشاء الاتصال. لا يفسر التقاط منفرد فشل MAC من دون معرفة الحقبة.

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

الجلسة الواحدة تحمل عمليتي تبديل مترابطتين

لكل طرف current_key واحد كحد أقصى للإرسال وrnext_key واحد مفضل للاستقبال. توجد أربعة مؤشرات مادية بين A وB، لا زر متناظر واحد.

تبدأ العملية بالتثبيت: يصبح الـMKT الجديد صالحاً للاستقبال في الطرفين مع بقاء القديم فعالاً. يجب قراءة الحالة الفعلية للمقبس؛ حفظ الإعداد لا يثبت أن العملية الجارية حمّلته.

ثم يعلن A تفضيل الاستقبال. يحل B رقم RNext في قاعدته المحلية، وإن وجد MKT يغير مفتاح الإرسال. أول مقطع من B يحمل KeyID الجديد ويتحقق منه A يثبت اتجاه B إلى A فقط.

بعدها يعلن B تفضيله ويقرر A بصورة مستقلة. قد يعمل اتجاه بالمفتاح الجديد والآخر بالقديم لفترة مشروعة. ينبغي أن تعرض الواجهة هذه الحالة لا أن تخفيها.

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

عدم التبديل يحفظ القرار المحلي

يمكن أن يكون المقطع صحيحاً تحت المفتاح 17 ويعلن RNextKeyID غير معروف. من دون MKT مطابق لا يغير المستقبل خروجه. الطلب البعيد لا ينشئ حالة محلية ولا يمدد الصلاحية ولا يتجاوز الموافقة.

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

ينبغي للمراقبة أن تتبع النتيجة. هل تغير KeyID الخارج من النظير؟ هل زادت عدادات MAC الصحيحة على MKT الجديد؟ هل ظهرت key-not-found أو bad MAC أو طلبات RNext بلا حل؟ بقاء BGP في Established تحت 17 يثبت استمرار القديم فقط.

إدارة المفاتيح تقع خارج TCP-AO

يفترض RFC 5925 بروتوكولاً خارجياً أو إجراء يدوياً لتوفير MKTs. لا يعرف الخزنة أو API أو قناة النقل أو سلطة الموافقة أو الحراسة أو التدقيق، ولا ينسق إزالة الـMKT القديم.

يربط RFC 6518 العمر المحدود بالحذر التشغيلي: قد تزيد التغييرات اليدوية المتكررة التسرب والخطأ. يجب أن يتيح النقل التدوير بلا إسقاط adjacency، وأن تجعل الإدارة freshness قابلة للتطبيق. ويوصي RFC 7211 بتمكين الاستقبال قبل الإرسال، وفحص اتساق جدول المفاتيح، ومراقبة الانتهاء والتنبيه المبكر.

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

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

الإزالة هي الحافة غير القابلة للعكس

التثبيت يضيف خياراً، والحذف يلغي طريق العودة. بقاء MKT القديم يسمح باتجاه متأخر أو rollback. بعد حذفه تتحول أي فجوة جديدة إلى فقد TCP وBGP.

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

يجب أن تغطي المهلة نشر الإعداد وإعادة الإرسال وتأخر القياس وإعادة الاتصال والتراجع. يسجل كل اتجاه آخر KeyID قديم وأول KeyID جديد، وتثبت زيادة good MAC وعدم زيادة bad/unknown واستقرار BGP وتطابق المسارات مع baseline. واختبار اتصال جديد ضروري لأن اختيار MKT في SYN قد يختلف عن socket قديم.

توثق Linux عدادات good/bad وkey-not-found وAO-required وفحص MKT وأحداث trace. كما تتيح حذفاً قسرياً مع تعيين current/rnext بديل، وتحذر من كسر الاتصال إذا ظل النظير يطلب المفتاح القديم. أداة الإصلاح لا تلغي إثبات الاتجاهين.

يعيد rollback النطاق وSendID وRecvID والخوارزمية والطول وسياسة الخيارات والصلاحية ومصدر السر. «أعد 17» وصف ناقص.

MAC صحيح لا يمنح سلطة للمسار

يثبت TCP-AO أن المقطع يطابق سياق المفتاح المتوقع، ولا يثبت ملكية prefix أو صحة AS_PATH أو سلامة المشغل البعيد. يستطيع نظير شرعي أن يرسل معلومات خاطئة.

يفصل RFC 4272 بين هجمات الخارج وbogus routing الصادر من نظير حقيقي. ويبقي RFC 7454 حماية TCP وGTSM ومرشحات مستوى التحكم وprefix وmax-prefix وسياسة المسار طبقات منفصلة.

يفعل التشخيص الشيء نفسه. يسقط bad MAC قبل BGP. يصل المسار الموثق لكن غير المسموح إلى import policy فيُرفض هناك. وقد يغلق max-prefix اتصالاً سليماً تشفيرياً. لا تصادق إشارة خضراء على بقية الأعمدة.

يثبت الاختبار المحدود الحواف الأربع

نثبت المثيل والعناوين والمنافذ والنظير وحقبة TCP وخط أساس المسارات. نقرأ كل MKT مطابق في الطرفين مع IDs والخوارزميات والطول والسياسة والصلاحية والدور. نقارن السر ببصمة محمية أو اختبار مضبوط، ولا نضعه في التذكرة.

أولاً نثبت جاهزية الاستقبال في الطرفين. ثم يعلن A التفضيل، فنلتقط أول KeyID جديد من B وأول MAC يقبله A. نكرر الاتجاه الآخر مستقلاً.

بعد انتقال الاتجاهين، نرسل KEEPALIVE وعملية BGP محدودة، ونقارن Adj-RIB والمسارات وإعادة الإرسال. بعد التداخل وإعادة الاتصال نثبت صفراً من الاستخدام القديم، ثم نحذف 17 في نظير الاختبار ونكرر الفحص.

قوة TCP-AO في ضيق سلطته. ينسق نظامان مستقلان labels محلية من دون تحويل السلك إلى موزع أسرار. لا تصبح الحقبة 42 حقيقة إلا حين يحلها الطرفان، وينتجها الاتجاهان ويتحققان منها، ويبقى BGP سليماً، وينعدم الاعتماد القديم، ويبقى التراجع. قبل ذلك هي اقتراح.