[core] Issues of CoAP with DTLS
Zhen Cao <zhencao.ietf@gmail.com> Fri, 18 August 2017 09:06 UTC
Return-Path: <zhencao.ietf@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813AA132932; Fri, 18 Aug 2017 02:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFQX2m4ASNhb; Fri, 18 Aug 2017 02:05:59 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2561132518; Fri, 18 Aug 2017 02:05:55 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id d124so30324798vkf.2; Fri, 18 Aug 2017 02:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GERBG/eM/yasj4k+eJolpwzBm2VkJMJl9Es7PbD/YF4=; b=ClaY6h3e9i/gJ2rcuxRMouBIxe0/dVIxOHfU9kJYilLiOTjrv1grEGXdUn8r3pU+6a xsF7cUcT9apQ5AKGBInPBQMyBDwFo6SR3B+DeqLSrzQzkVm7eE6ai7RyU7ZX7SxcT7jb K5KnOPOCqJo9irQKk/wUqDvH0zj4Ci7jN7wPbR6JdWZDQSukbbNQnSyLOZ8k9t4FBkTn 99jxKXEUPo2dJBvGluDBV2TsLgwm2aBCUga/RJfYtsrUlxHZSPxAEaPVdHVogj4izWZO VTpQd2RVqMs1JdA2bXBUZl/lmJYSrHBueZtuNXJFHNFYo1Ngt8234KNVJAzZf4CtGKst DoAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GERBG/eM/yasj4k+eJolpwzBm2VkJMJl9Es7PbD/YF4=; b=dkGP4WIpKjYo2h9G3CWWtWr6Zrxf9Sq4ruzIa7aHEVrMsfkpc5tILRGCLFfvsIb4fO lqq4nNKeSV80jaeaktd6haDgvBc09Qhr5SuyeUQXFW6D0mDm7SGtkv/9X1HMGeSjuUzB E2vJIryDvofK0iU8ehBfL5NXUUQWuhpbTqPllO2mLFuI5fpBh00z0LTwD9MjChU04Szk 16lLeN+xnUlr+B5XNXJ28wBJXQyJ7G3W4VIJgilVG8IvJ7J6oQp2XfYgwQeX2w8f0AGV T5/8HeRgiF5bQBtRAEmhaIO1489YbiI72QgWi+JsX7gpqLUYgsP72xDt5cbyEgCesLNv 72SQ==
X-Gm-Message-State: AHYfb5jupAXrP3CflgRpFshb3z56R8VdFaYIaKP9iTFX0FVtqgqkfNit llvJ7weQ2qfDn8T8ww5W8r0PfgEB0EkJ
X-Received: by 10.31.232.7 with SMTP id f7mr5110527vkh.32.1503047154801; Fri, 18 Aug 2017 02:05:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.41.161 with HTTP; Fri, 18 Aug 2017 02:05:54 -0700 (PDT)
From: Zhen Cao <zhencao.ietf@gmail.com>
Date: Fri, 18 Aug 2017 17:05:54 +0800
Message-ID: <CAFxP68y5RihLYHXoMr+od3LUfZ5P9asHaPXxGx=jNFS5T-z9Mg@mail.gmail.com>
To: draft-ietf-lwig-coap@ietf.org, lwip@ietf.org, "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/5-VYd2i_FcP3wMCKCfRMpyw-ECU>
Subject: [core] Issues of CoAP with DTLS
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Aug 2017 09:06:00 -0000
Hi Authors of draft-lwig-coap, Thank you for the draft. I have a question related to CoAP-over-DTLS. Section 5.4 of the draft (https://tools.ietf.org/html/draft-ietf-lwig-coap-04#section-5.4) has some discussion over the problem, it however does not help with the case below. Say, the client and server is talking over a CoAP-DTLS session with a NAT between. Then the NAT session expires because of an idle period when no traffic re-enforce the NAT state. Assume afterwards the client would like to send a new CoAP-CON message towards the server. With the NAT outgoing <address port> pair changed, the server will not be able to resume the previous DTLS session and will discard this message. Sad though, it is not that serious because NAT problems is everywhere. What's worse is however, under such scenario, the client is unclear if it needs to retransmit the CoAP-over-DTLS message or re-negotiate a new DTLS (isn't it? because it does not know whether it is a network issue or DTLS failure). If it takes it as a network issue, it will keep trying to retransmit the CoAP-CON, until it reaches the retry limit (4 defined in RFC7252). This is very costly because of the exponential backoff may sum to more than 10s. In this case, it will be more efficient in this case to have the client re-negotiates the DTLS with server immediately. a) So my first question will be : Is this an issue with the current implementation and shall we make some recommendations? b) With regards to a better solution, draft-fossati-tls-iot-optimizations-00 will be a direct solution by including a connection ID in the DTLS record layer, but I do not know why this draft expires. @Hannes, could you help me with some background. Many thanks for discussion. BR, Zhen
- [core] Issues of CoAP with DTLS Zhen Cao
- Re: [core] [Lwip] Issues of CoAP with DTLS Hannes Tschofenig
- Re: [core] [Lwip] Issues of CoAP with DTLS Fossati, Thomas (Nokia - GB/Cambridge, UK)