icmp and bro

[Vern Paxson]

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