Thanks Wing, Please see my comments inline.
Regards, Yin Xinxing -----邮件原件----- 发件人: Dan Wing [mailto:danw...@gmail.com] 发送时间: 2017年7月13日 8:52 收件人: yinxinxing 抄送: tls@ietf.org; Sean Turner 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 > On Jul 12, 2017, at 5:21 PM, yinxinxing <yinxinx...@huawei.com> wrote: > > Hi Dan Wing, > > Thanks for your comments. > > Please see my comments inline. > > Regards, > Yin Xinxing > > -----邮件原件----- > 发件人: Dan Wing [mailto:danw...@gmail.com] > 发送时间: 2017年7月13日 1:09 > 收件人: yinxinxing > 抄送: tls@ietf.org; Sean Turner > 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation > with high power consumption in DTLS1.2 > > >> 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 > [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. >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 [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. > >> 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
