[cap-talk] controversial article

[Mark Miller]

On Sun, Jul 5, 2009 at 4:48 AM, Ben Laurie<benl at google.com> wrote:
> By the definition I saw somewhere in this thread, the fact that there
> is no hard guarantee of service seems orthogonal - what you are after
> is that an attacker can't deny service, which seems quite different to
> me (i.e. if the attacker cannot alter the reliability of the network
> then, indeed, there is a chance service will not be delivered, but it
> was not caused by the attacker).
>
> Even if an attacker can alter reliability, they still can't _deny_
> service, just slow it down.
>
> That is, intuitively, the expected time a service takes to deliver has
> a component that is governed by the reliability of the network.
> Decreasing reliability increases expected time, but not to infinity.

Either your suggestion corresponds to an approximation of defensive
correctness I stated at the beginning of this thread:

> * Distributed defensive correctness in the absence of
>   spontaneous partitions or crashes, where "spontaneous"
>   means, not caused by the actions of the programs we
>   are concerned with.

or you are saying that we should assume a guarantee that all messages
are eventually delivered, in which case the network is ultimately
reliable in the relevant sense; with just a high variance in delivery
times.

The first perspective is consistent with viewing the network routing
fabric as outside our TCB, in which case it may conspire with the
attacker to never deliver us any traffic. For example, a dissident
behind a Great Firewall may be forever denied traffic. The second
perspective requires us to include the network routing fabric in our
TCB, which seems like a much stronger assumption than what people
normally mean by "unreliable networks".


> So, to make this real-world, should we instead talk about expected
> delivery times? Denial of service would be increasing the expected
> delivery time to infinity. Anything else would not be denial of
> service.

At which point the discussion shifts from correctness per se to
performance and quality, as it should. But let's not confuse that with
correctness.


-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM