> [ Of course, I might be wrong, but Google seems to agree with my
> assessment. A related use of this idea is 'firewalk' by Schiffman and
> Goldsmith, a tool to probe firewall ACLs; another utility called
> 'tcptraceroute' by Michael C. Toren implements TCP SYN probes, but since
> the tool does not ride an existing connection, it is less likely to
> succeed (sometimes a handshake must be completed with the NAT device
> before any traffic is forwarded). ]
Erik Kamerling pointed off-the-list that everybody's favourite Dan
Kaminsky (www.doxpara.com) did some research on that subject, too; his
'paratrace' followed a similar principle, but relied on the party
correcting out-of-sync retransmissions. I found this approach to give poor
results in today's networks with overzealous commercial packet filters,
and hence, my tool implements an invasive approach where the current
session is trashed with in-sync data to solicit a high response rate.
> [ Of course, I might be wrong, but Google seems to agree with my
> assessment. A related use of this idea is 'firewalk' by Schiffman and
> Goldsmith, a tool to probe firewall ACLs; another utility called
> 'tcptraceroute' by Michael C. Toren implements TCP SYN probes, but since
> the tool does not ride an existing connection, it is less likely to
> succeed (sometimes a handshake must be completed with the NAT device
> before any traffic is forwarded). ]
Erik Kamerling pointed off-the-list that everybody's favourite Dan
Kaminsky (www.doxpara.com) did some research on that subject, too; his
'paratrace' followed a similar principle, but relied on the party
correcting out-of-sync retransmissions. I found this approach to give poor
results in today's networks with overzealous commercial packet filters,
and hence, my tool implements an invasive approach where the current
session is trashed with in-sync data to solicit a high response rate.
Still, a credit is due!
Cheers,
/mz
[ reply ]