Wycieki tras BGP doprowadziły do masowych zakłóceń w łączności w internecie

Firma Cloudflare opublikowała raport z wczorajszego incydentu, w wyniku którego przez trzy godziny od 13:34 do 16:26 (MSK) występowały problemy z dostępem do wielu zasobów w globalnej sieci, w tym infrastruktury Cloudflare, Facebooka, Akamai, Apple, Linode i Amazon AWS. Problemy w infrastrukturze Cloudflare, która dostarcza CDN dla 16 mln stron, odnotowano od 14:02 do 16:02 (MSK). Według szacunków Cloudflare w trakcie awarii zanotowano utratę około 15% globalnego ruchu.

Problem występował jest spowodowany wyciekiem tras przez BGP, w wyniku którego około 20 tys. prefiksów dla 2400 sieci zostało nieprawidłowo przekierowanych. Źródłem wycieku był dostawca DQE Communications, który używał oprogramowania BGP Optimizer do optymalizacji routingu. BGP Optimizer dzieli prefiksy IP na mniejsze, na przykład dzieli 104.20.0.0/20 na 104.20.0.0/21 i 104.20.8.0/21, a w konsekwencji DQE Communications posiadał po swojej stronie dużą liczbę specyficznych tras, które nadpisywały bardziej ogólne trasy (tzn. zamiast ogólnych tras do Cloudflare używano bardziej szczegółowych tras do konkretnych podsieci Cloudflare).

Te konkretne trasy zostały ogłoszone jednemu z klientów (Allegheny Technologies, AS396531), który również był podłączony przez innego dostawcę. Allegheny Technologies transmitował otrzymane trasy innemu dostawcy tranzytowemu (Verizon, AS701). Z powodu braku odpowiedniego filtrowania ogłoszeń BGP i ograniczenia liczby prefiksów, Verizon przyjął to ogłoszenie i transmitował otrzymane 20 tys. prefiksów dla reszty internetu. Nieprawidłowe prefiksy z powodu swojej granularity zostały uznane za bardziej priorytetowe, ponieważ konkretny ruch ma wyższy priorytet niż ogólny.

W rezultacie ruch dla wielu dużych sieci zaczął być kierowany przez Verizon do małego dostawcy DQE Communications, który nie był w stanie obsłużyć napływającego strumienia, co doprowadziło do kolapsu (efekt porównywalny do sytuacji, gdy część obciążonej autostrady zastąpiono drogą gruntową).

Aby zapobiec wystąpieniu podobnych incydentów w przyszłości,
zaleca:

• Użyć weryfikację ogłoszeń na podstawie RPKI (BGP Origin Validation, pozwala na przyjęcie ogłoszeń tylko od właścicieli sieci);
• Ograniczyć maksymalną liczbę przyjmowanych prefiksów dla wszystkich sesji EBGP (ustawienie maximum-prefix pomogłoby odrzucić transmisję 20 tys. prefiksów w ramach jednej sesji);
• Stosować filtry oparte na rejestrze IRR (Internet Routing Registry, określa AS, przez które dozwolone jest trasowanie określonych prefiksów);
• Używać na routerach ustawień zalecanych w RFC 8212 do domyślnej blokady (‘default deny’);
• Zaprzestać nieprzemyślanego używania optymalizatorów BGP.

Źródło: opennet.ru