حوادث BGP Hijacking رو به افزایش است؛ پذیرش RPKI هنوز در جاهای مهم عقب مانده
تا اواسط ۲۰۲۶، معادل ۶۷.۴۳ درصد از مسیرهای اینترنتی اعلام‌شده دارای Route Origin Authorization معتبر بودند و ۷۰.۳ درصد از ترافیک جهانی از مسیرهای معتبر RPKI عبور می‌کرد. در ظاهر، این دستاوردی واقعی برای زیرساخت اینترنت است: RPKI یا Resource Public Key Infrastructure، سیستم رمزنگاری طراحی‌شده برای جلوگیری از ادعای جعلی مالکیت بلوک‌های آدرس IP، در کمتر از یک دهه از یک روش بهینه کم‌طرفدار به اکثریت پذیرش جهانی رسیده است. با این حال، Qrator Labs تنها در سه ماه نخست ۲۰۲۶، هفت نشت مسیر و حداقل یک BGP Hijack مهم را ثبت کرد؛ اپراتورهای شبکه نیز گزارش می‌دهند که روزانه بیش از ۶٬۰۰۰ پیشوند نامعتبر RPKI اعلام می‌شود. پذیرش افزایش یافته، اما حوادث از بین نرفته‌اند. این دو واقعیت در تناقض با یکدیگر نیستند، و درک علت آن برای هر کسی که زیرساختی وابسته به لایه مسیریابی اینترنت اداره می‌کند اهمیت دارد.
RPKI واقعاً چه مشکلی را حل می‌کند — و چه مشکلی را نه
Border Gateway Protocol یا BGP، سیستمی که به شبکه‌ها اجازه می‌دهد اعلام کنند «من مالک این بلوک آدرس IP هستم، ترافیک آن را از طریق من مسیریابی کن»، در دوره‌ای طراحی شد که حسن‌نیت میان اپراتورها را مفروض می‌گرفت. BGP احراز هویت داخلی ندارد: هر شبکه‌ای می‌تواند مالکیت هر بلوک آدرسی را اعلام کند و شبکه‌های همسایه معمولاً این اعلام را می‌پذیرند، مگر آنکه چیزی توجه‌شان را جلب کند. RPKI اساسی‌ترین نسخه این مشکل را برطرف می‌کند — یک شبکه یک Route Origin Authorization یا ROA را به‌صورت رمزنگاری‌شده امضا می‌کند که اثبات می‌کند مجاز به اعلام یک پیشوند خاص است، و شبکه‌های دیگر می‌توانند پیش از پذیرش مسیر، آن امضا را اعتبارسنجی کنند.
آنچه اعتبارسنجی پایه ROA در RPKI برطرف نمی‌کند، جعل مسیر همراه با اعلام زیرپیشوندهای دقیق‌تر است. این مکانیزم پشت بیشتر حوادثی است که در ۲۰۲۶ در شبکه‌های ظاهراً محافظت‌شده رخ می‌دهد: مهاجم شماره AS مبدأ را جعل می‌کند تا با یک ROA معتبر مطابقت داشته باشد، سپس زیرپیشوندی دقیق‌تر از پیشوند قانونی اعلام می‌کند. الگوریتم انتخاب مسیر BGP، مسیرهای دقیق‌تر را تقریباً به‌صورت بی‌قیدوشرط ترجیح می‌دهد — این یک اصل طراحی چندین‌دهه‌ای است، نه یک باگ — بنابراین اعلام جعلی و غیرقانونی حتی در شبکه‌هایی که Route Origin Validation یا ROV را به‌درستی اجرا می‌کنند، در تصمیم مسیریابی برنده می‌شود. بررسی ROA درست از آب درمی‌آید. مشکل در پیشوند است؛ به شکلی که ROV به‌تنهایی نمی‌تواند آن را شناسایی کند.
چرا راه‌حل این مشکل در جا می‌زند
پاسخ فنی به BGP Hijacking زیرپیشوند با جعل مبدأ وجود دارد: Autonomous System Provider Authorization یا ASPA، یک شیء جدیدتر RPKI که به یک شبکه امکان می‌دهد ارائه‌دهندگان upstream قانونی خود را به‌صورت رمزنگاری‌شده اعلام کند و دسته‌ای از حملات جعل مسیر را که اعتبارسنجی صرفاً مبتنی بر ROA از پس آن‌ها برنمی‌آید، مسدود نماید. مشکل در استقرار است: تا اواسط ۲۰۲۶، اشیاء ASPA تنها حدود ۲.۵۴ درصد از سیستم‌های خودگردان جهانی را پوشش می‌دهند. این فناوری نیاز دارد که هر شبکه در یک مسیر برای معنادار بودن حفاظت مشارکت کند؛ این ویژگی آن را به یک مشکل کلاسیک هماهنگی تبدیل می‌کند — هر شبکه منفردی تا زمانی که تعداد کافی از همسایگانش ASPA را استقرار نداده‌اند، بهره محدودی از آن می‌برد، بنابراین پذیرش آهسته پیش می‌رود؛ حتی اگر خود فناوری بالغ و استانداردشده باشد.
دلیل ساده‌تر و کمتر فنی‌تری هم برای تداوم حوادث وجود دارد: اعلام‌های نامعتبر RPKI در مقیاس بیش از ۶٬۰۰۰ پیشوند در روز، عمدتاً ناشی از مهاجمان مخرب در حال آزمایش تکنیک‌های پیچیده جعل مبدأ نیست — بلکه پیکربندی نادرست، اشتباهات تایپی و ROAهای منقضی از اپراتورهایی است که RPKI را یک‌بار راه‌اندازی کرده‌اند و پس از تغییر شبکه‌شان هرگز آن را بازبینی نکرده‌اند. این خطاهای معمول دقیقاً همان پس‌زمینه‌ای ایجاد می‌کنند که شناسایی تعداد کمتر BGP Hijackهای واقعاً مخرب در میان آن‌ها را دشوارتر می‌سازد.
این موضوع برای مدیران زیرساخت تولیدی چه معنایی دارد
اگر سازمان شما مستقیماً با ارائه‌دهندگان upstream تبادل ترافیک دارد یا AS خود را اداره می‌کند، Route Origin Validation در این مرحله یک الزام پایه است — استقرار آن دیگر چالش بزرگی نیست و بیشتر ارائه‌دهندگان Transit اصلی اکنون آن را به‌صورت native پشتیبانی می‌کنند. اما ROV را کف بدانید، نه سقف. پیشوندهای خود را برای اعلام‌های زیرپیشوند غیرمجاز با استفاده از یک سرویس نظارت بر مسیر رصد کنید — چند سرویس برای همین منظور پلن رایگان ارائه می‌دهند — چون یک BGP Hijack زیرپیشوند با جعل مبدأ علیه فضای آدرس شما از اعتبارسنجی ROV به‌راحتی عبور می‌کند و هشدارهایی را که بیشتر تیم‌ها تصور می‌کنند آن‌ها را پوشش می‌دهد، فعال نمی‌کند. اگر هم در حال ارزیابی یک ارائه‌دهنده Transit یا Cloud بر اساس انعطاف‌پذیری شبکه هستید، به‌طور مشخص بپرسید آیا ASPA را استقرار داده‌اند — با پوشش جهانی کمتر از ۳ درصد، یک «بله» هنوز یک مزیت واقعی است، نه چک‌باکسی که همه بتوانند ادعا کنند.