Community ID spec appears to rely on underlying application implementation for src/dst direction determination

Hey,

While doing some research on various data we have, we've seen across two separate applications which saw the same flow, they each had their own interpretation of src/dst ordering.

You'll have to excuse the formatting but in application 1 (the data is fake but the example has happened), the flow was seen as:

src,srcp,dst,dstp
aaa,65000,bbb,443

While in application 2 it was reversed:

src,srcp,dst,dstp
bbb,443,aaa,65000

Looking at the spec itself, we appear to leave the ordering of the src/dst combination up to the individual application and if we had implemented community ID in both applications, we would have ended up with a different community ID for the same flow.

I would suggest that the spec is updated to specify how the src/dst combination should be calculated/sorted in order to ensure a consistent community ID is generated for the same flow (regardless of what the underlying application thinks the direction is).

Thanks,
Conor

Start by reading the Community ID specification and the two src,srcp,dst,dstp examples in this issue. Compare the applications’ direction choices, then update the specification so the ordering rule is explicit and the same flow produces one consistent Community ID.

Written by the indexing model from the issue text.