[Please, note that my email address is no longer antirez@SECLAB.COM]
about the ip header id
From: Salvatore Sanfilippo (antirez@SECLAB.COM)
Date: Mon Dec 14 1998 - 11:03:16 GMT
Hi,
Several days ago, experimenting with the ip header id field,
I noticed that many unix, in order to avoid ambiguity
in datagram reassembly, increase the id by one for each packet sent.
This makes possible to approximate the number of outgoing packets from
a remote host by performing the following:
- send one packet that presuppose a replies from target host
- record reply's iphdr id in X
- send another packet on second after the first.
- record reply's iphdr in Y
- if Y >= X then sent packets = Y - X
- if Y < X then sent packets = (65535 - X) + Y /* id rewind */
Contrary to apparence and rtt variation it works fine.
The new hping 0.66 (see my last posting in this ml) implements this,
donwload it from http://www.kyuzz.org/antirez .
It's still an alpha but is more powerfull than last version.
This is the help screen:
#./hping
usage: hping host [options]
c - packet count
i - wait
n - numeric output
q - quiet
I - interface name
p - destination port default [ctrl+z inc, double ctrl+z dec]
s - base source port (default random)
t - ttl (default 64)
w - winsize (default 512)
h - show this help
v - show version
F - set FIN flag S - set SYN flag
R - set RST flag P - set PUSH flag
A - set ACK flag U - set URG flag
X - set X unused flag (0x40) Y = set Y unused flag (0x80)
f - split packets in two fragments (may pass weak acl)
x - set more fragments flag (maybe useless)
O - set fake tcp data offset (instead of tcphdrlen / 4)
r - relativize id field (to estimate host traffic)
z - bind ctrl+z to ttl
Z - unbind ctrl+z
As you can see this version allows you to use hping as a 'tcp
specific firewalk'. -O can be used to increase raw fingerprints
(i.e. win* and linux don't drop packets with wrong tcp data offset).
This is an example session, if some packets are lost, hping calculates
the average.
# ./hping -r www.debian.org -I ppp0
HPING www.debian.org (ppp0 209.81.8.242): no flags are set, 40 data bytes
40 bytes from 209.81.8.242: flags=RA seq=0 ttl=235 id=46870 win=0 time=999.1 ms
40 bytes from 209.81.8.242: flags=RA seq=1 ttl=236 id=+58 win=0 time=899.9 ms
40 bytes from 209.81.8.242: flags=RA seq=4 ttl=236 id=+53 win=0 time=700.1 ms
40 bytes from 209.81.8.242: flags=RA seq=5 ttl=236 id=+47 win=0 time=970.1 ms
40 bytes from 209.81.8.242: flags=RA seq=6 ttl=236 id=+39 win=0 time=890.1 ms
40 bytes from 209.81.8.242: flags=RA seq=7 ttl=236 id=+61 win=0 time=770.1 ms
It is possible that for some sites this information might be 'sensitive'.
For example your competitors can obtain statistics about your web
traffic. The two solutions that i have signled out are these:
- randomize the id in the same way of tcp seq number
(but without repetitions, I have an idea for a fast
algorithm that may perform this work)
- use distinct counters for each dest ip.
(I don't think it's such so good idea)
p.s. does somebody know why win* ip stack increase its id by 256?
this solution can prevent the problem but may create others.
bye,
antirez
--
Salvatore Sanfilippo
Intesis SECURITY LAB Phone: +39-02-671563.1
Via Settembrini, 35 Fax: +39-02-66981953
I-20124 Milano ITALY Email: antirez@seclab.com, md5330@mclink.it
Re: about the ip header id
From: Vern Paxson (vern@EE.LBL.GOV)
Date: Tue Dec 15 1998 - 05:39:30 GMT
(Note, this hack has been known to Internet measurement folks for a while.)
> - randomize the id in the same way of tcp seq number
> (but without repetitions, I have an idea for a fast
> algorithm that may perform this work)
A shuffling algorithm can do this using a single pass through an array.
> - use distinct counters for each dest ip.
> (I don't think it's such so good idea)
Yep, Solaris does that, maybe some others too.
> p.s. does somebody know why win* ip stack increase its id by 256?
> this solution can prevent the problem but may create others.
It's doing the increment little-endian instead of big-endian.
Vern