Subject: Re: [core] #388 (coap-tcp-tls): Multiple versions over the same connection

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

#388: Multiple versions over the same connection

Comment (by [email-masked]):

 The latest version of the CoAP over TCP document (version -02) does not
 contain a version field anymore. This does, however, raise the question
 how the client indicates what CoAP version to use. There are the following
 4 possible options:

 Option #1) Add version field back to the CoAP header
 Option #2) TLS/DTLS-style version exchange
 Option #3) Client indicates version + Server accepts / rejects
 Option #4) Client indicates version + Server accepts / rejects but
 provides additional info about what it supports in an error message

 My (weak) preference is for option #4. The figure below shows an example:

 {{{
                      Client              Server
                            |                  |
                            | <--- TCP --->    |
                            | Connection Setup |
                            |                  |
                            |7.02 ClientHello  |
                            | (version = x)    |
                            +----------------->|
                            |                  |
                            |7.03 ServerHello  |
                            |<-----------------+
                            |                  |

                  Figure: Successful Version Negotiation
 }}}

 {{{
                         Client              Server
                            |                  |
                            | <--- TCP --->    |
                            | Connection Setup |
                            |                  |
                            |7.02 ClientHello  |
                            | (version = y)    |
                            +----------------->|
                            |                  |
                            |8.01 Alert        |
                            | (Incompatible    |
                            |  Version)        |
                            | (+version=x)     |
                            |<-----------------+
                            |                  |

                  Figure: Failed Version Negotiation
 }}}

 A new option conveys the version information.

 This message also shows the new error response message.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  [email-masked]         |  [email-masked]
     Type:  protocol     |      Status:  new
  defect                 |   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/388#comment:1>
core <https://tools.ietf.org/core/>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Apr 2016 15:57:46 +0200

With TLS, we could do the version indication using ALPN.
(This would possibly be an argument for deciding #387 as "always".)

For TCP, we could provide a signaling message with a critical option.
Or we could make CoAP version 1 the default and add the signaling
message only when we need it.  That would be my preference.

Grüße, Carsten

---

From: Christian Groves <[email-masked]>
Date: Wed, 27 Apr 2016 14:26:02 +1000

Is there any assumption that new CoAP versions need to be backward 
compatible? I didn't see anything mentioned in RFC7252.

Christian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Apr 2016 08:01:56 +0200

Hi Christian,

> compatible? I didn't see anything mentioned in RFC7252.

UDP CoAP packets have a "version number" because there were two bits
free in the header and we wanted to have a specific bit pattern in there
so CoAP packets multiplex nicely with DTLS and STUN packets on the same
port.

Nobody had or has any idea what a future version of CoAP would look
like; no need for one has come up*).  A different version number would
only be used to ensure that current CoAP implementations never process
messages in a future new format; CoAP's protocol evolution method is to
use options.

In a reliable stream (TCP/TLS/Websockets), there is no need to indicate
a protocol version per-message; if version negotiation is ever required,
this can be done at the start of the stream.

Grüße, Carsten

PS.: I'm not sure people have tried using different HTTP versions (1.0
vs. 1.1) within the same TCP connection; not that HTTP versions ever
meant that much...   (See the note in Section 3.5 of RFC 7540 for the
HTTP/2 view on that.)

*)  OK, maybe we want to have a longer message ID in a future high-rate
variant of UDP CoAP.  No message-IDs are needed in TCP CoAP...

---

From: Christian Groves <[email-masked]>
Date: Wed, 27 Apr 2016 21:21:52 +1000

Hello Carsten,

Thanks for the background. I agree version negotiation for a reliable 
would be done at the start at the start of the stream. I was thinking 
that having backward compatible versioning might simplify negotiation 
but it seems one can't make that assumption.

Regards, Christian

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Apr 2016 18:51:15 +0200

Making version 1 the default sounds reasonable to me.

There is, however, an important design consideration:

1) Should the version indication be added to each message, or
2) Should there be a version indication/negotiation at the beginning of
the handshake

The discussion I included in the issue tracker focused on option #2
since I assumed we do not want option #1.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Apr 2016 20:24:03 +0200

> 1) Should the version indication be added to each message, or

No.

> 2) Should there be a version indication/negotiation at the beginning of

Yes.  (With the default being version 1.)

In any case, version numbers will be hop-by-hop.  (Cf. Section 2.1 of
RFC 2145 if you don't see what I'm trying to say here.)  It is hard to
see for me what would motivate an TCP endpoint to mix versions on one
connection.

Another question is whether we always want to have some initial
exchange, e.g.

1) to make cross-protocol attacks harder, or
2) just for its diagnostic value.

(I'm not a big fan of a passive opener ("TCP connection server") sending
unsolicited details right on connection open; this makes things too easy
for Shodan-like search engines.  If we don't do that, we essentially add
a roundtrip.  Probably not a big problem for CoAP-over-TCP connections
as these are likely to last longer than your typical HTTP connection.)

Grüße, Carsten