teredo tunnel parsing
Carter Bullard
carter at qosient.com
Fri Aug 14 16:18:14 EDT 2009
Gentle people,
In a meeting a few weeks ago, someone asked if argus could deal with
tracking
IPv6 flows tunneled using teredo. I felt a bit embarrassed as I had
to ask what
was teredo, not having any Microsoft machines.
I was pretty floored when I found out that teredo is IPv6 over UDP
(RFC 4380).
I should have known that!!! Well, argus is doing pretty well with
arbitrary encapsulations,
so I've now got a preliminary implementation of teredo tunnel
discovery and tracking
in argus-3.0.3. I have to put in a few more checks before I will put
it out there, because
I'm using a very simple IPv6 header discovery algorithm right now, and
we can do better.
OK, this has generated a situation that I've been avoiding for a
while, and so
now is the time to address it. How should I report the IPv4 flow that
is the
tunnel for the IPv6 traffic? We've had this problem with GRE
tunnels, but now that
we can have easily 3-4 of these, its time to deal with it.
So what I'd like to get some feedback on is how do we refer to the
encapsulations?
I'm not sure how to refer to the IP identifiers if we have a flow that
is teredo based
IPv6, inside IPv4, inside a GRE tunnel (which is an IPv4 flow). We'll
have 3 sets of
IP addresses pairs.
I've thought about having an array-like index reference scheme like:
ra -r file -s srcid saddr[2] daddr[2] proto[2] pkts bytes
Thoughts?
Carter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090814/6b2fe6ae/attachment.bin>
More information about the argus
mailing list