Subject: RE: [Raven] Summary of Observations

From: Mark McCutcheon <[email-masked]>
Date: Tue, 2 Nov 1999 10:29:46 UTC-0800

On 1 Nov 1999 23:17:50 "chefren" <[email-masked]> wrote:

> I wasn't promoting any companies design I was definitely 
> promoting a fully opened design tapbox that anyone could 
> construct below what was estimated by another to $3000.
>
> Open hardware architecture and open source software, closed 
> and sealed hardware box in the field and anyone can check 
> if someone has tampered with it.
>
> The over-all architecture isn't ours, it's what's required 
> in The Netherlands for phone-taps. The IP part of it is 
> "new", well thought out I think by multiple parties (law 
> enforcement agencies, communication providers and 
> suppliers but not "high tech" in any way.

These postings regarding a sealed-hardware, open-source software
"tapbox" are a complete red herring with respect to the purposes of
this list:

a) The IETF is not in the business of defining hardware
   architectures.

b) It amazes me that a T1/E1 connected "tapbox" is considered
   useful in the Netherlands, at least at carrier level.  Though
   Canada has only about twice the population of the Netherlands,
   this would be considered 1980's technology here.  Suitable
   perhaps for tapping the digital communications of a small
   business, but hardly a carrier or ISP.  The phrase "....but
   not `high tech' in any way" certainly IS true.

   The vendor engineers who wish to specify tap-friendly
   protocols for VoIP represent multi-gigabit-per-second switch
   manufacturers.  Tapping technology they build into their
   hardware will owe nothing to this quaint fiction, but rather a
   lot to the US FBI's demanded capacity requirement.  This has
   at times run as high as the ability to tap 1% of the system's
   "engineered capacity" simultaneously.

c) As Thomas Junker and others have pointed out, the discussion
   issue for which the IESG created this mailing list is NOT what
   means should be designed to facilitate authorized wiretaps,
   but whether IETF WGs should be permitted to develop protocols
   and publish standards which have as their primary purpose
   facilitation of wiretapping or other law enforcement
   activities.

So let's hear no more of this silly "tapbox", it's nothing more
than a diversionary discussion.

Mark McCutcheon

_______________________________________________
raven mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/raven

---

From: "chefren" <[email-masked]>
Date: Tue, 2 Nov 1999 22:33:58 +0100

On 2 Nov 99, at 10:29, Mark McCutcheon wrote:

..

> a) The IETF is not in the business of defining hardware

I agree but it seems usefull to explain how the auditable 
tcpdump standard could/should be used.

>    not `high tech' in any way" certainly IS true.

Here you are, in the explanation some day's ago I explained 
how it should work: The communication provider should route 
the to be tapped data allong the low-cost 10-100Mbit 
ethernet adapter of the tapbox.

After such a short explanation things become simple isn't 
it?

>    lot to the US FBI's demanded capacity requirement.

IETF should like communication providers never mind about 
the message into the message. Law enforcement should figure 
out what everything could mean by themselves or pay the 
VoIP software manufacturer for a decoding program.

>    This has at times run as high as the ability to tap 1%
> of the system's "engineered capacity" simultaneously. 

So a 100MBit tapinterface is good enough. Highest cost will 
probably the extra port on the high-speed router. Don't 
forget the interface isn't designed for driftnet fishing, 
every tap should get it's own tapbox. No sweat here.
 
>    means should be designed to facilitate authorized wiretaps,

I included a hardware sketch because the general design of 
tapping this way seems quite new to most of us here.

> than a diversionary discussion.

It isn't. It's the hardware that should implement a large 
part of the auditable IETF tapprotocol.

+++chefren

=Large signature follows=

I think we need a simple architecture for a point
to point tap interface that has strong provisions
against misuse.

On one side the communication provider who only
starts tapping a specific customer or IP number
with proper warrants.

On the other side the approved tapping room.
Everything should be organized by the central
"tapping office". This office should provide
keys for strong encryption to both communication
provider and tapping room.

Law and technology should both provide as
much checks and balances as we can come up
with. Law can provide good procedures,
technology can provide technical means to
check them or force them.    

=Large signature ended, please comment me
off-line to make it better=

---

From: "Thomas Junker" <[email-masked]>
Date: Wed, 3 Nov 1999 00:59:12 -0600

> tcpdump standard could/should be used.

Thank you.  You are very kind to want to educate us.  It is *still* off-topic. 
Nor does the IETF have any role in how legal mechanisms are implemented, 
therefore no influence over how auditable "anything" could/should be used, 
since "could/should" are legal and administrative issues that each 
jurisdiction decides for itself.

> tapping this way seems quite new to most of us here.

Dutch cooking might also be quite new to most of us here, but that, too, would 
be off-topic.

> part of the auditable IETF tapprotocol.

Two paragraphs after it has once again been explained to you what the issue is 
for discussion here, you again fail to grasp the essential and not very 
complicated truth of the matter.  Read the docs.

Regards,

Thomas Junker
[email-masked]

The Unofficial Wang VS Information Center
http://www.phoenix.net/~tjunker/wang.html