Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt

From: Brian Raymor <[email-masked]>
Date: Tue, 4 Oct 2016 20:54:44 +0000

Apologies for the delay. I've been waiting for additional comments prior to responding. 

There is some support for this feature expressed by working group members with early
CoAP+TCP implementations - see https://github.com/core-wg/coap-tcp-tls/issues/58

On Monday, September 12, 2016 9:48 PM, Gengyu WEI wrote:

> The CoAP server may be effected if client immediately sends messages after 
> sending its CSM without waiting for the server CSM.

Absolutely true. The server may need to reject/ignore messages that are too large.  There is no
requirement for the client to immediately send messages. It may only be preferable in cases where
the client and server have a "known" configuration. 

> Is the probability of battery loss caused by inconsistency of CSM big or small?

It depends on whether a constrained client needs to re-send data. 

> Is it a potential means for a client to attack the CoAP server by consuming its power?

Do you have an implementation/deployment with a constrained server? As Juan Perez
notes in his comment:

    From the perspective of a cloud and gateway software provider,
    the CoAP (using TCP/TLS) server will usually be in the cloud or
    gateway and therefore usually not power constrained. I may be
    missing other scenarios where a battery powered device is acting
    as a CoAP/TCP server. Does anyone have plans for any of those
    scenarios?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 05 Oct 2016 07:33:02 +0200

> Absolutely true. The server may need to reject/ignore messages that are too large.  

I don't understand how this could happen.

Until it receives an indication for an increased message size capability
from the other side, the limitations of Section 4.6 of RFC 7252 continue
to apply to messages sent by any one side.  (Now, the message receiver
might want to go *below* Section 4.6.  If that is a use case we want to
support, the argument does apply.  Is it?)

>     as a CoAP/TCP server. Does anyone have plans for any of those

I think we have to be more careful about separating the concept of
initiator/listener for the TCP connection from the concept of CoAP
client/server; these are not linked.  Indeed, the TCP initiator will
typically be the constrained device (and thus the CoAP server) in the
NAT traversal use case.

Grüße, Carsten

---

From: Brian Raymor <[email-masked]>
Date: Thu, 6 Oct 2016 21:34:19 +0000

> to apply to messages sent by any one side. 

We've addressed this directly in coap-tcp-tls [section 4.3.2] with the use
of base value for the Max-Message-Size Capability Option:

   As per Section 4.6 of [RFC7252], the base value (and the value used
   when this option is not implemented) is 1152.

> (Now, the message receiver might want to go *below* Section 4.6.
> If that is a use case we want to support, the argument does apply.  Is it?)

This is the potential case. The sender is exceeding the receiver's maximum
message size.

---

From: Brian Raymor <[email-masked]>
Date: Mon, 10 Oct 2016 22:26:03 +0000

If there are no further comments on the related pull request - https://github.com/core-wg/coap-tcp-tls/pull/64 - I will merge tomorrow and publish coap-tcp-tls-05.

...Brian

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Brian Raymor
Sent: Thursday, October 6, 2016 2:34 PM
To: Carsten Bormann <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]; Juan Perez <[email-masked]>
Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core