As noted in Flow's top README.md, its NetFlow module (flow::net_flow) is (unlike the rest of Flow which has general usability and has been actively developed for years) of niche interest and present for demo/historical reasons. However, even in that capacity, this TCP(-like)-over-UDP implementation should follow established knowledge about TCP attack vectors. There are places where we currently do not. One (group) of these is as follows.
- To generate a SYN-ACK security token, we use currently the RNG boost::random::mt19937.
- To generate the (internal) ephemeral ports, same.
- To generate an ISN (initial sequence number, 64 bits) for a given connection within the given flow::net_flow stack (net_flow::Node):
- First time (for the entire Node), use boost::random::mt19937 (for the 64-bit ISN).
- Subsequently: use the clock-based scheme from RFC 793 (original TCP RFC, from 1981), where one skips 1 ISN per 4 usec that have passed since the last generation, plus 500msec.
The first two use a cryptographically weak RNG. The 3rd does too, plus an outdated scheme from 1981. In short, all 3 can and should use a CSPRNG (/dev/urandom, boost::random::random_device), and the 3rd can forego that 1981-scheme and just generate a random one each time.
Priority: the sooner the better.
As noted in Flow's top README.md, its NetFlow module (flow::net_flow) is (unlike the rest of Flow which has general usability and has been actively developed for years) of niche interest and present for demo/historical reasons. However, even in that capacity, this TCP(-like)-over-UDP implementation should follow established knowledge about TCP attack vectors. There are places where we currently do not. One (group) of these is as follows.
The first two use a cryptographically weak RNG. The 3rd does too, plus an outdated scheme from 1981. In short, all 3 can and should use a CSPRNG (/dev/urandom, boost::random::random_device), and the 3rd can forego that 1981-scheme and just generate a random one each time.
Priority: the sooner the better.