Subject: Re: [Raven] Nevermore ...

From: Vernon Schryver <[email-masked]>
Date: Wed, 3 Nov 1999 11:19:49 -0700 (MST)

> My contention is, not only should IETF *NOT* develop protocols with
> methods that support wiretapping, IETF should develop protocols that are
> wiretap resistant.  Such as requiring NAT/PAT-style source-IP rewriting in
> the
> packet headers at each hop to DENY auditability.  And
> decryption/re-encryption
> between network nodes and out-of-order (vs. FIFO) forwarding of packets to
> dissuade traffic analysis.

A 1000 Gbit/sec router that can do "NAT/PAT-style source-IP rewriting"
for everything that passes sounds like a far more interesting box than
the current 1000 Gbit/sec routers.  Never mind the amount of state required
to remember which addresses and port numbers have been rewritten into
which new values, nor how it knows when to retire the state.  Forget about
the real life problems of afflict RSVP, multicasting, and friends.  Just
think about the address space problems.  From which and to which address
and port spaces do you map, and how do you keep it all straight?

How do you ensure that all routers through which a TCP/IP connection might
be routed at one time or another do consitent mappings, in a way that only
the good guy routers and none of the bad guy spies can predict?

How do you do routing in such a network where every address is purely
local?  Other than pure source routing, I don't see how, and that would
somewhat defeat the purpose of hiding things from snoops.

Nver mind that such mapping would do no more than slightly inconvenience
the naughty spies.  It would be a lot easier for a snoop to compare the
gozeintas and gozeoutas and figure out how interesting streams are being
routed in real time than it would be for the router to figure out and
maintain the mapping.

 ..........

Wouldn't it be swell if these were still the old days when IETF
mailinglists were not filled with technical statements like the following?:

  - a naughty HTTP server "loaded code" that "captured" the HTTP client's
      IP address.  (silly me, I thought that TCP/IP requires that both
      the HTTP/TCP/IP server and the HTTP/TCP/IP client know each other's
      IP address from before the first data bits are exchanged)

  - requiring all routers to do "NAT/PAT-style source-IP rewriting"

  - causing routers to not forward packets within streams FIFO 
     (It's sad that the many people who have dealt with the real life
     TCP/IP problems caused by out of order packets are just too stupid
     to use the trivial solution, whatever it is.)

  - a 100 MHz Ethernet being sufficient to capture all of the VoIP traffic
      for even a small nation like The Netherlands.

  - that timestamps and digitally signatures on a wiretap are sufficient
     to keep naughty police from falisfying evidence, from generating
     their own sounds and then getting valid timestamps and signatures on
     them, including by playing sounds from other, legitimately timestamped
     and signed recordings.

  - that real world tapping mechanisms would be free of bugs and security
     holes that could be exploited by "organized crime" and other chimeras.

Or at least that those who said such things would feel so badly afterwards
that they would retire from the fray for a few days?

Vernon Schryver    [email-masked]

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

---

From: "Brett Wooldridge" <[email-masked]>
Date: Wed, 3 Nov 1999 15:18:40 -0600

----- Original Message -----
From: Vernon Schryver <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 03, 1999 12:19 PM
Subject: Re: [Raven] Nevermore ...

> > the packet headers at each hop to DENY auditability.  And
> > decryption/re-encryption between network nodes and out-of-order
> > (vs. FIFO) forwarding of packets to dissuade traffic analysis.
>
> the current 1000 Gbit/sec routers.

Really?  Current routers are capable of doing this already.  The Cisco 7500
supports NAT, and is capable of 1M pps (OC-12 speeds).  The Cisco 12000GSR
is capable of OC-48 speeds, and is technically capable of, though doesn't currently
support, NAT for every packet.  The only reason NAT isn't on the 12000GSR is
that its positioned as a backbone switch, not something a company would use for
concentrating IPs.  Still, the fact exist that routers today ARE capable of Gbit
speeds along with packet rewriting.

> Never mind the amount of state required to remember which addresses
> and port numbers have been rewritten into which new values, nor how it
> knows when to retire the state.  <snip>  Just think about the address
> space problems.  From which and to which address and port spaces
> do you map, and how do you keep it all straight?

While seemingly overwhelming, all of these problems must be overcome
even in any mid-scale router than supports NAT.  Yes, every connection gets
assigned a new (singular) IP and port, etc.  Mapping entries take up a
suprisingly small space -- the 7500 does it all in 128M of RAM, and the
12000 Gbit switch comes with 128M expandable to 256M.  Even if it took 1G
of RAM, we're talking about a $150,000+ switch here.  Cisco even supports IP
pools for NAT, so exhusting ports is not even an issue.

> the good guy routers and none of the bad guy spies can predict?

The idea outlined ensures perfect forward secrecy.  Each router, even one
inserted in the chain by the NSA, sees the source of the packet as the
machine before it, denying an audit trail.  Traffic entering a router is decrypted
and re-encrypted to ensure that the "gozeintas and gozeoutas" never
match.  You must have missed that.  That along with out-of-order delivery (I know, it occurs already) foils all by the most
hardcore-accessible-to-maybe-
three-governments traffic analysis (even then I'm not convinced it's vulnerable).

> somewhat defeat the purpose of hiding things from snoops.

I'm not sure I catch your drift.  Other than to say, one can use NAT even
between segments of an internal network.  Are you concerned that you
can't effectively "route", if all packets appear to come from the same
IP?  Routing from A to B is based off the destination IP, not the source,
otherwise NAT wouldn't work at all.  If you are speaking of a network
in which there is no router (thus no NAT), you're right, no guarantee of
privacy, other than simple encryption.  Oh well.  But the 'I' in IETF stands
for Internet, not Intranet.

> routed in real time than it would be for the router to figure out and

If I didn't address the concerns above, let me know.  In any case, my major
point was, IETF should to everything technically within it's power to ensure
security.  If that means less than perfect, but highly inconvenient to untangle,
secrecy, fine.  It's a start.  All that's required for that is encryption and not
tagging packets with serial numbers.  IPv6 has the former, what some of
us here are lobbying for is the latter.

Brett Wooldridge

---

From: "Lyal Collins" <[email-masked]>
Date: Thu, 4 Nov 1999 18:48:27 +1100

> > > wiretap resistant.  Such as requiring NAT/PAT-style source-IP

This may lead to domestic laws that permit/emcourage/mandate covert
modification (either hardware or software) of your PC/worskation/access
device to assist with data recovery.

Given the stability of the tools we try to work and play with, such
modifications are unlikely to improve the situation, nor is there any
assurance that
- the "modification" will be removed after the expiry of the warrant.
- others cannot detect and use the "modification" to also listen in to your
data streams,
- others cannot detect and misuse the "modification" to gain further,
privileged access to your system(s).

Regards,
Lyal

---

From: "Brett Wooldridge" <[email-masked]>
Date: Thu, 4 Nov 1999 17:56:47 -0600

----- Original Message ----- 
From: Lyal Collins <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 04, 1999 1:48 AM
Subject: RE: [Raven] Nevermore ...

> device to assist with data recovery.

No more so than the people possesing strong encryption will do.

I don't know if you've heard, but the FBI has admitted to having a "virus"
called D.I.R.T. that they infect a "suspects" machine with (one would hope
with a warrant). It is like Back Orafice, in that it allows then to capture your
keystrokes and/or transfer files back and forth.  [It's the "forth" that scares
me, too easy to plant evidence on your machine, as American cops are
want to do].  There is no protection against this kind of "inside" attack --
virus detectors can't find DIRT because nobody's seen it.

Basically, what you fear already exists.  There's no reason to beleive that
just because they have wiretap, that that would disuade them from developing
other "investigative technologies" such as you mention.  So, let's not let that
stop us from making our protocols as secure as possible.

Brett Wooldridge

---

From: "chefren" <[email-masked]>
Date: Fri, 5 Nov 1999 01:43:27 +0100

On 4 Nov 99, at 17:56, Brett Wooldridge wrote:

..

> stop us from making our protocols as secure as possible.

The architecture of the FBI attack makes your defense seem 
quite silly to me...

I think if D.I.R.T. like breaches of privacy aren't 
regulated yet they should definitely be regulated as fast 
as possible.

+++chefren

p.s. Is there a place where I can read about the FBI 
admission?
= =
Verdien 100 Euro bij aanbrengen van een nieuwe
klant voor een website: http://www.ii.nl/premie

---

From: "Lyal Collins" <[email-masked]>
Date: Fri, 5 Nov 1999 15:36:18 +1100

You're right - there are a multitude of toolsthat allow, or assist in the
process of data stream tapping.
_All_ the remote access tools (BackOrifice, NetBus, DIRT, PCAnywhere
Dell/Compaq remote support services at al) contribute, or _may_ contribute
to unaudited, uncontrolled access to data streams.

Building in relaible auditing capabilites to these tools, so that I (or a
neutral, trusted  umpire/ombudsman) can verify that any access to _my_ data
streams was properly authorised, and started and stopped as per the
appropriate local/domestic authorisation process, is a desiable goal, I
think.

Regards,
Lyal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Brett Wooldridge
> Sent: Friday, 5 November 1999 10:57
> To: [email-masked]