Средства и методы разработки

Я правильно понимаю, что фундаментальный косяк для TCP в том, что conntrack тупо поиском ищет определённую строку во всех пакетах посылаемых на определённый порт и делает из этого глубикие выводы? 

Но ведь пишут: The nf_defrag_ipv4 module will defragment IPv4 packets before they reach Netfilter's connection tracking (nf_conntrack_ipv4 module). This is necessary for the in-kernel connection tracking and NAT helper modules (which are a form of "mini-ALGs") that only work reliably on entire packets, not necessarily on fragments.

Мне непонятно, тогда зачем все эти пляски с фрагментацией? С одной стороны у жертвы оно же обратно и дефрагментируется для начала, с другой стороны TCP -- вообще-то это поток и SIP-протокол запросто может оказаться разорванным между двумя пакетами, поэтому там фрагментация побоку, анализируется не один пакет, а сам анализатор имеет состояние, где помнит что он видел в предыдущем пакете...

Для UDP более-менее понятен смысл -- там данные всегда дискретны и разделены границами пакетов и анализировать имеет смысл только в пределах одного пакета (и алгоритм увидев другие заголовки пакета может отбросить весь пакет -- поэтому нужна фрагментация, чтоб во втором фрагменте было что нужно).

Но для TCP, цитирую источник:

• victim IP stack breaks the POST into multiple TCP packets, leaving the "SIP packet" (as part of POST data) in its own TCP packet without any accompanying HTTP headers

По-моему это какой-то бред, где-то здесь обман или что-то я не допонимаю... Почему в TCP речь идёт о пакетах? В SIP-протоколе весь траффик может пойти по одной букве в пакете -- и это валидный кейс, должно работать.