Co to jest wyciek tras (route leak)?
Wyciek tras to rozgłoszenie tras BGP poza zakres uzgodnionej polityki. Poznaj 6 typów wg RFC 7908, przyczyny i obronę: filtry, RPKI i peerlock.
Ostatnia aktualizacja:
Wyciek tras (route leak) to rozgłoszenie tras BGP poza zakres przewidziany przez polityki routingu zaangażowanych systemów autonomicznych. Najczęściej dzieje się tak, gdy sieć przekazuje trasy nauczone od jednego sąsiada do innego sąsiada, do którego nie powinny one trafić. Zgodnie z definicją z RFC 7908 wyciek narusza relacje handlowe (klient, dostawca, peer): trasy, które miały pozostać w wąskim zakresie, propagują się szerzej i ściągają ruch na sieć, która nie ma ani przepustowości, ani intencji, by go obsłużyć. W odróżnieniu od przejęcia prefiksu (hijacku) źródło (origin) trasy zwykle pozostaje prawidłowe, a problemem jest kierunek i zakres propagacji.
Typy wycieków według RFC 7908
RFC 7908 z 2016 roku porządkuje to zjawisko i definiuje sześć typów wycieków na podstawie relacji między sieciami. Większość z nich sprowadza się do złamania zasady valley-free, zgodnie z którą trasy nauczone od dostawcy lub peera nie powinny być przekazywane innemu dostawcy ani peerowi:
- Typ 1, Hairpin: sieć z wieloma uplinkami przekazuje trasę od jednego dostawcy tranzytowego do drugiego i staje się przypadkowym tranzytem między nimi.
- Typ 2, Lateral ISP-ISP-ISP: trasy nauczone od jednego peera są rozgłaszane do innego peera, choć peering jest z założenia dwustronny.
- Typ 3, wyciek prefiksów dostawcy do peera: sieć rozgłasza peerowi trasy nauczone od własnego dostawcy tranzytowego.
- Typ 4, wyciek prefiksów peera do dostawcy: sieć rozgłasza dostawcy tranzytowemu trasy nauczone od peera.
- Typ 5, re-origination prefiksu: sieć usuwa otrzymany AS_PATH i ogłasza prefiks tak, jakby sama była jego źródłem.
- Typ 6, przypadkowy wyciek prefiksów wewnętrznych i bardziej szczegółowych (more-specific), które nie były przeznaczone do rozgłaszania w BGP.
Najczęstsze przyczyny
Wycieki rzadko są celowe i niemal zawsze wynikają z błędów konfiguracji. Typowy scenariusz to brak filtra wyjściowego (export policy) na sesji eBGP, przez co router redystrybuuje pełną tablicę BGP do sąsiada, do którego powinien wysyłać wyłącznie własne prefiksy. Inne przyczyny to błędne mapowanie BGP community sterujących polityką, omyłkowa redystrybucja IGP do BGP, niepoprawna agregacja oraz pomyłki w automatyzacji. Skutki bywają poważne. W czerwcu 2019 roku wyciek przez małego operatora z Pensylwanii (DQE Communications), wzmocniony przez optymalizator BGP firmy Noction, został przepuszczony dalej przez Verizona, któremu zabrakło filtrowania. Na wiele godzin zdestabilizowało to dostępność części Cloudflare, AWS i innych sieci.
Zapobieganie: filtrowanie, RPKI i peerlock
Zapobieganie wyciekom opiera się na kilku warstwach, które wzajemnie się uzupełniają. Żadna z nich nie wystarcza w pojedynkę, ale razem domykają najczęstsze drogi propagacji błędnych tras:
- Ścisłe filtry prefiksów na wejściu i wyjściu, budowane z obiektów route i as-set w bazach IRR, plus limity max-prefix na każdej sesji.
- Walidacja pochodzenia RPKI (RFC 6811): odrzucanie tras o statusie invalid ogranicza skalę wycieku, choć samego naruszenia relacji w AS_PATH nie wykrywa.
- ASPA (drafty IETF SIDROPS): weryfikacja relacji w AS_PATH na podstawie podpisanych obiektów RPKI, zaprojektowana wprost do wykrywania wycieków łamiących zasadę valley-free.
- Peerlock i peerlock-lite: filtry odrzucające trasy, w których AS_PATH zawiera ASN sieci tranzytowych Tier-1 tam, gdzie nie powinny się one pojawić.
- Stosowanie zasad MANRS oraz ról BGP i atrybutu Only-to-Customer (OTC) z RFC 9234, który automatycznie blokuje propagację trasy poza klienta.
Wycieki tras a AS202520 SkyPass
AS202520 SkyPass stosuje ścisłe filtrowanie na każdej sesji BGP, zarówno na peeringu w polskich IXP-ach (THINX, TPIX, WRIX i 1-IX), jak i na sesjach tranzytowych klientów. Budujemy listy prefiksów z obiektów IRR, walidujemy pochodzenie tras przez RPKI i stosujemy limity max-prefix, dzięki czemu błędne ogłoszenie klienta lub partnera nie propaguje się dalej w sieci. Klientom IP tranzytu i remote IXP udostępniamy te same mechanizmy ochronne, a looking glass pozwala na bieżąco sprawdzić, jak nasze prefiksy i ścieżki są widziane z zewnątrz.
Najczęstsze pytania
Czym różni się wyciek tras od przejęcia prefiksu (hijacku)?
Przy wycieku źródło (origin) trasy zwykle pozostaje prawidłowe, a błędny jest kierunek i zakres propagacji. Przy hijacku obca sieć ogłasza prefiks, do którego nie ma prawa, fałszując origin.
Czy RPKI zapobiega wyciekom tras?
Nie bezpośrednio. RPKI (RFC 6811) waliduje pochodzenie trasy, więc ogranicza skalę wycieku z nieprawidłowym origin, ale nie wykrywa naruszenia relacji w AS_PATH. Do tego służą ASPA (drafty IETF) oraz role BGP i OTC z RFC 9234.
Co to jest zasada valley-free?
Zasada mówiąca, że trasy nauczone od dostawcy lub peera nie powinny być przekazywane innemu dostawcy ani peerowi, tylko własnym klientom. Złamanie tej zasady to istota większości wycieków wg RFC 7908.
Jak peerlock chroni przed wyciekami?
Peerlock odrzuca trasy, w których AS_PATH zawiera numery ASN dużych sieci Tier-1 w miejscach, gdzie nie powinny się pojawić. Blokuje to typowe wycieki, w których mały operator przypadkowo staje się tranzytem między gigantami.
