تجربة BGP لعام 2010 بين RIPE NCC وجامعة Duke: من الامتثال للمعايير إلى اختبار مساءلة التوجيه

ملخص

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

في 27 أغسطس 2010، عمل موظفو RIPE NCC الذين يديرون خدمة معلومات التوجيه، أو RIS، مع مجموعة بحثية من جامعة Duke على تجربة حية لبروتوكول بوابة الحدود (BGP). كان الباحثون يدرسون تصميم توجيه آمن يحمل معلومات اعتماد في سمة مسار اختيارية متعدية. وفي الساعة 08:41 بالتوقيت العالمي المنسق، أعلنت RIPE NCC عن الشبكة 93.175.144.0/24 من النظام المستقل AS12654 عبر اتصالات في AMS-IX وGN-IX. وتم سحب المسار كما كان مخططًا في الساعة 09:08 بالتوقيت العالمي المنسق.[1]

كان الإعلان غير مألوف لأن السمة كانت جديدة على الإنترنت العام. لكن غير المألوف لا يعني غير صالح. فقد وصفت RIPE NCC وCisco السمة المُطلقة بأنها صالحة أو متوافقة مع المعايير.[1][2] وهذا التمييز يحدد كيفية تحليل الحدث. لم تُظهر التجربة ببساطة أن الموجّهات ترفض المدخلات غير الصالحة، بل أظهرت أن مدخلاً متوافقًا مع المعايير يمكن أن يجتاز الفحوصات الرسمية، ثم يصادف عيبًا في البرمجيات المنشورة، فيتلف أثناء النشر، ثم يفعل معالجة أخطاء شديدة في مكان آخر.

ذكرت Cisco أن أنظمة IOS XR المتأثرة أساءت التعامل مع السمة المتعدية الصالحة ولكن غير المعترف بها أثناء إرسالها إلى الأمام. فقد يستقبل الموجّه المجاور تحديث UPDATE الناتج التالف ويعيد ضبط جلسة النظير في BGP. ولأن جلسة BGP تحمل العديد من المسارات، فإن الاستجابة لتحديث تالف واحد قد تزيل مؤقتًا معلومات وصول صالحة غير مرتبطة. وإذا لم يكتشف الموجّه المسؤول عن التلف الخارجي خطأه، فقد يعلن المعلومات المشكلة مرة أخرى بعد عودة الجلسة، مما يجدد عدم الاستقرار.[2][3]

تدعم قياسات RIPE NCC استنتاجًا بأثر محدود لكنه ملموس. فقد أنتج الحدث معدلات تحديث وصلت إلى عشرين ضعف خط الأساس المحيط. وقدرت RIPE أن 0.5 في المائة إضافية من البادئات أصبحت غير قابلة للوصول تمامًا لفترة أطول من المعتاد. وبلغت نسبة البادئات غير المستقرة ذروتها عند 1.4 في المائة، أي ما يمثل نحو 4,500 بادئة وحوالي تسعة أضعاف المستوى العادي الملاحظ حول الحدث. وتباينت النتائج حسب المجمّع والموقع، مع نشاط تحديث مكثف بشكل خاص في مجمّع فيينا.[1]

هذه الأرقام مهمة، لكنها ليست ترخيصًا للادعاء بأن نسبة معروفة من المستخدمين أو الموجّهات أو الشبكات أو حركة المرور قد اختفت. فملاحظات مستوى التحكم تعد سلوك التوجيه، لا الأشخاص. ولم يعثر تحليل DNSMON من RIPE على فشل في خوادم الجذر. لكنه وجد فقدانًا محدودًا للاستعلامات في بعض النطاقات المراقبة ومشاكل أكثر وضوحًا في أجزاء من البنية التحتية للسلطة.si و.fr، بينما استمرت الخوادم الزائدة في الإجابة.[1] وذكرت تعليقات المشغلين المعاصرة مشاكل في الوصول وتغييرات في حركة التبادل، لكن هذه التقارير لا تشكل حسابًا كميًا كاملاً.[4][6]

لذا فإن درس المساءلة أضيق وأكثر فائدة من قصة جهة واحدة «كسرت الإنترنت». فقد تحكمت RIPE NCC في ما إذا كانت بنيتها التحتية للقياس ستطلق مسارًا تجريبيًا مرئيًا على الإنترنت، إلى جانب التوقيت والإشعار والمراقبة والسحب. وتحكم باحثو Duke في تصميم البحث والتنفيذ الخاص بالبحث. وتحكمت Cisco في معالجة IOS XR للسمة الصالحة غير المعترف بها، واختبار المنتج، والإفصاح، وإصلاحات الصيانة. وتحكم مشغلو الشبكات في برمجياتهم المثبتة وسياسات التوجيه وحماية النظير والمراقبة والاستعادة داخل شبكاتهم. ووفرت قواعد البروتوكول في تلك الفترة آلية تضخيم من خلال السماح لتحديث UPDATE واحد مشوه بالتسبب في فشل على مستوى الجلسة.

كما كانت الإصلاحات تنتمي إلى طبقات منفصلة. أصدرت Cisco استشارة في يوم الحدث وأعدت ترقيات صيانة.[2] وحافظت RIPE NCC على الأدلة، وزودت البائع بالمعلومات، ونشرت تحليلاً، والتزمت بضوابط أكثر صرامة للتجارب التعاونية المستقبلية.[1] ودعم مجلسها التنفيذي لاحقًا مواصلة البحث مع التأكيد على التواصل المناسب.[5] قلل تصحيح المنتج من مخاطر التنفيذ؛ بينما قللت حوكمة التجارب الأقوى من خطر اكتشاف تفاعل مجهول عبر نطاق فشل عام واسع بلا داع.

تساعد المعايير اللاحقة في تفسير كيفية تعلم الصناعة من هذه الفئة من الفشل، لكنها لا يمكن استخدامها كدليل على ما كان منشورًا أو مطلوبًا في أغسطس 2010. فقد روج RFC 7606 لاحقًا لمعالجة أضيق لتحديثات BGP المشوهة لأن إعادة ضبط جلسة كاملة يمكن أن تتجاهل العديد من المسارات الصالحة.[13] وتضيء التوصيات التشغيلية المتعلقة بالسياسة الخارجية الصريحة ومنع تسرب المسارات والتحقق من الأصل وRPKI وBGPsec الضوابط المجاورة، لكن أياً منها لا يثبت الإهمال بأثر رجعي، ولا يصحح وحده عيب التلف الخارجي الدقيق الذي كشفه هذا الحدث.[14][15][16][17][18][19][20]

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

1. لماذا يستحق هذا الحدث تحليلاً دقيقًا

غالبًا ما تُختزل حوادث BGP في تسميات مثل تسرب أو اختطاف أو انقطاع أو سوء تهيئة. يمكن أن تكون هذه التسميات مفيدة عندما تناسب الأدلة، لكنها قد تمحو الآلية المهمة فعلاً. يتطلب هذا الحدث حدًا أدق.

الموضوع هو فقط تجربة RIPE NCC وجامعة Duke في 27 أغسطس 2010. وليس سردًا لتسربات مسارات لاحقة أو اختطافات لاحقة أو كل فشل BGP لاحق. إن تصنيف تسرب المسارات في RFC 7908 اللاحق مفيد للتمييز بين الفئات، لكنه لا يبرر إعادة تسمية هذه التجربة كتسرب مسار تقليدي دون دليل على أن شروط التسرب المحددة حدثت.[16]

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

1. هل كان تحديث BGP المُطلق صالحًا؟
2. أي مكوّن حوّل المعلومات الصالحة إلى معلومات تالفة؟
3. أي ضوابط سمحت للفشل الناتج بالانتشار خارج نطاق اختبار محدود بدقة؟

يجيب السجل المتاح عن السؤالين الأولين بثقة عالية نسبيًا. فقد وصفت كل من RIPE NCC وCisco السمة الأصلية بأنها صالحة أو متوافقة مع المعايير، بينما حددت Cisco ثغرة في IOS XR تتضمن تلفًا أثناء النشر.[1][2] وسجلت NVD مشكلة المنتج باسم CVE-2010-3035.[3]

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

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

توجد RIS نفسها لجمع وعرض معلومات التوجيه من نقاط مراقبة متعددة.[7][8] توفر سجلات RIPEstat وقاعدة بيانات RIPE سياق تحديد لـAS12654، لكن سجل النظام المستقل لا يمكنه كشف كل سلوك برمجي يصادف على طول مسار منشور.[9][10] تعد أنظمة تجميع المسارات مثل RIS وRoute Views قيّمة على وجه التحديد لأنه لا يمكن لأي سجل واحد أو بيان نظير أو سجل محلي أن يصف نظام التوجيه بين النطاقات بالكامل.[11]

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

2. التسلسل الزمني: من إعلان مجدول إلى اضطراب غير مقصود

قبل 08:41 بالتوقيت العالمي: التصميم والفحص قبل الإعلان

كانت مجموعة بحث Duke تدرس تصميم توجيه آمن تنتقل فيه معلومات الاعتماد في سمة مسار BGP اختيارية متعدية. وقدمت Duke تنفيذًا معدلاً لـQuagga ضمن الجهد البحثي. وأثبتت الفحوصات السابقة للإعلان أن السمة لها شكل بروتوكول مقبول، وأن نسخة Quagga ثانية لم تستنسخ السلوك الذي شوهد لاحقًا في المعدات المنشورة المتأثرة.[1]

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

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

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

08:41 بالتوقيت العالمي: يصبح المسار مرئيًا

في الساعة 08:41 بالتوقيت العالمي المنسق يوم 27 أغسطس 2010، بدأت RIS AS12654 بالإعلان عن 93.175.144.0/24 مع السمة الاختيارية المتعدية التجريبية. وانتقل الإعلان عبر اتصالات RIPE NCC في AMS-IX وGN-IX.[1]

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

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

أثناء النشر: تتلف المعلومات الصالحة

استقبلت أنظمة IOS XR المتأثرة سمة لم تتعرف عليها. وبموجب تصميم السمة الاختيارية المتعدية في BGP، لم يكن عدم التعرف بحد ذاته سببًا لرفض السمة. السلوك ذو الصلة هو الحفاظ عليها ونشرها.

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

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

ثم عبر التلف حدود التنفيذ. استقبل جار لاحق تحديثًا لم يعد مكافئًا للتحديث الصالح الذي أطلقته التجربة.

الاستقبال في اتجاه التيار: تحديث واحد يهدد جلسة كاملة

بموجب قواعد معالجة الأخطاء المرتبطة بخط الأساس للمعايير في تلك الفترة، يمكن أن تنتج سمة مسار مشوهة خطأ في رسالة التحديث وإغلاق جلسة BGP.[12] كانت هذه الاستجابة شديدة بالتصميم: فالموجّه الذي لا يستطيع تفسير معلومات التوجيه بأمان يحمي نفسه بإنهاء الجلسة.

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

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

لذلك كانت سلسلة الفشل أكبر من البادئة التجريبية:

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

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

09:08 بالتوقيت العالمي: السحب المجدول

سحبت RIPE NCC الإعلان التجريبي في الساعة 09:08 بالتوقيت العالمي المنسق، كما كان مخططًا.[1] وبذلك يكون المسار قد أُطلق لمدة سبع وعشرين دقيقة تقريبًا.

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

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

بعد السحب: استجابة المشغلين وجمع الأدلة

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

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

22:00 بالتوقيت العالمي: استشارة Cisco

نشرت Cisco استشارتها حول IOS XR في الساعة 22:00 بالتوقيت العالمي المنسق يوم 27 أغسطس 2010.[2] وسُجلت المشكلة باسم CVE-2010-3035، وأعدت Cisco ترقيات صيانة برمجية.[3]

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

31 أغسطس وما بعده: التحليل العام واستجابة الحوكمة

نشرت RIPE NCC تحليلها للحادث والقياسات في 31 أغسطس 2010.[1] وصف الحساب التجربة، وتفاعل التنفيذ، وآثار التوجيه الملاحظة، ونتائج DNSMON، والتغييرات المستقبلية المحتملة للتجارب التعاونية.

قالت RIPE NCC إن التجارب المستقبلية ستحظى بمعاملة أكثر صرامة، بما في ذلك تقييم أثر شامل، وإشعار مسبق كافٍ للمشغلين، ومعالجة مسؤولة للثغرات.[1] ودعم مجلسها التنفيذي لاحقًا استمرار التجريب مع التأكيد على التواصل المناسب.[5]

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

3. ما هي السمة الاختيارية المتعدية — ولماذا لا تعني «غير معروفة» أنها «غير صالحة»

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

يحدد RFC 4271 السلوك ذا الصلة. السمة الاختيارية غير المتعدية غير المعترف بها لا تحتاج إلى إعادة توجيه. أما السمة الاختيارية المتعدية غير المعترف بها فهي مختلفة: تُقبل وتُمرر إلى نظائر BGP الآخرين، مع استخدام بت الجزئي للإشارة إلى أن نظامًا وسيطًا لم يتعرف على السمة بالكامل.[12]

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

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

يجب أن تبقى أربعة مفاهيم منفصلة:

الاعتراف.هل يفهم الموجّه دلالات السمة؟

القبول.هل للسمة شكل يمكن للموجّه استقباله بأمان بموجب قواعد البروتوكول؟

النشر.هل يجب أو يمكن للموجّه تمرير السمة إلى الأمام؟

الطفرة.هل يغير الموجّه السمة، وإذا كان كذلك، فهل التغيير مسموح ومشفر بشكل صحيح؟

لم يتطلب حدث 2010 من أنظمة IOS XR المتأثرة فهم مخطط الاعتماد البحثي. كان العيب يتعلق بالنشر. كان حساب Cisco أن الأنظمة المتأثرة أتلفت السمة المتعدية الصالحة غير المعترف بها أثناء إرسالها إلى الأمام.[2]

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

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

لا تفسر طبقة واحدة وحدها الأثر:

• قدمت التجربة المدخل غير المألوف.
• قدم المنتج المتأثر التلف.
• قدمت استجابة الخطأ اللاحقة فقدان الجلسة.
• قدمت إعادة تقارب BGP تضخيم التحديثات.
• قدم النشر العام نطاق الفشل.

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

الوصف الدقيق هو فشل متسلسل بمالكين نقاط تحكم مميزين.

4. من تحديث واحد تالف إلى عدم استقرار أوسع في التوجيه

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

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

حجم التحديثات في الحدث يتسق مع آلية التضخيم هذه. لاحظت RIPE معدلات تحديث وصلت إلى عشرين ضعف خط الأساس المحيط.[1] وهذا قياس مستوى تحكم: كانت الموجّهات تتبادل تغييرات توجيه أكثر بكثير. لا يذكر مباشرة مقدار حركة التطبيقات المفقودة، لكنه يُظهر أن الاضطراب امتد إلى ما هو أبعد من رفض هادئ واحد لبادئة واحدة.

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

1. إنشاء الجلسة؛
2. إعلان المسار؛
3. التلف أثناء النشر؛
4. استقبال تحديث مشوه؛
5. إغلاق الجلسة؛
6. سحب المسار وإعادة التقارب؛ و
7. تجدد الإنشاء.

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

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

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

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

5. التأثير المحدود: ما تدعمه الأدلة

توفر قياسات RIPE ثلاثة مؤشرات رئيسية.

أولاً، وصلت معدلات تحديث التوجيه إلى عشرين ضعف خط الأساس المحيط.[1] وهذا يثبت نشاط مستوى تحكم استثنائي أثناء نافذة الحدث. عبارة «وصلت إلى» مهمة: فهي تصف ذروة، لا معدلاً موحدًا في كل مجمّع أو طوال الفترة.

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

ثالثًا، بلغت حصة البادئات غير المستقرة ذروتها عند 1.4 في المائة. ربطت RIPE تلك الذروة بنحو 4,500 بادئة، أي نحو تسعة أضعاف المستوى المعتاد.[1] «غير مستقر» ليس مطابقًا لـ«غير قابل للوصول عالميًا». قد تمر البادئة بتغييرات مسار متكررة مع بقائها قابلة للوصول من بعض الأماكن.

تدعم هذه النتائج الاستنتاج بأن الحدث تسبب في عدم استقرار توجيه مادي وملموس وموزع. ولا تدعم التأكيد على أن 1.4 في المائة من الإنترنت انقطع بالكامل.

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

التباين الجغرافي وبين المجمعات

تباينت الآثار حسب الموقع والمجمّع. أظهر مجمّع فيينا نشاط تحديث مرتفعًا بشكل خاص.[1] يمكن أن يعكس التباين الطوبولوجيا واختيار النظير والتعرض للتنفيذات المتأثرة وتوفر مسارات بديلة.

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

ملاحظات DNS

استخدمت RIPE أداة DNSMON لفحص ما إذا كان اضطراب التوجيه أنتج آثار DNS مرئية. ولم تجد فشلاً في نظام خوادم الجذر.[1] هذا الاستنتاج السلبي مهم لأن عدم استقرار التوجيه الواسع لا يعني تلقائيًا فشل كل خدمة حرجة.

لاحظ التحليل فقدانًا محدودًا للاستعلامات في بعض النطاقات المراقبة وصعوبة أكثر وضوحًا في أجزاء من البنية التحتية للسلطة.si و.fr. واستمرت الخوادم الزائدة في الإجابة.[1] لذا تدعم الأدلة آثار DNS جزئية وغير متساوية، لا فشل DNS شامل.

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

تقارير المشغلين

سجلت المنتديات التشغيلية المعاصرة تقارير عن انقطاع الوصول وتفاعلات التوجيه وتغييرات حركة المرور.[4][6] تساعد هذه التقارير في إثبات أن الحادث كان مرئيًا خارج المؤسسات المُطلقة. ويمكنها أيضًا تحديد أسئلة لمزيد من التحقيق.

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

ادعاءات لا تدعمها الأدلة

لا يثبت السجل المحدود:

• قائمة كاملة بإصدارات IOS XR المتأثرة كما كانت منشورة وقتها؛
• عددًا دقيقًا للموجّهات أو الأجهزة المتأثرة؛
• كل نظام مستقل أعاد ضبط جلسة؛
• عددًا دقيقًا للمستخدمين المتأثرين؛
• إجمالي حركة التطبيقات المفقودة؛
• فشلاً شاملاً للبادئة التجريبية؛
• فشل جذر DNS؛
• نية خبيثة من RIPE NCC أو Duke أو Cisco أو المشغلين؛
• حسابًا كاملاً لكل موافقة سابقة للحدث؛
• أن كل مشغل كان لديه تخفيف متاح قبل الحدث؛ أو
• مسؤولية قانونية.

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

6. المساءلة عبر توزيع نقاط التحكم

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

تحكم RIPE NCC

تحكمت RIPE NCC في الفعل الذي أدخل المسار التجريبي إلى النشر العام. كانت RIS AS12654 هي المنشأ المستخدم للاختبار، وعبر الإعلان اتصالات RIPE NCC في AMS-IX وGN-IX.[1] كما تحكمت RIPE NCC في السحب المخطط وجمع الأدلة وقواعدها المستقبلية للبحث التعاوني المماثل.

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

يشير الالتزام اللاحق بتقييم أثر أكثر شمولاً وإشعار مسبق للمشغلين ومعالجة مسؤولة للثغرات إلى أن RIPE NCC حددت بنفسها تحسينات في الحوكمة.[1] ويعزز دعم المجلس التنفيذي لاستمرار التجريب مع تواصل مناسب التمييز بين شرعية البحث وكفاية ضوابطه التشغيلية.[5]

تحكم Duke

تحكم باحثو Duke في تصميم بحث التوجيه الآمن وقدموا تعديل Quagga المستخدم ضمن نطاقهم. ساعد عملهم في إنشاء المدخل التجريبي الصالح. لا يُظهر السجل المتاح أنهم تحكموا في المعالجة الداخلية لـIOS XR أو استجابة الخطأ لدى الموجّهات اللاحقة.

تتعلق مساءلة جانب البحث بافتراضات التصميم واتساع اختبار التشغيل البيني. يمكن لنسخة Quagga ثانية أن تُظهر السلوك في بيئة برمجية مماثلة. لكنها لا يمكن أن تثبت السلامة عبر جميع التنفيذات المنشورة ذات الصلة.

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

تحكم Cisco

تحكمت Cisco في تنفيذ IOS XR المتأثر. حددت استشارتها تلف سمة متعدية صالحة غير معترف بها أثناء النشر.[2] يقع هذا السلوك ضمن نطاق تحكم المنتج: التحليل والاحتفاظ والتسلسل ومعالجة أعلام السمة واختبار الانحدار.

كما تحكمت Cisco في استجابة الإفصاح والصيانة. ظهرت الاستشارة في يوم الحادث، وأُعدت ترقيات صيانة برمجية.[2] يوفر CVE-2010-3035 معرف الثغرة العام.[3]

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

تحكم المشغلين

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

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

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

لماذا لا ينبغي إسناد دور مختلق للتبادلات

استخدمت التجربة اتصالات في AMS-IX وGN-IX.[1] تثبت هذه الحقيقة مسار نشر. لكنها لا تثبت، بدون أدلة إضافية، أن أيًا من التبادلين صمم التجربة أو وافق على السمة أو شغل موجّهًا متأثرًا أو تحكم في سياسات تصدير المشاركين.

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

7. إصلاح المنتج وإصلاح حوكمة التجارب مساران مختلفان

تطلبت الاستجابة الكاملة مسارين للإصلاح.

إصلاح المنتج

كان عيب المنتج هو تلف سمة متعدية صالحة غير معترف بها أثناء النشر بواسطة أنظمة IOS XR المتأثرة. كان الإصلاح المباشر في البرمجيات واختباراتها.

سيُظهر إصلاح منتج موثوق أن:

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

كانت استشارة Cisco وترقيات الصيانة هي الإجراءات العامة الفورية التي عالجت هذه الطبقة.[2] الاستشارة توصل العيب؛ الترقية تغير التنفيذ. الاثنان مرتبطان لكن غير قابلين للتبادل.

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

إصلاح حوكمة التجارب

لم يكن عيب الحوكمة هو حدوث البحث. بل كان اختبار تفاعل غير مؤكد عبر بنية توجيه عامة دون ضوابط كافية لمنع أو الحد بسرعة من نطاق الانفجار الملاحظ.

حددت استجابة RIPE NCC متطلبات مستقبلية أكثر صرامة: تقييم أثر شامل، وإشعار مسبق كافٍ للمشغلين، ومعالجة مسؤولة للثغرات.[1] تعالج هذه القرارات التي اتخذت قبل وأثناء التجربة.

سيشمل إصلاح حوكمة موثوق:

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

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

لماذا لا يمكن لإصلاح واحد أن يحل محل الآخر

إذا صححت Cisco نظام IOS XR لكن ضوابط التجارب بقيت دون تغيير، فقد تكشف تجربة لاحقة عيبًا مجهولًا مختلفًا في تنفيذ آخر. سيتراجع خطر المنتج المحدد بينما يبقى خطر الاكتشاف.

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

لذا يتطلب الحدث سؤالين مستقلين للإغلاق:

1. هل عيب التنفيذ مصحح ومنشور حيثما كان ذلك ذا صلة؟
2. هل التجارب الحية المستقبلية محدودة وقابلة للملاحظة ومحكومة بطريقة تناسب عدم يقينها؟

تقرير يجيب عن واحد فقط لم يُظهر إصلاحًا كاملاً.

8. المعايير اللاحقة كسياق تحليلي — وليس حكمًا بأثر رجعي

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

RFC 4271: خط الأساس التاريخي

يصف RFC 4271 بروتوكول BGP-4، بما في ذلك السمات الاختيارية المتعدية ومعالجة الأخطاء.[12] تفسر قواعد نشره لماذا يجب حمل السمة المتعدية غير المعترف بها إلى الأمام. كما تساعد معالجة أخطاء التحديث فيه في تفسير لماذا قد تؤدي السمة المشوهة إلى إنهاء الجلسة.

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

RFC 7606: تضييق نطاق الفشل

راجع RFC 7606 لاحقًا معالجة أخطاء تحديث BGP لأن إعادة ضبط الجلسة يمكن أن تتجاهل أعدادًا كبيرة من المسارات الصالحة وتسبب اضطراب توجيه كبيرًا.[13] يروج عمومًا لاستجابات أضيق، بما في ذلك معاملة المسارات المتأثرة كمسحوبة في حالات محددة، بدلاً من تدمير الجلسة بأكملها تلقائيًا.

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

سيكون من غير الدقيق القول إن RFC 7606 كان القاعدة التي حكمت حدث 2010. فقد نُشر لاحقًا. وسيكون من غير الدقيق أيضًا افتراض أن كل تنفيذ حالي يطبق كل توصية بشكل موحد. يشرح RFC اتجاه إصلاح معماري؛ لا تزال أدلة النشر مطلوبة.

RFC 7454 وRFC 8212: سياسة خارجية صريحة

يجمع RFC 7454 توصيات الأمن التشغيلي لـBGP، بينما يؤسس RFC 8212 توقع سياسة صريحة لإعلانات وقبول BGP الخارجي.[14][15] يعززان معًا مبدأ تحكم أساسيًا: لا ينبغي تبادل المسارات الخارجية لمجرد وجود جلسة.

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

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

RFC 7908: تصنيف تسرب المسارات

يصف RFC 7908 أنواع تسرب المسارات.[16] وهو مفيد هنا أساسًا كحد ضد المصطلحات الفضفاضة. تضمن حدث 2010 مسارًا تجريبيًا أُطلق عمدًا وعيب تنفيذ أثر على سمة اختيارية متعدية. لا ينبغي تمديد الأدلة المتاحة لوضعه في فئة تسرب لاحقة دون مطابقة شروط الفئة.

يدعم التصنيف المساءلة عندما يمنع دمج آليات غير مرتبطة. ويقوض المساءلة عندما يحل تسمية مألوفة محل التحليل السببي.

التحقق من أصل RPKI

يصف RFC 6480 بنية البنية التحتية للمفتاح العام للموارد، ويعرف RFC 6811 التحقق من أصل بادئة BGP.[17][18] يسأل التحقق من الأصل ما إذا كان نظام مستقل الأصل مخولًا بموجب تفويض أصل مسار ذي صلة لبادئة.

يعالج هذا الضابط سؤالاً مختلفًا عن السؤال المكشوف هنا. يمكن أن يكون للمسار علاقة أصل مقبولة بينما يحمل سمة يتلفها منتج وسيط لاحقًا. لا يثبت التحقق من الأصل أن كل سمة مسار مشفرة أو محفوظة بشكل صحيح.

لا حاجة إلى استنتاج حول حالة RPKI الفعلية للتجربة. النقطة التحليلية محدودة: التحقق من الأصل، بمفرده، لن يختبر مسار المعالجة الصادرة المتأثر.

BGPsec

يحدد RFC 8205 التحقق من مسار BGPsec.[19] يعالج BGPsec الحماية التشفيرية لمعلومات المسار في بنية محددة. وهو مرتبط بالهدف الأوسع للتوجيه الآمن الذي درسته مجموعة Duke، لكنه ليس دليلاً على ما كان منشورًا أثناء تجربة 2010.

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

إرشادات NIST لأمن التوجيه

يوفر NIST SP 800-189 إرشادات لاحقة لتأمين تبادل حركة المرور بين النطاقات، بما في ذلك حماية التوجيه والممارسات التشغيلية.[20] وهو مفيد لتنظيم التوقعات الحالية حول الترشيح والمراقبة والتحقق والاستجابة.

لا يؤسس واجبًا قانونيًا في 2010 أو يثبت ما كان يعرفه أي مشارك وقتها. استخدامه الصحيح استباقي: السؤال عن الأدلة التي يجب أن تحتفظ بها الشبكة الآن وأي الضوابط يمكنها تقليل سلاسل فشل مماثلة.

9. السيناريوهات المضادة: أي تغيير في الوقائع كان سيقلل الأثر؟

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

السيناريو المضاد 1: يحافظ IOS XR على السمة بشكل صحيح

غيّر حقيقة واحدة: تستقبل أنظمة IOS XR المتأثرة السمة المتعدية الصالحة غير المعترف بها وتنشرها دون تلف.

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

هذا أقوى سيناريو مضاد للمنتج لأنه يزيل آلية التلف المحددة. ولا يثبت عدم تفاعل تنفيذ آخر بشكل سيئ.

السيناريو المضاد 2: الاختبار غير المتجانس يستنسخ السلوك المنشور

غيّر حقيقة واحدة: يشمل الاختبار السابق للنشر تنفيذًا متأثرًا ممثلاً بما يكفي ويفعّل التلف الصادر.

يمكن التحقيق في العيب قبل دخول المسار في نشر عام واسع. يمكن لـCisco استلام حالة الاختبار، بينما يمكن لـRIPE NCC وDuke أن يقررا تأجيل أو تقييد أو إعادة تصميم التجربة.

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

السيناريو المضاد 3: تُجرى التجربة داخل بيئة توجيه محدودة

غيّر حقيقة واحدة: تتفاعل نفس السمة والبرمجيات المتأثرة في بيئة اختبار مغلقة أو محكمة التحكم بدلاً من النشر العام العادي.

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

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

السيناريو المضاد 4: تستخدم الموجّهات اللاحقة معالجة أخطاء تحديث أضيق

غيّر حقيقة واحدة: يحتوي موجّه لاحق الإعلان المشوه دون إغلاق جلسة BGP بأكملها، حيثما تنطبق استجابة ضيقة بأسلوب لاحق.

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

يعكس هذا السيناريو الاتجاه الذي صيغ لاحقًا في RFC 7606.[13] يجب أن يبقى تحليليًا لأن هذا RFC لاحق للحدث، وتعتمد المعالجة الدقيقة على فئة الخطأ والتنفيذ.

السيناريو المضاد 5: يصل الإشعار المسبق إلى المشغلين المتأثرين

غيّر حقيقة واحدة: يستلم المشغلون إشعارًا تقنيًا كافيًا بالبادئة والسمة والنافذة والسلوك المتوقع وشروط التوقف.

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

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

السيناريو المضاد 6: معايير إيقاف كمية تطلق سحبًا أبكر

غيّر حقيقة واحدة: تحدد المراقبة معدلات تحديث غير طبيعية أو إعادة ضبط جلسات مبكرًا بما يكفي لعبور عتبة توقف محددة مسبقًا قبل 09:08 بالتوقيت العالمي.

تسحب RIPE NCC أبكر. ينتهي الإطلاق المستمر أبكر، مما قد يقلل التكرارات وزمن التعرض.

الحد هو حالة BGP الموزعة. التحديثات المنشورة بالفعل ستتطلب سحبًا وإعادة تقارب. يمكن للعمل الأبكر تقليل المدة لكنه لن يعيد فورًا كل المسارات المتأثرة.

السيناريو المضاد 7: تقيد السياسة النشر على نظراء مختارين

غيّر حقيقة واحدة: تقيد سياسات الاستيراد والتصدير المسار التجريبي على الشبكات المشاركة صراحة.

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

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

السيناريو المضاد 8: توفر مجمعات المسارات ومسابر الخدمة إنذارات مترابطة فورية

غيّر حقيقة واحدة: تُربط ملاحظات مستوى التحكم وقياس الجلسة ومسابر الخدمة ذات الصلة في الوقت الفعلي.

يمكن للمحققين تمييز إعلان جديد غير ضار عن تضخيم التحديث واختفاء البادئة وآثار الخدمة أبكر. يصبح قرار السحب مدفوعًا بالأدلة.

لا يمنع هذا التلف الأول. لكنه يحسن الكشف ويقصر الفترة التي يستمر فيها عدم اليقين.

السيناريو المضاد 9: لا تحدث التجربة أبدًا

غيّر حقيقة واحدة: لا يُصدر إعلان عام.

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

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

10. كيف يبدو الإصلاح القابل للتحقق

يجب ربط ادعاء الإصلاح بمصنوعات وملاحظات بدلاً من الطمأنة.

أدلة المنتج

بالنسبة للتنفيذ المتأثر، ستشمل الأدلة الموثوقة:

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

يحدد CVE والاستشارة العامان المشكلة والاستجابة.[2][3] وهما بداية قابلية التحقق، لا البرهان الكامل على إغلاق الميدان.

أدلة التجربة

بالنسبة لتجربة توجيه حية مستقبلية، ستشمل الأدلة الموثوقة:

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

توضح RIS وRoute Views قيمة نقاط مراقبة توجيه متعددة.[7][11] فهي لا تحل محل سجلات الأجهزة أو التقاط الحزم، لكنها يمكن أن تُظهر بشكل مستقل ما إذا كان الإعلان قد انتشر، وما إذا كانت السحوبات تضاعفت، وما إذا كانت الآثار تختلف حسب نقطة المراقبة.

أدلة المشغل

يجب أن يكون المشغل الذي يؤكد حماية شبكته قادرًا على إظهار:

• ما إذا كانت برمجيات IOS XR المتأثرة موجودة أو كانت موجودة؛
• أي إصدار تصحيحي مثبت؛
• كيف تُعرف سياسة المسار الخارجي؛
• كيف تعالج البرمجيات الحالية تحديثات التحديث المشوهة؛
• كيف تُكشف إعادة ضبط الجلسات؛
• كيف يُقاس فقدان المسارات غير المرتبطة؛
• أي حمايات نظير مفعلة؛
• كيف تُسجل قرارات الاستعادة؛ و
• ما إذا كان اختبار انحدار مضبوط قد اكتمل.

هذه هي الاستمرارية التشغيلية في شكل ملموس. بيان تهيئة بدون دليل إصدار عامل غير مكتمل. وإصدار برمجي بدون دليل سياسة وملاحظة غير مكتمل أيضًا.

معايير الإغلاق

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

هذه المعايير منفصلة عمدًا. يجب أن يذكر تقرير الحادث العام أيها محقق وأيها يبقى مجهولاً.

11. الأدلة التي قد تغير الاستنتاج

الاستنتاج الحالي يعتمد على الأدلة. ستتطلب عدة اكتشافات مراجعة مادية.

التقاط حزم يظهر أن السمة المُطلقة كانت مشوهة

إذا أظهرت التقاطات موثوقة أن RIS AS12654 أطلقت سمة مشوهة قبل وصولها إلى نظام IOS XR متأثر، فيجب أن يتغير الاستنتاج بأن مدخلاً صالحًا تلف أولاً أثناء النشر.

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

سجلات أجهزة تحدد نقطة تلف مختلفة

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

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

بيانات مجمّع تراجع تقديرات الأثر ماديًا

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

لن تغير المراجعة تلقائيًا آلية التنفيذ. السبب والحجم أسئلة إثباتية مرتبطة لكن مستقلة.

سجلات الموافقة والمخاطر تظهر ضوابط إضافية

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

وعلى العكس، السجلات التي تظهر أن مخاطر عالية التأثير محددة قُبلت دون تخفيف ستقوي نقد الحوكمة. الحساب العام وحده لا يثبت أي سيناريو.

سجلات منتج تُظهر تحديدًا مسبقًا وتحكمًا فعالاً

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

لا يثبت السجل الحالي مثل هذا التحديد المسبق.

أدلة أثر خدمة أوسع أو أضيق

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

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

12. استنتاج متحفظ

لم تكن تجربة RIPE-Duke لعام 2010 اختطاف مسار خبيثًا تقليديًا، ولا تدعم الأدلة المتاحة تصويرها كذلك. ولم تكن مجرد اختبار معايير غير ضار صادف موجّهات غير عقلانية.

كانت تجربة توجيه حية صادفت فيها سمة اختيارية متعدية صالحة غير مألوفة تنفيذ IOS XR متأثرًا. أتلف ذلك التنفيذ السمة أثناء نشرها. ثم يمكن لموجّه لاحق الاستجابة للتحديث المشوه بإعادة ضبط جلسة BGP، وسحب مسارات صالحة غير مرتبطة، والمساهمة في إعادة تقارب متكررة. التقطت قياسات RIPE اضطرابًا محدودًا لكنه ملموس: معدلات تحديث استثنائية، واختفاء بادئات إضافي، وذروة نحو 4,500 بادئة غير مستقرة.[1][2]

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

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

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

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

المصادر

1. https://labs.ripe.net/author/erik/ripe-ncc-and-duke-university-bgp-experiment/
2. https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20100827-bgp.html
3. https://nvd.nist.gov/vuln/detail/CVE-2010-3035
4. https://puck.nether.net/pipermail/cisco-nsp/2010-August/072867.html
5. https://www.ripe.net/about-us/executive-board/minutes/2010/minutes-73rd-executive-board-meeting/
6. https://seclists.org/nanog/2010/Aug/915
7. https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
8. https://www.ripe.net/analyse/archived-projects/ris-tools-web-interfaces/articles-with-ris-analysis/
9. https://stat.ripe.net/AS12654
10. https://apps.db.ripe.net/db-web-ui/query?searchtext=AS12654
11. https://www.routeviews.org/routeviews/
12. https://www.rfc-editor.org/rfc/rfc4271
13. https://www.rfc-editor.org/rfc/rfc7606
14. https://www.rfc-editor.org/rfc/rfc7454
15. https://www.rfc-editor.org/rfc/rfc8212
16. https://www.rfc-editor.org/rfc/rfc7908
17. https://www.rfc-editor.org/rfc/rfc6811
18. https://www.rfc-editor.org/rfc/rfc6480
19. https://www.rfc-editor.org/rfc/rfc8205
20. https://csrc.nist.gov/pubs/sp/800/189/final