Extended encapsulation support

[openargus]

We've been working with Stanford to extend Argus's encapsulation accountability. Stanford has a modern network infrastructure and monitors their research networks using a number of 100G argus sensors, primarily for security but also for operations. The Stanford network uses modern WAN/CAN/MAN strategies to support a large number of wired and wireless networks, with multi-level tunneling strategies in portions of the network. Argus processes these services well, however, the Argus strategy to report on the innermost L3/L4 flow (ie the end-to-end flow) can leave out information regarding some of the middle encapsulations. Multiple levels of VxLAN, GRE, GUE and MPLS tunneling can be confusing, and with adversaries trying to exploit issues in GRE and VxLAN, having better tunnel awareness is becoming more important.

To support this effort, I've created a branch carter/encapsBuffer where we have added encapsulation header capture for Argus flows. The idea is to capture all of the packet headers that lead up to the L3/L4 headers used to generate the classic 5-tuple flow ... using the same strategy we use to capture the user data ... and put the contents in the existing encaps DSR. We'll do this for the first packet, in both directions, of a new flow.

Adding this data will increase the size of the flow record, so we'll need to play with it to figure out the best way to use this support ... We definately don't want Argus to become a packet capture device, so I'm working with the idea of capturing this data on flow exceptions, rather than all of the flows, and providing configuration support to define what an exception is.

Argus client support will include the same strategy we use in radump.1 and radecode.1, where we use tshark to decode hex buffers. I've got this working, kind of ... but will have to change the ArgusDump library routine (which generates hex dumps of buffers) so that it is compatible with wireshark's text2pcap.1 ...

If this is of interest, please get involved !!!

[openargus]

I've generated a carter/encapsBuffer branch in the clients to test modifications to ArgusDump, to generate the hex dumps that text2pcap.1 requires.

ArgusDump generated a standard short hex buffer dump, but text2pcap.1 requires a byte hex buffer dump ...

Was:

0x0000	 0257 4820 935d 02ba ad0f 5df6 0800 4500	.WH..]....]...E.
0x0010	 00aa 0000 0000 ff11 2408 0a75 414a 0a75	........$..uAJ.u
0x0020	 4107 ffeb 12b5 0096 0000 0800 0000 a887	A...............
0x0030	 5700 064c 79f4 f510 06d8 8ebf 36ea 0800	W..Ly.......6...
0x0040	 4500 0078 0000 0000 ff11 23cf 0a75 414a	E..x......#..uAJ
0x0050	 0a75 4172 ed0b 17c1 0064 5a62 0800 0800	.uAr.....dZb....
0x0060	 0000 0000 0108 0102 4e92 408e 3fcd ffbe	........N.@.?...
0x0070	 0108 0202 0000 0000 0000 0000 0108 0301	................
0x0080	 380e 87db                              	8...

Now:

000000	 02 57 48 20 93 5d 02 ba ad 0f 5d f6 08 00 45 00	.WH..]....]...E.
000010	 00 aa 00 00 00 00 ff 11 24 08 0a 75 41 4a 0a 75	........$..uAJ.u
000020	 41 07 ff eb 12 b5 00 96 00 00 08 00 00 00 a8 87	A...............
000030	 57 00 06 4c 79 f4 f5 10 06 d8 8e bf 36 ea 08 00	W..Ly.......6...
000040	 45 00 00 78 00 00 00 00 ff 11 23 cf 0a 75 41 4a	E..x......#..uAJ
000050	 0a 75 41 72 ed 0b 17 c1 00 64 5a 62 08 00 08 00	.uAr.....dZb....
000060	 00 00 00 00 01 08 01 02 4e 92 40 8e 3f cd ff be	........N.@.?...
000070	 01 08 02 02 00 00 00 00 00 00 00 00 01 08 03 01	................
0x0080	 38 0e 87 db    

ArgusDump() is used to generate the "-M printer=hex" option for ra programs.
I'm not thinking that a lot of people use this, and so this may not be a problem.
But lets test it out using this branch