Hi Zhen, If you are interested in the f2f discussion that Hannes mentioned, see [1].
Cheers, t [1] https://youtu.be/ms-0PlY1R-8?t=2534 On 18/08/2017, 10:37, "core on behalf of Hannes Tschofenig" <core-boun...@ietf.org on behalf of hannes.tschofe...@gmx.net> wrote: Hi Zhen, a few people have pointed out this problem and hence a solution will be worked on (as agreed at the last TLS WG meeting). Ciao Hannes On 08/18/2017 11:05 AM, Zhen Cao wrote: > 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 > _______________________________________________ core mailing list c...@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
