Subject: Re: [core] Coap-07 deduplication rules - clarification needed?

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 4 Oct 2011 09:57:15 +0200

Dear Klaus,

thanks for responding and clarifying.

> The text is written in the scope of one client communicating with one
> server, i.e. duplicate detection must be performed within the scope of
> the respective client.

I think this scope is not immediately apparent in the current text. Section 4.1 as a whole does not have this scope, which I deduce from the text "related to a confirmable message by means of a Message ID along with additional address information of the corresponding end-point". The "additional address information of the corresponding end-point" seems to indicate the scope of the section is multi-client. Then we should say it with the same clarity for duplicate detection, e.g. change the text to:

   A recipient MUST be prepared to receive the same confirmable message
   (as indicated by the Message ID and additional address information of the corresponding end-point) multiple times, ...

This is better but it still some information is missing, see below. (PS. I interpret the bracketed text as a definition of what the word "same" in the sentence before means.)

> With NoSec, a client is identified by IP source address and UDP source
> port, so this (3.).

Ok it's clear. But this behavior is somehow only specified for Section 5 (request/response level) and not for Section 4. If implementations are supposed to do this in uniform fashion, it is best to mention this in Section 4 also, for use in CON/ACK matching and duplicate detection. And a reference to Section 10 would also be needed to point out that this matching depends on security mode, similar how it's done in Section 5.

Would you agree?

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: Thursday 22 September 2011 17:11
To: [email-masked]
Subject: Re: [core] Coap-07 deduplication rules - clarification needed?

Esko Dijk wrote:
> I noted that section 5.3 has detailed rules for request/response matching
> which include Message ID, IP address and UDP port matching.
>
> For duplicate detection such rules are not specified so well.  The relevant
> text I found is:

The text is written in the scope of one client communicating with one
server, i.e. duplicate detection must be performed within the scope of
the respective client.

> 3. Consider Message ID, IP source address and UDP source port.

With NoSec, a client is identified by IP source address and UDP source
port, so this (3.).

With other security modes, the client may be identified by
certificate, key, dtls session, ... in addition to or instead of IP
source address and UDP source port. But duplicate detection is not
necessary if the security mode prevents replay attacks.

Klaus
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 4 Oct 2011 10:41:21 +0200

Esko Dijk wrote:
> I think this scope is not immediately apparent in the current text.

You're right; the text used to have this scope until it was "fixed" as
part of ticket #151. This change was obviously not complete; I'll
reopen the ticket.

> (PS. I interpret the bracketed text as a definition of what the word "same" in the sentence before means.)

Yes.

> Ok it's clear. But this behavior is somehow only specified for Section 5 (request/response level) and not for Section 4. If implementations are supposed to do this in uniform fashion, it is best to…

Yes. Please create a ticket.

Thanks,
Klaus