Subject: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

From: yinxinxing <[email-masked]>
Date: Fri, 7 Jul 2017 03:04:06 +0000

Hi all,

The NAT table expiring problem mentioned in the  following email should also be considered in DTLS1.2 as an extension.

The value and necessity are as follows.

1. Essentially, NAT expiring problem causing DTLS renegotiation with high power consumption is existing in DTLS 1.2. Even if we solve this in DTLS1.3, this problem still exist for products using DTLS1.2.
Currently, many IOT products using DTLS 1.2 are going to be deployed commercially, such as intelligent water/gas meter. These meters usually have limited battery and low cost. To be more accurate, the battery of the chip module of the intelligent water/gas meter are required to last for 10 years. These lead to an exercise strict control over the power consumption of the chip module. NAT expiring problem causing DTLS renegotiation with high power consumption is a bottleneck of these IOT devices. According to our experimental data, under the worst coverage level (ECL2), power consumption of the chip module when DTLS is embedded increases by nearly 60%. Therefore, there should be a solution to solve the urgent problem to match the low-cost and low-battery feature of the IOT devices in DTLS 1.2.

2. DTLS 1.3 will be standardized in 2018, but the corresponding open source code will be available about one year later after the standardization. At present, large-scale commercial IOT industry deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope that the above problem could be solved in DTLS 1.2 as soon as possible.

Any comment is appreciated.

Regards,
Yin Xinxing

发件人: yinxinxing
发送时间: 2017年6月27日 16:28
收件人: 'Eric Rescorla'
抄送: [email-masked]; Tobias Gondrom
主题: Re: [TLS] Yin Xinxing joins the TLS WG

Thanks Eric,

I have seen the CID scheme, and talked with Hannes(the author of the scheme).

CID scheme is a good idea to solve the problem I mentioned.

I think the length of CID (currently, it is 32 bits) can be longer so that it can support more DTLS sessions. It is known that for IOT scenario, 1 million connection is nothing.

Regards,
Yin Xinxing

发件人: Eric Rescorla [mailto:[email-masked]]
发送时间: 2017年6月25日 21:33
收件人: yinxinxing
抄送: [email-masked]<mailto:[email-masked]>; Xiongxiaochun
主题: Re: [TLS] Yin Xinxing joins the TLS WG

Hi Yin,

The usual solution to this is to add a connection id. Please see:
https://github.com/tlswg/dtls13-spec/issues/6

-Ekr

On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing <[email-masked]<mailto:[email-masked]>> wrote:
Hello everyone,

I am Yin Xinxing from Huawei company. I am glad to join the TLS WG.

For the DLTS 1.3 draft, I am interested and have some ideas to talk with you.

DTLS has a lot of application scenarios in IOT fields, but currently, there is some difficulty when DTLS 1.2 is applied to IOT devices, especially the battery-constrained IOT devices.

For example, when the IOT device wakes up from sleep mode, the NAT table may have expired.
Then the IOT device has to establish a new DTLS session or at least launches a resume process with the server, the corresponding power consumption is too high for some power-constrained devices.
How can DTLS renegotiation be avoided in order to save battery?

I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider this problem and give a proper solution.

Any comment or idea about this problem is welcome.

Regards,
Yin Xinxing

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Sean Turner <[email-masked]>
Date: Wed, 12 Jul 2017 10:56:32 -0400

> On Jul 6, 2017, at 23:04, yinxinxing <[email-masked]> wrote:
> 
> Hi all,
>  

I have to ask whether these IoT devices are updatable?

> 2. DTLS 1.3 will be standardized in 2018, but the corresponding open source code will be available about one year later after the standardization. At present, large-scale commercial IOT industry de…

On this point, I’m hoping that you’ll be wrong ;). From the list of TLS implementations found here:
https://github.com/tlswg/tls13-spec/wiki/Implementations
and assuming there is as much enthusiasm to implement DTLS1.3 as there was for TLS1.3 then I’m hoping that the DTLS implementations will be ready much sooner than a year after publication (they might be ready before the RFC is published).

spt

> 抄送: [email-masked]; Xiongxiaochun
> On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing <[email-masked]> wrote:
> Hello everyone,
>  
> [email-masked]
> [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Jul 2017 10:08:46 -0700

> On Jul 12, 2017, at 7:56 AM, Sean Turner <[email-masked]> wrote:
> 
> 

Yin Xinxing,

While waiting for cid, perhaps today do session resumption (RFC5077), anytime the client has reason to suspect their UDP port or IP address might have changed -- such as it's been longer than, say, 30 seconds since last UDP transmission.  (The problem isn't solely NAT; there are several ISPs that change subscriber's IP address, also forcing re-negotiation of DTLS security association.  Less frequent than NATs timing out UDP, of course.)

-d

---

From: yinxinxing <[email-masked]>
Date: Thu, 13 Jul 2017 00:21:20 +0000

Hi Dan Wing,

Thanks for your comments.

Please see my comments inline.

Regards,
Yin Xinxing

-----邮件原件-----
发件人: Dan Wing [mailto:[email-masked]] 
发送时间: 2017年7月13日 1:09
收件人: yinxinxing
抄送: [email-masked]; Sean Turner
主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

>While waiting for cid, perhaps today do session resumption (RFC5077), anytime the client has reason to suspect their UDP port or IP address might have changed -- such as it's been longer than, say, 30 seconds since last UDP transmission.  (The problem isn't solely NAT; there are several ISPs that change subscriber's IP address, >also forcing re-negotiation of DTLS security association.  Less frequent than NATs timing out UDP, of course.)

>-d
[Yin] Yes, you are right. The problem isn't solely NAT expiring, but changing from WLAN to 3GPP, or IOT devices waking up from sleep mode. All of these could lead to IP change.
Session resumption is a good way to re-negotiate the DTLS session. However, according to our IOT products, e.g., intelligent water/gas meter, session resumption mechanism still needs to communicate 6 or 5 messages(based on the cipher suite TLS_PSK_WITH_AES_128_CBC_SHA256) and this re-negotiation mechanism still costs too much battery and can not ensure 10-year lifetime of the IOT products' battery.

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Jul 2017 17:52:21 -0700

> On Jul 12, 2017, at 5:21 PM, yinxinxing <[email-masked]> wrote:
> 
> Hi Dan Wing,
> 

I see 3 messages and no cryptographic operations for the client in Figure 2 of https://tools.ietf.org/html/rfc5077#page-5.  So I guess you're saying the IoT device can't send two packets and receive one packet without impacting its battery.  I agree 'cid' is more efficient, but it isn't yet standardized.  I would consider doing RFC5077 and then, when 'cid' or DTLS 1.3 is available, update the devices to support 'cid' or DTLS 1.3, as Sean implied when he asked if the devices could be updated.

(I hope the devices aren't using the same pre-shared key!  That would be bad.)

-d

---

From: yinxinxing <[email-masked]>
Date: Thu, 13 Jul 2017 01:11:26 +0000

Thanks Sean!

Your question and comments are valuable. 

Please check my comments inline.

Regards,
Yin Xinxing

-----邮件原件-----
发件人: Sean Turner [mailto:[email-masked]] 
发送时间: 2017年7月12日 22:57
收件人: yinxinxing
抄送: [email-masked]
主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

> I have to ask whether these IoT devices are updatable?
[Yin]Yes, these IOT devices are updatable. However, in IOT application scenario, there will be millions( even billions ) of IOT devices. Companies will not easily upgrade such a large number of devices because of operation and maintenance cost and power consumption of IOT device upgrading. You see that current products from different companies are all based on DTLS1.2 since DTLS1.3 is under standardization. We hope there could be a solution to solve the problem of these products based on DTLS1.2.

> spt
[Yin] Thanks for providing this useful information. I got wrong information about the implementation state of TLS/DTLS1.3. For DTLS1.3, the implementation will be ready about 1 year, and during this period products have no DTLS1.3 implementation to use.

---

From: yinxinxing <[email-masked]>
Date: Thu, 13 Jul 2017 02:11:21 +0000

Thanks Wing,

Regards,
Yin Xinxing

-----邮件原件-----
发件人: Dan Wing [mailto:[email-masked]] 
发送时间: 2017年7月13日 8:52
收件人: yinxinxing
抄送: [email-masked]; Sean Turner
主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

>I see 3 messages and no cryptographic operations for the client in Figure 2 of https://tools.ietf.org/html/rfc5077#page-5.  So I guess you're saying the IoT device can't send two packets and receive one packet without impacting its battery.  I agree 'cid' is more efficient, but it isn't yet standardized.  I would consider doing >RFC5077 and then, when 'cid' or DTLS 1.3 is available, update the devices to support 'cid' or DTLS 1.3, as Sean implied when he asked if the devices could be updated.

>-d
[Yin] Figure 2 is TLS resumption. For DTLS, there are "clienthello" and "helloverifyrequest" before the resumption procedure in Figure2. Anyway, the resumption mechanism is not efficient for battery-constrained IOT devices.
For upgrading problem you and Sean mentioned, please see my reply for Sean.

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Jul 2017 21:35:15 -0700

> On Jul 12, 2017, at 7:11 PM, yinxinxing <[email-masked]> wrote:
> 
> Thanks Wing,
> 
> [Yin] Figure 2 is TLS resumption. For DTLS, there are "clienthello" and "helloverifyrequest"

HelloVerifyRequest is only sent if the DTLS server is defending itself from attack.  I would imagine DDoS mitigation companies will, or have already, built DTLS defenses that can avoid sending that message in many cases, or such logic could be included as part of a quality DTLS server implementation?  If the client devices are so sensitive to sending/receiving packets, I wouldn't want the server to challenge them with HelloVerifyRequest, but instead be sure there is DoS and DDoS mitigation on the server that doesn't push effort back to the clients.  Afterall, the client sent a packet that the server could have validated, at cryptographic cost to the server.  Creative encoding of that nonce could allow the server to reduce its validation effort and reduce its likelyhood of challenging with a HelloVerifyRequest.

> before the resumption procedure in Figure2. Anyway, the resumption mechanism is not efficient for battery-constrained IOT devices.

Thanks, I did read that reply.  The devices can't be upgraded.

-d

---

From: yinxinxing <[email-masked]>
Date: Thu, 13 Jul 2017 08:55:31 +0000

Hi Wing,

Please see the comments inline

Regards,
Yin Xinxing

-----邮件原件-----
发件人: Dan Wing [mailto:[email-masked]] 
发送时间: 2017年7月13日 12:35
收件人: yinxinxing
抄送: [email-masked]; Sean Turner
主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

> HelloVerifyRequest is only sent if the DTLS server is defending itself from attack.  I would imagine DDoS mitigation companies will, or have already, built DTLS defenses that can avoid sending that message in many cases, or such logic could be included as part of a quality DTLS server implementation?  
> If the client devices are so sensitive to sending/receiving packets, I wouldn't want the server to challenge them with HelloVerifyRequest, but instead be sure there is DoS and DDoS mitigation on the server that doesn't push effort back to the clients.  Afterall, the client sent a packet that the server could have validated, 
> at cryptographic cost to the server.  Creative encoding of that nonce could allow the server to reduce its validation effort and reduce its likelyhood of challenging with a HelloVerifyRequest.

> -d

[Yin] I don't think so. From the perspective of security, these messages are needed. Even the client devices are battery-constrained, security is needed in DTLS as required by our customers.

---

From: yinxinxing <[email-masked]>
Date: Mon, 17 Jul 2017 03:39:01 +0000

Hi Wing,

I noticed that Helloverifyrequest is optional by the server and used when DOS is to be mitigated. 

But from practical use cases, the IOT server may not have dedicated anti-DOS mechanism. 

If there is a more power-saving solution with the function of DOS mitigation retained, and don't need to bother the server(customer) to deploy anti-DOS devices, why not have a try?  

Regards,
Yin Xinxing

-----邮件原件-----
发件人: yinxinxing 
发送时间: 2017年7月13日 16:56
收件人: 'Dan Wing'
抄送: [email-masked]; Sean Turner
主题: 答复: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

Hi Wing,

Regards,
Yin Xinxing

---

From: Dan Wing <[email-masked]>
Date: Tue, 18 Jul 2017 09:34:16 -0700

> On Jul 16, 2017, at 8:39 PM, yinxinxing <[email-masked]> wrote:
> 
> Hi Wing,
> 

Sure.  You might work with the authors of draft-mavrogiannopoulos-tls-cid to add more considerations around denial of service, perhaps also a longer cid as you suggested earlier.

-d

---

From: yinxinxing <[email-masked]>
Date: Wed, 19 Jul 2017 00:52:20 +0000

Thanks Wing.

I am glad to discuss the technical details of CID draft with Hannes, Thomas and Nikos. 

Regards,
Yin Xinxing

-----邮件原件-----
发件人: Dan Wing [mailto:[email-masked]] 
发送时间: 2017年7月19日 0:34
收件人: yinxinxing
抄送: [email-masked]; Sean Turner
主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

-d

> 主题: 答复: [TLS] Solving the NAT expiring problem causing DTLS 
> renegotiation with high power consumption in DTLS1.2
> 
> Hi Wing,
> 
> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS 
> renegotiation with high power consumption in DTLS1.2
> 
> 
>> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS 
>> renegotiation with high power consumption in DTLS1.2
>> 
>> 
>>> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS 
>>> renegotiation with high power consumption in DTLS1.2
>>> 
>>> 
>>>> While waiting for cid, perhaps today do session resumption 
>>>> (RFC5077), anytime the client has reason to suspect their UDP port 
>>>> or IP address might have changed -- such as it's been longer than, 
>>>> say, 30 seconds since last UDP transmission.  (The problem isn't 
>>>> solely NAT; there are several ISPs that change subscriber's IP 
>>>> address, >also forcing re-negotiation of DTLS security association.  
>>>> Less frequent than NATs timing out UDP, of course.)
>>> 
>>>> -d
>> If the client devices are so sensitive to sending/receiving packets, 
>> I wouldn't want the server to challenge them with HelloVerifyRequest, but instead be sure there is DoS and DDoS mitigation on the server that doesn't push effort back to the clients.  Afterall, the client sent a packet that the server could have validated, at cryptographic cost to the server.  Creative encoding of that nonce could allow the server to reduce its validation effort and reduce its likelyhood of challenging with a HelloVerifyRequest.
>