Traceroute, ICMP, UDP and TCP

I believe you are referring to these utilities:

http://www.vdberg.org/~richard/tcpping.html

http://michael.toren.net/code/tcptraceroute/

Since tcpping requires tcptraceroute, I'll start with tcptraceroute.

The author of tcptraceroute states that unlike a traditional traceroute, "By sending out TCP SYN packets instead of UDP or ICMP ECHO packets, tcptraceroute is able to bypass the most common firewall filters."

Further: It is worth noting that tcptraceroute never completely establishes a TCP connection with the destination host.

So, tcptraceroute does not measure the time it takes to complete the three-way handshake because that never happens. It measures the time from the initial SYN to the SYN/ACK. This is sometimes referred to as a half-open connection scan.

From the nmap manpage:

          This technique is often referred to as half-open scanning,
          because you don’t open a full TCP connection. You send a SYN
          packet, as if you are going to open a real connection and then
          wait for a response. A SYN/ACK indicates the port is listening
          (open), while a RST (reset) is indicative of a non-listener. If
          no response is received after several retransmissions, the port
          is marked as filtered. The port is also marked filtered if an
          ICMP unreachable error (type 3, code 1,2, 3, 9, 10, or 13) is
          received.

As to your packet size question, the above description also has the answer. Since tcptraceroute sends a standard SYN packet, it should be a small packet, perhaps 64 bytes.

ICMP is not UDP, and it's actually not even IP. It's another OSI layer 3 protocol (network layer) alongside IP. That said, it has an IP compatible header at the beginning of a packet.

There is no guarantee that an ICMP packet will be delivered. It has the same delivery guarantees of any other packet on the internet: none. There are no attempts to ensure that it gets delivered, no retry mechanism, but there is a checksum in both the IP header and the ICMP header. A higher level protocol should retry sending the packet that generated the error, which will cause another Time Exceeded packet to be generated, and eventually one of these will be received by the sender.

http://www.networksorcery.com/enp/protocol/icmp.htm has an example ICMP header (encapsulated inside what is identical to an IP header) and information about the different types of ICMP messages.

Given that people are downvoting this post and misunderstanding, I'll clarify:

IP is the lingua franca of the internet. Packets are routed by their IP headers. Protocols are encapsulated within IP (TCP, UDP, SCTP, etc) for most application level communication.

How do you communicate when something goes wrong with IP layer communication? ICMP is used for this. Can you communicate IP layer errors in IP? It's a chicken and egg problem, and as indicated by RFCs, gets muddy. ICMP messages have an IP header, and an IP protocol is reserved for them, but ICMP is an IP layer protocol, not it is not encapsulated inside an IP packet. Therefore I consider it to be a protocol used alongside IP.

We can quibble all day long as to "whether ICMP is IP", but the most I'd concede is that yeah, it's IP, "sort of".