Subject: [core] The CoAP Ping

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Nov 2012 10:59:53 +0100

Klaus came up with a way to "ping" CoAP servers:
Send them an empty Confirmable message, i.e. with code=0 and no payload.

According to the letter of 4.2 in coap-12:

   A Confirmable message
   always carries either a request or response and MUST NOT be empty.  A
   recipient MUST acknowledge such a message with an Acknowledgement
   message or, if it lacks context to process the message properly
   (including the case where the message is empty or has an encoding
   error), MUST reject it; rejecting a Confirmable message is effected
   by sending a matching Reset message and otherwise ignoring it.

... the server MUST send an RST message.

Both messages are 4 bytes and are correlated by the Message ID; a great basis for a "ping" type interaction.
(And there is no amplification, making this less useful in an attack.)

I wrote a little tool to make use of this:  coaping

$ coaping coap.me 5683 0.5 3
Trying 3 times with coap.me at port 5683, waiting 0.5 seconds max:
  0 13.3 ms 2001:638:708:30da:221:70ff:fe46:17d3
  1 3.6 ms 2001:638:708:30da:221:70ff:fe46:17d3
  2 2.4 ms 2001:638:708:30da:221:70ff:fe46:17d3

To install, just type this (should work on any modern Linux/Unix/OSX, more work on Windows):

  gem install coaping

(or "sudo gem install coaping" if you need additional permission).

Now the interesting questions for the WG:

1) Are we interpreting coap-12 right here?

e.g., vs0.inf.ethz.ch sends back an empty ACK, not a RST.

More importantly,

2) is this the right thing to require of a server?  Or should the spec change?
Should we have ping-like functionality?  Should that ping be based on something else?
Do we need a more elaborate ping?  A traceroute? :-)

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 20 Nov 2012 12:24:51 +0200

> Send them an empty Confirmable message, i.e. with code=0 and no payload.

Background: When the host in a CoAP URI is a DNS name, resolving the
name can lead to multiple IP addresses. When applying the Happy
Eyeballs algorithm [1], there is a need to determine a "winning
connection". DTLS aside, we don't have a connection setup handshake
that could be used for this. It's also not a good idea to make actual
requests to the server, in particular if the method is POST, since the
server likely does not deduplicate requests that it receives on
different IP addresses. So I was looking for a harmless way to probe
an IP address and port for a CoAP server, which the current behaviour
specified in -coap seems to perfectly provide.

Klaus

[1] http://tools.ietf.org/html/rfc6555

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 22 Nov 2012 09:44:17 +0000

> 1) Are we interpreting coap-12 right here?
Yes, in my view - the text mentions the empty message case explicitly.

> 2) is this the right thing to require of a server?  Or should the spec change?
Suppose we change the spec to let the server not respond to empty CON message.
Then I can still 'ping' it by sending a malformed ("encoding error") CoAP CON message.

So it would not matter much I assume whether the server responds to empty CON messages or not?
The ping function would still be there.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Tuesday 20 November 2012 11:00
To: [email-masked] WG
Subject: [core] The CoAP Ping

   A Confirmable message

  gem install coaping

More importantly,

Grüße, Carsten

_______________________________________________
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.