[katzenpost] mixnet notes from visit to KU Leuven

[Yawning Angel]

Hello,

Note: A bunch of this will be a rehash of what I've said before,
because the open questions haven't changed all that much.  Sorry for
being repetitive, but now that more people have joined in on the
conversation, it's good to get everyone on the same page.

On Fri, 09 Feb 2018 02:14:54 +0100
Kali Kaneko <kaliyuga at riseup.net> wrote:
> In reply to some transmogrified bits by yawning at schwanenlied.me on
> the 2018-02-08 16:38:01: 
> >    Right now there is one (network wide) parameter `LambdaP`, that
> >    specifies the mean of a Poisson distribution (in seconds).  The
> >    client will attempt to send traffic (be it cover or otherwise)
> >    by sampling from this distribution.
> > 
> >    Note: This is distinct from the (network wide) `Lambda` which
> >    is used to derive mixing delay.
> > 
> >    Should there be separate parameter(s) for decoy traffic?  If
> >    so how should it be parameterized?  
> 
> At the risk of talking nonsense, I'll venture here than ideally
> this should be parametrized dinamically by the mix authority. I do
> not know much about proper theoretical approaches, but my gut
> feeling (and what I got from the talk with Claudia) is that
> whatever decoy traffic modelling we end up using needs to be
> adjusted dynamically in response to some property of the global
> system (or otherwise this will be getting into some absurd delay
> vs. bandwith tradeoffs - did you get to talk about this in the
> other day's call?).

`LambdaP` is something that is set by the authority, and can be
updated per document. If there were to be another set of parameters
added (LambdaL, LambdaD to use those in the Loopix paper), then they
would be network wide as well.

Making the client sample from/honor additional distributions is trivial
and would require minor changes to the loop that drives outgoing sends,
but from my reading of the paper, a client that is entirely
parameterized by a single lambda value (as in will send payload,
loop or discard traffic based on intervals sampled from Pois(LambdaP))
with behave identically.

> This leads me to think that the authority could publish some
> aggregate of the total traffic, does this make sense? (inputs could
> be received via a mix path to an agent).

At that point it's better for the authority to publish the
parameterization directly (which is current behavior).  The open
questions here that requires more research are (and have been):

 * How will the authorities gain a realistic view of the current state
   of the network in terms of congestion and capacity?

 * How will the authorities gain a realistic view of the network in
   terms of anonymity provided (and cover traffic required to hit a
   given target)?

   (This is what I suspect there will be papers on.)

 * How to parameterize clients to not overload the network while
   providing "sufficient" anonymity?

 * Should we lower the voting period?  There's other problems
   associated with this in terms of the network being resilient to
   transient issues, but not doing so results in a rather long interval
   between parameterization updates.

> >  * What fraction of client decoy traffic should be loop vs
> >    discard?
> > 
> >  * What actions if any should a client take if loop decoy traffic
> >    fails to loop?  How is the client supposed to combat false
> >    positives?  
> 
> I'd say fail close: after a statistically meaningful threshold
> client should block normal operation. then it could check some view
> of the health of the mixes, and report anomaly to user if network
> is healthy (but, how to distinguish that from congestion?)

Clients measuring congestion is "hard", because the standard mechanisms
for measuring congestion (ie: packet loss) is detected a considerable
amount of time after the loss event occurs.  It is not immediately
obvious to me how to suppress false positives.

> > General questions:
> > 
> >  * How should a mix behave when it encounters a packet with
> > exactly `0` delay?  
> 
> Can a well-behaved client choose 0 delay? I was assuming that the
> delays were an open interval. If so, the only application for this
> that I can see is to measure performance.  If those assumptions are
> tru, I'd say drop as badly formed packets, *unless* the mix is
> running with some kind of debug flag. 

Conformat clients will draw an integer delay in milliseconds that falls
into [0.0,MaxDelay], where MaxDelay is yet another parameter published
by the authority that clips off the long tail.

With the current default test value, a 0 ms delay will occur
~0.0125% of the time due to rounding.  I can and will change the
client behavior to enforce delay >= 1 ms shortly, but a delay of 0
should probably be allowed with the caveat that "if clients choose to
specify it, they get exactly what they deserve".

Ultimately, my view is that nodes should make a best possible effort to
honor the client delay, and only drop well formed packets to shed load
or manage network congestion, though I am open to being convinced
otherwise.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.mixnetworks.org/pipermail/katzenpost/attachments/20180209/db48d1ec/attachment.sig>