استجابة Cloudflare لتسرب الطريق جعلت الإصلاح القابل للتحقق أكثر أهمية من الطمأنة

ملخص

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

سجل الأدلة وكيفية استخدامه

تستخدم هذه المقالة تحليل الحادث العام من Cloudflare كحساب مزود متأثر من الطرف الأول، ومصادر التوجيه والصناعة الخارجية لسياق أمن التوجيه، وRFCs أو توجيهات الحكومة لإجراءات BGP وRPKI والتحكم في تسرب الطريق الحالية. تُستخدم المعايير اللاحقة لتأطير الإصلاح القابل للتحقق، وليس كواجبات قانونية بأثر رجعي لكل مشارك في 2019.

الطمأنة ليست إصلاحًا

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

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

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

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

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

التسرب له أدوار: المصدر، المضخم، والضحية

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

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

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

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

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

RPKI يغير معيار الأدلة

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

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

RPKI ليس درعًا سحريًا. يمكن أن يتضمن تسرب الطريق طريقًا يظل صالح المصدر لأن النظام المستقل الأصلي لا يزال مصرحًا به بينما علاقة المسار خاطئة. لهذا السبب مهم تصنيف تسرب الطريق RFC 7908 والآليات اللاحقة مثل أدوار BGP. التحقق من مصدر الطريق يجيب على من قد ينشأ؛ منع تسرب الطريق يسأل أيضًا عما إذا كان يجب نشر الطريق عبر علاقة معينة. يجب أن يشمل الإصلاح القابل للتحقق كلاً من التحقق من المصدر والتصفية الواعية بالعلاقة.

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

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

معايير على غرار MANRS تحول التوجيه الخاص إلى توقع عام

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

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

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

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

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

أدلة BGP العامة جزء من سجل الحادث

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

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

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

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

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

مساءلة مزود النقل هي نقطة التأثير العالي

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

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

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

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

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

استمرارية العميل لها حدود تحت فشل التوجيه

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

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

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

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

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

الإصلاح القابل للتحقق يحتاج إلى قائمة مرجعية

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

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

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

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

يجب أيضًا تحديث القائمة المرجعية مع تطور التكنولوجيا. أدوار BGP وآليات Only-to-Customer في RFC 9234 تعالج منع تسرب الطريق الواعي بالعلاقة الذي لا يمكن لتحقق مصدر RPKI وحده حله. لا ينبغي للمزودين تجميد نموذج الإصلاح الخاص بهم عند الضوابط المتاحة في 2019. برنامج إصلاح حقيقي يتبنى آليات أفضل عندما تصبح قابلة للنشر.

الدعوة أقوى عندما تقترن بالمشتريات

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

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

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

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

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

تسريبات الطرق تظهر حدود تكرار الحافة

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

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

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

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

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

المسارات الخاطئة تخلق دينًا للثقة

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

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

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

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

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

الحد الأقصى للطول هو قرار حوكمة

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

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

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

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

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

تسريبات العلاقة تحتاج إلى أدلة علاقة

التحقق من مصدر RPKI يجيب على سؤال محدد: هل هذا النظام المستقل المصدر مصرح به لهذه البادئة؟ غالبًا ما تسأل تسريبات الطرق سؤالًا مختلفًا: هل كان يجب تمرير هذا الطريق من علاقة إلى أخرى؟ يمكن أن يكون الطريق صالح المصدر وما زال مسربًا. لهذا السبب مهم الضوابط الواعية بالعلاقة مثل تصفية الطرق، وأدوار BGP، وآليات Only-to-Customer. يجب أن يعالج الإصلاح القابل للتحقق طبقة العلاقة.

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

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

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

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

لغة الحادث يجب أن تتجنب تسوية السببية

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

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

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

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

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

معيار الإصلاح هو الدليل العام

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

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

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

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