Update DHCPv4 protocol to use ECS fields#10089
Conversation
d4041ca to
a8b287b
Compare
The DHCPv4 protocol dataset works on uni-flows (it's not transacted, see elastic#7956) so the `source` and `destination` will indicate the original packet header data. Meanwhile the `client` / `server` fields are copies of the `source`/`destination`, but they are copied based on which side is the client and server. Here's a summary of what fields changed. Part of elastic#7968 Changed - bytes_in -> source.bytes - transport -> network.transport = udp Added - source - destination - event.dataset = dhcpv4 - event.start - network.bytes - network.community_id - network.protocol = dhcpv4 - network.type Unchanged Packetbeat Fields - status - type = dhcpv4 (we might remove this since we have event.dataset)
a8b287b to
2123e0e
Compare
ruflin
left a comment
There was a problem hiding this comment.
LGTM.
But someone with more knowledge of the packetbeat code should also have a look.
webmat
left a comment
There was a problem hiding this comment.
LGTM. One nit/question about the columns used in the saved search.
| "dhcpv4.option.message_type", | ||
| "client_ip", | ||
| "source.ip", | ||
| "destination.ip", |
There was a problem hiding this comment.
Nit: shouldn't you use client.ip and server.ip here, to be better aligned with past naming, and the "data transfer" visualization?
Unless it's semantically important to use those because of the mapping src/dst vs cli/srv flipping around?
There was a problem hiding this comment.
Using source/destination makes more sense to me because this dataset produces unidirectional flows. The table essentially shows the traffic at a packet level so with source and destination you can see that A sent this message to B and then know that B responded to A. When I use client/server for a uni-flow I'm not 100% which direction the communication is going since the client/server fields remain the same for all events.
There was a problem hiding this comment.
Makes sense. Would it make sense to align the "Data transfer" visualization to use source and destination, then?
In any case, I'm all good with this. 👍
There was a problem hiding this comment.
No it wouldn't because for a uni-flow only the source has bytes. I had the same thought.
| // Reverse | ||
| client, server := ecs.Client(*pbf.Destination), ecs.Server(*pbf.Source) | ||
| pbf.Client = &client | ||
| pbf.Server = &server |
There was a problem hiding this comment.
Thanks for filling out src/dst, even if the cli/srv pair makes more sense at a conceptual level. 👍
The DHCPv4 protocol dataset works on uni-flows (it's not transacted, see #7956) so
the
sourceanddestinationwill indicate the original packet header data. Meanwhilethe
client/serverfields are copies of thesource/destination, but they arecopied based on which side is the client and server.
Here's a summary of what fields changed.
Part of #7968
Changed
Added
Unchanged Packetbeat Fields