[ARGUS] Argus 5.0 and tunnel parsing

[Carter Bullard]

Gentle persons,
There have been a bunch of incidents over the years that have been discovered analyzing argus flows generated within L2TP, GRE, VxLAN and MPLS tunnels … great success !!!  

Because argus is an end-to-end bi-directional flow monitor, it is designed to parse through the tunnel headers it encounters, to report on the end-to-end flows.  This means that argus will parse the packet until it finds a L4 header (TCP, UDP, ICMP, RTP, UDT, etc …) that it will use to generate the 5-tuple flow identifiers/key.

In a few instances, this has surprised/confused a few users, as they expect to see flow data for their tunnels, rather than the flows that are in the tunnel.  In several cases, sites needed to know which GRE or L2TP tunnel was this flow in when it was captured, so we hadn’t captured all the features that were needed.

There are two features that I’m implementing in v5.0.0.  One is a configuration option to not parse through tunnels.  This is important for some of the carrier / core network users of argus, as they just want ops and performance features for the tunnels they are transporting.  Parsing into the packet could be a legal issue for some of these network operators.  As an example, we would stop parsing at the inner most L3 header (first IP header).  The second feature is to add the flow spec of the observed tunnels to the flow record (ie add the src/dst IP addresses of the GRE tunnel a GRE DSR).  This gives more context for the flow for debugging and investigation.

Argus v5.0.0 currently has encapsulation reporting (-s +senc +denc), which will indicate the presence of tunnels, but when you see GRE, or L2TP, as examples, there isn’t any data to print for the addresses of the tunnels.

Sometimes the hardest part is how to configure argus to do these things.  I think I'll add two configuration options (with default values):
   ARGUS_TUNNEL_PARSING=yes
   ARGUS_TUNNEL_INFORMATION=no

The defaults will generate existing data.  The tunnel parsing option is pretty simple if enabled, just stop at the first tunnel, so that will go into v5.0.0.

The tunnel information will increase the size of flow records, which is important for many on the list … so we’ll phase that into the release ...
Adding additional data to DSRs is always a big deal … you need to print the new info, filter on it, aggregate it, graph it, provide database support, etc … and in this case, how will you pick which flow spec to print, the tunnel's (which tunnel when there are more than one) or the end-to-end flow … 

I’ll use GRE as the test case and then do VxLAN, as the cloud crowd likes VxLAN ...

Please, do respond with opinions, suggestions, reactions, flames, condolences, and/or support …. They are always welcome.

Hope all is most excellent,

Carter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1385 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20240522/1cc32a5d/attachment.bin>