الخلاصة

  • قالت Cloudflare إن شركة صغيرة أصبحت، نحو 10:30 بتوقيت UTC في 24 يونيو 2019، مسارا مفضلا لكثير من الطرق عبر Verizon AS701، وكانت بعض بادئات Cloudflare ضمن الإعلانات المتأثرة [1].
  • ربط تحليل Cloudflare اللاحق المشكلة بطبقة route optimizer وبنشرها عبر مزود عبور كبير [2].
  • ردت Noction علنا لأن منتج تحسين المسارات الخاص بها كان جزءا من النقاش، وهذا يساعد على فصل نية المنتج عن حوكمة النشر [3].
  • رصدت ThousandEyes/Catchpoint آثارا خارجية على قابلية الوصول لمستخدمي Cloudflare، ما يثبت حدود الضرر بقياسات عامة [4].
  • يوضح RFC 7908 وRFC 9234 لماذا يتعلق الأمر بتسرب علاقة BGP، ولماذا تصبح الأدوار الصريحة مثل Only-to-Customer مهمة [6][7].

ماذا حدث

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

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

لماذا يهم

يمكن لتسرب المسار أن يحتفظ بأصل صحيح، بينما تكون العلاقة في منتصف AS path خاطئة. لذلك تساعد RPKI Origin Validation عندما يكون الأصل غير مصرح به، لكنها لا تكفي لكل تسرب. الإصلاح المسؤول يحتاج إلى دليل علاقة، وسياسة استيراد وتصدير، وحدود بادئات، ومرشحات AS-path، وانضباط IRR/RPKI، واكتشاف تسربات ومراقبة.

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

الطبقة التقنية

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

كان ينبغي لإغلاق تقني موثوق أن يذكر البادئات، ومسارات AS، وبداية الحدث ونهايته، ومواقع التجميع، والجلسات المتأثرة، ومرشحات الاستيراد والتصدير، وحدود max-prefix، وأدلة IRR/RPKI، ورسائل السحب، واختبارات عدم التكرار. بدون ذلك لا يمكن للجمهور التمييز بين تقارب قصير وسياسة واسعة وخطأ تشغيلي أعمق.

من يتأثر

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

ما الذي ينبغي مراقبته

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

Sources

  1. https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
  2. https://blog.cloudflare.com/the-deep-dive-into-how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-monday/
  3. https://www.noction.com/news/incident-response
  4. https://www.thousandeyes.com/blog/cloudflare-users-burned-by-internet-routing-pile-up
  5. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/
  6. https://www.rfc-editor.org/rfc/rfc7908
  7. https://www.rfc-editor.org/rfc/rfc9234