icmp and bro

[Paul Howell]

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