[Bro-Dev] Tunnels

Gregor Maier gregor at icir.org
Thu Jul 28 18:23:22 PDT 2011


 > [was used for VLAN]

Hmm. Interesting. In this case I'm surprised it worked because the way I 
read the code, it always assumes that there is an IP header. It cast the 
pkt pointer into a struct ip* and checks whether the caplen is large 
enough to the IP header length from this struct ip* (which should work 
often enough because the max header length is 64 bytes) but some short 
packets might have been missed by that code.


>> Note, the reason I was looking at this code is that I want to write
>> something that can decapsulate tunneled IPv6 packets (6in4, 6to4, Teredo).
>
>
> I have code to do this written for Click! and it's fortunately very easy (I have AYIYA decapsulation code too).


Cool. I've actually never used Click, but yeah, the actual decapsulation 
is really quite easy. Deciding what to do with the parent connection 
(and how to implement that) is the hard part....

> The problem is that you have two IP layer headers and only the one with your address space makes any sense.  It's really confusing to see two non-local networks show up in your conn.log because it was a local host using tunneled address space.

The right way to do that is to pull IP analysis into the analyzer tree 
and then do tunnel de-capsulation using the analyzer tree. Then you 
could even decapsulate IP-over-HTTP-over-whatever. But that's going to 
be a lot of work. My plan was to do a simpler work-around though:

> I think we need the ability in the connection record to specify a parent connection or something.  I suppose even just logging the presence of a tunnel may be enough.  There are a lot of questions that will need answered once we start decapsulating tunnels.
>

Yeah. I haven't looked into that too much yet. But I was thinking of 
either (or possibly both configureable)
   * removing the parent headers completely but generate an event to
     associate the child connection with the parent connection (1)
   * create a copy for the packet data of the child . Thus Bro would see
     both the parent connection and the decapsulated connection. One
     would still want an event to link the two and you'll have two
     packets with the same timestamp and the total byte counts will be
     inflated.....

(1) not that it's not necessarily a connection. 6to4 and 6in4 are 
directly on top of IP (using proto 41). So Bro wouldn't even see these 
packets because it only handles TCP/UDP/ICMP (you would get a weird though)



cu
Gregor
-- 
Gregor Maier
<gregor at icir.org>  <gregor at icsi.berkeley.edu>
Int. Computer Science Institute (ICSI)
1947 Center St., Ste. 600
Berkeley, CA 94704, USA
http://www.icir.org/gregor/


More information about the bro-dev mailing list