Open zez3 opened 2 years ago
Is this 802.1x authentication traffic? Would this not be prior to getting any IP? Do you need to specify source ip as unknown since u have Mac address, why not just leave source ip blank?
As visible in one of the events included Dot1x_NW_MsgTask_3, this is indeed 802.1x auth related.
Now from my point of view I don't need to specify it(Cisco found, it did) for the reasons that I forgot to mention here and are also not visible in my 2 events above.
e.g. 25 Fri Jul 12 07:26:52 2013 Client Excluded: MACAddress:00:13:e8:88:d8:95 Base Radio MAC :88:75:56:6f:67:70 Slot: 1 User Name: unknown Ip Address: unknown Reason:802.1x Authentication failed 3 times. ReasonCode: 4
or other like IP Pool full, client has static IP address configured and tries to connect or other unspecified reasons. Perhaps others from the community will find more reasons for this.
@andrewkroh @P1llus @adriansr @leehinman @marc-gr have you encountered this issue when you wrote/contributed to the Cisco Integrations?
So, eventually we could use something like null/blank or 0.0.0.0 but I was thinking that being more concrete and keep the unknown in a field would help our NOC colleagues investigate the issue in the long term.
I am open for suggestions/discussion here. If you think, it does not make sense to create an extended new source field as this might enable other future destination.ip_unknown like fields, we can stick with the blank.
I see the existing .address
fields, like source.address
, providing a place for these values.
The .address
fields use keyword
to allow flexibility for different values: IPs, hostname, UNIX socket, etc. The IP address can be copied into .ip
fields allowing for CIDR queries. Users can also consistently search or build rules against .address
without accounting for additional fields in queries.
"Some event source addresses are defined ambiguously. The event will sometimes list an IP, a domain or a unix socket. " now this unknown string is neither but Indeed we could use that. I wanted to get a bit more opinions from the community or the people that actually hit this before. We should come to a common consensus for such situations.
Summary
Add an source.ip_unknown or source.unknown field so that id does not conflict with source.ip type ip mapping
Motivation:
Since the https://www.elastic.co/guide/en/ecs/current/ecs-source.html does not yet provide an option to keep the WLC source.ip=='unknown' string without mapping type conflicts, for brevity, we should keep it in a different source type (keyword)
Detailed Design:
Add to ECE documentation the optional extended source.unknown field type keyword
Provide additional details around the design of the proposed changes.