Subject: Packet capture problem statement

From: "Carter Bullard" <[email-masked]>
Date: Wed, 20 Jun 2001 10:07:30 -0400

Gentle people,
   In following up on the packet capture issues that were identified
at the RTFM2 BOF, the Management and Operations Area Directors have
suggested that we send a problem description and explanation to
the RMONMIB mailing list to see if there is consensus on the problem
and if RMONMIB is the right working group to consider the effort.

   I have put together an initial draft problem statement, and I 
would really like to get your input/comments.  Since this is a
formal step in trying to get the IETF to address issues in packet
capture, I hope that we can put together a good statement and
explanation.  If you have any comments, suggestions, opinions,
reactions, attitudes, flames, whatever, please do respond .

Thanks for the attention,

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

------- Insert Rmonmib Problem Statement.txt -------

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 make 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 "port copy" 
mechanisms as a 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 "port copy" facilities, in part because the "port copy" mechanism 
does not convey enough information regarding the source, disposition, 
loss characteristics, order and time of replicated packets.  As a 
simple example, many "port copy" operating modes can result in multiple 
copies of the same packet being delivered to an application, without 
any means to detect that the packet is a duplicate.  In these 
conditions, port copy derived data will generate erroneous values in 
applications such as RMON MIB.

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 can only copy entire datagrams to 
another interface.  Without any mechanisms for minimizing user data 
exposure or for limiting access to the resulting packet data, simple 
port copy strategies introduce new significant threats to privacy.

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 packet copy facility that can act as a 
definitive source of packet data for network analytic applications.

---

From: "Carter Bullard" <[email-masked]>
Date: Fri, 22 Jun 2001 08:32:21 -0400

Gentle people,
   Because there is little discussion regarding this,
I would like to assume that this is a reasonable start
for the process.  Again if there are any comments,
opinions, reactions, either good or bad, please do send
them, as I would like to put this problem statement to
the RMONMIB mailing list today (Friday) or Monday.

Thanks for your attention!!!

Carter

Carter Bullard
QoSient, LLC

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

> -----Original Message-----
> From: Carter Bullard [mailto:[email-masked]] 
> Sent: Wednesday, June 20, 2001 10:08 AM
> To: [email-masked]'
> Cc: 'Juergen Quittek'; [email-masked]'; 'Georg 
> Carle'; 'Tanja Zseby'; 'Sebastian Zander'; 'Marcelo Pias'
> Subject: Packet capture problem statement
> 
> 
> Gentle people,
>    In following up on the packet capture issues that were 
> identified at the RTFM2 BOF, the Management and Operations 
> Area Directors have suggested that we send a problem 
> description and explanation to the RMONMIB mailing list to 
> see if there is consensus on the problem and if RMONMIB is 
> the right working group to consider the effort.
> 
> would really like to get your input/comments.  Since this is 
> a formal step in trying to get the IETF to address issues in 
> packet capture, I hope that we can put together a good 
> statement and explanation.  If you have any comments, 
> suggestions, opinions, reactions, attitudes, flames, 
> whatever, please do respond .
>

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 26 Jun 2001 13:36:48 +0200

Hi Carter,

I think your text expresses the idea very well. I just have three
minor comments which you will find inline.

    Juergen

> Switched Networks Version 1.0".

Maybe, you should mention, that (and why!) current RMON does not meet
the requirements of the applications you mention above. Or better, to
what degree these requirements are matched and what gap would be filled
by pcap.

> applications such as RMON MIB.

Another drawback of port copy you shuld mention here is the potentially
huge amount of data sent to the collector, particuarly if you want to
report on more than one port. Selective packet capturing can help, if
only a part of all port traffic is of interest.

> port copy strategies introduce new significant threats to privacy.

I would mention here that there still remains a threat to privacy
that should be considered thoroughly.

---

From: "Carter Bullard" <[email-masked]>
Date: Tue, 26 Jun 2001 15:53:27 -0400

Hey Juergen,
   Thanks for the comments.  Just a few responses for
clarification.  I'll incorporate your suggestions in
the draft.

Thanks again!!!

Carter

> -----Original Message-----
[snip]
> Maybe, you should mention, that (and why!) current RMON does 
> not meet the requirements of the applications you mention 
> above. Or better, to what degree these requirements are 
> matched and what gap would be filled by pcap.

The RFC's mentioned are just examples of IETF standards track
documents that specifically describe some property of packet
capture.   The purpose is to demonstrate that the IETF is
invested in defining packet capture technology.  I could
include a brief list of RFC's that are dependant on
packets for their function, including RTFM, of course!!
But I did want it to be brief.

I've been asked to simply present the problem statement, and
not necessarily present a solution, so I'll not mention pcap
except for a "draft is available" statement at the end.

[snip]

> > style mechanisms pose a significant threat to individual privacy.  
> > This is because port copy mechanisms can only copy entire 
> datagrams to 
> I would mention here that there still remains a threat to 
> privacy that should be considered thoroughly.
>

How about adding?

   port copy strategies introduce new significant threats to privacy,
that need to be addressed.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 27 Jun 2001 10:52:13 +0200

Hi Carter,

Seems like I did not phrase well. Please see my comment below.

-- Carter Bullard <[email-masked]> wrote:

 [snip]
> except for a "draft is available" statement at the end.

My point is that when proposing something on the RMON list,
we should state, that and why current RMON does not cover this
already, particularly that current RMON does not meet the
requirements of the applications you mentioned.

Best wishes,

    Juergen

---

From: "Carter Bullard" <[email-masked]>
Date: Wed, 27 Jun 2001 09:03:53 -0400

Hey Juergen,
   Now I understand.  I was trying to use RFC-2613 to
reiterate that RMON had problems and that vendors were
implementing their own technology to get around RMON's
shortcoming.  Since RFC-2613 was created by RMONMIB, I
was hoping they would remember that problems exist ;o)

   I'll add a phrase that RMONMIB also doesn't meet
the requirements, but I'll not explain why.  I want
this to be short and to the point, to get interest and
to highlight the problem.  I don't want to introduce
debatable issues that could simply confuse the discussion.

Definitely thanks for the comments!!!!

Carter

Carter Bullard
QoSient, LLC

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

> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Wednesday, June 27, 2001 4:52 AM
> To: Carter Bullard; [email-masked]
> Cc: [email-masked]; 'Georg Carle'; 'Tanja Zseby'; 
> 'Sebastian Zander'; 'Marcelo Pias'
> Subject: RE: Packet capture problem statement
> 
> 
> Hi Carter,
> 
> >> what degree these requirements are matched and what gap would be 
> >> filled by pcap.
> >
> > invested in defining packet capture technology.  I could include a 
> > brief list of RFC's that are dependant on packets for their 
> function, 
> > including RTFM, of course!! But I did want it to be brief.
> >
> > I've been asked to simply present the problem statement, and not 
> > necessarily present a solution, so I'll not mention pcap 
> except for a 
> > "draft is available" statement at the end.
> 
> we should state, that and why current RMON does not cover 
> this already, particularly that current RMON does not meet 
> the requirements of the applications you mentioned.
> 
> Best wishes,
> 
>     Juergen
> 
> 
>

---

From: "Carter Bullard" <[email-masked]>
Date: Wed, 27 Jun 2001 13:08:20 -0400

Gentle people,
   I will not be able to send the problem statement to
RMONMIB until Monday, as my plane is leaving soon, and
I still have a change or two to make.

   I will be sending it out on Monday, so if you have
comments, still.  Please do send them this way before
the end of the week.

Thanks!!!!

Carter

Carter Bullard
QoSient, LLC

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