Community ID spec appears to rely on underlying application implementation for src/dst direction determination #3
Labels
bug
Something isn't working
question
Further information is requested
spec-ambiguity
Something isn't spelled out in excrutiating detail in the spec
Milestone
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
The text was updated successfully, but these errors were encountered: