BGP: best path, eBGP policy и route leak

⚙️ Теория

🧠 Что такое BGP и где его граница

BGP (Border Gateway Protocol) это междоменный протокол маршрутизации между автономными системами (AS).
В отличие от IGP-протоколов внутри AS, BGP работает как path vector: вместе с префиксом передает атрибуты и путь AS.

Ключевая идея: BGP выбирает путь не только по "кратчайшему расстоянию", а по политике оператора.

🧩 Decision Process по RFC 4271

RFC 4271 описывает три фазы:

Phase 1: вычисление степени предпочтения для полученных маршрутов (policy-driven).
Phase 2: выбор лучшего маршрута для каждой цели и установка в Loc-RIB.
Phase 3: экспорт маршрутов соседям согласно policy.

Практически это означает:

без четкой import/export policy поведение может быть опасным;
BGP это в первую очередь policy engine, а не просто "автоматический выбор shortest path".

🔒 RFC 8212: eBGP по умолчанию без policy не должен пропускать маршруты

RFC 8212 обновляет RFC 4271 и фиксирует безопасное ожидание:

для eBGP должны быть явно заданы и Import Policy, и Export Policy;
без них маршруты не должны автоматически импортироваться/экспортироваться.

Это базовая защита от случайных route leak из-за "permissive default".

🚨 Route leak и почему это происходит

RFC 9234 определяет route leak как распространение маршрутов с нарушением предполагаемых отношений между AS (provider/customer/peer).
На практике причины почти всегда организационные:

отсутствует фильтрация префиксов;
отсутствует согласованная export-policy;
неправильные бизнес-роли у eBGP-сессий.

RFC 9234 добавляет механизм BGP Roles, который помогает выявлять/предотвращать такие утечки при согласовании ролей между соседями.

🛡️ RPKI origin validation и где его место

RPKI origin validation (RFC 6811 + обновления RFC 8481/RFC 8893):

присваивает маршруту состояние Valid / Invalid / NotFound;
не "чинит" AS_PATH и не заменяет policy;
должен быть частью policy (обычно: Invalid отбрасывать, остальные обрабатывать по правилам).

RPKI уменьшает класс ошибок с подменой origin AS, но не закрывает все route leak-сценарии.

❓ Что нужно уметь объяснить

Почему "BGP работает" и "BGP безопасен" это разные вещи?

Потому что соседство может быть поднято и маршруты могут ходить, даже если policy отсутствует или слишком широкая.
Работоспособность без policy не равна безопасной маршрутизации.

Почему RFC 8212 критичен?

Он переводит модель с "implicit allow" на "explicit policy".
Это резко снижает вероятность случайной утечки глобальных префиксов.

Почему одного RPKI недостаточно?

RPKI проверяет происхождение (origin), а не всю корректность распространения пути между AS.
Поэтому нужны и фильтры, и роли, и лимиты, и мониторинг.

🧪 Практика

1. Явно задайте import/export policy на каждом eBGP-соседе

Минимальный шаблон (vendor-agnostic идея):

neighbor <peer>:
  import-policy: ONLY_EXPECTED_PREFIXES + RPKI_POLICY
  export-policy: ONLY_OWN_AND_ALLOWED_CUSTOMER_PREFIXES

Если policy не задана, сессия не должна обмениваться маршрутами (модель RFC 8212).

2. Добавьте защитные лимиты на прием префиксов

Из практик BGP OPSEC (RFC 7454):

ограничить max-prefix на сессию;
фильтровать по префиксам/AS-path там, где это применимо;
использовать community-политику осознанно, без "прозрачного транзита всего подряд".

3. Включите RPKI origin validation в policy

Базовый подход:

Invalid: reject;
Valid: prefer (или пропускать с приоритетом policy);
NotFound: обрабатывать отдельно по рисковой модели.

4. Настройте мониторинг route leak-индикаторов

Контрольные сигналы:

внезапный рост количества принятых маршрутов от соседа;
неожиданная смена origin AS для критичных префиксов;
резкое изменение AS_PATH и транзитных направлений.

🧾 Вывод

Надежный BGP строится не на "дефолтах", а на явной политике.
База для production:

explicit import/export policy (RFC 8212),
фильтры и лимиты (RFC 7454),
route leak prevention/detection через роли (RFC 9234),
RPKI как обязательный слой валидации origin.