Fix: Decoding of IPFIX templates with Enterprise Number field

[shyam334]

Bug: Decoding of IPFIX templates with Enterprise Number field

The goflow IPFIX template decoder isn't aware of the Enterprise Number field, which results in malformed template(s) and processing, when decoding IPFIX templates with Enterprise Number field.

Following is the field specifier format from RFC7011#section-3.2, Figure G :

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |E|  Information Element ident. |        Field Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Enterprise Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When goflow tries to decode an IPFIX template with Enterprise Number, It attempts to decode the Enterprise Number field as a regular Field in the template.

This results in a malformed template. As a result the corresponding IPFIX Datasets would not be processed. (i.e. goflow would not emit any records)

Patch

The patch adds a seperate path for IPFIX template parsing, where it checks for the Enterprise bit condition and skips the Enterprise Number field.

This will enable the IPFIX Template(s) to be decoded correctly and the corresponding IPFIX Datasets to be processed.

[lspgn]

Thanks a lot for the bugfix! (also referencing #31 as it was mentioning Enterprise Templates).
Do you have some samples I could test this with?

[shyam334]

@lspgn Thanks for promptly looking into this.
I just realised that I don't have a representative pcap that I can share publicly. Let me work that out and get back.

Separately, Is there a more ad-hoc channel to collaborate. (slack or such)

[shyam334]

@lspgn Here is a tiny but representative anonymized sample

[lspgn]

There is no slack for GoFlow but feel free to email me: louis at cloudflare.com

Thank you for the sample, will test it out.

[raghurampai]

@lspgn I guess merge is pending for this request. So, is this planned for next release?

[JustinAzoff]

This is off by one, you need

field.Type -= 1 << 15                                                                                  

Because:

1000000000000001

needs to turn into just '1', so you need to subtract

1000000000000000

not

0111111111111111

[shyam334]

Thanks, will update. (could've sworn it was in my fork)

[JustinAzoff]

Skipping the 4 bytes fixes the parsing, but I think it needs to track that this was a PEN field inside the Field type. In the data that I have the resulting Type will be 1 or 2. The later bits will then just treat those fields as as IPFIX_FIELD_octetDeltaCount or IPFIX_FIELD_packetDeltaCount which would be wrong.