[cap-talk] controversial article

[Matej Kosik]

Mark Miller wrote:
> 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.
> 
> 

I have added a conclusion where I try to summarize the possiblity to
achieve defensive correctness also in other environments:

<conclusion>
It was already
shown~\cite{Shapiro03vulnerabilitiesin} how to
achieve defensive correctness among concurrent
processes interacting via synchronous rendezvous.
The proposed updates of the Pict programming
language enable us to achieve defensive
correctness among concurrent processes
interacting via asynchronous message-passing over
channels. It is an open challenge how to update
other programming languages supporting other
programming paradigms (functional, procedural,
object-oriented) in a similar way. In our work we
are concerned with non-distributed software
systems.  It is an open challenge how to define a
platform for building defensively correct (or at
least dependable with availability determined not
by attackers but by inherent reliability of the
network infrastructure) distributed software
systems. Proposals for solutions would probably
face serious problems caused by network effect
which often represents a much stronger force than
the desire for improved quality.
</conclusion>

By "enable us to achieve defensive correctness" I mean that I consider
scenarious:
- what services given server wants to provide
- what could clients try to do
and whether in a given case I have enough mechanisms to defend server
from any kind of client.

By "problems caused by network effect" I mean that if it turns out that
we need DSR, it would probably be too optimistic to assume that it would
be adopted just because (even it were true) it enables us to build
systems that have higher quality. If quality is not determing factor of
the revenues, quality may even be harmfull (less revenue for software
vendor).