1994-08-07 - Re: Latency vs. Reordering (Was: Remailer ideas (Was: Re: Latency vs. Reordering))

Header Data

From: jdd@aiki.demon.co.uk (Jim Dixon)
To: hughes@ah.com
Message Hash: ac9c5cf3cbbec381a0215c8cee0e709fa72e652bdcd37598b46514abffd1933a
Message ID: <4192@aiki.demon.co.uk>
Reply To: N/A
UTC Datetime: 1994-08-07 11:39:44 UTC
Raw Date: Sun, 7 Aug 94 04:39:44 PDT

Raw message

From: jdd@aiki.demon.co.uk (Jim Dixon)
Date: Sun, 7 Aug 94 04:39:44 PDT
To: hughes@ah.com
Subject: Re: Latency vs. Reordering (Was: Remailer ideas (Was: Re: Latency vs. Reordering))
Message-ID: <4192@aiki.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


In message <9408070005.AA17290@ah.com> Eric Hughes writes:
>    In a system that is carrying continuous traffic, random packet delay
>    is functionally identical to packet reordering.
> 
> OK.  Prove it.  Here are some difficulties I expect you'll find along
> the way.
> 
> First, "continuous traffic" is the wrong assumption; some sort of
> multiple Poisson distribution for arrival times is.

Sigh.  I say "A implies B".  You say, "not A, and so proposition is
incorrect".  In elementary logic, you are wrong.  IF the traffic is
continuous, THEN random delays introduce reordering.  The proposition
is completely obvious.	Do I really have to spell out a trivial
proof?

>						       This is by no
> means a hypothetical.  The backoff algorithms for TCP had to be
> developed because packet streams are not continuous, but bursty.

Under this modified assumption, you must remember that I proposed
that noise packets be introduced to defeat traffic analysis.  The
bursts will be smoothed out.  Not perfectly.

Many of the characteristics of TCP/IP derive from its design being
optimized for speed.  RemailerNet would give less importance to
speed, and more importance to opaqueness to traffic analysis.

[snip]
> Fourth, the problem is incompletely specified, since the distribution
> of random added latencies is not made specific.

Correct.  You assume details that have not been specified, and then
critique them at length.

>    If messages are fragmented, random delays on sending packets out is
>    functionally identical to reordering.
> 
> This is false; a system that concentrates on reordering has provably
> better average latency that one based only on adding latencies.

If a message is fragmented into N packets, and then the dispatch time
slot for each packet is assigned randomly, the packets are reordered.

[Comments deleted ignore the fact that messages are fragmented, and
so are irrelevant.]

His arguments also ignore the fact that reordering messages of different
lengths is useless as a defense against traffic analysis, suggesting that
this is polemic rather than a serious argument.

>    More importantly, RemailerNet as described defeats traffic analysis by
>    more significant techniques than reordering.  Reordering is a weak
>    technique.  
> 
> WHAT??
> 
> Anyone else listening to this: I believe the above quoted two
> sentences to be distilled snake oil.

I say again: reordering is not weak, it is irrelevant if messages are of
signficantly different lengths and are not fragmented.

>    The introduction of noise, 'MIRV'ing of messages,
>    fragmentation of messages, random choice of packet routes, and
>    encyphering of all traffic are stronger techniques.
> 
> Encyphering is necessary.  Reordering of quanta is necessary.
> 
> "MIRV" messages may actually decrease security; multiple routes may
> decrease security; fragmentation may decrease security.  Noise
> messages may not be resource effective.

>					  All the above claims require
> some justification, and I have seen nothing robust yet.

If by "the above claims" you mean the preceding two sentences, I do
agree.
-- 
+-----------------------------------+--------------------------------------+
|  Jim Dixon<jdd@aiki.demon.co.uk>  |	    Compuserve: 100114,1027	   |
|AIKI Parallel Systems Ltd + parallel processing hardware & software design|
|	     voice +44 272 291 316  | fax +44 272 272 015		   |
+-----------------------------------+--------------------------------------+





Thread