Subject: FW: Packet capture problem statement

From: "Carter Bullard" <[email-masked]>
Date: Mon, 2 Jul 2001 20:00:31 -0400

Gentle people,
   Because some have expressed an interest in this 
topic, I'm forwarding the packet capture problem statement
that I've just now sent to the RMONMIB mailing list, to
the RTFM and the IPFX mailing list's.  Sorry if this is
an inconvenience.

   If you have an interest in this topic, please track
the thread on the RMONMIB mailing list.

Thanks!

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

-----Original Message-----

Gentle people,
   As recommended by the AD's for Operations and Management,
I would like to present a problem statement to the RMONMIB mailing
list for consideration.  I hope that the WG can come to some
consensus as to whether this work could/should be added to the
work list of the RMONMIB WG.

   There are two ID's that describe some aspects of this
problem and potential solutions, which are listed after
the problem statement.  Please refer to these as examples
of preliminary work in this area.

Thanks for your consideration!

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

RMONMIB Packet Capture Problem Statement

Packet capture is a fundamental mechanism in Internet network 
management and is used in support of a wide range of network 
operational tasks, such as fault detection, protocol analysis, 
performance analysis, and security assessment.  The IETF has specified 
technology for packet capture in STD-59, Remote Network Monitoring 
Management Information Base (RMON MIB) and RFC-1761, Snoop Version 2 
Packet Capture File Format.  Working groups, such as RMON and IPPM, 
continue to describe various aspects of packet capture technology in 
RFC-2021, "Remote Network Monitoring Management Information Base 
Version 2 using SMIv2", RFC-2330, "Framework for IP Performance 
Metrics", and RFC-2613, "Remote Network Monitoring MIB Extensions for 
Switched Networks Version 1.0".

RFC-2613 identified 5 fundamental barriers that made packet monitoring 
in modern networks difficult and noted that, "In order to overcome the 
limitations of the existing standards, new monitoring mechanisms have 
been implemented by vendors of switching equipment.  All these 
monitoring strategies are currently proprietary in nature".  The 
principal monitoring strategy referred to by RFC-2613 is "port copy", 
which has been implemented by many switch and router vendors.  While 
RFC-2613 extended the RMON MIB standard definition of data source 
objects to include "port copy" as a data source for RMON and SMON data, 
RFC-2631 did not qualify these extended RMON and SMON data sources as 
suitable for a particular task.

Packet analysis applications are being extended and new ones are being 
proposed in several IETF working groups that cannot rely on either RMON
Packet Capture or "port copy" mechanisms as their definitive source of
packet data.  Packet analysis applications, such as Real Time Flow
Monitors, Intrusion Detection Devices and IPPM Framework based
performance meters have difficultly using existing packet capture
facilities, in part because these mechanism cannot provide all the
packets of interest or do not convey enough information regarding the
source, disposition, order and arrival time of the captured packets. As
a simple example, "port copy" operating modes, such as N:1 or N:M, can
result in multiple copies of the same packet being delivered to an
application.  Because "port copy" mechanisms do not provide the
originating interface of a particular captured packet, applications
cannot detect that either packet is a duplicate.  Such data would
generate errors in applications such as RMON MIB.

Simple "port copy" implementations also have the potential to generate
large amounts of information, especially when operating in N:1 or N:M
modes of operation.  Without mechanisms to control the load generated by
these mechanisms, the reliability and utility of these new mechanisms is
in question.

In addition to the technical issues that limit "port copy" as a 
definitive source of packet data for analytic functions, "port copy"
style mechanisms pose a significant threat to individual privacy. This
is because "port copy" mechanisms simply copy entire datagrams to
another interface.  Without any mechanisms for minimizing user data
exposure, simple "port copy" strategies introduce new significant
threats to privacy, that should be addressed.

As RFC-2613 indicated, vendors are implementing "port copy" schemes to
overcome limitations of the existing standards.  We would like to 
propose that the Remote Monitoring Working Group consider as a work 
item, the specification of a remote packet copy or capture facility that
can act as a definitive source of packet data for network analytic
applications.

Applicable Internet Drafts
http://search.ietf.org/internet-drafts/draft-bullard-pcap-01.txt
http://www.ietf.org/internet-drafts/draft-quittek-pcap-ext-00.txt