رد شركة 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 ليس درعًا سحريًا. قد يتضمن تسريب الطريق طريقًا تظل صالحة من حيث المصدر لأن AS المصدر لا يزال مصرحًا به بينما علاقة المسار خاطئة. لهذا السبب فإن تصنيف تسريبات الطرق في RFC 7908 والآليات اللاحقة مثل أدوار BGP مهمة. التحقق من صحة مصدر الطريق يجيب على من يمكنه الإصدار؛ منع تسريب الطريق يسأل أيضًا عما إذا كان يجب نشر الطريق عبر علاقة معينة. يجب أن يشمل الإصلاح القابل للتحقق كلاً من التحقق من صحة المصدر والتصفية الواعية للعلاقات.

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

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

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

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

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

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

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

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

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

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

استخدم التحليل العام لـ Cloudflare أدلة توجيه لإظهار كيفية تطور الانقطاع. هذه ممارسة جيدة. يجب أن يتضمن تحليل ما بعد الحادثة لتسريب طريق بيانات كافية من الطرق العامة لجعل الآلية قابلة للقراءة: أي البادئات تأثرت، وما هي مسارات 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، أو تصفية مزود الخدمة، أو انتشار الطريق. قدرة المزود على شرح الطبقة بسرعة جزء من المرونة.

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

المسارات الكاذبة تخلق دين ثقة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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