The current code for converting NFv9 PDUs to IPFIX (convert.c:541-598) takes template and data sets in NFv9 PDUs as is, meaning that in case padding is used, it will be considered for the IPFIX PDU, and no padding will be inserted otherwise. This works well as long as exporters adhere to the protocol specifications when it comes to padding. However, we have recently come across a (Cisco) exporter that does not insert padding in NFv9 PDUs at all, even though RFC 3954 dictates the following with respect to padding:
The Exporter SHOULD insert some padding bytes so that the subsequent FlowSet starts at a 4-byte aligned boundary.
In a situation where plugins perform PDU manipulation and insert padding to obtain 4-byte aligned boundaries (as kind of recommended in RFC 7011 in the case of IPFIX), this can lead to memory errors. Although these errors are fixable in plugins, it may be good to overcome problems introduced by poor exporter implementations already in IPFIXcol input plugins, to avoid any interoperability issues further in the processing chain. Also, fixing this will make the resulting IPFIX PDUs (especially when used together with the Forwarding plugin, for example) more compliant with IPFIX PDUs from many other vendors.
mikeek
commented
9 years ago
The current code for converting NFv9 PDUs to IPFIX (
convert.c:541-598) takes template and data sets in NFv9 PDUs as is, meaning that in case padding is used, it will be considered for the IPFIX PDU, and no padding will be inserted otherwise. This works well as long as exporters adhere to the protocol specifications when it comes to padding. However, we have recently come across a (Cisco) exporter that does not insert padding in NFv9 PDUs at all, even though RFC 3954 dictates the following with respect to padding:The Exporter SHOULD insert some padding bytes so that the subsequent FlowSet starts at a 4-byte aligned boundary.
In a situation where plugins perform PDU manipulation and insert padding to obtain 4-byte aligned boundaries (as kind of recommended in RFC 7011 in the case of IPFIX), this can lead to memory errors. Although these errors are fixable in plugins, it may be good to overcome problems introduced by poor exporter implementations already in IPFIXcol input plugins, to avoid any interoperability issues further in the processing chain. Also, fixing this will make the resulting IPFIX PDUs (especially when used together with the Forwarding plugin, for example) more compliant with IPFIX PDUs from many other vendors.