Re: ICMP time exceed in-transit packets

[paul () MOQUIJO COM (Paul Cardon)]

Dave Dittrich wrote:

> OK. So you have a bunch of packets, which are hard to trace, look like
> they are coming from all over the Internet, get successfully delivered
> to the target you intend, and has embedded in it at most 64 bytes of the
> original, purposely messed up packet.

First problem is that the intended target is a network address of the form
x.x.x.0.  I have been seeing this hitting a class B that where the third octet is
being selected randomly and covered nearly the full range of Class C subnets.  Many
of these are not even in use (nice, efficient use of address space, I know).  Most
of the devices returning the ICMP time exceeded do appear to be routers.

Second problem is that the contents are 64 bits, not bytes.  If Chris had said 8
bytes, it would have been clearer to most people upon first read.

These ICMP time exceeded messages consist of:

1 byte type: 11
1 byte code: 0 (for TTL equals 0 during transit)
2 byte checksum
4 byte unused: must be 0
original IP header (including options)
8 bytes of original IP datagram

In my case, the original IP datagram is an ICMP echo request of which I see only
the required fields (type, code, checksum, identifier, sequence number).  The
identifier and sequence number are both set to 0.  In  other words, if there is
optional data in the original echo request, we don't see it.

Looking at the original IP header, the header length is 20 bytes and the total
length is 92 bytes.  Subtracting for the ICMP message header, this means that there
is potentially 92 - 20 - 8 = 64 bytes in the optional data portion of the original
ICMP echo request.  What it is we can't know without seeing the original packet.

-paul