.. заголовок: Проверка происхождения маршрутов RPKI и BGP
.. пул: rpki-bgp-route-origin-validation
.. дата: 07.04.2026 12:00:00 UTC
.. тэги: rpki, bgp, безопасность, маршрутизация, перехват маршрутов, roa
.. категория: Статьи
.. ссылка:
.. описание: Как RPKI и проверка происхождения маршрута защищают BGP от перехвата и утечек маршрутов, включая ROA, состояния проверки, протокол RTR и статистику развертывания.
.. тип: текст
<style>
.calc-container { max-width: 860px; margin: 20px auto; padding: 20px; }
.calc-header { margin-bottom: 30px; padding: 25px; background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); border-radius: 12px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); color: white; }
.calc-header h2 { margin-top: 0; color: white; font-size: 28px; margin-bottom: 10px; }
.calc-header p  { margin: 10px 0; opacity: 0.95; font-size: 15px; }
.result-section { background: white; border: 1px solid #e0e0e0; border-radius: 8px; margin-top: 20px; overflow: hidden; box-shadow: 0 2px 4px rgba(0,0,0,0.05); }
.section-content { padding: 20px; background: #fafafa; }
@media (max-width: 768px) { .calc-header h2 { font-size: 22px; } .calc-container { padding: 10px; } }
.article-body { padding: 24px; background: white; line-height: 1.8; font-size: 15px; color: #333; }
.article-body h3 { color: #2d6a2d; border-bottom: 2px solid #4CAF50; padding-bottom: 6px; }
.article-body a { color: #2d6a2d; }
.article-body a:hover { color: #4CAF50; }
.callout { background: #e8f5e9; border-left: 4px solid #4CAF50; padding: 12px 16px; border-radius: 6px; margin: 16px 0; font-size: 14px; }
.callout.warn { background: #fff8e0; border-color: #f0a500; }
pre, .code-block { background: #1e1e2e; color: #cdd6f4; padding: 14px 18px; border-radius: 8px; font-family: 'Courier New', monospace; font-size: 13px; overflow-x: auto; line-height: 1.5; margin: 12px 0; white-space: pre; }
table { width: 100%; border-collapse: collapse; margin: 16px 0; font-size: 14px; }
th { background: #2d6a2d; color: white; padding: 10px 12px; text-align: left; }
td { padding: 8px 12px; border-bottom: 1px solid #e0e0e0; vertical-align: top; }
tr:nth-child(even) td { background: #f5f5f5; }
.state-valid   { color: #276227; font-weight: 600; }
.state-invalid { color: #b91c1c; font-weight: 600; }
.state-unknown { color: #92400e; font-weight: 600; }
</style>
<div class="calc-container">
<div class="calc-header">
<h2>Проверка происхождения маршрутов RPKI и BGP</h2>
<p>Как инфраструктура открытых ключей ресурса предотвращает перехват маршрутов — охватывая цепочку доверия ROA, состояния проверки, протокол RTR и текущее состояние развертывания.</p>
</div>
<div class="result-section">
<div class="section-content article-body">
<h3 id="problem">1. Почему в BGP нет встроенной проверки происхождения</h3>
<p>BGP был разработан для совместного Интернета, в котором всем участникам доверяли. Маршрутизатор принимает сообщение UPDATE и распространяет его без криптографической проверки того, что исходная AS действительно уполномочена объявлять эти IP-префиксы. Это означает, что любая AS — из-за неправильной конфигурации или злого умысла — может объявить чужие префиксы, и это объявление может распространиться по всему миру в течение нескольких минут.</p>
<p>Известные инциденты, ускорившие внедрение RPKI:</p>
<ul>
<li><strong>2008 г. — «Пакистан Телеком»:</strong>PTCL случайно объявила о более конкретном префиксе для адресного пространства YouTube (208.65.153.0/24), заблокировав YouTube по всему миру примерно на 2 часа, прежде чем вышестоящие провайдеры отменили маршрут.</li>
<li><strong>2010 — «Чайна Телеком»:</strong>China Telecom создала около 50 000 префиксов, принадлежащих военным, государственным и коммерческим сетям США, в течение примерно 18 минут. Случайность или намеренность так и не были подтверждены.</li>
<li><strong>2018 г. — Взлом DNS Amazon Route 53:</strong>Злоумышленник использовал BGP для захвата адреса 205.251.196.0/24 (Amazon DNS), перенаправляя трафик криптовалютного кошелька для кражи средств. Атака использовала ОБНОВЛЕНИЕ BGP от eNet (AS10297).</li>
<li><strong>2019 г. — Европейский трафик перенаправлен через China Telecom:</strong>Европейский мобильный трафик (включая Vodafone и швейцарский Swisscom) был перенаправлен через China Telecom примерно на 2 часа из-за утечки маршрута BGP.</li>
</ul>
<h3 id="rpki-trust">2. Иерархия доверия RPKI</h3>
<p>РПКИ (<a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>) строит иерархию сертификатов X.509, отражающую способ делегирования пространства IP-адресов:</p>
<ol>
<li><strong>ЯНА</strong>содержит корневой якорь доверия. Он выдает сертификаты ресурсов пяти RIR (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), каждый из которых охватывает свое адресное пространство.</li>
<li><strong>РИРы</strong>выдавать сертификаты своим членам (провайдерам Интернета, предприятиям) на адресное пространство, принадлежащее этим участникам.</li>
<li><strong>Члены</strong>выдавать сертификаты конечного объекта (EE) и подписывать<em>Авторизация источника маршрута</em>(ROA) — подписанные свидетельства, разрешающие конкретному ASN создавать определенные префиксы.</li>
</ol>
<p>Верификаторы загружают эту иерархию подписанных объектов из пяти репозиториев RIR (а также всех делегированных репозиториев), проверяют цепочку сертификатов и создают проверенную таблицу полезной нагрузки ROA (VRP). Затем маршрутизаторы запрашивают локальный кэш RPKI через<em>протокол РТР</em> (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>), чтобы получить эту таблицу и выполнить проверку происхождения входящих обновлений BGP.</p>
<h3 id="roa">3. Авторизация происхождения маршрута (ROA)</h3>
<p>РОА (<a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>) — подписанный объект, содержащий три поля:</p>
<ul>
<li><strong>АСН</strong>: Автономная система, уполномоченная создать префикс.</li>
<li><strong>Префикс</strong>: Авторизуемый префикс IP (IPv4 или IPv6).</li>
<li><strong>максимальная длина</strong>: максимальная длина префикса, которую ASN имеет право объявлять. Если не указан, разрешен только точный префикс. Если для префикса /20 установлено, скажем, значение 24, ASN может также объявлять более конкретные значения между /20 и /24.</li>
</ul>
<div class="callout warn">
<strong>maxLength — распространенный вектор неправильной конфигурации.</strong>Установка maxLength = 32 (IPv4) или maxLength = 128 (IPv6) в ROA позволяет ASN объявлять любую более конкретную подсеть, включая маршруты хостов /32, которые могут быть использованы при перехвате. Рекомендация: установите для maxLength самый длинный префикс, который вы фактически объявляете (часто такой же, как длина префикса).</div>
<p>Один ROA может авторизовать несколько префиксов для одного и того же ASN, но один ROA не может авторизовать несколько ASN для одного префикса. Чтобы разрешить вторичному ASN (например, транзитному провайдеру или CDN) создавать ваш префикс, создайте отдельный ROA для этого ASN.</p>
<h3 id="validation-states">4. Состояния проверки</h3>
<p>Когда маршрутизатор получает ОБНОВЛЕНИЕ BGP, он выполняет проверку источника (<a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>) против своей локальной таблицы VRP:</p>
<table>
<tr><th>Состояние</th><th>Состояние</th><th>Типичное лечение с учетом местных предпочтений</th></tr>
<tr><td><span class="state-valid">Действительный</span></td><td>По крайней мере, один ROA охватывает префикс (префикс ⊆ префикс ROA И длина префикса ≤ maxLength), И ASN ROA соответствует исходному ASN BGP UPDATE.</td><td>+20 или предпочтительно (обычно)</td></tr>
<tr><td><span class="state-invalid">Неверный</span></td><td>По крайней мере один ROA покрывает префикс, но ни один покрывающий ROA не имеет соответствующего ASN и maxLength ≥ объявленной длины префикса.</td><td>Установить local-pref 0 или удалить (выбор оператора; RFC 6811 рекомендует разрешить, но отметить)</td></tr>
<tr><td><span class="state-unknown">Не найдено</span></td><td>Не существует ROA, охватывающего объявленный префикс.</td><td>Без изменений (рассматривается так же, как и до существования RPKI)</td></tr>
</table>
<p>Ключевое понимание:<em>Неверный</em>является более сильным доказательством проблемы, чем<em>Не найдено</em>. NotFound просто означает, что владелец префикса еще не создал ROA. Недействительно означает, что существует ROA, говорящий, что этот ASN является<em>нет</em>авторизован — сильный сигнал о неправильной настройке или взломе.</p>
<h3 id="rtr">5. Протокол РТР</h3>
<p>Маршрутизаторы сами не проверяют цепочки сертификатов X.509 — это требует больших вычислительных затрат и требует хранения полного кэша RPKI. Вместо этого выделенный<em>валидатор RPKI</em>(Routinator, OctoRPKI, Fort, rpki-client) загружает и проверяет полный репозиторий RPKI и экспортирует только полученные проверенные полезные нагрузки ROA (VRP) на маршрутизаторы через протокол RTR (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>).</p>
<p>RTR использует TCP (порт 323, назначенный IANA; валидаторы, такие как Routinator, по умолчанию используют порт 3323, чтобы не требовать привилегий root) с механизмом инкрементной синхронизации: валидатор отправляет серийные номера, а маршрутизаторы запрашивают только дельту с момента последней синхронизации. Это обеспечивает низкую пропускную способность даже для больших таблиц VRP (в настоящее время около 400 000+ записей IPv4 по всему миру).</p>
<h3 id="deployment">6. Развертывание и статистика</h3>
<p>По состоянию на начало 2026 года развертывание RPKI достигло значительных масштабов:</p>
<ul>
<li>Более 50% префиксов IPv4 с глобальной маршрутизацией имеют хотя бы один покрывающий ROA (по сравнению с примерно 10% в 2019 году).</li>
<li>Большинство интернет-провайдеров уровня 1 и уровня 2 теперь выполняют проверку происхождения маршрута и удаляют или деприоритизируют недействительные маршруты.</li>
<li>MANRS (Взаимосогласованные нормы безопасности маршрутизации) требует создания RPKI ROA в качестве предварительного условия для членства и публикует панель мониторинга соответствия для каждой AS.</li>
</ul>
<p>Живая статистика:<a href="https://rpki-monitor.antd.nist.gov/" target="_blank">Монитор NIST RPKI</a>, <a href="https://www.rov.rpki.net/" target="_blank">РОВ++</a>, <a href="https://stats.labs.apnic.net/rpki" target="_blank">Статистика APNIC RPKI</a>.</p>
<h3 id="beyond-rov">7. За пределами ROV: ASPA и BGPsec</h3>
<p>Проверка происхождения маршрута RPKI только проверяет, что<em>происхождение ASN</em>имеет право объявить префикс. Он не проверяет AS_PATH — злоумышленник все равно может создать ложный AS_PATH с легитимной исходной AS в конце. Два стандарта IETF решают эту проблему:</p>
<ul>
<li><strong>BGPsec</strong> (<a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>): Каждая AS на пути криптографически подписывает UPDATE, создавая нерушимую цепочку хранения. Требуется, чтобы все транзитные AS поддерживали BGPsec, что является существенным препятствием для развертывания. По состоянию на 2026 год используется редко.</li>
<li><strong>АСПА</strong>(Авторизация поставщика автономной системы,<a href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/" target="_blank">проект-ietf-sidrops-aspa-профиль</a>): AS подписывает объект со списком своих авторизованных вышестоящих поставщиков. Верификаторы могут обнаружить недопустимые пути без долин (например, клиент объявляет маршруты, как если бы он был поставщиком). Его проще развернуть, чем BGPsec, и он наберет обороты с 2025–2026 годов.</li>
</ul>
<h3 id="references">Ссылки</h3>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>— Инфраструктура для поддержки безопасной интернет-маршрутизации (обзор RPKI)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>— Профиль авторизации источника маршрута (ROA)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>— Проверка происхождения префикса BGP</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>— Протокол RPKI для маршрутизатора, версия 1 (RTR).</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8416" target="_blank">RFC 8416</a>— Упрощенное управление локальными номерными ресурсами Интернета с помощью RPKI (SLURM — локальное переопределение)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc9286" target="_blank">RFC 9286</a>— Манифесты для инфраструктуры открытых ключей ресурсов (RPKI).</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>— Спецификация протокола BGPsec</li>
<li><a href="https://www.manrs.org/" target="_blank">МАНРС</a>— Взаимосогласованные нормы безопасности маршрутизации</li>
<li><a href="https://rpki.cloudflare.com/" target="_blank">Портал Cloudflare RPKI</a>— живой поиск ROA</li>
</ul>
</div>
</div>
</div>