icmp and bro

Vern Paxson writes:
> 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.

Okay, well then I'll sign up.

I haven't been working on this too much since I sent the original question,
but I'll start now in earnst.

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

Gotcha. I leave out the notion of connection for now.

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

I assume you're referring to the fragment handling code which is
called early on in NetSessions::NextPacket()?

There isn't something before this that handles fragments, is there?


< paul