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?
Thanks.
< paul