Hi Philip,

Thanks for reaching out. Let me ask you, are you looking for "own extensions" for IPFIX collection or for IPFIX export (i ask because you mentioned softflowd and that boils to IPFIX export). For collection, totally: aggregate_primitives allows you to do that, ie. https://github.com/pmacct/pmacct/blob/master/CONFIG-KEYS#L146-L152 and https://github.com/pmacct/pmacct/blob/master/examples/primitives.lst.example . For export the same feature is available but much-much more limited.

Paolo

Hi Paolo,

thanks for your kind answer and your advices. Actually I am searching for open source netflow (IPFIX) exporter allowing the definition and extraction of specific fields out of pcap files or network interfaces.

Thanks and best regards,
Philip

Hi Philip,

If you can bring some examples, we can see whether that is feasible or there is a gap - and whether the gap looks solvable or not. The more detailed the example, the better. Feel free to reach out by unicast email if there is sensible data.

Paolo

Hi Paolo,

I try to be as concrete as possible. The data is not sensible but not that significant as fields may change or be missing. The main idea is to monitor MQTT traffic in IoT networks and analyze whether people access resources they aren't allowed to. The first milestone in my research involves the following PDF from a Czech university:

https://www.fit.vut.cz/research/publication-file/12110/IPFIX%20Extension%20for%20MQTT.pdf

The authors propose extensions for IPFIX to monitor MQTT network traffic successfully. These fields are also exciting, but I would also like to assess the MQTT topic messages.

The following snippet shows an MQTT packet sent from a Zigbee coordinator in our internal IoT lab.

This packet does not currently exhibit all interesting fields, but I would like to extend the header in the next step, e.g., adding correlation IDs for request/response, etc.

I hope to find a solution that allows the configuration of a NetFlow (IPFIX) exporter to include these details as MQTT is not happening on the IP or transport layer but more on the application of the ISO/OSI stack. I suggest enriching flows by MQTT data to make IoT monitoring more efficient.

Is this feasible with pmacct?

Philip

Hi Philip,

Thanks for the extra details. None of this exists right now in pmacct and i understand that your final wanted scenario is a long shot for the current status quo: that is, not only grab MQTT data here and there in a standalone fashion but also, in future, potentially save / cache IDs to correlate request/response messages, etc.

I can leave this Issue open and mark it as Enhancement. Maybe somebody is also interested and/or can volunteer / help out to do (some of) the work. Can you yourself dedicate any resources to development of such a feature?

Paolo

Hi Paolo,

Thank you for the conversation and the enhancement tag. If I would like to modify the exporter of pmacct, which file should I touch? This should be the first step if I have the resources available or if someone is interested in enhancing pmacct with MQTT capabilities.

Have a nice evening!

Hi Philip,

I think there are 3 phases in this process. Collect info, store it in a meta-data format inside pmacct (so that it can be exported, surely, but it could be potentially accounted for in other plugins) and export it as IPFIX. In super brief:

phase-1: in let's say we focus on pmacctd, the libpcap-based daemon. Packets with MQTT data are made available by the library; in ll.c the layer-2 is handled, in nl.c you may see how layer-3 is handled and also some light handling of layer-4 is done up to the point where a pptrs->payload_ptr is set: that is the base of where MQTT stuff would be taking place (and you may see you have an off offset, ie. where you are in the current captured packet, and a caplen that tells you how much portion of the packet was captured - and doing basic math among the two, you can figure out how much portion of the MQTT stuff you have captured (and increase snaplen if needed)). This is also the place where you should make a cache if wanting to correlate data across packets, ie. like flows handling (ip_flow.c) and packet classification do;

phase-2: Having the playground set, you should cherry-pick what is of interest and transform it in meta-data. You can follow how this is done for pkt_nat_primitives or pkt_mpls_primitives; similarly you could define in src/network.h a pkt_mqtt_primitives, define what in the packet goes where in the meta-data in src/pkt_handlers.c and have auto-magically meta-data offered to any plugin you like in pmacct, including of course nfprobe - the IPFIX exporter;

phase-3: perhaps the most easy part, templates for MQTT data should be crafted and exported & meta-data pieces should be cherry-picked and framed in IPFIX format for export. This all happens in nfprobe/netflow9.c and, why the most easy part?, this can be done similarly to all other pieces of meta-data. Not a simple copy/paste exercise but surely an exercise for which you have plenty of examples in the existing code.

Paolo