Cisco WLC wlan controller source.ip unknown

[zez3]

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.

• Field names

  source.ip_unknown
  source.unknown

• Example values for the fields

  source.ip_unknown == 'unknown'

• Suggested appropriate datatypes

  keyword

• Any example events that map to the proposed use case(s)

  
  <139>cisco-wlc-mgmt: *rsyncmgrXferTrasport: May 09 16:02:41.748: %LOG-3-Q_IND: [PS]apf_80211.c:19558 Client Authenticated: MACAddress:f6:b1:ec:aa:aa:aa Base Radio MAC:58:f3:9c:ff:ff:ff Slot:1 User Name:someuser123@campus.mydom.tld Ip Address:unknown SSID:myssid

<139>cisco-wlc-mgmt: *Dot1x_NW_MsgTask_3: Apr 09 14:58:50.288: %APF-3-AUTHENTICATION_TRAP: [PA]apf_80211.c:19558 Client Authenticated: MACAddress:f8:59:71:ff:ff:ff Base Radio MAC:50:06:04:ff:ff:ff Slot:1 User Name:myuser123@student-net.mydom.tls Ip Address:unknown SSID:eduroam ```

[legoguy1000]

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?

[zez3]

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.

[ebeahan]

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.

[zez3]

"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.