Reaktionen auf das TCP-Problem

Die Schlag­zei­le, TCP hätte ein ernst­haf­tes Pro­to­koll­pro­blem macht er­war­tungs­ge­mäß die Runde im Netz. Ei­ni­ge Mel­dun­gen sind mehr oder min­der pa­nisch, man­che be­inhal­ten un­glaub­lich dumme Rat­schlä­ge (SYN-Coo­kies de­ka­ti­vie­ren - argh!)... die meis­ten sind zum Glück aus­rei­chend be­son­nen und wer­den erst ein­mal bis zur voll­stän­di­gen Ver­öf­fent­li­chung der De­tails ab­war­ten, bevor sie ein end­gül­ti­ges Ur­teil ab­ge­ben. Nun kom­men­tiert auch Fyo­dor, der Autor des Netz­werk­scan­ners nmap die An­kün­di­gung.

Die Idee, den für den Ver­bin­dungs­auf­bau nö­ti­gen Zu­stand auf der Seite des Cli­ents eben­falls in der Se­quenz­num­mer zu co­die­ren, ist nicht neu - sie wurde be­reits 2000 auf der Bug­traq-Mai­ling­lis­te dis­ku­tiert. Dies war das ein­zi­ge tech­ni­sche De­tail, das aus den In­ter­views der Uni­corn­scan-Au­to­ren zu er­ah­nen war - über alles wei­te­re schwei­gen sie sich aus. Als Schutz vor einem sol­chen An­griff schlägt auch Fyo­dor vor, die Ab­sen­der-IP-Adres­se zu blo­ckie­ren; da der An­grei­fer auf die Ant­wort des Ser­vers re­agie­ren muß, kann er die Ab­sen­de­r­adres­se nicht spoo­fen.
Im all­ge­mei­nen kri­ti­siert Fyo­dor den Me­di­en­rum­mel, wel­chen die bei­den Ent­wi­cker an­ge­sto­ßen haben: "Re­s­pon­si­ble dis­clo­sure" be­dingt zwar, die be­trof­fe­nen Her­stel­ler vorab zu in­for­mie­ren, bevor man ein Pro­blem an die brei­te Öf­fent­lich­keit trägt - FUD-In­ter­views, wel­che Ängs­te schü­ren, ohne die An­deu­tun­gen mit ech­ten Fak­ten zu hin­ter­le­gen, ge­hö­ren je­doch nicht dazu. Das ist jen­seits der Gren­ze zur PR-Ar­beit.

In jedem Fall hat die An­kün­di­gung wie­der etwas wach­ge­rüt­telt; das Pro­blem des Hand­shakes ist seit 2000 be­kannt und hat reich­lich wenig Be­ach­tung ge­fun­den. Mög­li­cher­wei­se stößt nun je­mand auf eine prak­ti­ka­ble Idee. Ei­ni­ge Leute hat der Rum­mel zu ei­ge­nen Ex­pe­ri­men­ten mo­ti­viert: Ro­bert Gra­ham hat bei­spiels­wei­se mit den TCP-Ack­now­led­ge­ments her­um­ge­spielt und her­aus­ge­fun­den, daß viele TCP-Stacks den nö­ti­gen Re­trans­mit bei einem feh­len­den TCP-Pa­ket erst sehr spät an­sto­ßen - auf diese Weise muß die Ge­gen­stel­le eine große Menge an Daten puf­fern.