Skip to content

Added Network Session Objects - From Split of #43 #48

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

Closed
wants to merge 1 commit into from
Closed

Added Network Session Objects - From Split of #43 #48

wants to merge 1 commit into from

Conversation

MikePaquette
Copy link
Contributor

Add network.session_id and network.virtual_ip in response to issue #37
This PR was from the split-out of #43

Add network.session_id and network.virtual_ip in response to issue #37
@MikePaquette MikePaquette requested review from webmat and ruflin July 12, 2018 18:59
- name: session_id
type: keyword
description: >
This is the session ID or connection ID,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the description I'm wonder if we should put it into a connection object? See other discussions around connection.

I think there is value for network info and connection info.

@krisATelastic
Copy link

Hey guys, it looks like this PR was not merged because of conflicts. Implementing session_id actually fixes a heap of use cases that i'm helping with, especially F5's. Are we going to re-push this or was it superceded? cc. @MikePaquette

@webmat
Copy link
Contributor

webmat commented May 6, 2019

Hey @krisATelastic, thanks for the ping. We'll look at it again.

In the meantime if you or a customer needs to store session ID, please create custom fields in the meantime.

You should never feel blocked by ECS not supporting your use case yet.

@MikePaquette
Copy link
Contributor Author

The network.community_id field should be used for this purpose.

Docs at: https://www.elastic.co/guide/en/ecs/current/ecs-network.html

@andrewthad
Copy link
Contributor

network.community_id is not the same thing as a session ID. According to the spec published by Corelight, a community ID is just a hash of the source ip, dest ip, source port, dest port, and network protocol. If a client opens a TCP connection to the same server twice and uses the same ephemeral port as the source port both times, the community ID will be the same for both sessions. By contrast, a session ID (as provided by Cisco, F5, Fortinet, and possibly other vendors that I'm not aware of) uniquely identifies the TCP session. I would like to see this included in ECS. Alternatively, one of the tracing fields (transaction.id, span.id, or trace.id`) could be used for this purpose, but this doesn't seem to fit their expressed purpose:

Distributed tracing makes it possible to analyze performance throughout a microservice architecture all in one view. This is accomplished by tracing all of the requests - from the initial web request in the front-end service - to queries made through multiple back-end services.

@ebeahan
Copy link
Member

ebeahan commented Sep 15, 2020

Hi @andrewthad. A proposal for a top-level session field set, including session.id, is actively going through the RFC process. Here are the links to the merged stage 0 proposal and the opened stage 2 PR if you have any feedback:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants