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