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

[Aaron T. <syn...@gm...>]

Comments inline...

On 1/29/07, Eric Hacker <li...@er...> wrote:
> Dear Packet Fanatics,

[snip]

> The following elements are needed to support this. Each element may be
> either standardized if a value space is defined or normalized if it
> needs to be. For these purposes, I'll break out the flows into the
> client and the server, understanding that sometimes that is not
> appropriate, but mostly it is. Shoulds and musts are apply to  this
> use case only.

[snip list of description oriented metadata]

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.

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

> Port in data, boolean, same as IP in data.
> Flow-pointer, normalized, a URL for the actual packet dump file.

I'm not sure what a "flow-pointer" is.  More info?

> OpenPacket meta-data, such as reliability of the source or if verified
> by others.
> Meta-data URL, standardized, for getting updates to the meta-data,
> especially the open-packet portion of the meta-data.

Good idea.

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

> Sometimes the OS is what is vulnerable and sometimes it is just the
> application. Having the OS separate is nice. It may allow a
> sophisticated testing system to manipulate OS specific fingerprints in
> a flow, such as Source ports, sequence numbers, options etc. to
> simulate different OSs from one capture. Is that dreaming, or what. :)

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

> I don't recall if there has been a final decision regarding packaging
> of captures. In order to support meta-data, they probably need to be
> gzipped-tarballs that include both the meta-data and the packet
> capture. Alternatively, if the capture file names could be completely
> unique and normalized, then a testing system could look locally for a
> cached copy, by filename, and then use the full URL if not found. This
> is probably a feature for a later version of OpenPacket.
>
> A wonderful feature for tcpreplay that would support this use case is
> client-server mode. Here the tcpreplay client and server would 'play'
> their respective side of the conversation after receiving the packet
> from the other side. This would be very useful for inline NSD testing.

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.

[snip]

-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix