Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sharefulness - 4 tuple #21

Open
jonz-secops opened this issue Mar 3, 2020 · 3 comments
Open

Sharefulness - 4 tuple #21

jonz-secops opened this issue Mar 3, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@jonz-secops
Copy link

If there was a 4 tuple hash, then I could share these hashes with other people and tools, between different networks, and use them in very much the same way. Dropping the source address would mean that hash x can be applied against traffic in any network inside and outside of a particular organization. it would put the community in community ID.

@neu5ron
Copy link

neu5ron commented Mar 5, 2020

I think a 4tuple would be great too! But I think dropping source address is only taking into consideration outbound traffic - would say a 4 tuple for both with src and one with dst

@skrap3e
Copy link

skrap3e commented Mar 5, 2020

4 tuple would be very useful. Drop either SRC or DST. Different use cases but equally valuable.

@ckreibich
Copy link
Member

ckreibich commented Sep 14, 2020

Thumbs up to "put the community in community ID" :)

The theme here seems to be dropping some part of the tuple — not clear that it's necessarily a specific address. The immediate workaround that comes to mind for this would be using null-values, like 0.0.0.0, for the parts you don't care about. There seem to be two deficiencies if one does this: (1) whatever part you omit would also need to be omitted by the other orgs/peers you're exchanging the IDs with, (2) there's no "matching" of such partial IDs with full-tuple IDs since the hashes will come out differently. Would this address your use case, anyway?

Fwiw, there seems to be a whole class of applications where standardized textual rendering would be useful, i.e., simply some form of "saddr:daddr:proto:sport:dport". Pattern-matching this would obviously be feasible, and various representations (in JSON, etc) would be easy to come by. Thoughts on this are also welcome.

@ckreibich ckreibich added the enhancement New feature or request label Sep 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants