RPKI and BGP Route Origin Validation

1. چرا BGP اعتبار سنجی منشأ بومی ندارد

BGP برای یک اینترنت مشارکتی طراحی شده بود که در آن همه شرکت کنندگان مورد اعتماد بودند. روتر یک پیام UPDATE را می پذیرد و آن را بدون تأیید رمزنگاری منتشر می کند که AS مبدأ واقعاً مجاز به اعلام آن پیشوندهای IP است. این بدان معنی است که هر AS - از طریق پیکربندی نادرست یا سوء استفاده - می تواند پیشوندهای شخص دیگری را اعلام کند و این اعلامیه ممکن است در عرض چند دقیقه در سطح جهانی منتشر شود.

حوادث قابل توجهی که پذیرش RPKI را تسریع کردند:

• 2008 — پاکستان مخابرات:PTCL به طور تصادفی یک پیشوند خاص تری برای فضای آدرس YouTube اعلام کرد (208.65.153.0/24)، تا 2 ساعت قبل از اینکه ارائه دهندگان بالادست مسیر را پس بگیرند، YouTube را در سطح جهانی سیاه نمایی کرد.
• 2010 — مخابرات چین:China Telecom حدود 50000 پیشوند متعلق به ارتش، دولت و شبکه های تجاری ایالات متحده را برای 18 دقیقه ایجاد کرد. تصادفی یا عمدی بودن هرگز تایید نشد.
• 2018 - آمازون Route 53 DNS ربایش:یک مهاجم از BGP برای ربودن 205.251.196.0/24 (DNS آمازون) استفاده کرد و ترافیک کیف پول ارزهای دیجیتال را برای سرقت وجوه هدایت کرد. در این حمله از یک BGP UPDATE از eNet (AS10297) استفاده شد.
• 2019 - ترافیک اروپا از طریق China Telecom تغییر مسیر داد:ترافیک موبایل اروپا (از جمله Vodafone و Swisscom سوئیس) به دلیل نشت مسیر BGP به مدت تقریباً 2 ساعت از طریق China Telecom تغییر مسیر داده شد.

2. سلسله مراتب اعتماد RPKI

RPKI (RFC 6480) سلسله مراتبی از گواهینامه های X.509 را ایجاد می کند که نشان دهنده نحوه واگذاری فضای آدرس IP است:

1. IANAلنگر اعتماد ریشه را نگه می دارد. این گواهینامه ها را برای پنج RIR (ARIN، RIPE NCC، APNIC، LACNIC، AFRINIC) صادر می کند که هر کدام فضای آدرس آنها را پوشش می دهد.
2. RIR هابرای اعضای خود (ISP ها، شرکت ها) برای فضای آدرسی که آن اعضا دارند گواهی صادر می کنند.
3. اعضاگواهینامه های Entity End (EE) صادر کنید و امضا کنیدمجوزهای مبدا مسیر(ROAs) - گواهی های امضا شده که به یک ASN خاص اجازه می دهد تا پیشوندهای خاص را ایجاد کند.

تأییدکنندگان این سلسله مراتب شی امضا شده را از پنج مخزن RIR (به علاوه هر مخزن تفویض شده) دانلود می کنند، زنجیره گواهی را تأیید می کنند و یک جدول بارگذاری ROA معتبر (VRP) می سازند. سپس روترها یک کش محلی RPKI را از طریق پرس و جو می کنندپروتکل RTR (RFC 8210) برای دریافت این جدول و انجام اعتبارسنجی مبدا در به روز رسانی های BGP ورودی.

3. مجوزهای مبدا مسیر (ROA)

یک ROA (RFC 6482) یک شی امضا شده است که شامل سه فیلد است:

• ASN: سیستم خودمختار مجاز به ایجاد پیشوند.
• پیشوند: پیشوند IP (IPv4 یا IPv6) مجاز است.
• حداکثر طول: حداکثر طول پیشوندی که ASN مجاز به اعلام آن است. اگر مشخص نشده باشد، فقط پیشوند دقیق مجاز است. اگر مثلاً روی 24 برای پیشوند 20/ تنظیم شده باشد، ASN ممکن است هر نوع خاص تری را بین 20/ و 24/ اعلام کند.

یک ROA می‌تواند چندین پیشوند را برای یک ASN یکسان تأیید کند، اما یک ROA نمی‌تواند چندین ASN را برای یک پیشوند واحد تأیید کند. برای اجازه دادن به یک ASN ثانویه (به عنوان مثال، یک ارائه دهنده حمل و نقل یا CDN) برای ایجاد پیشوند شما، یک ROA جداگانه برای آن ASN ایجاد کنید.

4. ایالات اعتبارسنجی

هنگامی که روتر یک BGP UPDATE دریافت می کند، اعتبار سنجی مبدا را انجام می دهد (RFC 6811) در برابر جدول VRP محلی آن:

بینش کلیدی:نامعتبر استشواهد قوی تر از یک مشکل استیافت نشد. NotFound به سادگی به این معنی است که مالک پیشوند هنوز ROA ایجاد نکرده است. نامعتبر به این معنی است که یک ROA وجود دارد که می گوید این ASN استنهمجاز - یک سیگنال قوی از پیکربندی اشتباه یا ربودن.

5. پروتکل RTR

روترها خودشان زنجیره های گواهی X.509 را تأیید نمی کنند - این امر از نظر محاسباتی گران است و نیاز به نگه داشتن یک کش کامل RPKI دارد. در عوض، اختصاص داده شده استاعتبار سنجی RPKI(Routinator, OctoRPKI, Fort, rpki-client) مخزن کامل RPKI را بارگیری و تأیید می کند و فقط بارهای اعتبار ROA معتبر (VRPs) حاصل را از طریق پروتکل RTR به روترها صادر می کند (RFC 8210).

RTR از TCP (درگاه اختصاص داده شده توسط IANA 323؛ اعتبارسنجی‌هایی مانند Routinator به طور پیش‌فرض در پورت 3323 برای اجتناب از نیاز به امتیازات ریشه) با مکانیزم همگام‌سازی افزایشی استفاده می‌کند: اعتبارسنجی شماره‌های سریال را ارسال می‌کند و روترها از آخرین همگام‌سازی فقط دلتا را درخواست می‌کنند. این امر حتی برای جداول VRP بزرگ (در حال حاضر ~400000+ ورودی IPv4 در سطح جهانی) پهنای باند را پایین نگه می دارد.

6. استقرار و آمار

از اوایل سال 2026، استقرار RPKI به مقیاس قابل توجهی رسیده است:

• بیش از 50٪ از پیشوندهای IPv4 روت شده در سطح جهانی حداقل یک ROA را پوشش می دهند (در مقایسه با 10٪ در سال 2019).
• اکثر ISP های Tier-1 و Tier-2 اکنون اعتبارسنجی مبدا مسیر را انجام می دهند و مسیرهای نامعتبر را حذف یا اولویت بندی می کنند.
• MANRS (هنجارهای مورد توافق متقابل برای امنیت مسیریابی) به ایجاد RPKI ROA به عنوان پیش نیاز عضویت نیاز دارد و داشبورد انطباق هر AS را منتشر می کند.

آمار زنده:مانیتور NIST RPKI, ROV++, آمار APNIC RPKI.

7. فراتر از ROV: ASPA و BGPsec

RPKI Route Origin Validation فقط تأیید می کند کهمبدا ASNمجاز به اعلام پیش شماره می باشد. AS_PATH را تأیید نمی‌کند - مهاجم همچنان می‌تواند یک AS_PATH نادرست با منشأ قانونی در پایان بسازد. دو استاندارد IETF به این موضوع می پردازند:

• BGPsec (RFC 8205): هر AS در مسیر به صورت رمزنگاری UPDATE را امضا می کند و یک زنجیره ناگسستنی از نگهبانی ایجاد می کند. به همه AS های ترانزیت نیاز دارد که از BGPsec پشتیبانی کنند - یک مانع استقرار مهم. از سال 2026 به ندرت مستقر شده است.
• ASPA(مجوز ارائه دهنده سیستم مستقل،پیش نویس-ietf-sidrops-aspa-profile): یک AS شیئی را امضا می کند که ارائه دهندگان بالادست مجاز خود را فهرست می کند. تأییدکننده‌ها می‌توانند مسیرهای بدون دره نامعتبر را شناسایی کنند (مثلاً، مشتری مسیرها را مانند ارائه‌دهنده اعلام می‌کند). استقرار ساده تر از BGPsec و جلب توجه از 2025-2026.

مراجع

• RFC 6480- زیرساختی برای پشتیبانی از مسیریابی امن اینترنت (نمای کلی RPKI)
• RFC 6482- نمایه ای برای مجوزهای مبدا مسیر (ROA)
• RFC 6811- اعتبارسنجی مبدأ پیشوند BGP
• RFC 8210- پروتکل RPKI به روتر، نسخه 1 (RTR)
• RFC 8416- مدیریت منابع شماره اینترنت محلی ساده با RPKI (SLURM - لغو محلی)
• RFC 9286- مانیفست‌ها برای زیرساخت کلید عمومی منبع (RPKI)
• RFC 8205- مشخصات پروتکل BGPsec
• MANRS- هنجارهای مورد توافق دوجانبه برای امنیت مسیریابی
• پورتال Cloudflare RPKI- جستجوی زنده ROA