Sorry for the delay in replying - I've been away at the IETF all week.
Before I get too far into this, I wanted check and see if anyone
else is actively working on adding ICMP to bro?
Others have mentioned it, but no one has actually signed up for doing this.
I've started working on it and hope to be done pretty soon (famous
last words!). Maybe I'm naive, but it doesn't look too hard.
I'd expect it to not be particularly tricky - look forward to having this
addition, it's frequently requested.
NetSessions::NextPacket() looks like the best place to start.
Yes, that's where the demux happens. A key question is whether to introduce
the notion of a ICMP "connection" (this is the model used for UDP, since most
non-multicast UDP flows are bidirectional). With ICMP, this makes sense for
ping, but not for the others that come to mind, though many of them fit into
a model of ICMP-associated-with-other-connection, for example Unreachables
associated with TCP or UDP connection initiations.
So I think for now just tacking handling individual ICMP's without creating
associated connection state or matching them to existing state is the way
to go. A notion of connection state can be added later as needed; hopefully
this will be fairly orthogonal to the rest of the ICMP analysis.
I've got some very simple ICMP recognition code in place. I haven't
looked at fragments or reassembly yet.
You don't need to do those, there's a layer already in Bro that reassembles
fragments and dispatches the recovered packet.
Vern