Subject: Re: [core] #391 (coap-tcp-tls): Server name indication

From: "core issue tracker" <[email-masked]>
Date: Tue, 05 Apr 2016 02:47:11 -0000

#391: Server name indication

Comment (by [email-masked]):

 Clarification from Klaus:
 http://www.ietf.org/mail-archive/web/core/current/msg06947.html

 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.

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

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  [email-masked]         |  [email-masked]
     Type:  other        |      Status:  new
  technical              |   Milestone:
 Priority:  minor        |     Version:
Component:  coap-tcp-    |  Resolution:
  tls                    |
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/391#comment:1>
core <https://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Tue, 05 Apr 2016 12:13:52 -0000

Comment (by [email-masked]):

 Related: HTTP/2 allows the reuse of connections for different origins:

     Connections that are made to an origin server, either directly or
     through a tunnel created using the CONNECT method (Section 8.3), MAY
     be reused for requests with multiple different URI authority
     components.  A connection can be reused as long as the origin server
     is authoritative (Section 10.1).  For TCP connections without TLS,
     this depends on the host having resolved to the same IP address.

 http://tools.ietf.org/html/rfc7540#section-9.1.1

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/391#comment:2>
core <https://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Tue, 26 Apr 2016 13:22:21 -0000

To indicate the name of a server in a CoAP over TCP solution scenario the
 following approaches are possible:

 1) Indicate the host option in every request
 2) Indicate the host option during a connection setup phase

 Given the connection-oriented nature of TCP it certainly makes sense to
 provide the server name indication at the beginning of the connection
 setup, similarly to what Websockets and TLS/DTLS does.

 Here is how this could look like.

 {{{
                         Client              Server
                            |                  |
                            | <--- TCP --->    |
                            | Connection Setup |
                            |                  |
                            |7.03 ClientHello  |
                            |+ SNI: example.com|
                            +----------------->|
                            |                  |
                            |7.04 ServerHello  |
                            |<-----------------+
                            |                  |
                            |   NON            |
                            | GET /temperature |
                            |   (Token 0x74)   |
                            +----------------->|
                            |                  |
                            |   NON [0x23bc]   |
                            |   2.05 Content   |
                            |   (Token 0x74)   |
                            |     "22.5 C"     |
                            |<-----------------+
                            |                  |
                            |      ......      |
                            |   time passes    |
                            |      ......      |
                            |                  |
                            |                  |
                            |  <--- TCP --->   |
                            |  Conn. Teardown  |
 }}}

 There are two aspects worth highlighting:

 1) There is an initial handshake between the client and the server using
 newly defined CoAP Method Codes / CoAP Response Codes (7.02 & 7.03 in our
 example).

 2) The ClientHello message contains information about the Server Name
 Indication as a FQDN (similarly to what is done in TLS/DTLS with the SNI
 extension sent in the ClientHello msg).
 This SNI is a new option that needs to be defined.

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/391#comment:3>
core <https://tools.ietf.org/core/>