Re: [Openpacket-devel] Use cases and meta data

[Eric H. <li...@er...>]

On 1/29/07, Aaron Turner <syn...@gm...> wrote:
> Comments inline...
>
> On 1/29/07, Eric Hacker <li...@er...> wrote:
> > Dear Packet Fanatics,
>
> [snip]
>

> Having some experience creating a taxonomy in this area, I can say
> it's quite doable.  However, it does take time to manage the taxonomy
> and time to connect the dots.  In general I suspect that most people
> with pcap's they'd contribute no longer have this sort of information,
> and if they did would be unwilling to spend the time fill out the data
> for each pcap.  I'm not saying some people won't, but a majority won't
> bother.

Sadly, I agree. That's what karma points are for though, right. :)

> > IP in data, boolean, must indicate if the IP address of either the
> > client or server is represented in the data. If so, it would be nice
> > to have a way to define where (for this particular flow) the IPs are
> > in the data so that they can be changed. Something like packet 4, byte
> > offset 54, client IP.
>
> I assume the reason you want the above is so that you can properly
> rewrite IP addresses to match your test bed network.   I would argue
> that this really should be automated (who wants to look through pcap's
> in Wirkshark and find IP addresses??) and hence should be a separate
> tool.  Perhaps the OpenPacket team develops such a tool, but that
> seems outside of the scope of this project at this time.  On a side
> note, I'd suggest looking at tshark's pdml's output.  At least that
> way you won't be spending all your time writing protocol decoders.

Rewriting supports more than just matching the testbed. It allows the
simulation of multiple flows. Sure the IDS catches one attack, but
does it handle 500 all at different targets?

I agree that rewriting IP addresses needs to be automated, and perhaps
a tool can do it automatically most of the time so this isn't
necessary. It just seems to me that often the protocols are new or
complex enough that the tools can't support this. Whereas if the meta
data can explicitly provide the location, the tool can do it without
knowing the protocol.

PDML sucks as far as XML goes and using other tools to parse it. It is
a Packet DISPLAY ML. A good Packet ML would look much like RFC 3252,
fixed up a bit.

> > Flow-pointer, normalized, a URL for the actual packet dump file.
>
> I'm not sure what a "flow-pointer" is.  More info?

I was assuming that the meta-data and the actual pcap are not in a
single file, so the meta-data ought to point to the pcap. Flow pointer
is probably a poor choice of words.

> > Not all elements need to be a part of the system as stored in the
> > OpenPacket repository, however the method of creating the meta-data
> > should support having all these elements.
>
> Not sure I 100% follow, but I will say that data is only useful if
> people have access to it.  And people are less likely to contribute
> data if they don't see the immediate value.

What I meant here is that the format should be extensible and systems
shouldn't choke on meta-data that they don't understand. There is a
core set of required meta-data, a set of optional meta-data, but if it
is there, this is what it has to look like, and then there's the
meta-data that someone needed and decided to give back because someone
else might find it useful too. There are limits of course.

> I think a lot of the vuln target information should come from the CVE.
>  No need to duplicate info IMHO.

I agree, when it is CVE related. What if just some nice Microsoft
Exchange traffic that happens to trigger some dumb ISS signature all
the time? I think this is the kind of info that is optional, but needs
to have rules established on how to put it in.

> Yep.  Actually, I would love to see OpenPacket ship tcpreplay
> (tcpprep) cache files along with the pcap's so people can use them in
> inline mode right away.   I'm sure a lot of people would find that
> useful.

That's a perfect reason to keep the meta-data format extensible. It
enables you to create a way to ship extra information in the
meta-data.

Thanks for tcpreplay, BTW.

Peace,
Hacker