Subject: Re: [pcp] Another suggestion - Re: Resolving contentious issue #1: Epoch

From: Stuart Cheshire <[email-masked]>
Date: Sat, 23 Oct 2010 11:02:57 -0700

On 23 Oct 2010, at 4:02 AM, Reinaldo Penno wrote:

> I suggest asking a different question to resolve many outstanding  
> issues.
>
> I suggest polling the WG to reach rough consensus if the protocol  
> should rely on permanent storage to work.

More specifically:

Should the protocol require *all* implementations to have infallible  
permanent storage?

Should the protocol have no provisions for recovering from real-world  
errors and quickly converging back to correctness, because we assert  
that real-world errors are not allowed to happen?

To make an analogy with DHCP: If a DHCP server allocates an address  
to a client, and the client does RFC 5227 Address Conflict Detection  
and determines the address to be already in use, then the client  
sends a DHCP DECLINE to the DHCP server. Why does DHCP DECLINE even  
exist? A DHCP server is not supposed to allocate the same address to  
two different clients. Why not just assert that this can never happen  
and forget about it? The DHCP designers believed in what I call  
"convergence to correctness". You can't stop errors and mistake and  
state loss from happening, but you can make the system self-healing  
after such errors happen. If you swap your home gateway for a new  
one, the new one may not know about all the leases the old one handed  
out, but because of they way DHCP is designed this is not fatal, and  
the network soon self-heals itself back to a sane working state.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 22:37:47 +0200

In your previous mail you wrote:

   More specifically:

=> IMHO it must require stable storage when the customers (the side
which is behind the NAT, not the side connected to the Internet) don't
trust together, i.e., when an attacker can be one of the customers.

   ...

=> there are two places (client and server) and perhaps third (IWF)
with state so there are synchronization/recovery problems to solve.

   To make an analogy with DHCP:

=> I am afraid DHCP is not the best example of a secure protocol.

   If a DHCP server allocates an address  
   two different clients.

=> DECLINE is not the solution to this problem (yes, DHCP is supposed
to not allocate the same address to two different clients at the same
time, and yes, some clients use addresses which are not allocated
by DHCP. I know at least two cases: configuration error of the DHCP
server, i.e., the server is configured to allocate addresses which
are already in use, and clients which can't communicate with a DHCP
server and which reuse last allocated addresses: it can be considered
to be better than to use no address and with the standard behavior
of DHCP servers it lowers the probability of a conflict, i.e., it
is less worse than to pick up an address at random).
 BTW the DECLINE is really a recovery mechanism: without it the
server should allocate the same address. We have the same in PCP
(what I called the amnesiac client case) but without recovery.

Regards

[email-masked]