[core] Issues of CoAP with DTLS

[Zhen Cao]

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

[Hannes Tschofenig]

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

Post by Zhen Cao
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.
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
background.
Many thanks for discussion.
BR,
Zhen
_______________________________________________
Lwip mailing list
https://www.ietf.org/mailman/listinfo/lwip

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Zhen,

If you are interested in the f2f discussion that Hannes mentioned, see [1].

Cheers, t

[1]

On 18/08/2017, 10:37, "core on behalf of Hannes Tschofenig" <core-***@ietf.org on behalf of ***@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

Post by Zhen Cao
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.
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
background.
Many thanks for discussion.
BR,
Zhen
_______________________________________________
Lwip mailing list
https://www.ietf.org/mailman/listinfo/lwip