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' 抄送: tls@ietf.org; Sean Turner 主题: 答复: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2 Hi Wing, Please see the comments inline Regards, Yin Xinxing -----邮件原件----- 发件人: Dan Wing [mailto:danw...@gmail.com] 发送时间: 2017年7月13日 12:35 收件人: 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:11 PM, yinxinxing <yinxinx...@huawei.com> wrote: > > 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" > 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. > For upgrading problem you and Sean mentioned, please see my reply for Sean. > Thanks, I did read that reply. The devices can't be upgraded. > -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. > > > >> >>> 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
