> On Jul 12, 2017, at 7:56 AM, Sean Turner <s...@sn3rd.com> wrote: > > >> On Jul 6, 2017, at 23:04, yinxinxing <yinxinx...@huawei.com> wrote: >> >> 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. > > 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 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. > > 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).
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 > spt > >> Any comment is appreciated. >> >> Regards, >> Yin Xinxing >> >> >> 发件人: yinxinxing >> 发送时间: 2017年6月27日 16:28 >> 收件人: 'Eric Rescorla' >> 抄送: tls@ietf.org; 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:e...@rtfm.com] >> 发送时间: 2017年6月25日 21:33 >> 收件人: yinxinxing >> 抄送: tls@ietf.org; 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 <yinxinx...@huawei.com> 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
