Subject: [core] Possible false-duplicate detection

From: Maciej Wasilak <[email-masked]>
Date: Fri, 21 Sep 2012 14:08:56 +0200

Hello,

with current CoAP draft if two nodes send requests and responses to each
other (both acting as client and server), there is a small chance that
valid incoming request will be identified as a duplicate of an earlier
response. It may happen when Node randomly generates the same Message ID
for Request, that Node 1 generated earlier.

                         Node 1                 Node 2
                            |                     |
                            |  Request1 [0x7d34]  |
                            +-------------------->|
                            |                     |
                            |  Response1 [0x7d34] |
                            |<--------------------+
                            |                     |
                            |  Request2 [0x7d34]  |
                            |<--------------------+
                            |                     |

Request 2 will be dropped as a duplicate if it arrives up to 256
seconds after response 1.

Probability of such event is initially very low, but it raises with
each request (so if nodes constantly send requests to each other it
might become a problem).
Should the implementation protect against it?
Best regards
Maciej Wasilak

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Sep 2012 14:56:23 +0200

Hi Maciej,

yes, that risk is intrinsic in randomly generating message-IDs.
Section 4.4.2.3 of draft-ietf-lwig-guidance-02.txt contains some recommendations on choosing message-IDs.

If you do need to go random for some reason (e.g., no memory for keeping per-peer counters even for EXCHANGE_LIFETIME), you could randomize the source port (and, possibly, even the source IP address) as well, turning the probability of a false positive from 1e-5 to 1e-9.  By choosing a different token, you can detect the false positive with very high probability, but (for POST) I haven't really thought about recovery strategies that would fully maintain "at-most-once" semantics.
In many cases with very simple clients (which only ever send one kind of request), the damage may just be a lost update (if this is for POST), or simply getting a copy of old data (if this is for GET and the server does buffer the old response, which many don't).

Grüße, Carsten