الملخص

  • تشير مراقبة Qrator إلى أن بداية الحادث كانت حوالي الساعة 19:28 UTC في 1 أبريل 2020 وتصف ملاحظة استمرت لنحو ساعة واحدة. هذه نافذة ملاحظة خارجية منسوبة، وليست التسلسل الداخلي الكامل لحدث Rostelecom أو برهانًا على بداية ونهاية دقيقة لكل شبكة متأثرة.[1]

  • بلغت عددات المسارات المتأثرة المبلغ عنها من قبل Qrator 8,870 مسارًا تنتمي إلى ما يقارب 200 نظام مستقل (AS). لخص CERT-EU أكثر من 8,800 مسار من أكثر من 200 شبكة. تصف هذه الأرقام قياسات مرئية من زوايا تقريرية مختلفة؛ ولا يثبت أيٌّ منها كل مسار تحكمه أو كل مستخدم متأثر أو الأثر التجاري الكلي.[1][2]

  • لاحظت Qrator إعلانات AS12389 عبر Rascom AS20764 وCogent AS174 وLevel 3 AS3356. يُظهر هذا التسلسل أن الحدث عبر مجالات توجيه تسيطر عليها كيانات مستقلة، لكنه لا يكشف مرشحات الاستيراد المحددة أو العقود أو حالة التحقق أو إعدادات الموجهات في أي شبكة مسماة.[1]

  • تستلزم أدلة التوجيه بقاء عدة فئات منفصلة: مسار مُستَرجَع تم تصديره خارج نطاق السياسة المقصود؛ إعلان أصل غير مصرح به؛ إعادة إحياء/إعادة نشر بادئة أكثر تحديدًا؛ ومسار أصل مصرح به يحتفظ بأصله المصرّح فيه بينما يخرق ترتيب العلاقات المتوقعة. تتفاعل هذه الفئات بشكل مختلف مع مرشحات التصفية، وعلاقة التحكم، وفحص سلامة الأصل في RPKI.[4][17]

  • حدثت حادثة منفصلة في RIPE NCC ضمن طبقة تحكم RPKI. بعد تحديث برمجي في سجل RIPE، حُذفت 2,669 تفويضًا لأصل المسار (ROA) بعد تصنيف بعض التخصيصات المستقلة عن المزودين بأنها غير قابلة للتصديق. أعادت RIPE NCC نشر ROAs المفقودة في 2 أبريل.[3][5]

  • التزامن الزمني لم يثبت السببية. وجد كل من RIPE NCC في المراجعة اللاحقة ومجموعة تحليل routing Working Group المستقلة عدم وجود علاقة مباشرة بين حذف ROAs وحادث التوجيه المرتبط بـ AS12389.[4][5]

  • تقاطع القياس بين الحادثتين كان ضيقًا: ثلاثة حائزين لموارد مستقلة (PI holders) و12 بادئة. لا يمكن تعميم هذا التقاطع على جميع مسارات الـ 8,870، ولا يدعم السجل العام وصف جميع المسارات المتأثرة على أنها RPKI Invalid.[4][5]

  • يمكن لفحص التحقق من أصل المسار (Route Origin Validation) مقارنة بادئة وASN أصلي مع بيانات ROA المصدّقة وتصنيف النتيجة كـ Valid أو Invalid أو NotFound. لكنه لا يتحقق من المسار الكامل لـ AS، ولا يحدد ما إذا كان كل تصدير يحترم علاقة تجارية محددة، ولا يعيد بناء تغيير في الإعداد، ولا يثبت النية.[13]-[15]

  • كان التحكم العملي موزعًا. تحكمت Rostelecom في إعلاناتها وسياسة التصدير؛ وتحكمت الشبكات المتلقية في قرارات الاستيراد والتصدير والتحقق الخاصة بها؛ وتحكم حاملو البادئات في سجلاتهم وROAs؛ وكانت RIPE NCC تتحكم في خدمات الشهادات وإدارة ROA؛ وتحكمت جهات الاعتماد في حداثة الذاكرة المؤقتة والتفعيل؛ كما سيطرت مزودات المراقبة على أنظمة الملاحظة والتنبيه.

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

  • ولذلك فإن نتيجة المساءلة تشغيلية وليست اتهامية. وفّرت سجلات RIPE والـROAs دليلًا عن تفويض المورد وأصل الإعلان، بينما حددت الإعدادات الجارية وحالة ذاكرة التحقق الحالية وسياسة الجيران والمراقبة والتعافي المنسق ما إذا كان هذا الدليل غيّر سلوك التوجيه الحي.

سؤال المساءلة

يمتلك حادث 1 أبريل 2020 أهمية لأنه كشف عن الفجوة بين السلطة المسجلة والتحكم الجارٍ. استطاعت RIPE Database تحديد الكائن الإداري المرتبط بـ AS12389، كما تمكن RPKI من التعبير عن تفويضات بعض حاملي البادئات الأصلية.[8][10] لا يفرض أي من النظامين وحده ما يقبله كل موجه أو يفضّله أو يعلنه لجيرانه. يتبادل المتحدثون في BGP رسائل UPDATE، ويختارون المسارات وفق سياسة محلية، ويعلنون النتائج المسموح بها لجيرانهم.[12] بعد أن تجاوزت إعلانات غير متوقعة حدود شبكة معيّنة، اتخذ كل مشغل مستقبِل قرارًا تحكمًا آخر على مستوى محلي.

هذا البناء يستبعد تفسيرًا بسيطًا يفترض أن سجلًا تنظيميًا واحدًا أو آلية أمنية واحدة أو منظمة واحدة حكمت النتيجة الكاملة. أظهر مرور Qrator عبر AS20764 وAS174 وAS3356 أن هناك عدة طبقات تحكم تشغيلية فعلية في السلسلة الملاحظة.[1] كان سلوك Rostelecom مركزيًا لأن AS12389 ظهر في الإعلانات قيد الفحص. إلا أن امتداد تلك الإعلانات اعتمد أيضًا على أي الجيران الذين قبلوها، والطرق التي صدّروها لاحقًا، والشبكات التي اختارتها لاحقًا.

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

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

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

التسلسل الزمني الجنائي

ينبغي أن يميز التحليل الجنائي بين الملاحظات المعلنة مباشرة وبين الاستدلالات والأحداث الداخلية غير المُحَدَّدة. تُظهر جامعـات الطرق العامة ومنصات المراقبة عروضًا مختارة من طبقة التحكم بدل نص حرفي موحد للحدث بالكامل. وتؤكد وثائق RIPEstat أن بيانات التوجيه تُصوّر كـ “ملاحظات” من مصادر متاحة، مع حدود تُفرض بنقاط الرصد وتغطية البيانات.[9] ولذلك يحدد هذا التسلسل الزمني ما هو مُبلّغ عنه، وما هو منفصل، وما يظل غير معلوم.

الوقتحدث مُثبت بالأدلة
قبل 19:28 UTC، 1 أبريللا يحدد السجل العام تغيير التكوين المبدئي في Rostelecom، أو الموجّه، أو الأمر، أو الموظف، أو سلسلة الموافقات الداخلية التي بدأت الحادث. كما لا يثبت الحالة الدقيقة للتصفية في RPKI وما قبل الحادث في كل شبكة قبل أن تقبل لاحقًا إعلانًا.
حوالي 19:28 UTCتضع Qrator بداية ملاحظتها نحو 19:28 UTC. وأشارت أن AS12389 أعلن مسارات مرتبطة بمجموعة كبيرة من الشبكات الأخرى.[1] هذا الطابع الزمني يخص حساب المراقبة لدى Qrator؛ وليس برهانًا على أن كل موجه متأثر رأى أول تحديث له في تلك اللحظة نفسها.
خلال الانتشار اللاحقأبلغت Qrator أن الإعلانات انتشرت عبر Rascom AS20764 وCogent AS174 وLevel 3 AS3356.[1] تثبت الملاحظة انتقالًا واضحًا عبر تلك الأنظمة المستقلة، لكنها لا تثبت كل قرار جلسة على حدة أو تقييم route-map أو العلاقة التجارية الكامنة.
خلال نافذة تقارب الساعة الواحدةعدّت Qrator 8,870 مسارًا متأثرًا تنتمي إلى ما يقارب 200 نظام مستقل.[1] لخص CERT-EU لاحقًا أكثر من 8,800 مسار من أكثر من 200 شبكة.[2] هذه قياسات منسوبة ولا تثبت أن كل مسار حمل نفس حالة التحقق من الأصل أو أنتج نفس أثر البيانات.
أثناء استجابة الحادثذكرت Qrator أن Rostelecom تلقّت إنذارًا لحظيًا وتعاونت مع Qrator في استكشاف الخطأ واستعادة الخدمة.[1] كما سجّل CERT-EU التعاون مع جهة التقرير.[2] لكن التسلسل الكامل للتصعيد والتخفيف واستعادة الحالة داخل Rostelecom غير متاح علنًا.
حوالي ساعة بعد الملاحظة الأولىوصف Qrator الحدث بأنه استمر تقريبًا ساعة.[1] الحساب العام يدعم استعادة الخدمة داخل هذه النافذة، لكنه لا يثبت أي إعداد انسحاب أُنهي به كل مسار متأثر أو ما إذا كانت عملية التقارب قد اكتملت في كل مكان في نفس الوقت.
حادث RIPE NCC المتزامنحدث بشكل منفصل فشل في إدارة سجل RIPE NCC في طبقة التحكم؛ إذ أدى تحديث برنامج في السجل إلى تصنيف بعض التخصيصات المستقلة عن المزودين كمخصصة غير قابلة للتصديق، مما أدى إلى حذف 2,669 ROA.[3][5] هذا كان سجلًا إداريًا منفصلاً عن سلوك AS12389 في BGP.
2 أبريلأعادت RIPE NCC ROAs المفقودة.[3][5] هذا الإجراء ينتمي إلى خط زمنية منفصلة تتعلق باستعادة خدمة RPKI، ولا ينبغي تقديمه كآلية أنهت حادث Rostelecom.
التحليل اللاحقوجدت Routing Working Group تحليلًا وراجع RIPE NCC لاحقًا عدم وجود علاقة مباشرة بين الحادثتين. وحددت تقاطعًا يشمل ثلاثة حائزين للموارد المستقلة (PI) و12 بادئة.[4][5]

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

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

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

ما تثبته الانتشارات الملاحظة

تُثبت ملاحظات مسار AS أن معلومات الوصول غير المتوقعة لم تبق محصورة في شبكة واحدة. BGP بروتوكول موزّع: يُمكن لرسالة UPDATE مقبولة في نظام مستقل أن تصبح مدخلاً لعملية قرار نظام آخر، ومن ثم إعلانًا إلى جيران إضافيين وفق السياسة.[12] وبذلك فإن سلسلة الانتشار AS12389–AS20764–AS174–AS3356 المبلّغ عنها تضع سلسلة من القرارات التشغيلية عبر مجالات إدارية منفصلة.[1]

هذه السلسلة لا تثبت أن كل شبكة مسماة قبلت كل واحد من المسارات الـ 8,870 أو أن مسارًا موحدًا واحدًا وصل إلى كامل الإنترنت. ولا تكشف لماذا قبلت سياسة استيراد محددة مسارًا ما. قد يعوّل مشغل على مرشحات ببادئات العملاء، وبيانات RIR، وRPKI، واستثناءات يدوية، وحدود عامة، وافتراضات تعاقدية، أو مزيج منها. الأدلة المتوفرة لا تكشف إعدادات أبريل 2020 لأية شبكة صاعدة أو شريكة.

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

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

أربع فئات توجيه لا يمكن خلطها

غالبًا يُستخدم مصطلح “تسرب” بشكل فضفاض، لكن هذا الحدث لا يمكن فهمه بدقة دون فصل أربع حالات توجيهية. RFC 7908 تُعرّف تسربات المسارات حول انتقال إعلانات التوجيه خارج نطاقها المقصود، خصوصًا حين ينتج عنه مسار لا يتوافق مع ترتيب العلاقات المألوف بين العميل والمزوّد والـ peer.[17] هذا المفهوم يختلف عن تفويض الأصل.

  1. تسرب سياسة مسار متعلم.تتعلم شبكة مسارًا شرعيًا من جار، ثم تصدّره إلى جار آخر خارج النطاق المنشود للسياسة. قد تبقى البادئة صاحبة الأصل المفوض عند نهاية AS path. الخطأ هنا في نطاق التصدير: الشبكة المتوسطة تعمل كممر transit حيث لم تكن السياسة تريد ذلك. لأن ASN الأصلي وطول البادئة قد يظلّان مطابقين لـ ROA، قد يصنّف التحقق من أصل المسار المسار كـ Valid حتى لو كان المسار تجاريًا أو تشغيليًا غير لائق.

  2. إعلان أصل غير مصرح به.يقوم ASN بإعلان بادئة لم يصرّح له صاحب المورد بحق منشئها. إذا كانت هناك ROA تغطي أصل ASN مختلفًا، وكان لدى مزود الاعتماد بيانات حالية مصدّقة، يمكن تصنيف الإعلان كـ Invalid بسبب عدم مطابقة الأصل.[13]-[15] يُستخدم مصطلح “اختطاف الأصل” أحيانًا لوصف هذه الحالة، لكن هذا المصطلح لا يثبت وحده نية ضارة أو اعتراض مرور أو سلوكًا جنائيًا أو ملكية قانونية.

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

  4. تسرب سياسة أصل مصرح.تكون البادئة والأصل وmaxLengthمصرحًا بها، لكن مسار AS أو علاقة التصدير تتجاوز السياسة المقصودة. هذه الحالة تُظهر بوضوح حدود ROV. يجيب التحقق من الأصل عن ما إذا كان الأصل مصرحًا به ضمن ROA المتاحة، ولا يجيب عن ما إذا كان AS وسيطًا مخوّلًا لإتاحة Transit، أو عن التوافق مع العلاقات، أو عن ما إذا كان المسار يُفترض أن يُصدَّر لذلك الجار.

تشير التحليلات العامة إلى أن ملاحظات أبريل 2020 تضمنت مزيجًا من المسارات المتعلمة وإعادة الإعلانات أكثر تحديدًا.[4] التقسيم الدقيق غير معلوم. لذا سيكون وصف جميع 8,870 مسارًا بأنها أصول غير مصرح بها، أو كلّها تسريبات سياسة بأصل مصرح، أو كلّها RPKI Invalid، وصفًا غير دقيق ويستبدل توزيعًا غير محلول بتصنيف واحد.

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

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

ما يمكن أن يثبته التحقق من أصل المسار في RPKI

توفر RPKI بنية داعمة تشفيرياً يمكّن حَمَلَة موارد العنوان من إنشاء تفويضات أصل المسار (ROA). تعبّر ROA عن أن ASN محدد مصرح له بإعلان بادئة معينة، مع حد أقصى لطول البادئة.[13] يسترجع مزود الاعتماد (المرتكز) والجهة المستندة (relying party) بيانات RPKI المصدّقة، وينتج payloads معتمدة، ويجعلها متاحة لأنظمة التوجيه أو محركات السياسة. تشغّل RIPE NCC خدمات الشهادات وإدارة ROA للموارد في نطاق خدمتِها، لكنها لا تبرمج موجهات كل شبكة مشاركة بشكل مركزي.[10]

بالنظر إلى مجموعة بيانات معيّنة مصدّقة، يمكن لفحص الأصل أن يعطي ثلاثة نتائج ذات صلة. تكون المسارValidعندما تسمح تفويضات مغطية لكل أصل ASN والطول المعلن. وتكونInvalidعندما توجد تفويضات مغطية لكن لا تسمح بمزيج الأصل والطول المعروض. وتكونNotFoundحين لا توجد تفويضات مغطية متاحة.[14] هذه أحكام نسبية للبيانات المحتفظ بها لدى جهة الاعتماد في لحظة محددة، لا خصائص عالمية أزلية مدمجة في المسار نفسه.

هذا القيد مهم أثناء حادثة إدارة سجلات. يمكن لشبكتين من جهات الاعتماد أن تملكا وجهات نظر مصدّقة مختلفة مؤقتًا بسبب أزمنة مزامنة المستودعات، وحالة الكاش، وسلوك الانتهاء، وردود الفعل التشغيلية.[15] لا يكشف السجل المجمّع حالة الكاش الدقيقة التي رآها كل شبكة أثناء مدة الرصد ساعة واحدة لـ Rostelecom. ولذلك أي ادعاء بأن مشغلًا باسم محدد “رأى Invalid” يحتاج دليلًا على بياناته المصدّقة وسياساته في اللحظة ذاتها.

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

نتيجة Valid تثبت أقل بكثير من “مسار آمن”. لا تحقق من تسلسل AS الوسيط. لا تصدّق على علاقات العميل/المزوّد أو peer. لا تظهر أن شبكة وسيطة كانت مخولة بتصدير مسار متعلم. ولا تثبت أن مسار البيانات وصل إلى الوجهة المقصودة أو أن المرور لم يتحول أو أن جهات الاتصال التشغيلية ستستجيب. يمكن لأصل مصرح به أن يظهر خلف مسار غير مقصود.

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

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

يُجسّد حذف RIPE NCC هذا التمييز بوضوح. حذف 2,669 ROA يمكن أن ينقل بعض المسارات من Valid أو Invalid إلى NotFound في مخرجات جهات الاعتماد بعد المزامنة، وفقًا للسجلات التغطية المتبقية وتوقيت الذاكرة المؤقتة.[3][5] لكنه لم يخلق إعلانات AS12389 في BGP، ولم يُسبب أن الشبكات الوسيطة صدّرتها، ولم يعدّل AS paths بالكامل. في حادث Rostelecom، كان التقاطع الموثق ثلاثة PI holders و12 بادئة فقط، ووجدت التحليلات اللاحقة عدم وجود علاقة مباشرة بين الحادثتين.[4][5]

لذلك لا يمكن الادعاء بأن ROV الشامل قد منّع هذا الحدث بالكامل. كان يمكنه أن يقيد فقط الجزء الذي يندرج ضمن Invalid وفق توفر بيانات ROA الحالية وسياسة منفذٍ فعالة، لكنه لا يرفض تلقائيًا مسارًا متعلمًا ضمن سياسة صحيح الأصل، كما لا يصدّق AS path كاملاً. هذا ليس ضعفًا في الأدلة؛ بل الوصف الصحيح لما صُممت هذه الآلية ليجيب عنه.

السبب الجذري

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

على مستوى المستوى المرئي، بدأ الحادث بإعلان أو تصدير AS12389 لمسارات غير متوقعة في BGP، بما في ذلك ملاحظات فُسّرت كـ learned-route leakage وإعادة إعلانات أكثر تحديدًا.[1][4] قبوله وتصديره اللاحق من شبكات أخرى وسّعا النطاق المرئي. هذا سلسلة أحداث مدعومة بملاحظات التوجيه؛ وليست حسمًا كاملاً للسبب الجذري.

الحدث المنسوب إلى RIPE NCC كان له تسلسل تقني مختلف. تحديث برمجي في سجل أدى إلى تصنيف بعض التخصيصات المستقلة عن المزودين كغير قابلة للتصديق وحذف 2,669 ROA.[3][5] هذا الفشل في البرمجيات وإدارة السجلات غير هيكل مسارًا تشغيليا في BGP. بينما عدّل حادث Rostelecom إعلانات BGP المباشرة. وتؤكد التحليلات اللاحقة عدم وجود علاقة سببية مباشرة بينهما.[4][5] دمجهما كسبب أحادي يتعارض مع السجل الموثق.

الظروف المساهمة

كان الشرط الأول هو اعتماد BGP على السياسة المحلية في كل حد شبكة. يوزع BGP قابلية الوصول ولكن المشغلون يقررون ما يقبلونه ويفضّلونه ويعلنونه.[12] قد يبقى مسار كان من المفترض أن يبقى داخل علاقة سياسية واحدة ويتنقل عبر طبقات متتالية إذا سمحت التكوينات المتتالية بذلك. يبرهن المرور الملحوظ عبر AS20764 وAS174 وAS3356 وجود نقاط قبول وتصدير متعددة، لكن لا يعرّي السياسة المحددة في أي واحدة منها.[1]

والشرط الثاني كان تفاوت دلالة تفويض الأصل. المسارات ذات ROA متعارضة أو مغطّاة كانت قد تكون مرشحة لرفض عبر ROV. المسارات ذات أصل مصرح لا تُعد فشل سياسات مصدر. المسارات بدون ROA مغطية ستكون NotFound. إن المزيج غير المعروف يعني عدم إمكان تحليل واحد يعين وصفًا موحدًا للتثبيت.

والشرط الثالث كان الاعتماد على بيانات تشغيلية حالية. ROA المصحّحة صحيحًا لا يكون له أثر توجيهي ما لم تسترجعها جهات الاعتماد وتتحقق منه وأن تبقى الكاشات حديثة وأن تُسلَّم النتائج للموجهات وأن تؤثرها السياسة المحلية. حذف RIPE NCC أثّر مؤقتًا في طبقة السجل؛ وتزامن المزامنة واستمرار التنفيذ المحلي حددا متى أو ما إذا أثّر هذا التغيير في قرارات شبكة ما.[3][10][15]

والشرط الرابع كان التصفية الموزعة. يمكن أن تتكامل مرشحات بارامترات العملاء، وضوابط الحد الأقصى، وسجلات RIR، والتحقق عبر RPKI، وفحوصات سياسة التصدير.[11][16] لا يثبت السجل العام ما إذا كانت هذه الضوابط كانت موجودة أو غائبة أو متجاوزة أو ذات نطاق غير صحيح لدى Rostelecom أو الشبكات المنتقلة في أبريل 2020؛ فهي فئات تحكم ذات صلة لا نتائج عن إعدادات غير موثقة.

أما الشرط الخامس فهو الرؤية المعيقة. توفر مزودات المراقبة انبعاثات غير طبيعية من نقاط مرئية محدودة وتحذيرات للمشغلين، لكنها لا تمتلك كل Adj-RIB-In لموجهات كل جهاز أو جدول توجيه محلي أو تاريخ إعداد. إن إنذار Qrator وفر دليلًا عمليًا خارجيًا.[1] لكنه لم يكن قادرًا على إعادة بناء العطل الداخلي المبدئي أو ضمان توافق زمني متزامن في كل شبكة متأثرة.

الحدث المحفز

يبقى المحفز المباشر داخل Rostelecom غير معرف. لا يمكن مسؤولياً إسناده إلى شخص أو أمر أو موجه أو عقد أو دافع من الأدلة العامة. أول حدث خارجي يمكن الاعتماد عليه هو ظهور الإعلانات ذات الصلة عبر AS12389 من نقاط ملاحظة Qrator حوالي 19:28 UTC.[1]

لا ينبغي الخلط بين “المحفز” و”الشرط”. قد تسمح السياسة المتساهلة مع الجار، أو تغطية ROA غير مكتملة، أو بيانات قديمة، أو مراقبة محدودة بانتشار الحدث وتأخير احتوائه، لكن أيًا منها لا يثبت من أطلق الإعلانات. كذلك، الحذف المنفصل لـ ROAs كان متزامنًا زمنًا لا محفزًا موثقًا لمسار AS12389.[4][5]

الاكتشاف

ذكرت Qrator أنها اكتشفت الحدث لحظيًا وحذّرت Rostelecom.[1] وقد قدّمت قياساتها بداية وفترة ومقياسًا تقريبيًا للنطاق المرئي وسلسلة الانتشار التي تؤطر إعادة البناء العامة.[1] وأشار CERT-EU لاحقًا إلى ملخص الحدث مع الإشارة إلى عدم وضوح ما إذا كان عرضيًا وتوثيق التعاون بين CERT-EU وRostelecom.[2]

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

الاستجابة

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

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

استجابة RIPE NCC اتبعت مسارها. حققت في ROA المفقودة، وأعادت نشرها في 2 أبريل، ووصفت لاحقًا تحسينات المراقبة.[3][5] هذا الاستجابة لمسألة سلامة وتوفر سجلات RPKI، وليس آلية الاستجابة التوجيهية التي عدّلت إعلانات AS12389.

الاستعادة

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

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

إستعادة خدمة RPKI كانت منفصلة: أعادت RIPE NCC نشر الـROAs المحذوفة في 2 أبريل.[3][5] ثم اعتمدت جهات الاعتماد على عمليات المزامنة والتحقق الخاصة بها لاستقبال الحالة المصلحة. لذا فإن الاستعادة في الريبو واستعادة التوافق في كل جهة اعتماد كانت أحداثًا مرتبطة لكنها غير متطابقة.

تخصيص السيطرة العملية

تصير المساءلة أوضح عندما تُخصص السيطرة بحسب القرار لا بحسب توصيف مؤسسي واسع.

الجهةالتحكم العمليحد الإثبات
Rostelecom / AS12389سياسات إعلان وتصدير المسار، مرشحات الاستيراد حسب الجار، جرد البادئات، مراجعة الإعدادات، نشر التغييرات، المراقبة، التصعيد، وإعادة الإعدادالتغييرات المبدئية وسلسلة الاستجابة الداخلية ليست معلنة
Rascom AS20764 وCogent AS174 وLevel 3 AS3356 وشبكات الانتشار الأخرىمرشحات الاستيراد والتصدير الخاصة بكل منها، سياسة العلاقات، حدود البادئات، استخدام ROV، الاستثناءات، الاستجابة للشذوذ، والإعلانات اللاحقةإعدادات أبريل 2020، حالات الكاش، والعقود غير معروفة
حاملو البادئاتدقة سجلات الموارد، إنشاء ROA، اختيار ASN الأصلي وmaxLength، جهات الاتصال التشغيلية، ورصد الطرق المستقللا يمكن استنتاج قرارات كل طرف بشكل موحد عبر ما يقارب 200 نظام مستقل
RIPE NCCأنظمة الشهادات وإدارة ROA، اختبارات البرمجيات، مراقبة الخدمة، الرجوع العكسي، استعادة الحالة، والإفصاح عن الحادث ضمن دورهالم تحدد بشكل مركزي أو تُفرض مسارات مستخدمة من قبل موجهات تُدار بشكل مستقل
مزودو اعتماد ROVمزامنة المستودعات، حداثة الكاش، تسليم نتائج التحقق، سياسات Invalid/NotFound المحلية، إدارة الاستثناءات، وقرارات التوجيه النهائيةلا يمكن لمراقب عالمي استنتاج حالة التحقق لكل جهة اعتماد في كل لحظة
مزودو مراقبة المساراتجمع من نقاط الرصد، تحليل الشذوذ، تسليم التنبيهات، توفير أدلة تنسيق، وتقارير بعد الحادثيرصدون رؤى توجيه مختارة ولا يسيطرون على الإعلانات أو يعيدون بناء كل إجراء داخلي

هذا التخصيص يمنع خطأين متعاكسين. الأول حصر كل مساءلة في الشبكة المصدّرة وإهمال القرارات المستقلة التي مكنت الانتشار. والثاني تفتيت السيطرة إلى حد يصبح فيه أي قرار بلا مالك. كانت Rostelecom تتحكم فيما أعلنته أو صدّره AS12389. كل جار تحكم في قبوله. وكل شبكة انتقالية تحكمت بتصميم نشر آخر. تحكمت RIPE NCC في توفر سجلات الأصل. وتحكمت جهات الاعتماد فيما إذا أثرت هذه السجلات على التوجيه.

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

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

أدلة السبب الجذري مقابل أدلة المساهمة

أدلة السبب الجذري كانت ستحدد الآلية الداخلية التي أنتجت سلوك AS12389 غير المتوقع أولًا: كتغيير إعداد، أو سجل أتمتة، أو تاريخ جلسة، أو سجل commit وتواريخ متطابقة. لا يوجد أي منها في السجل العام. ملاحظات المسارات الخارجية تُثبت الحدث ومداه، لكنها لا تملأ هذا الفراغ الداخلي.

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

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

تصحيح قابل للقياس

الحادث يدعم نهجًا طبقيًا للإصلاح، لكن ينبغي تقديم الإجراءات كتحكمات قابلة للرصد بدل ادعاءات خطأ.

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

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

ثالثًا، يمكن قياس تشغيل RPKI نهاية النهاية. تشمل المؤشرات عمر مزامنة المستودع، وتقدم أرقام التسلسل في الكاش، وتوافر تدفق التحقق، وعدد المسارات Valid وInvalid وNotFound لكل جلسة، واستثناءات السياسة، وإنذارات التغير المفاجئ في تغطية ROA. وجود سجل في نظام الإصدار غير كافٍ إذا كانت ذاكرة الكاش قديمة أو محرك السياسة منفصلًا فلا يوصل الأثر إلى القرارات الحية.[10][15]

رابعًا، يمكن لحاملي البادئات مراجعة هل ROAs تعكس الأصول الحالية وهل قيمةmaxLengthليست أوسع مما تتطلبه الخطة التشغيلية. يُمكن أن يجعل الحد الأدنى قيمة غير مصرح قد يثبت unauthorized more-specifics كـ Invalid، لكن قيمة مفرطة الضيق قد تبطل إعلانات هندسة الحركة المشروعة. الإعداد الصحيح يعتمد على خطة التوجيه الفعلية، والتحليل اللاحق لمسافاتmaxLengthوتعريض البادئات الفرعية الوهمية يعزز اعتبار هذا الإعداد كخيار تشغيلي دقيق.[20]

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

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

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

أدلة السجل والواقع التشغيلي

السجلات المرجعية وROAs أدلة أساسية. يربط سجل قاعدة البيانات المعلومات الإدارية بمورد شبكي، بينما تعبر ROA عن تفويض الأصل الذي يحدده صاحب المورد.[8][13] الدقة والتفرّد والبيانات الأمنية الحديثة تجعل هذه السجلات مفيدة للمشغلين والمحققين. تساعد في الإجابة: من هو المسجل لمورد معين، وأي ASN مصرح له بإعلان البادئة.

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

حادثة RIPE NCC المنفصلة تُبرز جانبي هذا البناء. كانت السجل وRPKI مهمين لأن إزالة التفويضات كانت يمكن أن تغيّر أدلة الأصل المتاحة لجهات الاعتماد. لكن الحذف لم يعدّل AS paths مركزيًا أو يجبر الشبكات على قبول إعلانات AS12389. استمرارية التشغيل اعتمدت على استعادة السجل، وحداثة الكاشات، وسياسة التوجيه المحلية، والمرشحات الفعالة، والتنسيق في الاستجابة.

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

سياق تصميم لاحق، لا متطلبات رجعية

يصف RFC 8212 وضعية رفض افتراضي في جلسات BGP الخارجية عند عدم تهيئة سياسات الاستيراد أو التصدير صراحة.[18] كإطار تصميم، يقلل هذا النهج من خطر تبادل المسارات عندما تُعرض علاقة غير مكتملة. له صلة بانضباط تكوين لاحق، لكنه ليس دليلًا أن جميع المشغلين المذكورين فعّلوا السلوك في أبريل 2020، وليس دليل مسؤولية قانونية رجعية.

حدّد RFC 9234 لاحقًا أدوار BGP وميكانيكية Only-to-Customer التي تعرّف إشارات بروتوكولية للمساعدة في منع بعض التسريبات المرتبطة بالعلاقة دون اعتماد على ROV.[19] هذا العمل يعالج معلومات لا يحملها ROV مثل اتساق المسار مع الأدوار المُعلنة. لا ينبغي وصفه على أنه متطلب لحدث 2020 أو آلية معروفة على الجلسات الملاحظة.

حللت RFC 9319 لاحقًا اعتبارات تشغيلية حولmaxLengthفي RPKI وتعريض البادئات الفرعية المزيفة.[20] تساعد على فهم لماذا قد لا يقيد التفويض المغطّي إعلانًا أكثر تحديدًا. لكنها لا تثبت إعداد ROA الدقيق لكل مسار متأثر في 2020، ولا تحول عدد 8,870 مباشرة إلى عدد Invalid.

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

ما لا تختلطه هذه المقالة

تختلف هذه الحادثة عن شذوذ المسارات المالي المرتبط بـ PJSC Rostelecom عام 2017. ذاك الحدث كان بزمن مختلف، ومجموعة متأثرة مختلفة، ومدة مختلفة، وسؤال إسناد مختلف. لا يُعاد استنساخه هنا، ولا يمكن استخدام أدلته لافتراض نية أو سبب متكرر أو مسؤولية مرتبطة بحادث 1 أبريل 2020. يقتصر هذا التحليل على سلسلة انتشار AS12389 الملاحظة، ونطاق المراقبة التقريبي لمدة ساعة، والضوابط ذات الصلة لذلك الحدث.

كما تختلف المقالة عن تحليل عام لخطأ ROA وتبعيات الاعتماد واسعة النطاق. حذف RIPE NCC له صلة هنا فقط كحادثة معاصرة مستقلة ذات تقاطع موثق يتضمن ثلاثة PI holders و12 بادئة.[4][5] نظرية أوسع حول أخطاء إنشاء ROA قد تحجب السؤال الكانوني: أي أجزاء من هذا الحدث المختلط يمكن أن يحددها التحقق من الأصل، وأي الأجزاء كانت تتطلب فحوصات علاقة المسار والحدود.

هذا التمييز يحافظ على مركزية الدليل في هذا الحدث. يعتمد اختبار المساءلة في 2020 على إعلانات AS12389 ومرورها عبر AS20764 وAS174 وAS3356، وتصنيف المسارات الفئوي، وتغير حالة ROA زمنيًا، وقرارات التلقّي والتصدير التي تُديرها شبكات مستقلة. دون هذه العناصر يتحول النقاش إلى تكرار حادث آخر لــ PJSC Rostelecom أو مقالة عامة مجردة عن RPKI.

الشكوك الأساسية

لا تزال سلسلة العطل المبدئية غير معروفة. يبقى الانقسام الدقيق بين التسريبات المتعلمة وإعادة إعلانات more-specifics غير معروف. المسارات الأمامية الكاملة ومظاهر المستخدم النهائية في نهاية الخدمات لا تزال غير معروفة. كما تظل حالة RPKI الظاهرة لكل جهة اعتماد في كل لحظة غير معروفة. وتبقى مرشحات الاستيراد والتصدير التي هيّأتها كل شبكة مرور غير معروفة.

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

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

الخلاصة

أظهر حادث PJSC Rostelecom في 1 أبريل 2020 أن تفويض الأصل وفي الوقت نفسه أدلة سياسة المسار تجيب أسئلة مختلفة. رصدت Qrator حدث AS12389 كبير بدأ نحو 19:28 UTC، استمر قرابة ساعة، وانتشر عبر Rascom وCogent وLevel 3، وحسبت 8,870 مسارًا مرتبطة بما يقارب 200 نظام مستقل وأبلغت عن تنسيق لحظي مع Rostelecom.[1] تثبت هذه الملاحظات الحجم والانتشار والاستجابة، لكن ليس السبب الداخلي الكامل.

كان حذف 2,669 ROA على RIPE NCC فشلًا تشغيليًا منفصلًا. التحليل اللاحق لم يجد علاقة مباشرة بينه وبين تسرب Rostelecom، وحدد فقط ثلاثة PI holders و12 بادئة متداخلة.[3]-[5] هذا يمنع خلط الأسباب المباشر أو ادعاء أن كل المسارات المتأثرة كانت Invalid.

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

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

المصادر

  1. https://qrator.net/blog/details/how-you-deal-route-leaks/
  2. https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
  3. https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004072.html
  4. https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004083.html
  5. https://labs.ripe.net/author/nathalie_nathalie/lessons-learned-on-improving-rpki/
  6. https://manrs.org/2021/03/a-regional-look-into-bgp-incidents-in-2020/
  7. https://qrator.net/blog/details/2020-report/
  8. https://apps.db.ripe.net/db-web-ui/lookup?key=AS12389&source=ripe&type=aut-num
  9. https://stat.ripe.net/docs/
  10. https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-roa-management/
  11. https://manrs.org/netops/
  12. https://www.rfc-editor.org/rfc/rfc4271
  13. https://www.rfc-editor.org/rfc/rfc6480
  14. https://www.rfc-editor.org/rfc/rfc6811
  15. https://www.rfc-editor.org/rfc/rfc7115
  16. https://www.rfc-editor.org/rfc/rfc7454
  17. https://www.rfc-editor.org/rfc/rfc7908
  18. https://www.rfc-editor.org/rfc/rfc8212
  19. https://www.rfc-editor.org/rfc/rfc9234
  20. https://www.rfc-editor.org/rfc/rfc9319