BGP: jak jedna błędna trasa potrafi odciąć pół internetu

Internet nie ma centralnego sterowania ruchem. Trasy między sieciami ustalają operatorzy, którzy wymieniają między sobą informacje o tym, dokąd prowadzą ich adresy. Protokół, który to umożliwia, nazywa się BGP i opiera się na zaufaniu do tego, co ogłasza sąsiad. Dlatego pojedyncza błędna konfiguracja potrafi zniknąć z globalnej tabeli całą firmę albo skierować ruch do sieci, która go nie udźwignie.

Czym jest BGP i co dokładnie ogłasza

Internet dzieli się na systemy autonomiczne, w skrócie AS. To zbiory adresów IP zarządzane przez jedną organizację, na przykład dostawcę internetu, centrum danych albo dużą firmę. BGP, opisany w dokumencie RFC 4271 z 2006 roku, służy do wymiany informacji o osiągalności między takimi systemami. Komunikat nie mówi „jestem najlepszą drogą”, tylko „te adresy są osiągalne przez taką ścieżkę systemów” ^[1].

Router zbiera ogłoszenia od sąsiadów i wybiera jedną trasę na podstawie polityki: preferencji lokalnych, długości ścieżki AS, wcześniejszych ustaleń handlowych. Nie kieruje się opóźnieniem ani przepustowością. Adres, który nie został ogłoszony, po prostu nie istnieje z punktu widzenia reszty internetu, nawet jeśli serwer działa i ma zasilanie.

Druga zasada jest równie ważna. Przy wyborze trasy wygrywa najbardziej szczegółowy prefiks. Jeśli jedna sieć ogłasza blok 104.20.0.0/20, a inna ogłasza jego fragment 104.20.0.0/21, cały ruch do tego fragmentu pójdzie do drugiej, niezależnie od tego, jak długa jest jej ścieżka AS. To właśnie ta reguła sprawia, że wyciek kilku „bardziej szczegółowych” tras potrafi przekierować ruch milionów użytkowników.

Jak wygląda awaria: wycofanie tras

BGP nie tylko dodaje trasy, ale też je wycofuje. Gdy router przestaje ogłaszać prefiks, sąsiedzi usuwają go ze swoich tabel i po chwili ruch do niego przestaje być routowany. W normalnej eksploatacji to pożądane zachowanie: awaria łącza powinna przenieść ruch na zapas. Problem zaczyna się wtedy, gdy wycofanie jest skutkiem ubocznym błędu w innym miejscu.

Najbardziej znany przykład to awaria Facebooka z 4 października 2021 roku. Firma opisała ją w swoim blogu inżynierskim. Podczas rutynowej konserwacji sieci szkieletowej wydano polecenie, które miało sprawdzić dostępność przepustowości, a w praktyce odcięło wszystkie połączenia między centrami danych. System audytu, który miał zatrzymać takie polecenie, zawierał błąd i nie zadziałał ^[2].

Dalej wydarzyło się coś, co dobrze pokazuje sprzężenie zwrotne w infrastrukturze. Serwery DNS Facebooka, odpowiadające za zamianę nazw na adresy IP, były zaprogramowane tak, aby wycofać swoje ogłoszenia BGP, jeśli stracą łączność z centrami danych. Przy odciętym szkielecie uznały się za niezdrowe i wycofały trasy. Adresy serwerów DNS przestały być osiągalne, choć same maszyny nadal działały. Reszta internetu nie mogła znaleźć facebook.com, a narzędzia wewnętrzne firmy, również oparte na DNS, przestały działać, co utrudniło diagnozę ^[2].

DNS ma własny mechanizm podpisów, DNSSEC, ale chroni on integralność odpowiedzi, a nie osiągalność serwerów.

Wzorzec jest ogólny: mechanizm bezpieczeństwa, który ma zapobiegać kierowaniu ruchu do niedziałającego centrum, w sytuacji awaryjnej usuwa z internetu również to, co jeszcze działa.

Jak wygląda awaria: wyciek tras

Drugi scenariusz to sytuacja, w której trasa nie znika, ale trafia tam, gdzie nie powinna. W czerwcu 2019 roku mały dostawca z Pensylwanii, DQE Communications, używał optymalizatora BGP, który dzielił otrzymane prefiksy na mniejsze fragmenty, żeby lepiej sterować ruchem wewnątrz własnej sieci. Te fragmenty nie miały opuszczać jego infrastruktury. Opuściły, trafiły do klienta, potem do Verizona, a stamtąd do globalnej tabeli routingu ^[3].

Cloudflare opisało to jako moment, w którym mała firma stała się preferowaną drogą do wielu tras w internecie. Verizon przyjął i rozgłosił około 20 tysięcy tras, których nie powinien przyjąć, a ruch do Cloudflare, Amazona i innych usług zaczął płynąć przez sieć, która nie miała na to przepustowości. Efektem były masowe straty pakietów i niedostępność usług przez kilka godzin, aż ogłoszenia zostały wycofane ^[3].

Niezależna analiza ThousandEyes potwierdziła ten sam przebieg i wskazała na brak filtrów po stronie Verizona: sesja BGP nie miała limitu liczby przyjmowanych prefiksów ani filtrów opartych na rejestrze routingu ^[4]. To nie był atak. To była suma kilku zaniedbań, z których każde osobno wyglądało na drobiazg.

Co miało temu zapobiec

Pierwsza linia obrony jest prosta i tania. Limit maksymalnej liczby prefiksów przyjmowanych od sąsiada powoduje, że router zamyka sesję, gdy ktoś nagle ogłasza ich tysiące. Filtr prefiksów pozwala przyjąć tylko to, co sąsiad naprawdę posiada. Rejestry routingu, takie jak IRR, pozwalają budować takie filtry z publicznie zadeklarowanych danych.

Druga linia to RPKI, czyli infrastruktura klucza publicznego dla zasobów adresowych. Właściciel bloku publikuje podpisane upoważnienie, zwane ROA, które mówi, jaki system autonomiczny może ogłaszać dany prefiks i do jakiej długości. Routery wykonujące walidację pochodzenia oznaczają każdą trasę jako poprawną, niepoprawną albo nieznaną, zgodnie ze specyfikacją RFC 6811 ^[5]. Trasy niepoprawne są zwykle odrzucane.

Warto jednak wiedzieć, czego RPKI nie robi. Sprawdza tylko pochodzenie prefiksu, a nie całą ścieżkę AS. Nie wykryje wycieku tras, w którym każdy uczestnik ścieżki jest legalny. Samo wdrożenie walidacji jest też nierówne: jedne sieci odrzucają trasy niepoprawne, inne tylko je oznaczają. Dlatego RPKI zmniejsza ryzyko, ale go nie usuwa.

Osobną kategorię stanowią wycieki tras, które doczekały się własnej taksonomii w dokumencie RFC 7908 z 2016 roku. To zestawienie pokazuje, że problem nie jest pojedynczym błędem, ale klasą zachowań wynikających z tego, jak BGP działa ^[6].

Dlaczego to nadal funkcjonuje

Brak centralnego zarządzania brzmi jak wada, ale jest też powodem, dla którego internet działa. Żadna firma ani państwo nie może wyłączyć ruchu globalnie, bo nie ma jednego punktu, przez który wszystko przechodzi. Ta sama decentralizacja sprawia jednak, że higiena routingu zależy od dobrej woli i kompetencji dziesiątek tysięcy operatorów. Jeden z nich może przyjąć trasę, której nie powinien, i nikt nie zapyta go o zgodę.

Dlatego w praktyce liczą się trzy rzeczy: filtry na każdej sesji zewnętrznej, publikacja ROA dla własnych prefiksów oraz monitorowanie, czy ogłoszenia zgadzają się z zamiarem. Narzędzia takie jak RIPE RIS czy Route Views pozwalają zobaczyć własne prefiksy z perspektywy wielu punktów obserwacyjnych. To nie zabezpiecza przed błędem sąsiada, ale skraca czas, w którym błąd jest niewidoczny.

BGP nie jest zepsuty. Jest protokołem z lat osiemdziesiątych, który przetrwał skalę, jakiej jego twórcy nie planowali, i nadal działa, bo operatorzy nauczyli się go pilnować. Awaria Facebooka i wyciek z 2019 roku pokazują, co się dzieje, gdy ta pielęgnacja zawiedzie. Nie przez atak, ale przez zwykłe polecenie, brak filtra i zaufanie do tego, co przysłał sąsiad.

Źródła

1. Y. Rekhter, T. Li, S. Hares (red.), „A Border Gateway Protocol 4 (BGP-4)”, RFC 4271, IETF, styczeń 2006. https://www.rfc-editor.org/rfc/rfc4271.html
2. Santosh Janardhan, „More details about the October 4 outage”, Engineering at Meta, 5 października 2021. https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
3. Cloudflare, „How Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Today”, 24 czerwca 2019. https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
4. ThousandEyes, „Cloudflare Users Burned by Internet Routing Pile-Up”, 24 czerwca 2019. https://www.thousandeyes.com/blog/cloudflare-users-burned-by-internet-routing-pile-up
5. P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein, „BGP Prefix Origin Validation”, RFC 6811, IETF, styczeń 2013. https://www.rfc-editor.org/rfc/rfc6811.html
6. K. Sriram, D. Montgomery, D. McPherson, E. Osterweil, B. Dickson, „Problem Definition and Classification of BGP Route Leaks”, RFC 7908, IETF, czerwiec 2016. https://www.rfc-editor.org/rfc/rfc7908.html