Jednym z przykładów generowania fałszywych wiadomości jest tak zwany atak routingu źródłowego. W Internecie same protokoły TCP/IP są bardzo ufne. Bardziej troszczą się o zapewnienie niezawodności połączenia niż o jego autentyczność. Stworzyło to możliwość szczególnej formy ataku routingu źródłowego, który pozwala stronie trzeciej udawać kogoś innego, nawet bez możliwości obserwowania ruchu w sieci. Zastanów się, co się dzieje po zainicjowaniu sesji TCP/IP:
† A chce otworzyć sesję z B. Wysyła wiadomość „od A do B: synchronizacja, ISN(A)” Ta wiadomość jest adresowana do B i mówi mu, że A wybrał 32-bitowy numer ISN(A), jako „początkowy numer sekwencyjny” lub sesja.
† W zamian B wysyła „od B do A: synchronizacja, ISN(B), potwierdź ISN(A)”, który potwierdza numer inicjujący A i wydaje własny, ISN(B).
† A następnie odeśle „z A do B, potwierdź ISN(B)”.
Oznacza to teraz, że A i B dzielą parę numerów sekwencyjnych, których mogą użyć do zidentyfikowania połączenia między nimi. Jeśli te liczby są generowane przez losowy proces, osobie trzeciej trudno byłoby odgadnąć, jakie one są. Ale często tak nie jest. Na ogół są one generowane przez inkrementację prostego licznika, czasami o ustaloną kwotę po ustalonym okresie. Dlatego nie zawsze trudno jest poprawnie odgadnąć wartość. To, co może się wydarzyć dalej, pokazano na rysunku
† C (zły facet) najpierw otwiera połączenie z B, wysyłając „od C do B: synchronizacja, ISN(C)”.
† B odpowiada „od B do C: synchronizacja, ISN(B)”.
† C teraz udaje A, wysyłając „od A do B: synchronizacja, ISN(C)”.
Oznacza to, że używa adresu IP A, a także używa tej samej wartości synchronizacji, co wcześniej. Nie ma powodu, dla którego to drugie nie mogłoby mieć miejsca w legalnej komunikacji. Proces przebiega w następujący sposób:
† Odpowiedź B (którą C niekoniecznie widzi, ponieważ jest kierowana do A) to „od B do A: synchronizacja, ISN(B)”, potwierdzenie ISN(C).
Chociaż C niekoniecznie to widzi (ponieważ trasa z B do A może nie przechodzić przez router C), może odgadnąć wartość ISN(B’). Załóżmy, że zgaduje poprawnie:
† C wysyła „od A do B: potwierdź ISN(B)”.
Oznacza to, że B myśli teraz, że komunikuje się z A, a nie z C. Jeśli B jest zadowolony z przyjęcia adresu IP jako sposobu uwierzytelnienia wiadomości, to właśnie przyznał C dostęp do wszystkich uprawnień A. Z punktu widzenia C problem pojawia się, gdy A jest aktywnie on-line i wykrywa wiadomości od B. Wtedy automatycznie wygeneruje wiadomości, które zerwą połączenie. Istnieje jednak wiele strategii, których C może użyć, aby obejść ten problem, w tym blokowanie A ruchem w celu zignorowania wiadomości od B. Należy zauważyć, że C wymaga podszycia się pod A tylko przez krótki czas, wystarczająco długi, aby dostać się do system, aby zasadzić jakiś błąd, który umożliwi łatwy dostęp w przyszłości.