Subject: Re: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls - additional comments

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 22 Feb 2017 09:23:19 +0000

PS: two more review comments that were not yet included in my first email:

1. In RFC 7252, the Reset message (RST) is also used to deal with certain cases of malformed CoAP messages or incorrect field values. Since the RST message is now removed, I think there should be text on how to deal with these cases. For example in Figure 21 (RFC 7252) the Token value is not recognized which leads to a RST. How should CoAP-over-reliable deal with this case and related cases?  Although the draft suggests that Client (if we take the Fig 21 case) could abort the connection, that sounds rather drastic and unnecessary – the client and server need to keep talking to each other typically. Silently ignoring seems better in that case. And in case the receiver of an 'incorrect' message decides not to abort, what should it do instead – anything normative?
Related cases for CoAP message receivers are:

-          Token not recognized -> could happen in the Figure 21 use case, silently ignore seems best. Or would there be a reason to notify the response sender that the response is not recognized? (RFC 7252 allows to do this at least.)

-          Token Length TKL is wrong (e.g. length is 9 to 15) -> could be sent by a malicious CoAP endpoint, good reason to abort perhaps

-          Code unrecognized (e.g. 1.xx, 3.xx, 0.31 … ) -> could happen if one of the endpoints supports other/newer CoAP features, perhaps abort, or perhaps silently ignore? Possibly malicious endpoint.
Summarizing it seems to me the best to specify a receiver MAY abort the connection and also MUST silently ignore the malformed message. This could be made more explicit in the text.

2.  s/token/Token/  -> just to comply with the RFC 7252 notation

Esko

From: core [mailto:[email-masked]] On Behalf Of Jaime Jiménez
Sent: Wednesday, February 15, 2017 13:17
To: [email-masked] WG <[email-masked]>
Cc: [email-masked]
Subject: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

Dear CoRE WG,

There has been quite some work on the "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets” draft (draft-ietf-core-coap-tcp-tls) since the last WGLC.
BIG thanks to Brian for the time and effort dedicated as Editor. It now seems a good time for a final WGLC to get the last comments from the group in order to move the specification forward.

In particular there has not been much discussion on securing CoAP over WebSockets (https://github.com/core-wg/coap-tcp-tls/issues/102) as well as the Default URI host (https://github.com/core-wg/coap-tcp-tls/issues/108) feedback would be very much welcomed. Please go ahead and check the discussions on the other issues of this version: https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=1  and on the changelog summary. In addition to that, I would like to ask the group to let me know their current implementation status of the draft for the shepherd writeup, especially Open Source implementations of the draft.

latest version: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06
diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-06.txt
changelog: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-06#appendix-C.4

The WGLC will last one week, until 2017-02-22 .

Thanks!
Jaime Jiménez

________________________________
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: Brian Raymor <[email-masked]>
Date: Tue, 28 Feb 2017 22:08:37 +0000

> 1. In RFC 7252, the Reset message (RST) is also used to deal with certain cases of malformed CoAP messages or incorrect field values.
> Since the RST message is now removed, I think there should be text on how to deal with these cases.
> For example in Figure 21 (RFC 7252) the Token value is not recognized which leads to a RST. How should CoAP-over-reliable deal with this case and related cases?
> Although the draft suggests that Client (if we take the Fig 21 case) could abort the connection, that sounds rather drastic and unnecessary – the client and server need to keep talking to each other typically.
> Silently ignoring seems better in that case. And in case the receiver of an 'incorrect' message decides not to abort, what should it do instead – anything normative?
<snip>
> Summarizing it seems to me the best to specify a receiver MAY abort the connection and also MUST silently ignore the malformed message. This could be made more explicit in the text.

Tracking in https://github.com/core-wg/coap-tcp-tls/issues/117

My initial instinct would be MUST abort the connection. Can those with early (but shipping) implementations offer any guidance on how this case is currently being handled? What do others think?

> 2.  s/token/Token/  -> just to comply with the RFC 7252 notation

OK.

From: core [mailto:[email-masked]] On Behalf Of Jaime Jiménez
Sent: Wednesday, February 15, 2017 13:17
To: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

Dear CoRE WG,

Thanks!
Jaime Jiménez