Kostnienie protokołu

Kostnienie protokołu to utrata elastyczności, rozszerzalności i możliwości rozwoju protokołów sieciowych . Dzieje się tak głównie z powodu modułów środkowych , które są wrażliwe na obraz sieciowy protokołu i które mogą zakłócać lub zakłócać komunikaty, które są ważne, ale których skrzynka pośrednia nie rozpoznaje poprawnie. Jest to naruszenie zasady end-to-end . Przyczyny wtórne obejmują brak elastyczności w implementacjach protokołów na punktach końcowych.

Kostnienie jest głównym problemem w projektowaniu i wdrażaniu protokołów internetowych , ponieważ może uniemożliwiać wdrażanie nowych protokołów lub rozszerzeń w Internecie lub nakładać ograniczenia na projektowanie nowych protokołów; nowe protokoły mogą wymagać enkapsulacji w już wdrożonym protokole lub naśladowania obrazu przewodowego innego protokołu. Ze względu na kostnienie protokoły kontroli transmisji (TCP) i protokół datagramów użytkownika (UDP) są jedynymi praktycznymi opcjami protokołów transportowych w Internecie, a sam protokół TCP uległ znacznej skostnieniu, co utrudnia rozbudowę lub modyfikację protokołu.

Zalecane metody zapobiegania kostnieniu obejmują szyfrowanie metadanych protokołu i zapewnienie wykorzystania punktów rozszerzeń oraz możliwie najpełniejszego ukazania zmienności obrazu przewodu; zaradzenie istniejącemu kostnieniu wymaga koordynacji pomiędzy uczestnikami protokołu. QUIC to pierwszy protokół transportowy IETF zaprojektowany z myślą o właściwościach zapobiegających kostnieniu.

Historia

Internecie doszło do znacznego kostnienia , kiedy to w tym samym roku opublikowano także analizy problemu; Ammar (2018) sugeruje, że kostnienie było konsekwencją osiągnięcia przez Internet skali globalnej i stania się podstawową siecią komunikacyjną.

Wielościeżkowy protokół TCP był pierwszym rozszerzeniem podstawowego protokołu internetowego, które podczas jego projektowania głęboko stawiło czoła kostnieniu protokołu.

W 2014 r. IETF utworzył grupę roboczą ds. usług transportowych (taps). Jej zadaniem jest zapobieganie kostnieniu w warstwie protokołu transportowego .

QUIC to pierwszy protokół transportowy IETF , który celowo minimalizuje obraz przewodu, aby uniknąć kostnienia.

Powoduje

Główną przyczyną kostnienia protokołu są zakłócenia typu midbox , unieważniające zasadę „od końca do końca” . Middleboxy mogą całkowicie blokować nieznane protokoły lub nierozpoznane rozszerzenia znanych protokołów, zakłócać negocjacje rozszerzeń lub funkcji lub przeprowadzać bardziej inwazyjne modyfikacje metadanych protokołów. Nie wszystkie modyfikacje środkowej skrzynki koniecznie powodują kostnienie; z tych, które są potencjalnie szkodliwe, są one nieproporcjonalne w kierunku brzegu sieci. Middleboxy są wdrażane przez operatorów sieci jednostronnie w celu rozwiązania określonych problemów, w tym optymalizacji wydajności, wymagań bezpieczeństwa (np. zapór sieciowych), translacja adresów sieciowych lub zwiększenie kontroli sieci. Te wdrożenia typu Middlebox zapewniają lokalną, krótkoterminową użyteczność, ale pogarszają globalną, długoterminową ewolucję Internetu, co jest przejawem tragedii tego, co wspólne .

Zmiany w protokole muszą być tolerowane przez wszystkich pośredników na ścieżce; jeżeli pożądane jest szerokie wdrożenie zmiany w Internecie, wówczas obejmuje to dużą część pośredników w Internecie. Skrzynka pośrednia musi tolerować powszechnie używane protokoły w stanie, w jakim były używane w momencie jego wdrożenia, ale może nie tolerować nowych protokołów lub zmian w istniejących, skutecznie tworząc błędne koło w postaci nowatorskich obrazów przewodów nie można uzyskać wystarczająco szerokiego wdrożenia, aby skrzynki pośrednie tolerowały nowy obraz sieci w całym Internecie. Nawet wszyscy uczestnicy tolerujący protokół nie gwarantują jego stosowania: w przypadku braku mechanizmu negocjacji lub wykrywania punkty końcowe mogą domyślnie korzystać z protokołu uznawanego za bardziej niezawodny.

Oprócz pól środkowych kostnienie może być również spowodowane niewystarczającą elastycznością w ramach implementacji punktu końcowego. Jądra systemu operacyjnego wolno się zmieniają i wdrażają, a protokoły zaimplementowane sprzętowo mogą również nieprawidłowo naprawiać szczegóły protokołu. Powszechnie używany interfejs API , który przyjmuje założenia dotyczące działania podstawowych protokołów, może utrudniać wdrażanie protokołów, które nie podzielają tych założeń.

Zapobieganie i naprawa

Rada ds. Architektury Internetu zaleciła w 2019 r., aby ukryte sygnały przekazywane obserwatorom zastępowano sygnałami celowo przeznaczonymi do użytku tych obserwatorów, a sygnały nieprzeznaczone do ich spożycia nie powinny być dla nich dostępne (np. poprzez szyfrowanie); a także, że metadane protokołu powinny być chronione pod kątem integralności tak, że nie można go modyfikować za pomocą środkowych pól. Jednak nawet w pełni zaszyfrowane metadane mogą nie całkowicie zapobiec kostnieniu w sieci, ponieważ obraz protokołu w sieci może nadal pokazywać wzorce, na których można polegać. Operatorzy sieci wykorzystują metadane do różnych łagodnych celów związanych z zarządzaniem, a badania Internetu opierają się również na danych zebranych z metadanych protokołów; Projektant protokołu musi zrównoważyć odporność na kostnienie z obserwowalnością dla potrzeb operacyjnych lub badawczych.

Aby nie doszło do skostnienia, konieczne jest aktywne korzystanie z punktów przedłużeń. Zmniejszenie liczby punktów rozszerzenia, dokumentowanie niezmienników, na których mogą polegać uczestnicy protokołu, w przeciwieństwie do przypadkowych szczegółów, na których nie należy polegać, oraz szybkie wykrywanie problemów we wdrożonych systemach może pomóc w zapewnieniu aktywnego wykorzystania. Jednak nawet aktywne stosowanie może dotyczyć jedynie wąskiej części protokołu, a kostnienie może nadal występować w częściach, które w praktyce pozostają niezmienione pomimo zmienności teoretycznej. „Smarowanie” punktu rozszerzenia, w przypadku którego niektóre implementacje wskazują obsługę nieistniejących rozszerzeń, może zapewnić tolerowanie faktycznie istniejących, ale nierozpoznanych rozszerzeń (por. inżynieria chaosu ). Nagłówki HTTP są przykładem punktu rozszerzenia, któremu udało się uniknąć znacznego kostnienia, ponieważ uczestnicy zazwyczaj ignorują nierozpoznane nagłówki.

Można zaprojektować nowy protokół tak, aby naśladował obraz przewodowy istniejącego skostniałego protokołu; alternatywnie nowy protokół może zostać zamknięty w istniejącym, tolerowanym protokole. Wadą enkapsulacji jest to, że zazwyczaj wiąże się to z narzutem i nadmiarowością (np. zewnętrzne sumy kontrolne stają się zbędne w wyniku wewnętrznych kontroli integralności).

Oprócz pól środkowych można również stawić czoła innym źródłom kostnienia. Implementacja protokołów w przestrzeni użytkownika może prowadzić do szybszej ewolucji. Jeśli nowy protokół jest hermetyzowany w UDP, możliwa jest implementacja w przestrzeni użytkownika. Tam, gdzie obsługa protokołów nie jest pewna, uczestnicy mogą jednocześnie wypróbować alternatywne protokoły, kosztem zwiększenia ilości przesyłanych danych.

Przy wystarczającym wysiłku i koordynacji kostnienie można bezpośrednio odwrócić. Dzień flagi , podczas którego uczestnicy protokołu wspólnie dokonują zmian, może przerwać błędne koło i rozpocząć aktywne wykorzystanie. Podejście to zastosowano do wdrożenia systemu EDNS , który wcześniej nie był tolerowany przez serwery.

Przykłady

Protokół kontroli transmisji uległ skostnieniu. Jeden z pomiarów wykazał, że jedna trzecia ścieżek w Internecie napotyka co najmniej jednego pośrednika, który modyfikuje metadane protokołu TCP, a 6,5% ścieżek napotyka szkodliwe skutki kostnienia ze strony pośredników. Wpłynęło to na rozszerzenia protokołu TCP: projekt MPTCP był ograniczony przez zachowanie środkowej skrzynki, a wdrożenie protokołu TCP Fast Open również zostało utrudnione.

Protokół transmisji Stream Control był rzadko stosowany w Internecie ze względu na nietolerancję ze strony urządzeń środkowych, a także z powodu bardzo rozpowszechnionego interfejsu API gniazd BSD, który nie pasował do jego możliwości. W praktyce jedynymi użytecznymi protokołami transportu internetowego są TCP i UDP .

Transport Layer Security (TLS) doświadczyło kostnienia. TLS był pierwotnym kontekstem wprowadzenia punktów przedłużenia smarowania. protokół TLS 1.3 okazał się niemożliwy do wdrożenia w Internecie: moduły pośrednie skostniały parametr wersji protokołu. Zostało to odkryte na późnym etapie procesu projektowania protokołu, podczas eksperymentalnych wdrożeń w przeglądarkach internetowych . W rezultacie wersja 1.3 naśladuje obraz wersji 1.2.

QUIC został specjalnie zaprojektowany tak, aby można go było wdrożyć, ewoluować i mieć właściwości zapobiegające kostnieniu; jest to pierwszy IETF , który celowo minimalizuje obraz drutu dla tych celów. Jest natłuszczony, ma wyraźnie określone niezmienniki protokołu, jest hermetyzowany w UDP, a jego metadane protokołu są szyfrowane. Mimo to aplikacje korzystające z QUIC muszą być przygotowane na powrót do innych protokołów, ponieważ UDP jest blokowany przez niektóre urządzenia pośrednie.

Zobacz też

Bibliografia

Dalsza lektura

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Protocol_ossification&oldid=1136361221 ”