Dlaczego manipulowanie TTL IP jest niebezpieczne?

Czytałem stronę podręcznika iptables (lekkie czytanie na dobranoc) i natknąłem się na cel „TTL”, ale ostrzega:

Ustawienie lub zwiększenie pola TTL może być bardzo niebezpieczne

i

Nigdy nie ustawiaj ani nie zwiększaj wartości pakietów opuszczających sieć lokalną!

Widzę, jak być może zmniejszanie lub obniżanie TTL może powodować upuszczanie pakietów przed dotarciem do miejsca docelowego, ale jaki efekt może mieć zwiększanie?

TTL ulega zmniejszeniu, gdy przechodzi przez router. To gwarantuje, że jeśli pakiet będzie krążył w kółko, w końcu umrze.

Pole TTL pakietu IP v4 to pole 8-bitowe (255 miejsc po przecinku). Tak więc ustawienie go wysoko na początku nie jest wielkim problemem, ponieważ nie może być tak duże w dobrze uformowanym pakiecie (chociaż niektóre rzeczy mogą akceptować zniekształcone pakiety IP).

Jeśli jednak coś to zwiększa, a krok inkrementacji jest częścią pętli , pakiet może nadal krążyć w kółko, nigdy nie osiągając zera. Z biegiem czasu (może to być bardzo krótki lub stopniowy wyciek) pakiety mogą gromadzić się w systemie zawierającym tę pętlę, powodując jej przeciążenie.

Zasadniczo TTL na pakietach utrzymuje rozsądny routing. Jeśli pakiet miałby mieć bardzo duży czas TTL i z jakiegoś powodu zostałby złapany w trasę kołową, może to spowodować mnóstwo ruchu (zwane „burzą pakietów”) i zakłócać normalne operacje. Zbyt niski TTL spowoduje utratę łączności, ponieważ stracisz pakiet, zanim dotrze on do miejsca docelowego.

Wydaje się, że brakuje jednej odpowiedzi, która byłaby czysto akademicka (z uwagi na to, ile przeskoków wydaje się być wymaganych w Internecie): jeśli pakiet normalnie nie osiągnąłby miejsca docelowego z powodu upływu czasu TTL, to zwiększając go pozwoli pakietowi dotrzeć do miejsca docelowego, ale nie wpłynie na zwrot pakietów i wygasną przed dotarciem do sieci.

AKTUALIZACJA: Według tej strony w Wikipedii :

Teoretycznie w IPv4 czas do życia jest mierzony w sekundach, chociaż każdy host, który przechodzi przez datagram, musi skrócić TTL o co najmniej jedną jednostkę. W praktyce pole TTL jest zmniejszane o jeden na każdym skoku. Aby odzwierciedlić tę praktykę, zmieniono nazwę pola na limit przeskoków w IPv6.

AKTUALIZACJA 2: Gdy ktoś zaktualizował mój post i odniósł się do Wikipedii, pomyślałem, że najlepiej będzie odwoływać się do samego RFC - http://www.ietf.org/rfc/rfc791.txt - Po prostu znajdź tam TTL i robi to całkiem dobra robota, tłumacząc to:

To pole wskazuje maksymalny czas, w którym datagram może pozostać w systemie internetowym ... każdy moduł przetwarzający datagram musi zmniejszyć TTL o co najmniej jeden, nawet jeśli przetworzy datagram w mniej niż sekundę

Znam tylko jeden program, który mógłby użyć wyższej wartości TTL, i to jest traceroute. Jak sama nazwa wskazuje, śledzi trasę do hosta docelowego, modyfikując wartość TTL. Standardowy maksymalny skok wynosi 20, ale możesz go zwiększyć.

Każdy router, który obsługuje pakiet, zmniejsza wartość TTL, dopóki pakiet nie osiągnie miejsca docelowego lub TTL osiągnie zero, i umrze.

Jak powiedzieli inni, zwiększenie TTL może spowodować, że pakiety nigdy nie umrą, jeśli wystąpi cykl ujemny. Ogólnie rzecz biorąc, jeśli wartość TTL nie jest wystarczająco duża, logika wypróbowania większego TTL powinna być prawdopodobnie obsługiwana przez klientów końcowych.

Jeśli masz pewność, że router nie jest w cyklu (topologia drzewiasta), teoretycznie możesz bezpiecznie zwiększyć wartość TTL. To powiedziawszy, dopuszczenie większej liczby przeskoków niż jest to standardowe, może zwiększyć prawdopodobieństwo zatoru w sieci zewnętrznej. Jeśli masz długi łańcuch routerów między siecią wewnętrzną i zewnętrzną, o ile nie ma cyklu, może pomóc większa wartość TTL. To powiedziawszy, może być dość łatwe dla kogoś, kto doda przewagę do sieci i utworzy cykl, więc rozpoczęcie od większej wartości TTL, w której pakiet powstał w pierwszej kolejności, jest znacznie bezpieczniejsze.