Subject: charter goal #2b

From: Juergen Quittek <[email-masked]>
Date: Thu, 08 Feb 2001 08:36:51 +0100

The second part of charter goal #2, the remote packet capturing,
is easier to discus than the first part, because some concrete
suggestion have been made already in the drafts for the BOF:

>    Define a distributed metering architecture to support metrics
>    defined within the IPPM framework, e.g. one-way delay,
>    connectivity, one-way loss rate.  This architecture will
>    include remote packet capture, and will address privacy
>    concerns such as the inadvertant disclosure of user
>    information and the need to authenticate and authorise
>    access to captured data.

Remote packet capturing can be seen as just one component of a
distributed metering architecture. I think this topic would be
a worthwhile goal of a future RTFM2 WG, even if we decided not
to work on a distributed metering architecture (I don't suggest
this). It is not a big effort like the architecture and some
technical solutions exist already. Work on this goal could be
just standardizing LFAP, probably with some modifications,
or following thesuggestions in the drafts for the BOF, or
something different.
Two aspects of remote packet capturing are to be covered:
configuring remote packet capturing devices and transmitting
captured packets (or just their headers).
 
- What would be the resulting benefit?
  There are already some solutions concerning or related to remote
  packet capture, for example Cisco netflow or LFAP from cabletron.
  However there are no standards yet. Furthermore, there is an
  increasing need for remote packet capture, for example for the
  applications I described in my previous mail on the distributed
  metering architecture.

- Is it or does it appear to be technically feasible?
  Yes, the existing proprietary solutions demonstrate this.

- Is "now" the right time to work on this item?
  I wonder why this topic has not already been solved by this IETF
  for a long time. For me, "now" is already very late.

- Can we expect sufficient support by technical,
  experts, i.e. who is willing to contribute?
  Yes, we have some people together, who are willing to work on
  this and on the BOF also LFAP people offered support.

- What would be the expected output documents?
  I would expect two output documents: A protocol for transmitting
  information about captured packets and a document (a MIB?) on
  configuring packet capturing devices.

- What timeframe would be appropriate?
  I guess, a year would be sufficient.

- Is the IETF the right place for this item?
  Yes, certainly.

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd., C&C Research Laboratories   Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: "Carter Bullard" <[email-masked]>
Date: Thu, 8 Feb 2001 19:23:12 -0500

Hey Juergen,
Thanks for driving the discussion.

>   applications I described in my previous mail on the distributed

Not to take away from your benefit section, or any part of 
your discussion, but the Packet Capture Group in RMON is a much
better example for prior work in the area of remote packet
capture.  It is an IETF standard and has been implemented by a
large number of vendors, so there is precedence for working
on the technology.  The issue is that the RMON architecture
has fundamental shortcomings.  RMON's local storage requirement
is the biggest one, as it places HUGE resource issues on probes,
and the limited filter support doesn't have flow based semantics
so you can not automatically capture the return traffic for a given
flow.

Neither Netflow nor LFAP have any support for packet capture, nor
do I see a role for either in the work that needs to be done
to realize this part of the technology.

    Yes, certainly.

>     Juergen

Carter

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

[email-masked]
Phone +1 212 813-9426
Fax   +1 212 813-9426

---

From: George Michaelson <[email-masked]>
Date: Fri, 09 Feb 2001 11:11:54 +1000

here'z another one.

Packet capture is going to trigger the 'mandated access point for tapping'
debate. Some people live in countries considering this as a requirement for
ISPs, who are claiming (amongst other things) can't be done.

But if RTFM goes down this path to do monitoring and metrics for 
self-referential reasons, somebody is going to point the finger this way.

cheers
	-George

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 09 Feb 2001 09:32:26 +0100

> Carter Bullard wrote:
 [...]
> to realize this part of the technology.

Well, yes and no. They do packet capturing and report a summary.
I consider this also as one of the requirements for packet capturing.
However, you are completely right, that they do not offer sufficient
means for reporting details on single captured packets. I could imagine
to extend LFAP in this direction, but I doubt that this would be the
right idea.

    Juergen

---

From: "Carter Bullard" <[email-masked]>
Date: Fri, 9 Feb 2001 06:37:17 -0500

Is this a technical issue?

Carter

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of George Michaelson
> Sent: Thursday, February 08, 2001 8:12 PM
> To: 'RTFM mailing list'
> Subject: Re: charter goal #2b 
> 
> 
> 
> here'z another one.
>

---

From: "Carter Bullard" <[email-masked]>
Date: Fri, 9 Feb 2001 07:00:12 -0500

Hey Juergen,
   I would like to differentiate packet capture from packet
processing.  Cisco does not implement Netflow in its switches
by creating a duplicated stream of packets and processing
them in parallel within its routing or switching function.
Nor do most integrated RMON implementations involve copying
packets in order to do their accounting.  Although it may
sound like a very subtle distinction to differentiate packet
stream duplication and packet processing, it actually is very
important to understanding what is being proposed.

   It would probably be more appropriate to call the mechanism
remote packet duplication, as it could be confused with
multicasting.  But a general packet duplication mechanism
may be the right way to describe it.

   I also believe that packet processing should be disjoint
from packet stream duplication, so I do not see any reason for a
metering or summary function to be a part of the proposed
remote packet capture facility.  This would be the job of an
RTFM or RMON probe that could be coupled to the RPCAP mechanism.
No sense in making it more complicated than it should be.

Carter

Carter Bullard
QoSient, LLC

[email-masked]
Phone +1 212 813-9426
Fax   +1 212 813-9426

> Behalf Of Juergen Quittek
> Sent: Friday, February 09, 2001 3:32 AM
> To: Carter Bullard
> Cc: 'RTFM mailing list'