المحتويات

المقدمة

معلومات أساسية

مقدمة

النطاق

المتطلبات الأساسية

إخلاء المسؤولية

مشاكل BGP بسبب إعلان البادئات السيئة

إختطاف الطرق

تدهور أداء النظام

خطف البادئة الفرعية

ربكي

مدقق

عرض BGP RPKI

طوبولوجيا

التكوين

BGP RPKI جلسة

تنزيلات ROA على الموجه

التحقق من الصحة

تمكين الأصل كصحة

حالات صلاحية البادئة

1. 203.0.113.0/24 - صالح

2. 203.0.113.1/24 - غير صالح

3. 192.168.122.1/32 غير موجود

السماح ببادئة غير صالحة

تكوين ROA اليدوي على الموجه

سياسة المسار وحالة التحقق من صحة البادئة

مشاركة معلومات التحقق من صحة البادئة من خلال المجتمع الموسع

توصيات لتنفيذ BGP RPKI

الممارسات الجيدة لإنشاء ROA

أداء تأثير صدمة RPKI على موجهات XR BGP

تأثير تحديث ROA على وحدة المعالجة المركزية مع سياسة المسار

تقليل تأثير وحدة المعالجة المركزية (CPU) الناجم عن تحديث ROA

مساحة ذاكرة BGP RPKI

السيناريو 1. ثلاثة خوادم RPKI تم تكوينها على الموجه

السيناريو 2. خوادم RPKI واحدة تم تكوينها على الموجه

المقدمة

يصف هذا المستند ميزة البنية الأساسية للمفتاح العام لمورد بروتوكول العبارة الحدودية (BGP) (RPKI) على النظام الأساسي ل Cisco IOS® XR.

معلومات أساسية

مقدمة

يناقش هذا المستند ميزة BGP RPKI وكيفية حماية BGP باستخدام الموجهات ضد تحديثات بادئات BGP الخاطئة/الضارة.

النطاق

يستخدم هذا المستند Cisco 8000 مع إصدار XR 7.3.1 للتوضيح. ومع ذلك، فإن BGP RPKI هي ميزة غير معتمدة على النظام الأساسي، تنطبق المفاهيم التي تمت مناقشتها في هذا المستند على منصات Cisco الأخرى (مع Cisco IOS، Cisco IOS-XE .) مع تحويلات CLI المكافئة المناسبة. لا يغطي هذا المستند إجراء إضافة أذون أصل المسار (ROAs) في سجلات الإنترنت الإقليمية.

المتطلبات الأساسية

يحتاج القارئ إلى معرفة ببروتوكول BGP.

إخلاء المسؤولية

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

مشاكل BGP بسبب إعلان البادئات السيئة

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

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

- يتم رفض سرقة عناوين IP لإرسال نتائج البريد العشوائي في IP، وبالتالي يتم رفض الخدمة.

- التجسس على حركة المرور للحصول على معلومات حساسة مثل كلمات المرور.

- حدثت حالات انقطاع نتيجة للتكوينات غير الصحيحة التي قام بها المسؤول.

- منع وصول حركة المرور من خلال إستخدام الخوادم المزيفة مما يؤدي إلى الحرمان من الخدمة.

هجوم رفض الخدمة (المعروف عادة باسم DoS) عبارة عن محاولة خبيثة لتعطيل حركة المرور العادية إلى الموجه والمحول والخادم وما إلى ذلك. هناك مجموعة متنوعة من هجمات رفض الخدمة (DoS) وهناك القليل من تلك الهجمات التي يتم مناقشتها هنا.

إختطاف الطرق

تأملوا في السيناريو الظاهر هنا. يرسل النظام الذاتي 3 (AS3) إعلان BGP القانوني للبادئة الخاصة به 10.0.0.0/24. بواسطة تصميم BGP، لا يوجد في BGP ما يمنع المهاجم من إعلان نفس البادئة للإنترنت.

كما هو موضح، يعلن المهاجم في AS4 عن نفس البادئة 10.0.0.0/24. خوارزمية أفضل مسار BGP تفضل مسار ذو AS_PATH أقصر. حيث فازت AS_PATH 1،5،4 على مسار أطول AS 1،5،2،3. وبالتالي، ستتم الآن إعادة توجيه حركة مرور البيانات من العملاء إلى بيئة المهاجم ويمكن أن تكون سوداء اللون، مما يؤدي إلى منع خدمة العملاء النهائيين.

إختطاف طريق

تدهور أداء النظام

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

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

تثبيط المسار

خطف البادئة الفرعية

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

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

خطف البادئة الفرعية

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

وبالتالي، يمكن الموجه تمييز الإعلانات الجيدة عن الإعلانات السيئة (غير القانونية) ويتم إضافة القدرة على تجنب جميع الهجمات التي تمت مناقشتها سابقا بشكل طبيعي على الموجه.  يوفر BGP RPKI مصدر المعلومات الموثوق به المطلوب.

ربكي

يستخدم RPKI المستودع الذي يحتوي على ROAs. تحتوي ROA على معلومات حول البادئة و BGP كرقم. تفويض أصل المسار هو عبارة موقعة مشفرة.

تعد مكاتب التسجيل الإقليمية الخمسة للإنترنت جهات الوديعة في RPKI. تعد "سلطة الأرقام المعينة عبر الإنترنت" (ANA) أعلى الشجرة التي توزع بادئات IP. ووكلاء إعادة الإعمار هم التالون في التسلسل الهرمي. فهم يقومون بتعيين البادئات الفرعية لسجلات الإنترنت المحلية (LIRs) وموفر خدمة الإنترنت الكبير (ISP). يوقعون شهادة لهذه البادئات. يخصص المستوى التالي البادئات الفرعية لتلك كما يستخدم الشهادات الواردة أعلاه لتوقيع شهاداتها الخاصة لاعتماد تخصيصات الخاصة بها. وعادة ما تستخدم هذه الشركات نقاطها المنشورة الخاصة بها لاستضافة الشهادات وتقارير ما بعد التصرف. تسرد كل شهادة نقاط النشر الخاصة بالشهادات التابعة التي توقعها. وبالتالي، يشكل RPKI شجرة الشهادات التي تعكس شجرة عمليات تخصيص عنوان IP. تقوم أجهزة التحقق من صحة RPKI المملوكة لأطراف الاعتماد باستطلاع جميع نقاط النشر للعثور على شهادات وبيانات محدثة عن حقوق الملكية (و CRLs والبيانات). يبدأون من مراكز الإئتمان ويتبعون الروابط لنقاط نشر شهادات الأطفال.

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

وفي هذه اللحظة، توجد خمسة مستودعات لرواسب الروزا تحتفظ بها شركة Ripe NCE، و ARINE، و APNIC، و LACNIC، و Afrinic.

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

اتصال بنية RPKI الأساسية

مدقق

يستخدم هذا العرض التوضيحي أداة التحقق من صحة RIPE. سيتواصل المدقق مع الموجه من خلال إنشاء جلسة عمل TCP. في هذا العرض التوضيحي، يستمع المتحقق إلى IP 192.168.122.120 و المنفذ 3323.

routinator server --rtr 192.168.122.120:3323 --refresh=900

حددت ANA المنفذ 3323 لهذا الاتصال. يحدد مؤقت التحديث الفاصل الزمني الذي ستتم بعده مزامنة المستودع المحلي وتحديثه للحفاظ على التحديث.

عرض BGP RPKI

طوبولوجيا

طوبولوجيا

ملاحظة: يستخدم هذا العرض التوضيحي عشوائي عام كرقم وبادئات لمجرد توضيح ميكانيكا BGP RPKI. ويتم إستخدام بروتوكولات الإنترنت (IP) العامة بسبب RPKI في المقام الأول بهدف حماية البادئات العامة، كما أن جميع وحدات المعالجة المركزية (ROAs) التي يتم إنشاؤها على وحدات المعالجة المركزية (RIRs) هي بادئات عامة. أخيرا، لا يؤثر أي من الإجراءات والتكوينات، إلخ، الموضحة في هذا المستند على عناوين IP و AS العامة بأي طريقة.

التكوين

router bgp 100

bgp router-id 10.1.1.1

rpki server 192.168.122.120

transport tcp port 3323

refresh-time 900

address-family ipv4 unicast

!

neighbor 10.0.12.2

remote-as 8100

address-family ipv4 unicast

route-policy Pass in

route-policy Pass out

!

!

neighbor 10.0.13.3

remote-as 100

address-family ipv4 unicast

!

!

// ‘Pass’ is a permit all route-policy.

BGP RPKI جلسة

يقوم الموجه بإنشاء جلسة TCP باستخدام أداة التحقق من الصحة (IP: 192.168.122.120، المنفذ 3323) لتنزيل ذاكرة ROA المؤقتة إلى ذاكرة الموجه.

RP/0/RP0/CPU0:Cisco8000#show bgp rpki server 192.168.122.120

Wed Jan 20 22:54:15.763 UTC

RPKI Cache-Server 192.168.122.120

Transport: TCP port 3323

Bind source: (not configured)

Connect state: ESTAB

Conn attempts: 1

Total byte RX: 4428792

Total byte TX: 1400

Last reset

Timest: Jan 20 05:59:58 (16:54:17 ago)

Reason: protocol error

تنزيلات ROA على الموجه

يقوم برنامج التحقق من الصحة بتغذية معلومات ROA للموجه. يتم تحديث ذاكرة التخزين المؤقت هذه على فواصل زمنية دورية لتقليل إمكانية قيام الموجه بالاحتفاظ بمعلومات ضئيلة. في هذا العرض التوضيحي، تم تكوين وقت منعش مدته 900 ثانية.  كما هو موضح هنا، قام الموجه Cisco 8000 بتنزيل عناوين IPv4 و 28350 IPv6 ROAs من أداة التحقق من الصحة.

RP/0/RP0/CPU0:Cisco8000#show bgp rpki server summary

Wed Jan 20 23:01:59.432 UTC

Hostname/Address        Transport       State           Time                 ROAs (IPv4/IPv6)

192.168.122.120         TCP:3323        ESTAB           17:00:21        172632/28350

RP/0/RP0/CPU0:Cisco8000#show bgp rpki table ipv4

Wed Jan 20 23:09:26.899 UTC

>>>Snipped output<<<

Network               Maxlen      Origin-AS         Server

10.0.0.0/24            24              13335             192.168.122.120

10.0.4.0/22            22              38803             192.168.122.120

10.0.4.0/24            24              38803             192.168.122.120

10.0.5.0/24            24              38803             192.168.122.120

10.0.6.0/24            24              38803             192.168.122.120

10.0.7.0/24            24              38803             192.168.122.120

10.1.1.0/24            24              13335             192.168.122.120

10.1.4.0/22            22              4134              192.168.122.120

10.1.16.0/20           20              4134              192.168.122.120

10.2.9.0/24            24              4134              192.168.122.120

10.2.10.0/24           24              4134              192.168.122.120

10.2.11.0/24           24              4134              192.168.122.120

10.2.12.0/22           22              4134              192.168.122.120

10.3.0.0/16            16              4134              192.168.122.120

10.6.0.0/22            24              9583              192.168.122.120

التحقق من الصحة

يوضح هذا القسم كيفية تشغيل BGP RPKI وكيف يمنع الموجه من الإعلانات غير الصحيحة/غير القانونية.

تمكين الأصل كصحة

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

RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity

Wed Jan 20 23:27:37.268 UTC

BGP router identifier 10.1.1.1, local AS number 100

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0xe0000000   RD version: 30

BGP main routing table version 30

BGP NSR Initial initsync version 2 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Origin-AS validation codes: V valid, I invalid, N not-found, D disabled

Network            Next Hop            Metric LocPrf Weight Path

D*> 203.0.113.0/24     10.0.12.2                0             0 8100 ?

D*> 203.0.113.1/24     10.0.12.2                0             0 8100 ?

D*> 192.168.122.1/32   10.0.12.2                0             0 8100 ?

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

router bgp 100

address-family ipv4 unicast

bgp origin-as validation enable

!

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

RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity

Thu Jan 21 00:04:58.136 UTC

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Origin-AS validation codes: V valid, I invalid, N not-found, D disabled

Network            Next Hop            Metric LocPrf Weight Path

V*> 203.0.113.0/24     10.0.12.2                0             0 8100 ?

I*  203.0.113.1/24     10.0.12.2                0             0 8100 ?

N*> 192.168.122.1/32   10.0.12.2                0             0 8100 ?

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

router bgp 100

address-family ipv4 unicast

bgp bestpath origin-as use validity

!

حالات صلاحية البادئة

هناك ثلاث حالات يمكن العثور على البادئة a فيها.

RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity

Thu Jan 21 00:04:58.136 UTC

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Origin-AS validation codes: V valid, I invalid, N not-found, D disabled

Network            Next Hop            Metric LocPrf Weight Path

V*> 203.0.113.0/24     10.0.12.2                0             0 8100 ?

I*  203.0.113.1/24     10.0.12.2                0             0 8100 ?

N*> 192.168.122.1/32   10.0.12.2                0             0 8100 ?

- غير صالح - يشير إلى أن البادئة تطابق أي من الشرطين التاليين: 1. وهو يطابق تفويض واحد أو أكثر لأصل المسار (ROAs)، ولكن لا يوجد تطابق ROA حيث يطابق الأصل كما هو على مسار AS. 2. وهو يطابق واحدا أو أكثر من إتفاقات المواد الخطرة في الحد الأدنى للطول المحدد في إتفاقات المواد الخطرة، ولكن بالنسبة لجميع إتفاقات المواد الخطرة حيث يطابق الحد الأدنى للطول، يكون أطول من الحد الأقصى المحدد للطول. لا يهم أصل AS للشرط رقم 2.

- صالح - يشير إلى العثور على البادئة وزوج AS في جدول ذاكرة التخزين المؤقت ل RPKI.

- غير موجود - يشير إلى أن البادئة ليست من بين البادئات الصالحة أو غير الصالحة.

يناقش هذا القسم كل بادئة وحالتها بالتفصيل.

1. 203.0.113.0/24 - صالح

قام نظير eBGP في AS 8100 بإنشاء هذا الموجه والإعلان عنه لعقدة Cisco8000. بما أن أصل AS (8100) يطابق أصل AS في ROA (تم إستلامه من أداة التحقق من الصحة)، يتم تمييز هذه البادئة بأنها صحيحة ويتم تثبيتها في جدول توجيه الموجه.

RP/0/RP0/CPU0:Cisco8000#show bgp rpki table | in "203.0.113.0|Max"

Thu Jan 21 00:21:26.026 UTC

Network               Maxlen          Origin-AS         Server

203.0.113.0/24                24       8100              192.168.122.120

يتم تثبيت المسار في جدول BGP.

RP/0/RP0/CPU0:Cisco8000#show bgp 203.0.113.0/24

Thu Jan 21 05:30:13.858 UTC

BGP routing table entry for 203.0.113.0/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 31          31

Last Modified: Jan 21 00:03:33.344 for 05:26:40

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

8100

10.0.12.2 from 10.0.12.2 (192.168.122.105)

Origin incomplete, metric 0, localpref 100, valid, external, best, group-best

Received Path ID 0, Local Path ID 1, version 31

Origin-AS validity: valid

ونظرا لأن هذه هي أفضل بادئة BGP وصالحة أيضا لكل RPKI، يتم تثبيتها بنجاح في جدول التوجيه.

RP/0/RP0/CPU0:Cisco8000#show route 203.0.113.0/24

Thu Jan 21 00:29:43.667 UTC

Routing entry for 203.0.113.0/24

Known via "bgp 100", distance 20, metric 0

Tag 8100, type external

Installed Jan 21 00:03:33.731 for 00:26:10

Routing Descriptor Blocks

10.0.12.2, from 10.0.12.2, BGP external

Route metric is 0

No advertising protos.

2. 203.0.113.1/24 - غير صالح

هذه البادئة غير صالحة بسبب وجود تعارض في معلومات AS الأصلية المضمنة في ROA ومعلومات الأصل كمعلومات مستلمة عبر رسالة BGP من نظير eBGP. يتم إستلام 203.0.113.1/24 عبر بروتوكول BGP ذي نقطة الوصول AS 8100.

RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity invalid

Thu Jan 21 00:34:38.171 UTC

BGP router identifier 10.1.1.1, local AS number 100

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0xe0000000   RD version: 33

BGP main routing table version 33

BGP NSR Initial initsync version 2 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Network            Next Hop            Metric LocPrf Weight Path

*  203.0.113.1/24     10.0.12.2                0             0 8100 ?

ومع ذلك، توضح عوائد الاستثمار (ROA) التي تم تلقيها من أداة التحقق من الصحة أن هذه البادئة تنتمي إلى AS 10021.

RP/0/RP0/CPU0:Cisco8000#show bgp rpki table 203.0.113.1/24 max 24

Thu Jan 21 00:37:05.615 UTC

RPKI ROA entry for 203.0.113.1/24-24

Origin-AS: 10021 from 192.168.122.120

Version: 124211

بما أن معلومات أصل AS في إعلان BGP المستلم (AS 8100) لم تتطابق مع أصل AS الفعلي المستلم في ROA (AS 10021)، فقد تم تمييز البادئة غير صحيحة ولم يتم تثبيتها في جدول التوجيه.

RP/0/RP0/CPU0:Cisco8000#show bgp 203.0.113.1/24

Thu Jan 21 05:37:26.714 UTC

BGP routing table entry for 203.0.113.1/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 32          32

Last Modified: Jan 21 00:03:33.344 for 05:33:53

Paths: (1 available, no best path)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

8100

10.0.12.2 from 10.0.12.2 (192.168.122.105)

Origin incomplete, metric 0, localpref 100, valid, external

Received Path ID 0, Local Path ID 0, version 0

Origin-AS validity: invalid

3. 192.168.122.1/32 غير موجود

هذه بادئة خاصة وليست موجودة في ذاكرة التخزين المؤقت ل ROA. أعلن BGP عن هذه البادئة على أنها "غير موجودة".

RP/0/RP0/CPU0:Cisco8000#show bgp 192.168.122.1/32

Thu Jan 21 05:44:39.861 UTC

BGP routing table entry for 192.168.122.1/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 33          33

Last Modified: Jan 21 00:03:33.344 for 05:41:06

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

8100

10.0.12.2 from 10.0.12.2 (192.168.122.105)

Origin incomplete, metric 0, localpref 100, valid, external, best, group-best

Received Path ID 0, Local Path ID 1, version 33

Origin-AS validity: not-found

ونظرا لأن RPKI لا يزال يتم اعتماده، يتم تثبيت البادئات "التي لم يتم العثور عليها" في جدول التوجيه. وإلا فسيتسبب ذلك في تجاهل BGP لهذه البادئات الشرعية التي لم يتم تسجيلها في قاعدة بيانات RPKI.

السماح ببادئة غير صالحة

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

router bgp 100

address-family ipv4 unicast

bgp bestpath origin-as allow invalid

!

مع هذا التكوين، يعتبر الموجه بادئات غير صالحة لحساب المسار الأفضل بينما تم وضع علامة "غير صالح" عليها. يظهر هذا الإخراج "203.0.113.1/24" مميز كأفضل مسار.

RP/0/RP0/CPU0:Cisco8000#show bgp

Thu Jan 21 06:21:34.294 UTC

BGP router identifier 10.1.1.1, local AS number 100

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0xe0000000   RD version: 34

BGP main routing table version 34

BGP NSR Initial initsync version 2 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Network            Next Hop            Metric LocPrf Weight Path

*> 203.0.113.0/24     10.0.12.2                0             0 8100 ?

*> 203.0.113.1/24     10.0.12.2                0             0 8100 ?

*> 192.168.122.1/32   10.0.12.2                0             0 8100 ?

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

RP/0/RP0/CPU0:Cisco8000#show bgp 203.0.113.1/24

Thu Jan 21 06:23:26.994 UTC

BGP routing table entry for 203.0.113.1/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 34          34

Last Modified: Jan 21 06:05:31.344 for 00:17:55

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

8100

10.0.12.2 from 10.0.12.2 (192.168.122.105)

Origin incomplete, metric 0, localpref 100, valid, external, best, group-best

Received Path ID 0, Local Path ID 1, version 34

Origin-AS validity: invalid

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

تكوين ROA اليدوي على الموجه

إذا لم يتم بعد، لسبب ما، إنشاء عوائد الاستثمار (ROA) لبادئة معينة أو استقبالها أو تأخيرها، يمكن تكوين عوائد الاستثمار (ROA) اليدوية على الموجه. على سبيل المثال، تم وضع علامة "غير موجود" على البادئة "192.168.122.1/32" كما هو موضح هنا.

RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity

Thu Jan 21 06:36:31.041 UTC

BGP router identifier 10.1.1.1, local AS number 100

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0xe0000000   RD version: 34

BGP main routing table version 34

BGP NSR Initial initsync version 2 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Origin-AS validation codes: V valid, I invalid, N not-found, D disabled

Network            Next Hop            Metric LocPrf Weight Path

V*> 203.0.113.0/24     10.0.12.2                0             0 8100 ?

I*> 203.0.113.1/24     10.0.12.2                0             0 8100 ?

N*> 192.168.122.1/32   10.0.12.2                0             0 8100 ?

يمكن تكوين ROA يدوي كما هو موضح هنا. يربط هذا الأمر البادئة' 192.168.122.1/32' ب AS 8100.

router bgp 100

rpki route 192.168.122.1/32 max 32 origin 8100

مع هذا التكوين، تتغير حالة البادئة من "N" إلى "V".

RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity

Thu Jan 21 06:36:34.151 UTC

BGP router identifier 10.1.1.1, local AS number 100

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0xe0000000   RD version: 35

BGP main routing table version 35

BGP NSR Initial initsync version 2 (Reached)

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Origin-AS validation codes: V valid, I invalid, N not-found, D disabled

Network            Next Hop            Metric LocPrf Weight Path

V*> 203.0.113.0/24     10.0.12.2                0             0 8100 ?

I*> 203.0.113.1/24     10.0.12.2                0             0 8100 ?

V*> 192.168.122.1/32   10.0.12.2                0             0 8100 ?

سياسة المسار وحالة التحقق من صحة البادئة

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

route-policy Invalid

if validation-state is invalid then

set weight 12345

endif

end-policy

!

router bgp 100

remote-as 8100

address-family ipv4 unicast

route-policy Invalid in

!

!

!

يظهر هذا الإخراج وزن تطبيق بادئة غير صالح من 12345.

RP/0/RP0/CPU0:Cisco8000#show bgp 203.0.113.1/24

Thu Jan 21 06:57:33.816 UTC

BGP routing table entry for 203.0.113.1/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 38          38

Last Modified: Jan 21 06:54:04.344 for 00:03:29

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

8100

10.0.12.2 from 10.0.12.2 (192.168.122.105)

Origin incomplete, metric 0, localpref 100, weight 12345, valid, external, best, group-best

Received Path ID 0, Local Path ID 1, version 38

Origin-AS validity: invalid

مشاركة معلومات التحقق من صحة البادئة من خلال المجتمع الموسع

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

وهذا ممكن بواسطة مجتمع BGP الموسع.

يتيح هذا الأمر للموجه مشاركة معلومات "التحقق من صحة البادئة" مع نظائر iBGP.

router bgp 100

address-family ipv4 unicast

bgp origin-as validation signal ibgp

بمجرد تكوين موجه Cisco 8000 كما هو موضح، تتضمن تحديثات BGP إلى الأقران معلومات التحقق من صحة البادئة. في هذه الحالة، يكون موجه iBGP المجاور هو موجه IOS-XE.

csr2#show ip bgp 203.0.113.1/24

BGP routing table entry for 203.0.113.1/24, version 14

Paths: (1 available, best #1, table default)

Not advertised to any peer

Refresh Epoch 1

8100

10.0.12.2 from 10.0.13.1 (10.1.1.1)

Origin IGP, metric 0, localpref 100, valid, internal, best

Extended Community: 0x4300:0:2

rx pathid: 0, tx pathid: 0x0

Updated on Jan 21 2021 18:16:56 UTC

يمكن فهم تخطيط المجتمع الموسع هذا باستخدام 0x4300 0x000 (4 بايت تشير إلى الحالة).

يتم التعامل مع وحدات البايت الأربع التي تشير إلى الحالة كعدد صحيح غير موقع 32 بت يحتوي على إحدى القيم:

- 0 - صالح

- 1 - لم يتم العثور عليه

- 2 - غير صالح

مجتمع البادئة 203.0.113.1/24 هو 0x4300:0:2 الذي يترجم إلى البادئة "غير الصالحة". بهذه الطريقة، لا يزال الموجه CSR2 قادرا على إتخاذ القرارات استنادا إلى حالة التحقق من صحة البادئة، وذلك على الرغم من عدم وجود ذاكرة تخزين مؤقت محلية خاصة به.

يمكن إستخدام حالة التحقق من صحة البادئة الآن للمطابقة في خريطة المسار أو في خوارزمية أفضل مسار BGP.

توصيات لتنفيذ BGP RPKI

الممارسات الجيدة لإنشاء ROA

هذه بعض التوصيات قائمة على الشبكات التي يتعذر الوصول إليها والتي تمت ملاحظتها في RPKI-Observatory. ويحلل مرصد RPKI جوانب متعددة من بيئة RPKI المنشورة.

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

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

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

- إذا كانت مؤسسة تمتلك بادئة، ولكنها تخطط لعدم الإعلان عنها في BGP، فيجب إنشاء قيمة ROA للبادئة AS0. سيؤدي هذا إلى إبطال أي إعلان عن البادئة لأنه لا يمكن أن يظهر AS0 في أي مسار AS.

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

- إذا كان 'A' منشئا لبادئة لعميله 'B' ومكونا ROA لتلك البادئة نيابة عن 'B'، فيجب أن يكون 'A' مسبقا 'B' حتى الإعلان أو أن يكون 'B' قد أنشأ البادئة نفسها.

أداء تأثير صدمة RPKI على موجهات XR BGP

تأثير تحديث ROA على وحدة المعالجة المركزية مع سياسة المسار

عندما يتم تحديث عناوين ROA وإذا كان الموجه يحتوي على سياسة مسار دخول محلية لجيران يحتوي على "حالة التحقق من الصحة"، يصبح من المهم إعادة التحقق من حالة البادئات استنادا إلى عناوين ROA المحدثة الجديدة. ويتحقق ذلك من خلال قيام الموجه بإرسال طلب تحديث BGP إلى النظير الخاص به.

عندما تستلم جيران BGP هذه الرسالة كما هو موضح، يرسل الجيران البادئات مرة أخرى ويمكن لسياسة المسار الواردة إعادة التحقق من صحة البادئات الواردة .

Jan 22 18:28:41.360: BGP: 10.0.12.1 rcv message type 5, length (excl. header) 4

Jan 22 18:28:41.360: BGP: 10.0.12.1 rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 0

تزداد المشكلة عندما يتم تحديث العديد من الجيران في نفس الوقت عند تحديث وحدات الأولوية (ROA). إذا كانت سياسة المسار الوارد المجاورة معقدة وتتطلب الكثير من المعالجة، فعندئذ تكون النتائج عالية لوحدة المعالجة المركزية لبضع دقائق بعد تحديث ROA. لا تحدث رسائل التحديث هذه إذا لم يحتوي نهج المسار الوارد المجاور على الأمر "validation-state is".

إذا تم تكوين "إعادة التكوين التلقائي الوارد دائما" لأحد الجيران، فلن يتم إرسال رسائل تحديث BGP، ولكن سيتم تنفيذ نفس سياسات المسار بنفس المعدل ويمكن توقع إستخدام وحدة المعالجة المركزية نفسه.

يوصى بتفضيل نهج 'BGP BESTPATH origin-as use validity' على تكوين سياسة المسار للأسباب الموضحة في 6.2.2 أدناه.

تقليل تأثير وحدة المعالجة المركزية (CPU) الناجم عن تحديث ROA

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

router bgp 100

address-family ipv4 unicast

bgp bestpath origin-as use validity

!

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

إذا كان المستخدم يفضل السماح بالبادئات "غير الصالحة" وعدم إستخدامها، فبالإضافة إلى أصل مسار أفضل كإستخدام لصلاحية، أستخدم أفضل مسار للتكوين كالسماح بعدم الصلاحية.

في هذه الحالة، عند تغيير أحد إجراءات الوصول عن بعد (ROA)، يتم تحديث المسار الأفضل تلقائيا دون الحاجة إلى رسالة تحديث. من أجل إلغاء التفضيل، يعني المسار أنه خلال تحديد مسار BGP، يعتبر مسار RPKI غير الصالح أقل تفضيلا من أي مسار آخر إلى الوجهة نفسها. ويكون مماثلا لوضع وزنه أو تفضيله المحلي اقل من 0.

وعدد المتعثرين في مرفق إعادة البناء وإعادة البناء صغير نسبيا ولا يؤدي إلى تأثير كبير على الموارد.

ملاحظة: من أجل إستخدام "أصلي أفضل مسار كصحة إستخدام"، يجب أن يكون لجميع مسارات المسار، بما في ذلك مسارات IBGP، صلاحية RPKI الصحيحة. وإذا لم يكن الأمر كذلك، فلا يزال من الممكن إستخدام إختبار حالة التحقق من الصحة في سياسة المسار.

لم يتم التحقق من صحة مسارات IBGP بواسطة الموجه مقابل قاعدة بيانات ROA. تكسب طرق IBGP صلاحية RPKI من مجتمع RPKI الممتد. إذا تم تلقي مسار IBGP دون هذا المجتمع الموسع، فسيتم تعيين حالة التحقق من الصحة الخاصة به على عدم العثور عليها.

مساحة ذاكرة BGP RPKI

وتستهلك كل عملية من عمليات عائد الاستثمار (ROA) الذاكرة اللازمة للفهرس والبيانات. إذا كان هناك نوعان من عائد الاستثمار (ROA) لنفس بادئة IP، ولكنهما يملكان max_len مختلف أو يتم استقبالهما من خوادم RPKI مختلفة، فيتشاركان نفس الفهرس ولكن لديهما بيانات منفصلة. قد تختلف متطلبات الذاكرة لأن مصروفات الذاكرة ليست ثابتة. ويوصى بميزانية زائدة تبلغ 10٪. تتطلب الأنظمة الأساسية 64 بت ذاكرة أكثر لكل كائن ذاكرة من الأنظمة الأساسية 32 بت. إستخدام ذاكرة IOS-XR بالبايت لكائن فهرس وكائن بيانات موجود في الجدول. وبعض النفقات العامة الثابتة في معظمها مدرجة في الأرقام.

النظام الأساسي 32 بت (بايت)

نظام أساسي 64 بت (بايت)

فهرس IPv4

74

111

فهرس IPv6

86

125

البيانات

34

53

يحتاج هذا القسم إلى سيناريوهين لشرح كيفية إستهلاك ROAs للذاكرة.

السيناريو 1. ثلاثة خوادم RPKI تم تكوينها على الموجه

خذ بعين الاعتبار الموجه الذي يستخدم 3 خوادم RPKI، حيث يوفر كل منها 2000000 IPv4 ROAs و 20000 IPv6 ROAs على معالج توجيه من فئة 64 بت سيتطلب هذه الذاكرة:

2000 * (125 + 3*53) + 20000 * (111 + 3*53) بايت = 59.68 مليون بايت

أثناء حساب الذاكرة، تمت مشاركة ROA لنفس البادئة من ثلاثة مدققات مختلفة في نفس قيمة الفهرس.

السيناريو 2. خوادم RPKI واحدة تم تكوينها على الموجه

ذاكرة عملية BGP بدون ROAs:

RP/0/RP0/CPU0:Cisco8000#show processes memory detail location 0/RP0/CPU0 | in $

Fri Jan 22 17:19:57.945 UTC

JID        Text       Data       Stack      Dynamic    Dyn-Limit  Shm-Tot    Phy-Tot       Process

1069           2M        71M       132K        25M      7447M        50M        74M        bgp

RP/0/RP0/CPU0:Cisco8000#show bgp rpki server summary

Fri Jan 22 17:12:09.073 UTC

Hostname/Address    Transport     State         Time          ROAs (IPv4/IPv6)

192.168.122.120     TCP:3323      NONE          00:00:25      N/A

تعتبر عملية BGP تستهلك ذاكرة سعة 25 ميجابايت دون أي عمليات ROAs.

ذاكرة عملية BGP مع ROA:

RP/0/RP0/CPU0:Cisco8000#show bgp rpki server summary

Fri Jan 22 17:23:46.769 UTC

Hostname/Address    Transport     State         Time          ROAs (IPv4/IPv6)

192.168.122.120     TCP:3323      ESTAB         00:02:42      172796/28411

RP/0/RP0/CPU0:Cisco8000#show processes memory detail location 0/RP0/CPU0 | in $

Fri Jan 22 17:24:14.659 UTC

JID        Text       Data       Stack      Dynamic    Dyn-Limit  Shm-Tot    Phy-Tot     Process

1069           2M        99M       132K        53M      7447M        50M       102M       bgp

تعتبر عملية BGP تستهلك ذاكرة سعة 25 ميجابايت دون أي عمليات ROAs.

ذاكرة عملية BGP مع ROA:

RP/0/RP0/CPU0:Cisco8000#show bgp rpki server summary

Fri Jan 22 17:23:46.769 UTC

Hostname/Address    Transport     State         Time          ROAs (IPv4/IPv6)

192.168.122.120     TCP:3323      ESTAB         00:02:42      172796/28411

RP/0/RP0/CPU0:Cisco8000#show processes memory detail location 0/RP0/CPU0 | in $

Fri Jan 22 17:24:14.659 UTC

JID        Text       Data       Stack      Dynamic    Dyn-Limit  Shm-Tot    Phy-Tot     Process

1069           2M        99M       132K        53M      7447M        50M       102M       bgp

يعمل الموجه Cisco 8000 بنظام التشغيل 64 بت. وقد حصل على 172796 IPv4 ROA و 28411 ROA.

الذاكرة (بالبايت) = 172796 × [111 (الفهرس) + 53 (البيانات)] + 28411 × [125 (الفهرس) + 53 (البيانات)].

هذه الحسابات تعطي حوالي 27 ميغابايت وهو تقريبا الزيادة التي تلاحظ على ذاكرة الموجه أعلاه.