…ale narzędzi należy używać odpowiedzialnie.
po pierwsze, niech wolno mi będzie złożyć pewne oświadczenie - dla tych, którzy mnie nie znają, żeby uniknąć nieporozumień, które może zrodzić pobieżna lektura tego postu:
jestem wielkim fanem dyskusji o zaletach technologii. wierzę głęboko, że możliwość tworzenia sieci, rozwiązań które naprawdę pozwalają ludziom zbliżyć się do siebie i komunikować na odległość to coś co robię i mogę robić przez resztę życia z całym zaangażowaniem
no to jedziemy!
mieliśmy okazję ostatnio na krótką wymianę zdań (w zakresie, jakim można takie wymiany prowadzić na pełnym śmieci i narcyzów portalu społecznościowym jakim stał się ostatnio LinkedIn) o nowym “rozszerzeniu do badania zawartości pakietów” dla BGP FlowSpec z Pawłem Odintsowem. dzień później, jakby na zawołanie i żeby potwierdzić mój punkt widzenia, CenturyLink/Level3 został trafiony poważną awarią. została spowodowana, a jakże, źle zbudowanym rozgłoszeniem BGP FlowSpec. najwyraźniej, w trakcie normalnej procedury blokowania ruchu złośliwego skierowanego w jednego ze swoich klientów, operatorzy sieci rozgłosili definicję filtra, która zamiast adresów źródłowych lub docelowych zawierała specyfikację “dowolny”. jak zwykle w takich sytuacjach, natychmiast wkroczyło prawo Murphy’ego, które mowi, że jeśli zdarza się awaria - uderza tam gdzie dokona największych szkód. w tym przypadku były to sesje BGP. część z nich pozostała podniesiona, ale routery przestały wymieniać prefiksy, lub restartowały sesje i zamierały w takim stanie. klienci, którzy oparli swoją strategię redundancji o to, że w razie awarii padną łącza lub sesje BGP - nie przełączyli się na łącza zapasowe. problem trwał ponad 5 godzin i spowodował ogromne problemy z łącznością nie tylko w Stanach Zjednoczonych ale też w części świata. oczywiście, nie była to pierwsza ani nie będzie to ostatnia awaria wywołana przez implementacje lub konfigurację FlowSpec. wystarczy wspomnieć, że zaledwie tydzień wcześniej podobny problem trafił innego dużego operatora w Stanach Zjednoczonych - Verizon Wireless.
no to w takim razie co chciałeś przekazać?
wracając do naszej dyskusji - chciałem zwrócić uwagę na to, że układanie skomplikowanych rozwiązań na skomplikowanych rozwiązaniach nigdy nie kończy się dobrze i się po prostu nie skaluje. w tym przypadku, dobudowywanie skomplikowanego rozszerzenia (BGP FlowSpec payload matching) do i tak już skomplikowanego w wykorzystaniu protokołu (BGP FlowSpec) nie jest skalowalne. natomiast prawdziwie dobre inżyniersko rozwiązania składają się z przemyślanych rozwiązań. to coś więcej niż radosne skakanie od technologii do technologii i podkreślanie, że “technologia dzisiaj daje niesamowite możliwości”. oczywiście, że daje, ale ludzie powinni używać też swojego mózgu.
no to co to jest właściwie ten BGP FlowSpec payload matching?
szczerze mówiąc, byłem - i do pewnego stopnia nadal jestem - wielkim fanem FlowSpec. pomysł został pierwotnie naszkicowany przez Pedro Marques’a (Cisco Systems), Nischal’a Sheth (Juniper Networks), Roberta Raszuka (Cisco Systems), Barry Greene’a (Juniper Networks), Jareda Maucha (NTT America) oraz Danny’ego McPhersona (Arbor Networks) jeszcze w 2009 i niedługo potem doczekał się implementacji w sprzęcie sieciowym. poprzednio dostępne mechanizmy walki z atakami DDoS w skali operatorskiej nie były zbyt dokładne. tak naprawdę, składały się z trzech głównych narzędzi - możliwości odrzucenia ruchu na podstawie adresu źródłowego lub docelowego (BGP blackholing), przekierowania go gdzieś (BGP sinkholing) i/lub nałożenia na niego określonych polityk QoS przez wykorzystanie mechanizmu BGP QPPB.
problem polega jednak na tym, że już na tym etapie tworzenia, FlowSpec był skomplikowany. nie tyle do przeczytania czy zrozumienia przez człowieka, ale do poprawnego zwalidowania w pakiecie UPDATE protokołu BGP i do prawidłowej implementacji w routerze sprzętowym. poszczególne operacje wymienione powyżej (odrzucenie ruchu, przekazanie go gdzieś lub nałożenie polityki QoS) są możliwe w sprzęcie klasy operatorskiej wiodących producentów od dekad i oparte o dobrze sprawdzone w produkcji mechanizmy. ale routery są stworzone i optymalizowane do przekazywania pakietów (co oznacza czasem, paradoksalnie, również ich odrzucanie). by prawidłowo obsłużyć operacje opisane w BGP FlowSpec, routery muszą zaprząc do pracy swoje mechanizmy klasyfikacji, które należą zwykle do trzech różnych podsystemów:
- podsystem routingu, umożliwiający wybieranie z ruchu adresu źródłowego i docelowego; RFC 5575 definiuje te operacje jako FlowSpec Typ 1 (Prefiks docelowy) oraz Typ 2 (Prefiks źródłowy)
- podsystem filtrowania, dostarczający selektorów podobnych do ACL; RFC 5575 definuje sprawdzanie portu (Typ 4, 5 i 6), ICMP (Typ 7 i 8), flag TCP (Typ 9), Fragmentów IP (Typ 12) oraz numer protokołu IP (Typ 3)
- podsystem QoS; RFC 5575 definiuje sprawdzanie DSCP (Typ 11) oraz długość pakietu (Typ 10)
nie przejmuj się, jeśli w twojej ulubionej architekturze elementy te są rozłożone jakoś inaczej - tak naprawdę nie jest to w tym momence ważne. ważne jest to, że reguły którymi posługuje się FlowSpec mogą stać się bardzo szybko całkiem skomplikowane. na przykład:
- pakiety TCP z ustawionymi tylko flagami SYN i ACK, podążający do portu 22, 23, 143 oraz z zakresu 6499-6899, z adresami docelowymi zawierającymi konkretny prefiks Twojego Klienta; każde kryterium z osobna może być zaadresowane przez mechanizmy filtrowania (ACL), ale gdy zestawisz je razem stają się problematyczne - do momentu gdy zobaczysz kolejny przykład:
- pakietu z rozmiarami pomiędzy 100 a 280 bajtów, z adresami źródłowymi ustawionymi na “dowolny”, adres docelowy zawierający prefiksy naszej sieci, port docelowy 53/udp oraz DSCP ustawione na AF31; do dopasowania takiego kryterium trzeba użyć silnika filtrującego, QoS oraz mechanizmu, który odpowiada za dopasowywanie długości pakietu - na każdym pakiecie
jeśli oczywiście wdrażałeś je z uwagą, skomplikowane filtry nie są zbyt dużym obciążeniem. z drugiej strony, od razu widać, że nie będą tak skalowalne jak istniejące mechanizmy typu BGP blackholing czy BGP sinkholing. z wykorzystaniem tych ostatnich można utrzymywać setki tysięcy prefiksów bez żadnego problemu (operatorzy których znam, potrafią utrzymywać średnio między 50 a 100 tysięcy prefiksów /32 i /128 w swoich tablicach blackholingu - tak dzisiaj wygląda zalewany mniejszymi i większymi atakami internet). a z wykorzystaniem FlowSpec, wartości typu 3-8k czy 5-8k najprostszych filtrów już są górnym pułapem. z dowolnymi filtrami tak złożonymi jak ten powyżej, należy spodziewać się nie tylko szybkiego spadku wolnego miejsca - ale i nieprzewidzianego zachowania. czy technologia pójdzie do przodu i przyszłe platformy mogą mieć większą pojemność? oczywiście. ale ponownie, poprawna inżynieria nie polega na stosowaniu metod siłowych.
złożoność konfiguracyjna BGP FlowSpec wcale nie jest jakaś duża. to co jest problematyczne to walidacja po stronie routera odbierającego rozgłoszenie i sprawdzenie, czy reguła ma faktycznie sens zanim spróbujemy zaprogramować ją w sprzęcie. pierwsi użytkownicy trafiali ciągle na błędy i podatności. niestety nadal się one zdarzają i będą się zdarzały, bo to nowy protokół, wiążący ze sobą wiele osobnych podsystemów i jest skomplikowany. a to tylko 12 “prostych” klasyfikatorów z pierwotnej specyfikacji BGP FlowSpec.
do tego wszystkiego dochodzi kolejna wersja rzeczonego draftu BGP FlowSpec, o którym wspomniał Pavel. autorzy poczynili w nim parę ciekawych obserwacji. o ile ich implementacja pozwoliłaby do pewnego stopnia uprościć pierwotne RFC FlowSpec dzięki zastosowaniu bardziej elastycznych operatorów, fundamentalnie nadal krytycznym elementem całej architektury jest odbierający rozgłoszenia router kliencki. a na szczycie wymagań pojawia się dodatkowo w tym drafcie silnik wyrażeń regularnych, który wg. autorów mógłby służyć do przeglądania zawartości pakietów. to doskonały pomysł, jeśli masz do dyspozycji swój komputer klasy x86 lub laptop z ARMem, ale niezbyt szczęśliwy gdy myślisz o sprzętowym routerze, który z natury rzeczy zoptymalizowany jest do szybkiego przeglądania nagłówków pakietów a nie ich zawartości.
czy to źle?
BGP FlowSpec sam jest skomplikowanym narzędziem, z wieloma ograniczeniami w skali. czy wprowadzanie ograniczeń i złożoności do sieci jest złe? tak, jest.
jeśli szukasz dowodów - rzuć okiem na wszystkie katastrofy telekomunikacyjne w ciągu trzech dekad. doszło do nich, ponieważ ktoś, kiedyś zdecydował się na dodanie dodatkowej funkcji, skrótu, specjalnej opcji czy konfiguracji. oczywiście o ile takie rzeczy testuje się przed wprowadzeniem na produkcję, raczej nigdy jako cały kompletny system. a skomplikowane systemy ulegają awarii w skomplikowany sposób.
jeśli miałeś okazję przeczytać książkę Russ’a White’a Navigating Network Complexity lub czytujesz blog Ivana Pepelnjaka zauważysz ten sam powracający temat - przez ludzi, którzy dosłownie całe swoje życie budowali sieci i rozwiązywali problemy z nimi związane - złożoność jest wrogiem dobrze zaprojektowanej, skalowalnej i długowiecznej sieci.
RFC 1925, zatytuowany “Dwanaście Sieciowych Prawd” i spisany jeszcze w 1996, ma dwa interesujące punkty w kontekście tej dyskusji:
(3) Przy użyciu odpowiednio mocnego napędu, świnie również mogą latać. Nie jest to jednak najlepszy pomysł. […]
…oraz:
(12) Podczas projektowania protokołu, perfekcję osiąga się nie wtedy, gdy nie ma już co dodać, ale wtedy, gdy nie ma już co odjąć.
możesz oczywiście zastosować rozwiązanie siłowe i zignorować zdrowy rozsądek, ale efekty nie będą pozytywne. w którymś momencie budowania kolejnego skomplikowanego rozwiązania, będziesz musiał posiłkować się kolejną warstwą abstrakcji. podążanie jednak w zgodzie z koncepcją KISS (ang. “Keep It Simple, Stupid”, które to powiedzenie można przetłumaczyć jako “Trzymaj się możliwie prostych, głupioodpornych rozwiązań”) zdecydowanie sprawdza się jednak lepiej.
i to cała historia z FlowSpec - z uwagi na wysoki poziom skomplikowania i fakt, że istniejący sprzęt nie jest wystarczająco elastyczny żeby obsługiwać funkcje DPI z taką skalą, z jaką robi to dla “zwykłego” routingu.
ale to działa!
tak. ale zastanawiałeś się dlaczego “Internet” skaluje się tak dobrze mimo już swoich 40 lat? ponieważ założenia, które legły u jego podstaw są proste. zaprojektowano je z jednym nadrzędnym celem - że o ile przyszłość zawiera na pewno wiele nieznanych, należy być elastycznym na ich przyjęcie a jednocześnie bardzo konserwatywnie podchodzić do dostępych zasobów. nazywamy to dzisiaj “zasadą niezawodności”, znaną także jako prawo Johna Postela:
Implementacje TCP powinny podążać pryncypiami niezawodności: konserwatywne w tym, co robią, ale bardzo liberalne w tym co akceptują od innych.
tak więc o ile uwielbiam geekowe dyskusje o tym jak i kiedy można użyć różnych ciekawych technologii żeby rozwiązać problem, albo jak wprowadzić nowe funkcjonalności do istniejących sieci - robimy to żeby rozwiązania działały lepiej a nie były dziwnym zlepkiem osobliwości. to, że coś może zostać zrobione, nie oznacza, że powinno być zrobione.
żeby podkreślić jeszcze raz, to co myślę o temacie postu - BGP FlowSpec jest interesującym narzędziem, dającym konkretne, wymierne korzyści. trafił nawet do mojego projektu BGP Blackholing PL tak aby ludzie mający styk z BGP na brzegu swoich sieci byli w stanie w bezpiecznych warunkach przetestować go sobie operacyjnie. obok innych narzędzi takich jak BGP QPPB, BGP blackholing, BGP sinkholing, uRPF czy ACLki. co ciekawe jednak, kilka lat temu podczas rozmowy na corocznym spotkaniu operatorów, które organizujemy jako Cisco w Amsterdamie (Cisco SP Security Forum), usłyszałem interesujące komentarze od uczestników (i to po tym, jak z wielkim entuzjazmem poopowiadałem towarzystwu przez godzinę ze szczegółami o praktycznych aspektach wdrażania BGP Blackholing/Sinkholing/FlowSpec). większość z nich powiedziała wprost, że już wycofali się, albo wycofują z używania operacyjnie FlowSpec, ponieważ jego implementacje okazały się wrażliwe na błędy, powodowały problemy i generalnie destabilizowały im sieci. zamiast tego, zrzucają odpowiedzialność na dedykowane serwery i VMki odpowiedzialne za obsługę bardziej udziwnionych rozwiązań.
dlaczego to rozwiązanie jest lepsze? ponieważ pozwala odseparować elementy opcjonalne, które mogą ulec awarii i nie spowodują przerwy w świadczeniu usługi, od elementów szkieletowych i dobrze już sprawdzonych. tak delikatne komponenty jak moduły FlowSpec dodane do i tak już delikatnych stosów sieciowych czy wręcz całego systemu operacyjnego routera tylko zwiększają stopień skomplikowania oraz oczywiście prawdopodobieństwo awarii.
oczywiście zaczynają pojawiać się dobre dokumenty, inicjatywy i udokumentowane najlepsze praktyki opisujące wdrożenia FlowSpec. z czasem, kod zostanie dopracowany, ale pryncypia o których tu wspomniałem - nie. nadal stopień skomplikowania będzie wyższy a w związku z tym całe rozwiązanie mniej skalowalne.
niektórzy operatorzy oczywiście wdrożyli lub wdrażają BGP FlowSpec w swojej sieci jako jedno z rozwiązań (tak jak na przykład rzeczony CenturyLink/Level3). wymaga to jednak większego wysiłku i oczywiście dodatkowego nadzoru żeby nie dopuścić do destabilizacji swojej własnej sieci. nasz własny system Cisco Service Provider zwalidował FlowSpec jako część ostatniego odświeżenia dokumentu opisującego peeringi - ale zwróćcie uwagę, jak bardzo dokładnie opisane są wzorce konfiguracji. no cóż - zobaczymy.
no dobrze, to skąd problem jeśli FlowSpec już tu jest?
BGP FlowSpec jest skomplikowanym narzędziem sam w sobie, z wieloma ograniczeniami co do skalowalności. słysząc, że to wspaniałe narzędzie które rozwiąże niemal wszystkie problemy całego świata, wewnętrznie zaczynam krzyczeć.
dlaczego? otóż idea badania zawartości pakietów na brzegu sieci operatorskiej za pomocą specyfikacji tychże pakietów wymienianej przez BGP brzmi jak kolejna świetna koncepcja wymyślona przez autorów oprogramowania. próba zamiany sprzętowego routera w wycudowane rozwiązanie DPI to jeden z takich pomysłów, który musiał powstać w głowie albo programisty (takiego, który do tej pory nie pracował z i nie ma zielonego pojęcia o sprzęcie), albo kogoś, kto miał ochotę upchnąć do BGP wszystko co się da już dekadę temu, ale mu się to nie udało, w wyniku czego ówcześnie jednowątkowy i gigantyczny demon nie mógł już nawet poradzić sobie poprawnie z rozdziną protokołów IPv4 unicast w stabilny i przewidywalny sposób. czy możemy być pewni, że tym razem poszli po rozum do głowy i ta propozycja jest lepiej przemyślana? nie chcę oczywiście czepiać się autorów draftu czy Pawła. czepiam się absolutnie świadomie i z pełną premedytacją podejścia “YOLO” (ang. “You Only Live Once”, czyli “Żyje się tylko raz”, albo bardziej szalona i nieodpowiedzialna wersja łacińskiego carpe diem).
jeśli naprawdę uważasz, że wdrożenie tego mechanizmu rozwiąże problem głodu na świecie i przychodzisz ze świata programistów, doskonale rozumiem dlaczego tak myślisz. nie masz po prostu doświadczenia z utrzymaniem produkcyjnych systemów sieciowych i nie pracowałeś z problemami, które wynikły z wdrożenia takich “wspaniałych pomysłów” w środek sieci.
sam fakt, że pisałeś aplikacje czy nawet budowałeś całe ekosystemy w frameworku-który-jest-najpopularniejszy-w-tym-tygodniu jest godny uznania i piszę to bez złośliwości - kudos. sam przez parę lat pracowałem zawodowo jako programista i wiem jak trudna ale jednocześnie satysfakcjonująca jest to praca. nie zamierzam nikogo obrażać, w szczególności programistów. głęboko jednak uważam (na podstawie również swojego, przyznaję niewielkiego, doświadczenia), że szafowanie wiedzą czysto programową to dopiero początek przygody w budowanie i integrację świata programowego ze sprzętowym. i sam fakt, że masz doświadczenie jako programista nie oznacza, że masz również doświadczenie lub choćby nawet blade pojęcie o sieciach czy architekturze sprzętowej routerów.
oczywiście nie twierdzę tego ot tak. miałem z takimi sytuacjami doświadczenia osobiste, wiele historii usłyszałem też od szacownych kolegów “z przemysłu”. widziałem programistów, którzy na siłę wynajdowali koło od nowa w ramach podejścia, które nazwać można najogólniej “restartuj aż zadziała”. mój bliski znajomy patrzył zupełnie nie wierząc w to co słyszy i widzi, jak cały dobrze opłacany zespół programistów pracujący ze środowiskami chmurowymi po sześciu miesiącach wytrwałej pracy wymyślił tagowanie pakietów (a’la 802.1Q) - choć w międzyczasie nie chcieli w ogóle słuchać jego porad. a co mieli osiągnąć? mieli oddzielić ruch aplikacji pochodzącej z tego samego serwera wirtualnego w całej ścieżce sieciowej, więc tak, odkryli na nowo tagowanie 802.1Q i nawet prawie dokładnie (i krótkowzrocznie) doszli do wniosku, że coś około 4000 będzie “wystarczająco”. zabawne? nie! a jeśli twierdzisz, że pracowałeś właśnie u jednego z wielkich dostawców chmury albo treści - tym bardziej będę na Ciebie uważał, bo te firmy mają tak skrzywione spojrzenie na świat, że przenika ono nawet najbardziej twardych realistów. pojawia się syndrom “tego sami nie wymyśliliśmy” (więc nie może być dobre), oraz naturalne przekonanie o wyższości samego siebie nad innymi. rozmawiając np. z eks-pracownikami Google’a obserwuje się to w zasdadzie w 99% przypadków - zanim zdążysz takiej osobie opisać swój problem, już postawiła setkę kontenerów za pomocą Kubernetesa i odpaliła BigTable w tle czekając aż skończysz (i zanim w ogóle dojdziesz do opisu problemu).
podsumowując - innowacja jest super, pomysły są super, ale gdy zaczynają być zapisywane, znajdą się tacy, którzy natychmiast postanowią je wdrożyć. czasami brakuje im doświadczenia i wiedzy by stwierdzić co z tego jest dobrym pomysłem, a co fatalną pomyłką. proponuje ich jednak nie zachęcać.
OK, czyli nie ma już nadziei?
przeciwnie. nadzieja jest zawsze :)
po pierwsze, wybieraj nardzędzia odpowiednie do pracy, którą chcesz wykonać a nie odwrotnie. to jedna z podstawowych zasad inżynierskich. jest takie stare powiedzenie - “jeśli masz w ręce młotek, każdy problem wygląda jak gwóźdź” i jest ono bardzo, bardzo prawdziwe. sam się na nim czasami łapię.
w tym konkretnie przypadku - patrząc na świat z perspektywy BGP, widzisz same atrakcyjne rzeczy, które można “dołożyć”. komunikacja tekstowa w communities? oczywiście. gra w szachy? czemu by nie. filtry dla ruchu i QoS? właściwie… nie. to błąd i kończy się tak jak już opisałem powyżej.
jeśli szukasz dla siebie rozwiązania anty-DDoS, jest parę firm oferujących dedykowane rozwiązania. jeśli szukasz systemów DPI, są też dostawcy takowych. jeśli chodzi Ci o klasyfikację aplikacji na brzegu - istnieją zwalidowane i sprawdzone technologie, które można wyskalować do zastosowań brzegowych. czy można je zastosować w Twojej infrastrukturze sieciowej? z dużą pewnością mogę powiedzieć, że tak. staraj się trzymać ich “miękkie” podbrzusze skupione na ich podstawowych funkcjach i nie próbuj przenosić na nie ciężkiej pracy wykonywanej przez sprzęt. jeśli chcesz to robić, to po co Ci w ogóle jakiekolwiek rozwiązania sprzętowe?
jeśli zadasz to pytanie dostawcy, a jego odpowiedź zacznie się w stylu “z uwagi na potencjał drzemiący w ML…”, lub “ponieważ samoświadome AI będzie mogło…” albo “gdyż blockchain mógłby…” uciekaj. uciekaj jak najszybciej możesz i już się nie oglądaj!
jeśli podobnie jak ja, uważasz że przeciążanie protokołu BGP nowymi śmieciami jest złe, powinieneś śledzić w internecie dokonania Roberta Raszuka oraz zasubskrybować listę IETF IDR WG. takie pomysły pojawiają się zwykle tam i to tam trzeba im dawać odpór w pierwszej kolejności.
a jeśli po prostu musisz, musisz pobawić się tymi wspaniałościami i wierzysz głęboko, że będzie “wspaniale”, zrób to. wraz z wrostem mocy przerobowych dzisiejszych procesorów sterujących routerami oraz ilości pamięci RAM (mamy dzisiaj w routerach de-facto serwery w architekturze x86) powinno być to prostsze i przyjemniejsze niż kiedyś. to jednak oznacza, że podchodzisz do projektowania swojej sieci siłowo, a to oznacza, że dzisiaj to może jeszcze zadziała. a za miesiąc? a za rok? trzy lata? i oczywiście pamiętaj o regule #3 z RFC 1925:
(3) Przy użyciu odpowiednio mocnego napędu, świnie również mogą latać. Nie jest to jednak najlepszy pomysł. […]
proszę, nie zmuszaj świni do latania. pomyśl o użytkownikach (swoich użytkownikach!) nad którymi będą one latać. czułbyś się komfortowo w ich butach stojąc pod taką?