ياندكس تقدم RPKI

مرحباً ، اسمي ألكسندر عظيموف. في Yandex ، أقوم بتطوير أنظمة مراقبة مختلفة ، وكذلك هندسة شبكات النقل. لكن اليوم سنتحدث عن BGP.



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

BGP وما هو الخطأ في ذلك

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

_{التين. 1. BGP SAFI}

لماذا تلقت BGP (وما زالت تتلقى) الكثير من الاستخدامات؟ هناك سببان رئيسيان:

• BGP هو البروتوكول الوحيد الذي يعمل بين الأنظمة المستقلة (AS) ؛
• يدعم BGP السمات بتنسيق TLV (نوع القيمة الطولية). نعم ، ليس البروتوكول وحده في هذا ، ولكن نظرًا لأنه لا يوجد شيء لاستبداله في المفاصل بين مشغلي الاتصالات ، فمن الأفضل دائمًا إرفاق عنصر أكثر وظيفية به بدلاً من دعم بروتوكول توجيه إضافي.

ما هو الخطأ معه؟ باختصار ، يفتقر البروتوكول إلى آليات مضمنة للتحقق من صحة المعلومات الواردة. بمعنى أن BGP هي بروتوكول لثقة مسبقة: إذا كنت تريد أن تخبر العالم أنك تملك الآن شبكة من Rostelecom أو MTS أو Yandex ، من فضلك!

IRRDB Filter - الأفضل من الأسوأ

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

_{التين. 2. Cloudflare اعتراض المرور}

ولكن لا يزال ، لماذا تحدث مثل هذه الحالات الشاذة كل ستة أشهر ، وليس كل يوم؟ لأن مشغلي الاتصالات يستخدمون قواعد بيانات معلومات التوجيه الخارجية للتحقق مما يحصل عليه جيرانهم من BGP. هناك العديد من قواعد البيانات هذه ، بعضها تتم إدارته بواسطة أمناء السجلات (RIPE ، APNIC ، ARIN ، AFRINIC) ، وبعضهم لاعبون مستقلون (أشهرهم - RADB) ، وهناك أيضًا مجموعة كاملة من المسجلين مملوكة لشركات كبيرة (Level3 ، NTT ، إلخ). بفضل قواعد البيانات هذه ، يحافظ التوجيه عبر النطاق على الاستقرار النسبي لعمله.

ومع ذلك ، هناك فروق دقيقة. يتم التحقق من معلومات المسار استنادًا إلى كائنات ROUTE-OBJECTS وكائنات AS-SET. وإذا كان السابق يتضمن تفويضًا من جانب IRRDB ، فحينئذٍ يكون الترخيص غائباً كفئة للفئة الثانية. أي أنه يمكن لأي شخص إضافة أي شخص إلى مجموعاته وبالتالي تجاوز مرشحات الموردين الأعلى. علاوة على ذلك ، فإن تفرد تسمية AS-SET بين قواعد IRR المختلفة غير مضمون ، مما قد يؤدي إلى تأثيرات مذهلة مع فقد مفاجئ للاتصال في مشغل الاتصالات ، وهو ما من جانبه لم يغير شيئًا.

هناك مشكلة إضافية تتمثل في نموذج الاستخدام AS-SET. هناك نقطتان:

• عندما يكون لدى المشغل عميل جديد ، فإنه يضيفه إلى AS-SET ، ولكنه لا يزيله أبدًا ؛
• يتم تكوين عوامل التصفية نفسها فقط عند التقاطعات مع العملاء.

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

ما هو استبدال مرشحات البادئة على أساس AS-SET؟ الشيء الأكثر إثارة للاهتمام هو أنه على المدى القصير - لا شيء. ولكن هناك آليات إضافية تكمل تشغيل المرشحات على أساس IRRDB ، وقبل كل شيء ، بالطبع ، RPKI.

RPKI

مبسطة ، يمكنك تخيل بنية RPKI كقاعدة بيانات موزعة يمكن التحقق من سجلاتها بطريقة مشفرة. في حالة ROA (ترخيص كائن المسار) ، يكون مالك مساحة العنوان هو الموقع ، والسجل نفسه ثلاثي (البادئة ، asn ، الطول الأقصى). في الواقع ، يفترض هذا الإدخال ما يلي - سمح مالك بادئة مساحة العنوان بـ AS بالرقم $ asn للإعلان عن البادئات بطول لا يزيد عن max_length $. وتستطيع أجهزة التوجيه ، التي تستخدم ذاكرة التخزين المؤقت RPKI ، التحقق من التوافق مع زوج من مكبرات الصوت البادئة الأولى أثناء التنقل .

_{الشكل 3. RPKI الهندسة المعمارية}

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

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

يتم الآن التحقق من الطرق المستندة إلى ROA بشكل تدريجي بواسطة لاعبين رئيسيين: أكبر IXs الأوروبية تتجاهل بالفعل الطرق غير الصحيحة ، ومن بين مشغلي المستوى 1 ، يجدر تسليط الضوء على AT&T ، التي قامت بتشغيل المرشحات عند التقاطعات مع شركائها الأقران. أيضا ، أكبر مقدمي المحتوى مناسبة للقذيفة. وقد قام العشرات من مشغلي وسائل النقل المتوسطة الحجم بالفعل بتنفيذها بهدوء ، دون إخبار أي شخص. لماذا كل هؤلاء المشغلين يطبقون RPKI؟ الجواب بسيط: لحماية حركة المرور الصادرة من أخطاء الآخرين. هذا هو السبب في أن Yandex هي الأولى من نوعها في الاتحاد الروسي لتضمين ROV على حدود شبكتها.

ماذا سيحدث بعد ذلك؟

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



ماذا هذا التغيير بالنسبة لك؟ إذا كنت ترغب في زيادة أمان توجيه حركة المرور بين شبكتك و Yandex ، فإننا نوصي بما يلي:

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

تدعم Yandex أيضًا تطوير نظام التصفية استنادًا إلى كائن RPKI الجديد - ASPA (تفويض مزود النظام المستقل). لا يمكن للمرشحات التي تستند إلى كائنات ASPA و ROA أن تحل محل AS-SETs "المتسربة" فقط ، ولكن أيضًا تغلق هجمات MiTM باستخدام BGP.

سأتحدث بالتفصيل عن ASPA في شهر واحد في مؤتمر Next Hop. سيكون هناك أيضًا زملاء من Netflix و Facebook و Dropbox و Juniper و Mellanox و Yandex. إذا كنت مهتمًا بمكدس الشبكة وتطوره في المستقبل - يأتي التسجيل مفتوحًا .