الخلاصة

  • تكمن المساءلة في هذه الواقعة في سلسلة سياسات تشغيلية: إعلان Google LLC مسارات متعلّمة من أقران، قبول Verizon لها وإعادة نشرها، جذب البادئات الأكثر تخصيصاً للحركة، ثم امتداد أثر ذلك على قابلية الوصول في اليابان بزمن تعافٍ أطول من زمن تصحيح الخطأ الأول.
  • لا تكفي سجلات ASN والبادئات أو RPKI وحدها لتفسير ما حدث أو منعه؛ فهي أدلة وقيود تحقق مهمة، لكن واقع الوصول تحدده المسارات التي تقبلها الموجهات وتختارها وتعيد تصديرها، لذلك يصبح الترشيح، وحدود العلاقة، والمراقبة، والتراجع، والتحقق اللاحق أدوات المساءلة الأساسية.

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

عندما انجذبت الحركة نحو Google LLC بينما لم تكن Google LLC تؤدي دور ناقل عبور لتلك الوجهات، أمكن أن تضيع الحركة أو تتأخر أو تفشل في الوصول.

لذلك لا يصح اختزال الواقعة في عبارة “عطل Google في اليابان”. كانت Google LLC طرفاً بادئاً في سلسلة الإعلان غير المتوقع، لكن الضرر العالمي احتاج إلى حد ثانٍ يفشل: حد قبول ونشر لدى Verizon. كما لا يصح القول إن كل الإنترنت الياباني توقف، أو إن كل نظير لدى Verizon قبل كل إعلان، أو إن كل خدمة يابانية سلكت المسار نفسه. الأدلة العامة تحدد واقعة كبيرة ومؤثرة، لكنها لا تمنح خريطة كاملة لكل جلسة BGP خاصة، ولا لكل قرار local preference، ولا لكل FIB داخلية، ولا لكل حزمة مستخدم. السؤال المحوري أكثر دقة: كيف يجب أن تُحاسب أنظمة الشبكات عندما تجعل سياسات التصدير والاستيراد والعبور مسارات لا ينبغي أن تنتشر تبدو قابلة للتصديق وقابلة للاختيار؟

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

تختلف الأرقام العامة حول عدد البادئات أو المسارات لأنها لا تقيس الشيء نفسه دائماً. Internet Society ناقشت الواقعة بوصفها تسريباً شمل ما يزيد على 135,000 بادئة، مع إبراز أن بعضها كان أكثر تخصيصاً وجاذباً للحركة. Doug Madory في تحليله المنشور عبر CircleID قدّم قراءة أخرى مبنية على المشاهدات والمسارات المرئية، وتناولت أرقاماً أكبر متداولة حول الحدث، ومنها نطاق يقارب 160,000 إعلان أو مسار في بعض الروايات. هذا الاختلاف لا ينبغي تسويته بقول رقم واحد كأنه حقيقة مطلقة.

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

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

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

أدلة المشغلين اليابانيين تجعل هذا الفصل ضرورياً. NTT Communications أبلغت عن عدم استقرار في اتصال OCN وربطته بتغيرات كبيرة في المسارات على الإنترنت، وحددت نافذة من 12:22 إلى 12:45 بتوقيت اليابان. كما قالت إن معدات OCN نفسها لم يظهر فيها خلل. هذا لا يعني أن NTT أثبتت كل مسار عالمي، لكنه دليل مباشر على أن أثر الوصول لدى مشغل ياباني استمر إلى ما بعد مجرد تصحيح إعداد Google LLC ذي الثماني دقائق. KDDI قدمت نافذة أطول لبعض عملاء الوصول إلى الإنترنت، مع انتهاء أثر معلن عند 16:47.

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

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

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

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

الأهمية التقنية هنا أن اختيار أطول بادئة يسبق، من حيث مطابقة الوجهة، مقارنات كثيرة تتعلق بخصائص المسار بين بدائل لا تغطي النطاق نفسه بالدقة نفسها. فإذا وُجد إعلان أكثر تخصيصاً، فإن حركة العناوين الواقعة داخله تتجه إليه حتى لو كان هناك مسار إجمالي أقل تخصيصاً يبدو طبيعياً من زاوية عامة. بعد ذلك تأتي مقارنات مثل خصائص AS path أو سياسات التفضيل بين طرق متنافسة للبادئة المطابقة. لذلك كان وجود more-specifics في التحليلات العامة مهماً: لم يكن مجرد رقم إضافي في جدول BGP، بل آلية جعلت جزءاً من الحركة يرى الطريق المسرّب كطريق أدق.

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

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

تصنيف RFC 7908 لتسريبات المسارات مفيد هنا لأنه يميز بين مشكلات الأصل ومشكلات العلاقة. Route leak قد يحدث عندما تُنشر مسارات متعلّمة من طرف في اتجاه لا ينبغي أن تُنشر إليه بحسب نموذج العلاقات المعتاد. إذا تعلمت شبكة مساراً من نظير ثم أعلنته إلى مزود أو نظير آخر بطريقة تجعله طريق عبور غير مقصود، تصبح المسألة سياسة علاقة أكثر من مسألة أصل مورد. في هذه الواقعة، وصف Internet Society جوهر الخطأ بأنه إعلان Google LLC بادئات متعلّمة من أقران إلى Verizon. ثم وصفت تحليلات أخرى قبول Verizon ونشرها. هذا لا يثبت سوء نية من أي طرف، لكنه يثبت أن حدين من حدود السياسة يستحقان الفحص: حد التصدير عند Google LLC وحد الاستيراد وإعادة التصدير عند Verizon.

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

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

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

RPKI وRoute Origin Validation يقدمان مثالاً دقيقاً لهذا الحد. RFC 6482 يعرّف ROA ككائن يربط بادئة بمنشأ مصرح له. RFC 6811 يحدد كيف يمكن للتحقق من أصل المسار أن يصنف إعلاناً بأنه Valid أو Invalid أو NotFound بحسب تطابق المنشأ مع التفويض. هذه أداة قوية ضد فئة من الأخطاء والهجمات، خصوصاً عندما يكون منشأ الإعلان غير مصرح. لكنها لا تكفي وحدها لتسريب علاقة يحافظ على المنشأ المشروع ويغير طريق الانتشار. إذا كانت البادئة ذات ROA صحيح والمنشأ لا يزال صحيحاً، فقد يمر فحص الأصل رغم أن الإعلان انتقل عبر علاقة لا ينبغي أن تحمله. لذلك سيكون غير دقيق القول إن RPKI وحده كان سيمنع حادثة 2017.

الأدق أن RPKI جزء من طبقة أدلة وتحقق، لكنه يحتاج إلى ضوابط علاقة مثل ترشيح الاستيراد والتصدير، ومقارنة IRR، وآليات لاحقة مثل BGP Roles وOnly-to-Customer وASPA أو Peerlock حيث تكون قابلة للتطبيق.

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

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

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

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

لذلك يجب استخدام القياس العام كأدلة اتجاه وحدود، لا كبديل عن سجلات المشغلين الداخلية.

تساعد هذه الحدود على قراءة تحليلات Madory وInternet Society دون تضخيمها أو تفريغها. عندما يعرض محلل مسارات مرئية من نقاط معينة، فالقوة هي أنه يقدم أثراً مستقلاً عن رواية الشركة: طريق ظهر، ثم انتشر، ثم ارتبط بأثر وصول. أما الحد فهو أن الصورة ليست شاملة. الطريق المرئي يثبت أن الحادثة لم تكن مجرد بيان علاقات عامة، لكنه لا يعطي كل مسار أو كل خسارة. لذلك يظل طلب الأدلة الداخلي مشروعاً: لقطات RIB وFIB محلية لدى Google LLC وVerizon والمشغلين اليابانيين، سجلات إعلانات received/advertised routes، تنبيهات max-prefix، قرارات rollback، وزمن وصول الإنذار إلى مالك يملك صلاحية التراجع.

من زاوية Google LLC، يقع التحكم الأساسي في أنظمة توليد المسارات وسياسات التصدير إلى الأقران والمزودين. إذا كانت Google LLC تتعلم مسارات من أقران، فيجب أن تمنع سياسة التصدير خروجها في اتجاه يحول Google LLC إلى ناقل عبور غير مقصود. ويجب أن تختبر تغييرات السياسة أو الإعداد أمام جداول واقعية لا أمام عينات صغيرة فقط. ويجب أن تُطبّق مراقبة abnormal route advertisement: عدد بادئات خارج المتوقع، ظهور more-specific غير معتاد، تغيرات AS path غير منطقية، أو إعلان وجهات لا تنتمي إلى سياسة العميل أو الخدمة.

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

من زاوية Verizon، لا تكفي عبارة “تلقينا إعلاناً من طرف آخر”. إذا قَبِل حد الاستيراد مسارات لا ينبغي أن تأتي من تلك العلاقة، ثم أعاد نشرها، فهو حد تحكم مستقل. يجب أن تسأل المساءلة: ما قواعد الاستيراد لذلك الجار؟ هل كانت مبنية على قوائم عملاء أو IRR أو حد أقصى للبادئات؟ هل كانت هناك عتبات max-prefix تجعل قفزة مفاجئة إلى عشرات الآلاف أو أكثر سبباً لوقف الجلسة أو تنبيه عاجل؟ هل كان إعادة التصدير إلى أطراف أخرى مقيداً بعلاقة المصدر؟ هل وُجدت مراقبة تقارن ما يقبله Verizon من Google LLC بما يتوقعه من Google LLC؟ هذه أسئلة تشغيلية لا تحتاج إلى ادعاء عقد خاص أو نية. هي أسئلة عن أنظمة تمنع الخطأ عند الحد الثاني عندما يفشل الحد الأول.

التمييز بين حد Google LLC وحد Verizon ليس توزيعاً خطابياً للوم، بل طريقة لتحديد أين كان يمكن إيقاف المسار. Google LLC تملك حد export: ما الذي يخرج من شبكتها إلى جار معين؟ Verizon تملك حد import ثم حد onward export: ما الذي تقبله من ذلك الجار، وما الذي تعيد إعلانه إلى الآخرين؟ إذا فشل حد التصدير الأول، لا يصبح الحد الثاني مجرد قناة محايدة؛ إنه طبقة تحكم كان يمكن أن تجعل الخطأ محلياً أو أضيق. وإذا فشل الحد الثاني أيضاً، يصبح الانتشار أوسع وتحتاج المساءلة إلى دليلين منفصلين: دليل يشرح لماذا خرجت المسارات من Google LLC، ودليل يشرح لماذا بدت مقبولة وقابلة لإعادة النشر داخل Verizon.

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

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

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

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