Update DHCPv4 protocol to use ECS fields #10089
Conversation
andrewkroh
force-pushed
the
feature/pb/dhcpv4-ecs
branch
from
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)
andrewkroh
force-pushed
the
feature/pb/dhcpv4-ecs
branch
from
a8b287b
to
2123e0e
Compare
| @@ -258,7 +258,8 @@ | |||
| "dhcpv4.transaction_id", | |||
| "dhcpv4.op_code", | |||
| "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