Teredo Stray Packet Analysis Johannes Ullrich

Teredo Stray Packet Analysis Johannes Ullrich
Teredo Stray Packet Analysis
Johannes Ullrich
This investigation started with Rick observing some odd UDP traffic hitting his firewall. In this case,
the traffic came from port 3544. The destination port was a "random" high port. If you
would like to provide your packet captures, see the end of this article for the right filter.
Port 3544 is assigned to Teredo. However, Teredo itself uses this port to establish connections, not
necessarily for the actual Teredo tunnel traffic itself. As a host establishes a Teredo connection, it will
connect to a Teredo server on port 3544 and negotiated the details of the connection. During this
negotiation, a IPv6 address is established for the host.
The IPv6 address used by Teredo will always start with "2001:0000:". This /32 prefix is reserved for
Teredo. It is followed by the IPv4 address of the Teredo server, 16 bits worth of "Flags" defining the
type of NAT used by the client's network, the UDP port used to connect back to the client and finally
the clients public IPv4 address. To illustrated this, here a more "graphical" representation of a Teredo
S = Server IP address, F = Flags, U = obfuscated UDP port, C = public client IP address
in short: Everything needed to connect back to the client is encoded in the IPv6 address.
The Teredo packet itself is rather simple. The IPv6 packet is embeded in a IPv4 UDP packet. We got
an IPv4 header, a UDP header followed by the IPv6 header. Wireshark for example does a nice job in
analyzing Teredo traffic.
Now lets go back to Rick's packet trace. If all this is true, then the last 4 bytes of the embeded IPv6
destination address should match the public IPv4 address the packet was sent to. In Rick's case, this
wasn't the case. The two addresses didn't match at all.
The only packets Rick saw where "Bubble Packets". Bubble packets are used by Teredo to keep the
firewall open. Typically every 30 seconds, the Teredo client will send an empty IPv6 packet to the
server. This will extend the connection timeout in most firewalls. For UDP, there is no state like for
TCP. In order to preserve the resemblance of state, firewalls assume that if a host sent a packet out,
there may be a reply coming back. Teredo takes advantage of this "statefull UDP" feature in modern
This is why we would like to connect more of these packets to see if Rick's experience was just a "one
off" oddity or if others are seeing the same traffic. Rick did not use Teredo or IPv6 for that matter. We
are interested in your packet in particular if you are NOT using IPv6.
You can use tcpdump or windump to collect the traffic. You probably have to collect the traffic outside
of your firewall. The tcpdump line is not perfect, and may capture some other UDP traffic (e.g. DNS).
Before you send it to us, take a quick look at it to make sure you are not sending us any confidential
data. As a reminder, the tcpdump command line to collect the traffic:
tcpdump -c100 -s0 -i any -w /tmp/teredo udp port 3544
Revised February 16, 2010
Page 1 of 1
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF