> On Jul 16, 2017, at 8:39 PM, yinxinxing <yinxinx...@huawei.com> wrote: > > 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?
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 > 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
