كلودفلير، تسرب المسار في يونيو 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) لإخبار الأنظمة المجاورة بالبادئات التي يمكنه الوصول إليها ومن خلال أي مسار 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 بتوجيه المسار حول المشكلة تلقائيًا. يسمح أي كاست للعديد من مواقع Cloudflare بالإعلان عن نفس البادئات، مما يسمح لـ BGP باختيار مثيل مناسب. يوفر توزيعًا جغرافيًا ويمكنه استيعاب فشل المواقع أو الروابط الفردية. لكن /21 المسربة كانت أكثر تحديدًا من إعلانات /20 العادية لـ Cloudflare. يمكن لنظام التوجيه العالمي تفضيل /21 قبل مقارنة موقع أي كاست الأقرب لـ 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 الخاص بهاحساب نشر 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. إنها سبب نشره مع ضوابط أخرى. تجمع إرشادات SP 800-189 من 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 دقيقة، وتنوع الاتصال، ومراقبة المسار الخارجي، والتشخيص السريع، وجهات اتصال النظير القابلة للوصول، والتواصل مع العملاء، وخيارات التخفيف، والإفصاح الشفاف. كان عليها أيضًا واجب عدم المبالغة في ما يمكن أن تتحمله بنيتها التحتية. يقلل الإرسال المتعدد والبنية التحتية العالمية الكبيرة العديد من حالات الفشل لكن لا يمكنه هزيمة مسار أكثر تحديدًا مقبول عالميًا دون مساعدة من شبكات التحقق.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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