Hi Authors of draft-lwig-coap, Thank you for the draft. I have a question related to CoAP-over-DTLS. Section 5.4 of the draft (https://tools.ietf.org/html/draft-ietf-lwig-coap-04#section-5.4) has some discussion over the problem, it however does not help with the case below.
Say, the client and server is talking over a CoAP-DTLS session with a NAT between. Then the NAT session expires because of an idle period when no traffic re-enforce the NAT state. Assume afterwards the client would like to send a new CoAP-CON message towards the server. With the NAT outgoing <address port> pair changed, the server will not be able to resume the previous DTLS session and will discard this message. Sad though, it is not that serious because NAT problems is everywhere. What's worse is however, under such scenario, the client is unclear if it needs to retransmit the CoAP-over-DTLS message or re-negotiate a new DTLS (isn't it? because it does not know whether it is a network issue or DTLS failure). If it takes it as a network issue, it will keep trying to retransmit the CoAP-CON, until it reaches the retry limit (4 defined in RFC7252). This is very costly because of the exponential backoff may sum to more than 10s. In this case, it will be more efficient in this case to have the client re-negotiates the DTLS with server immediately. a) So my first question will be : Is this an issue with the current implementation and shall we make some recommendations? b) With regards to a better solution, draft-fossati-tls-iot-optimizations-00 will be a direct solution by including a connection ID in the DTLS record layer, but I do not know why this draft expires. @Hannes, could you help me with some background. Many thanks for discussion. BR, Zhen _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
