Cloudflare وتسرب المسار في يونيو 2019 والمساءلة خارج حدود الشبكة

ملخص

• في 24 يونيو 2019، تم تمرير مسارات مُحسَّنة وأكثر تحديدًا تم إنشاؤها داخل شبكة DQE Communications عبر العميل AS396531 وقبلتها شركة Verizon من AS701. ثم قامت Verizon بنشر المسارات التي تغطي آلاف الشبكات. ونظرًا لأن أجهزة التوجيه تُفضّل بادئة وجهة أكثر تحديدًا، فقد اتبعت حركة مرور كبيرة المسارات المُسرَّبة إلى روابط لم تكن مُجهَّزة لاستيعابها؛ وأبلغت Cloudflare عن فقدان حوالي 15% من حركتها العالمية في أسوأ نقطة من الحادث.
• يُظهر سجل المسار العام سلسلة من إخفاقات التحكم، وليس شعارًا لسبب واحد. لم يحتفظ مُنشئ المسار بمسارات التحسين المحلية الخاصة به، وقام عميل متعدد المنازل بتصدير المسارات التي تعلمها المزود إلى مزود آخر، وقبلت شبكة عبور رئيسية ونشرت مسارات لا تتناسب مع سلطة التوجيه المتوقعة للعميل. كان بإمكان Cloudflare اكتشاف المسارات والإبلاغ عنها والمساعدة في سحبها، لكنها لم تستطع تغيير سياسة استيراد شبكة أخرى من جانب واحد.
• كان التحقق من أصل المسار RPKI مُطابقًا بشكل جيد غير معتاد لجزء Cloudflare من هذا الحدث لأن تفويضات أصل المسار الخاصة بـ Cloudflare سمحت ببادئاتها المجمعة فقط بطول أقصى مُحدد. تجاوزت المسارات الأكثر تحديدًا المُسرَّبة هذا الطول وبالتالي كانت غير صالحة. هذا لا يجعل من RPKI حلاً كاملاً لتسرب المسار: يمكن أن تنتهك المسارات الصالحة للأصل العلاقات التجارية، وهذا هو السبب في أن تصفية العملاء وحدود البادئات وأدوار BGP وضوابط المسار والمراقبة وجهات اتصال العمليات التي يمكن الوصول إليها تظل ضرورية.
• تتبع المساءلة قدرة التحكم. يجب على المشغلين الذين يُنشئون أو يُصدرون مسارات استثنائية احتواؤها واختبارها؛ ويجب على مقدمي الخدمة التحقق مما يُمكن للعملاء الإعلان عنه؛ ويجب على منصات السحابة نشر سلطة المسار ومراقبة المسارات الخارجية والتنسيق بسرعة والكشف عن تأثير العملاء؛ ويجب على العملاء التخطيط لفشل التبعية؛ ويجب على مجالس الإدارة والهيئات التنظيمية المطالبة بضمان أمن المسار المُقاس بدلاً من بيان عام باتباع أفضل ممارسات الصناعة.

انقطاع في التوجيه، وليس فشلاً في خوادم Cloudflare

في الساعة 10:34:25 بالتوقيت العالمي المنسق يوم 24 يونيو 2019، بدأت جامعات BGP العامة في تسجيل مسارات غير طبيعية وأكثر تحديدًا لمساحة عناوين Cloudflare. اختفى آخر مسار مدروس من مسارات Cloudflare في الساعة 12:38:54 بالتوقيت العالمي المنسق. يعيدالغوص العميق لمسار Cloudflare المؤرشفبناء تلك الفترة من بيانات RIPE NCC ويُظهر مسارًا متسقًا بشكل ملحوظ: AS13335 الخاص بـ Cloudflare، وأحد مزودي العبور لها، وAS33154 الخاص بـ DQE Communications، وAS396531 الخاص بـ Allegheny Technologies، وAS701 الخاص بـ Verizon. ثم تعلمت الشبكات الأخرى المسار عبر Verizon.

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

أفادتفسير Cloudflare المعاصر للحادثبأن حوالي 15% من حركتها العالمية فقدت في أسوأ نقطة. هذا قياس للشركة، وليس نسبة انقطاع عالمي تم تدقيقها بشكل مستقل. وهو يصف حركة مرور Cloudflare، وليس 15% من الإنترنت بالكامل. ومع ذلك، تدعم الملاحظة المستقلة الآلية العامة والتأثير عبر الخدمات. أفادت ThousandEyes فيتحليل مسار الشبكةبأن المستخدمين واجهوا صعوبة في الوصول إلى الخدمات التي تواجهها Cloudflare وبعض خدمات AWS لمدة ساعتين تقريبًا، بينما سجلتمراجعة حادثة Catchpointمشاكل في الأداء عبر خدمات محددة عبر الإنترنت حوالي الساعة 10:30 بالتوقيت العالمي المنسق.

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

وصفسجل حالة Cloudflare للحدثأولاً مشكلات أداء الشبكة، ثم حدد تسربًا محتملاً للمسار، وقال لاحقًا إن الشبكة المسؤولة أصلحته. تضع النسخ العامة لتحديثات الحالة إشعار التحقيق في الساعة 11:02 بالتوقيت العالمي المنسق، وتحديد الهوية في الساعة 11:36 بالتوقيت العالمي المنسق، والمراقبة بعد التصحيح في الساعة 12:42 بالتوقيت العالمي المنسق. يُظهر أرشيف BGP مسارات غير طبيعية قبل إشعار الحالة الأول. هذا الفرق ليس دليلاً على أن Cloudflare تجاهلت حدثًا معروفًا لمدة 28 دقيقة. إنه سؤال مساءلة مفيد: متى اكتشفت الأنظمة الآلية حركة مرور غير طبيعية، ومتى حدد المهندسون التوجيه الخارجي كسبب، ومتى كان لدى الشركة ثقة كافية لإخطار العملاء؟

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

كيف أصبح التحسين المحلي مسارًا عالميًا

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

قبل الحادث، استخدمت DQE منتج تحسين BGP من Noction. يمكن لمثل هذا المنتج قياس أداء المسار وحقن مسارات أكثر تحديدًا للتأثير على الرابط الذي يحمل حركة المرور المحددة. في المثال الذي نشرته Cloudflare، تم تقسيم إعلان104.20.0.0/20العادي إلى104.20.0.0/21و104.20.8.0/21. يغطي الـ /21ان نفس نطاق العناوين مثل /20، لكن كل واحد يُسمي كتلة وجهة أصغر.

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

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

ربطتحليل التوجيه المنفصل لـ Qrator Labsالبداية بإعادة إنشاء جلسة BGP بين AS396531 وVerizon بعد الساعة 10:35 بالتوقيت العالمي المنسق. يقول تقريرها إن AS396531 فقد المرشحات وقام بتصدير المسارات المُتعلمة من DQE. يوفر هذا سببًا معقولاً لبدء الحالة عندما بدأت، لكن السجل العام المتاح لا يتضمن تكوينات أجهزة التوجيه أو السجلات من AS396531 أو DQE أو Verizon. الاستنتاج الآمن أضيق: يثبت المسار القابل للملاحظة أن المسارات عبرت حدود AS هذه؛ تحدد تقارير المشغلين المرشحات المفقودة أو غير الكافية؛ يبقى التسلسل الدقيق للتغييرات الداخلية غير عام.

يمنع هذا التمييز ثلاثة أخطاء شائعة. أولاً، لا ينبغي وصف DQE بأنها أصل مساحة عناوين Cloudflare بالمعنى BGP. كان مسار AS الملاحظ لا يزال ينتهي عند AS13335 الخاص بـ Cloudflare. أنشأ مُحسِّن DQE مسارًا أكثر تحديدًا ونشره مع الاحتفاظ بالأصل الشرعي. ثانيًا، لم تخترع Verizon المسارات، لكن قبولها ونشرها العالمي وسع نطاق وصولها بشكل كبير. ثالثًا، لم تختر شبكة Cloudflare AS396531 كمسار مفضل. اتخذت الشبكات البعيدة قرارات إعادة التوجيه بناءً على الإعلانات التي تلقتها.

لماذا هزمت المسارات الأكثر تحديدًا المسافة والبث الأحادي المتعدد (Anycast)

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

لنفترض أن جهاز توجيه يعلم أن104.20.0.0/20الخاصة بـ Cloudflare يمكن الوصول إليها عبر مزود عادي ويتعلم أيضًا104.20.0.0/21عبر Verizon وAS396531 وDQE. تطابق وجهة داخل الـ /21 الأولى كلا الإعلانين. الـ /21 أكثر تحديدًا، لذلك تفوز حتى لو كان مسار AS الخاص بها أطول أو سخيفًا من الناحية التشغيلية. تحسم سمات المسار العادية بين المسارات إلى نفس البادئة؛ وهي لا تجعل /20 السليمة تهزم /21 المقبولة.

لهذا السبب لم تقم بصمة البث الأحادي المتعدد (Anycast) الخاصة بـ Cloudflare بالتحايل تلقائيًا على المشكلة. يسمح Anycast للعديد من مواقع Cloudflare بالإعلان عن نفس البادئات، مما يسمح لـ BGP باختيار مثيل مناسب. يوفر توزيعًا جغرافيًا ويمكنه استيعاب فشل المواقع أو الروابط الفردية. لكن الـ /21 المُسرَّبة كانت أكثر تحديدًا من إعلانات /20 العادية لـ Cloudflare. يمكن لنظام التوجيه العالمي أن يفضل /21 قبل مقارنة أي موقع Anycast لـ Cloudflare كان الأقرب. التكرار وراء المسار الخاسر لم يستعد حركة المرور.

كما ركز المسار غير المرغوب فيه الحمل. لم تكن AS396531 واتصالاتها مُجهَّزة لعبور عالمي لـ Cloudflare وAmazon وLinode والعديد من الشبكات المتأثرة الأخرى. دخلت حركة المرور التي جذبتها الإعلانات الأكثر تحديدًا ممرًا بدون سعة أو سياسة لحملها. تم تأخير الحزم أو إسقاطها. يمكن أن يوصل تسرب المسار أحيانًا حركة المرور عبر مسار غير فعال؛ هنا، حول الحجم المسار إلى عنق زجاجة.

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

التسلسل الزمني ونافذة المساءلة الآخذة في الاتساع

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

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

أربع فرص للتصفية فشلت في نفس الاتجاه

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

احتواء المُحسِّن والشبكة المنشئة.تحكمت DQE في البيئة التي أنتج فيها منتج Noction مسارات أكثر تحديدًا. تطلبت المسارات المخصصة فقط للقرارات المحلية حاجز تصدير لا يعتمد على سلوك كل مصب صحيح. تضمنت الخيارات سياسة تصدير محددة النطاق، وسياق توجيه مخصص، ومجتمعات صريحة تفسرها كل مخارج، وفحوصات آلية من جامعين خارجيين، ومفتاح قتل مرتبط بانتشار غير متوقع. تقول Noction إنها أجرت اختبارات نشر وتناقش استخدامNO_EXPORT، لكنها تجادل أيضًا بأنNO_EXPORTغير مناسب في كل تصميم متعدد AS. تم تعريف المجتمع المعروف فيRFC 1997: لا ينبغي الإعلان عن مسار يحمله خارج حدود الكونفدرالية. ما إذا تم استخدامه، الحفاظ عليه، إزالته، أو لم يتم إرفاقه مطلقًا في هذا الحدث غير مثبت علنًا.

التحكم في تصدير العميل متعدد المنازل.ما كان ينبغي لـ AS396531 أن يقدم مسارات كاملة أو محسنة من مزود إلى مزود آخر إلا إذا كان يعمل عن قصد كعبور. يمكن لشبكة طرفية أو مؤسسة تطبيق قاعدة بسيطة للخارج: الإعلان فقط عن بادئاتها المصرح بها وبادئات العملاء المعتمدة صراحة. الرفض الافتراضي أكثر موثوقية من محاولة تحديد كل مسار يجب ألا يغادر.RFC 8212، الذي نُشر في عام 2017، قنن رفض BGP الخارجي الافتراضي عندما لا يتم تكوين سياسة استيراد أو تصدير صريحة. لا يمكنه منع مشغل من إرفاق سياسة متساهلة خاطئة، لكنه يزيل فئة من الانتشار العرضي الناجم عن سياسة غائبة.

التحكم في دخول عميل المزود.كانت تمتلك Verizon نقطة الإيقاف الأعلى نفوذًا. يعرف مزود العبور أي جلسة هي جلسة عميل ويجب أن يعرف ما هو مصرح للعميل أن ينشئه أو يعبره. وجد الغوص العميق لـ Cloudflare أن معلومات سجل المسار المرتبطة بالعميل لم تتضمن ASN الخاص بـ Cloudflare أو الشبكات المسربة الأخرى. لذا كان يمكن لمرشح بادئة ومسار AS خاص بالعميل رفض الإعلانات. يوصيإرشادات عمليات وأمان BGP في RFC 7454، المنشورة في عام 2015، بسياسات للمسارات المستلمة والمعلن عنها في كل حدود، وضوابط بادئة العميل، وتصفية مسار AS، وحدود البادئة القصوى.

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

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

كان بإمكان RPKI حظر هذه المسارات، لكنه ليس الإجابة الكاملة

كانت Cloudflare قد بدأت في توقيع المسارات ونشر التحقق في عام 2018، كما هو موضح فيحساب نشر RPKI الخاص بها. يحدد تفويض أصل المسار، أو ROA، أي نظام ذاتي يمكنه إنشاء بادئة، واختياريًا، أقصى طول بادئة يمكنه الإعلان عنه. تقول Cloudflare إن مساراتها ذات الصلة أذنت لـ AS13335 بطول أقصى /20. احتفظت /21 المُسرَّبة بـ AS13335 كأصلها لكنها تجاوزت الطول الأقصى المصرح به. لذا كانت غير صالحة بموجب التحقق من أصل المسار.

تم إضفاء الطابع الرسمي على المنطق فيRFC 6811. يكون المسار المستلم صالحًا إذا غطت حمولة ROA المُتحقق منها البادئة، وتطابق ASN الأصل، ولا يتجاوز طول بادئة المسار الحد الأقصى لـ ROA. يكون غير صالح عندما يكون هناك تفويض تغطية لكن لا يتطابق مع جميع الخصائص المطلوبة. يفصلتفسير التحقق من الأصل لـ RIPE NCCبشكل مفيد حالات الصالح وغير الصالح والمجهول ويؤكد أن مشغلي الشبكات لا يزالون يقررون السياسة التي يطبقونها على تلك الحالات.

كان إجراء Cloudflare لإنشاء ROAs ضروريًا لكنه غير كاف. ROA هو دليل منشور، وليس أمر تنفيذ عن بعد. كان على Verizon أو أي شبكة مستقبلة أخرى استرداد بيانات RPKI المُتحقق منها، وتطبيق التحقق على مسار العميل، ورفض غير الصالح. يمكن لـ Cloudflare رفض المسارات غير الصالحة التي تدخل شبكتها الخاصة، لكن ذلك لم يمنع شبكات الطرف الثالث من إرسال حركة المرور المتجهة إلى Cloudflare عبر مسار تم اختياره في مكان آخر. لأمن التوجيه هيكل متبادل: ينشر حامل العنوان تفويضًا، بينما يجعله المشغلون الآخرون فعالاً.

بالنسبة لهذا الحادث، كان RPKI ضابطًا وقائيًا قويًا بشكل خاص لأن المُحسِّن غير طول البادئة. سيكون من الخطأ تعميم حالة النجاح هذه على كل تسرب مسار. إذا كان AS396531 قد سرب /20 العادية لـ Cloudflare مع الحفاظ على AS13335 في نهاية المسار، فقد يعتبر التحقق من الأصل المسار صالحًا. سيظل المسار ينتهك طوبولوجيا المزود-العميل المتوقعة. يجيب التحقق من أصل RPKI على من يمكنه إنشاء بادئة وبأي طول. لا يثبت أن كل علاقة عبور في مسار AS مصرح بها.

هذا الحد ليس انتقادًا لـ RPKI. إنه سبب لنشره مع ضوابط أخرى. يجمعإرشاد NIST SP 800-189بين RPKI والتحقق من أصل BGP مع تصفية البادئات وممارسات مرونة أوسع بين المجالات. يعامل تسربات المسار والاختطاف وتحويلات حركة المرور وهجمات حجب الخدمة وتدهور الأداء كمخاطر تشغيلية ذات صلة تتطلب طبقات. حدث يونيو 2019 هو عرض ملموس بشكل غير عادي: كان بإمكان طبقة واحدة رفض البادئات السيئة بالضبط، بينما كان يمكن للتصفية الأساسية للعميل رفض مسار السلطة غير المعقول حتى بدون التشفير.

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

ضوابط سياسة المسار بعد 2019

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

قدمRFC 9234، المنشور في عام 2022، أدوار BGP وسمة فقط-للعميل (OTC). يمكن للشبكات المجاورة إعلان ما إذا كانت العلاقة مزودًا أو عميلاً أو نظيرًا أو خادم مسار أو عميل خادم مسار. تسمح اتفاقية الدور ومعالجة OTC لأجهزة التوجيه باكتشاف بعض الإعلانات التي تعبر حدود العلاقة في اتجاه غير مسموح به. في نسخة مبسطة من مسار 2019، يجب أن يحمل المسار المُتعلم من مزود ثم المرسل إلى مزود آخر دليلاً غير متسق مع تصدير عميل فقط. تحول أدوار BGP بعض معرفة طوبولوجيا التجارة من اتفاقية مشغل إلى حالة مرئية للبروتوكول.

يقدم Peerlock نهجًا آخر يركز على المسار. درست ورقة عام 2020"Flexsealing BGP Against Route Leaks"الآلية التي نشرها المشغلون، بما في ذلك قدرتها على إيقاف المسارات التي تظهر فيها شبكة كبيرة محمية حيث لا ينبغي. كان Peerlock موجودًا قبل الورقة وقبل حدث يونيو 2019، لكن النشر اعتمد على المعرفة الثنائية والتكوين. إنه دليل على أن مرشحات المسار العملية كانت ممكنة، وليس دليلاً على أن ضبطًا عالميًا جاهزًا كان متاحًا.

يهدف تفويض مزود النظام الذاتي (ASPA) إلى السماح لـ AS بنشر علاقات المزود القابلة للتحقق من خلال نظام RPKI. إنه واعد لأن العديد من تسربات المسار هي إخفاقات في معقولية المسار بدلاً من إخفاقات الأصل. كما يتطلب لغة حذرة: تطورت معايير ASPA وحالة النشر، وتنتج التغطية الجزئية مسارات غير معروفة. يجب معاملتها كإشارة تحقق إضافية، وليس كدليل رجعي على أن المشاركين في 2019 انتهكوا معيار مسار تشفيري إلزامي حينها.

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

لذا فإن نموذج التحكم المفيد تراكمي:

1. نشر سلطة مسار دقيقة من خلال كائنات IRR وROAs.
2. إنشاء مرشحات استيراد العملاء من بيانات موثوقة وتحديثها بأمان.
3. الافتراضي إلى رفض المسارات التي تفتقر إلى سياسة صريحة.
4. فرض توقعات مخروط العميل ومسار AS وطول البادئة والحد الأقصى للبادئات.
5. رفض الإعلانات غير الصالحة لـ RPKI في كل مدخل خارجي ذي صلة.
6. إضافة ضوابط واعية بالعلاقات مثل أدوار BGP وOTC وPeerlock وعند نضوجها، التحقق من ASPA.
7. مراقبة الانتشار من نقاط مراقبة خارجية مستقلة.
8. الحفاظ على جهات اتصال عمليات مُختبرة باستمرار وسلطة سحب المسار.

لا يحل عنصر واحد محل الباقي. تأتي قيمتها من أوضاع فشل مختلفة.

توزيع المساءلة دون اختراع حكم بالمسؤولية

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

DQE Communications.تحكمت DQE في الشبكة حيث تم إنشاء مسارات التحسين والعلاقة التي وصلت من خلالها إلى AS396531. كانت أهم واجباتها تقييد نطاق المسار، واختبار الرؤية الخارجية، والحفاظ على سياسة تصدير صحيحة، وإيقاف الإعلانات بمجرد الاتصال بها. أشادت Cloudflare بموظفي DQE للمساعدة في سحب المسارات. قلل التعاون السريع من المدة؛ لكنه لا يمحو فشل الضبط الوقائي.

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

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

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

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

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

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

نجت مساءلة أعمال Cloudflare من السبب الخارجي

لا يزيل المحفز الخارجي التزامات مزود السحابة تجاه العملاء. قالبيان تسجيل Cloudflare المعدل لعام 2019 من النموذج S-1إن تسرب المسار في يونيو تسبب في تعطيل كبير لحركتها وحركة مقدمي خدمات آخرين. حذر من أن تسربات المسار يمكن أن تضر بالسمعة والثقة، ووصف التزامات مستوى الخدمة التي يمكن أن تؤدي إلى أرصدة أو استردادات، وذكر أن تسرب المسار في يونيو وانقطاع منفصل في يوليو أثارا بعض تلك الالتزامات. في ذلك الوقت، لم تتوقع Cloudflare أن يكون للحوادث تأثير مادي على نتائج العمليات أو الحالة المالية.

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

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

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

ما يجب أن تسأله مجالس الإدارة عن مخاطر النظير والعبور

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

تبدأ حزمة مجلس الإدارة المفيدة بالتعرض، وليس ادعاءات الامتثال:

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

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

مرونة العملاء دون نصائح مبسطة متعددة المزودين

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

يبدأ التصميم الصحيح بمسار الخدمة. أي مزود هو الموثوق لـ DNS؟ أين تُحفظ مفاتيح TLS وسياسات الأمان؟ هل يمكن للأصل قبول حركة المرور المباشرة بأمان؟ هل يمكن تحويل حركة المرور دون إنشاء تجاوز أمني؟ ما مدى سرعة تغيير مخابئ DNS؟ هل يحتفظ العملاء بالاتصالات؟ هل يمتلك مزود ثانوي التكوين والسعة الحاليين؟ هل يمكن للمؤسسة التمييز بين فشل التوجيه العلوي وفشل الأصل قبل أن تحول حركة المرور؟

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

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

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

من المعايير الطوعية إلى أدلة إدارة المخاطر

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

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

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

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

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

الأدلة التي لا تزال مفقودة من السجل العام

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

ستحسن السجلات التالية التحليل ماديًا إذا أصدرها المشغلون المعنيون:

• تكوين مُحسِّن DQE، وسياسة البادئة المُنشأة، وخرائط التصدير، ومعالجة المجتمع، واختبارات الانتشار الخارجي قبل وبعد النشر.
• سياسة BGP لـ AS396531 المرفقة بجلسات DQE وVerizon، والجدول الزمني لتوقف الجلسة وبدئها، وتغييرات التكوين، وعدد المسارات، وسبب أهلية المسارات المُتعلمة من المزود للتصدير.
• سجل تأهيل عميل Verizon، ومصدر IRR أو قائمة البادئات، وسياسة مسار AS، وإعداد البادئة القصوى، وحالة التحقق من RPKI، والتنبيهات، والجدول الزمني لاستجابة المشغل، وتفسير الانتشار العالمي.
• قائمة تدقيق نشر Noction، وضمانات الاحتواء المستمر، وسلوك التنبيه، وتغييرات المنتج التي أُجريت بعد الحادث.
• أول طابع زمني للكشف الداخلي لـ Cloudflare، ومصدر التنبيه، وقرارات التخفيف المُنظور فيها، والجدول الزمني لتصعيد الاتصال بالنظير، وتأثير العميل حسب الشبكة والمنطقة، والتحقق من الإجراء التصحيحي.
• أرصدة الخدمة الكمية، والاستردادات، وعبء الدعم، وتقلب العملاء المنسوب تحديدًا إلى تسرب المسار في يونيو بدلاً من انقطاع يوليو المنفصل.

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

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

معيار مساءلة دائم لمرونة المسار

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

كان الحدث قابلاً للمنع بضوابط كانت متاحة في ذلك الوقت. كان بإمكان DQE حصر مسارات التحسين. كان بإمكان AS396531 تصدير البادئات المصرح بها فقط. كان بإمكان Verizon تصفية إعلانات العملاء بأدلة السجل والمسار وعدد البادئات وRPKI. كان بإمكان الشبكات المتلقية رفض المسارات الأكثر تحديدًا لـ Cloudflare غير الصالحة لـ RPKI. كان يمكن للمراقبة الأفضل وجاهزية الاتصال تقصير الحدث. تجعل المعايير اللاحقة بعض افتراضات العلاقات أسهل للإشارة، لكنها لا تحول الانضباط التشغيلي إلى شاغل تراثي اختياري.

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

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

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