Subject: [core] Ticket #394 - CoAP over TCP: Server name indication

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 25 Mar 2016 20:05:09 +0100

In https://trac.tools.ietf.org/wg/core/trac/ticket/391 Klaus provided
feedback for the CoAP over TCP draft and wrote:

"
Should the FQDN of the server be set during connection setup (e.g.,
using the TLS Server Name Indication (SNI) extension), or should the
FQDN of the server be specified in each request?
"

The FQDN for the SNI is set during the TLS/DTLS handshake (in the
ClientHello). The client cannot convey the SNI later in the exchange.

The SNI is most often used in hosting deployments where multiple virtual
servers are run on single IP address.

Ciao
Hannes

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 28 Mar 2016 18:27:04 +0200

> ClientHello). The client cannot convey the SNI later in the exchange.

In CoAP, we have the Uri-Host Option [1] which can be included in CoAP
requests to indicate the FQDN of the server. In CoAP over UDP a client
can target a different virtual server with each request.

In CoAP over WebSockets, the virtual server is specified during the
WebSocket handshake in the Host header field. The Uri-Host Option is
therefore not needed. A client wishing to talk to multiple virtual
servers running on the same IP address has to open one WebSocket
connection to each virtual server. (Please correct me if I'm wrong.)

In CoAP over TLS we have the SNI extension, so I would expect that
CoAP over TLS behaves like CoAP over WebSockets: no Uri-Host Option in
requests, one connection to each virtual server.

The question is what CoAP over TCP should do. One option is to include
a Uri-Host option in each request, like CoAP over UDP. Then only one
connection would be needed for all virtual servers running on the same
IP address. Another option is to add a minimal handshake-like message
to CoAP over TCP.

I have no particular preference, but I think it's important that CoAP
over TCP, TLS and WebSockets are consistent and no protocol behaves
wildly different from the others.

Klaus

[1] https://tools.ietf.org/html/rfc7252#section-5.10.1