IETF Logo Mail Archive

Re: [core] [Lwip] Issues of CoAP with DTLS

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 18 August 2017 09:37 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 74162132937; Fri, 18 Aug 2017 02:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 1qinQQwK-q5S; Fri, 18 Aug 2017 02:37:42 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 296B91323AD; Fri, 18 Aug 2017 02:37:41 -0700 (PDT)
Received: from [192.168.91.203] ([80.92.118.73]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPppG-1ddfud1i9y-0052ut; Fri, 18 Aug 2017 11:37:38 +0200
To: Zhen Cao <zhencao.ietf@gmail.com>, draft-ietf-lwig-coap@ietf.org, lwip@ietf.org, "core@ietf.org WG" <core@ietf.org>
References: <CAFxP68y5RihLYHXoMr+od3LUfZ5P9asHaPXxGx=jNFS5T-z9Mg@mail.gmail.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <e2973c6e-ae8f-f089-5936-ee1ab76799b5@gmx.net>
Date: Fri, 18 Aug 2017 11:37:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAFxP68y5RihLYHXoMr+od3LUfZ5P9asHaPXxGx=jNFS5T-z9Mg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:x97znv5xVIMQ7Zgw3rN8iyD45MNHkj4uG1t5gxY5WIp6hyxzWHp AuxB5/0w+VXfNFoa5iaPMjiXV/wNEh3fyfp4r9xWPFIlfjV4vxvZ89j1hTcancj9ir54Rhi qgGFiNJn2lB+tV7GQS6N2+GgQuDdzQDUXXzYjm0fe0Uv1kfZ4N56R7B7oB9x8w5D6v9YhTF GhRG9KYBK+4djmar+THWQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:aRtLNAtT6Io=:/BusZgLvTJHvEdQbEIiKxh XIEZE5GNRdY5SN1JjaHYQ57ftlREOR5OnOIqX1BBWVLv1sAvASzW6/O3wwK+Epa1MzMDaOW+B P98MEtrR6vYsiKCrvtMV7XhP9UOVRdOe9tgzFN4QQNw4WyXmSOT6+ntscNi7OEWnKznAvcNWD N4bzccd2ZLXSANTwPJO8ufdX6Zoegg/cCEUqLLeHHsgIZNu05bK6oYlIV2D1p/VJtHZlVXyiu gKFdpmRwblbl85DNFeEve6bm3GBtZXTnHj1jJhBchHQa1Ya9OvW7Xz0AOh3FMQONe/dZKC35f mSCKYyHMn439FG3I3ew/3O8wpUwcXAbSQG+rBo8seuhIfFh2CMX7qzEjs3eTfKtaqmIbYmdfa LJeuTz3QmCcjSp0LEDSqxzSGg+wyunOswL7tTFCJ3E+vhg096imqUS3SwqXkvTSiI+eFBJPl0 3yEq2aPzaUlBtI+iDegxxg27G3tVLhCGZPMGt8DZyZBlK7jAAFsUSGJweTPUejVB2f0cg5t+s cKcDRC27qIioCKjciaGyMsM9CKWBEbqHrOJVd/I/NKmeyA2NLxhVKRCMkSMJXfJ4oLOErXT6b /ak7ZONbqLxzxsuFFdCdvi1xD+8lsc4/Rb3J6RMX2fOy3q7loG4C0HTWaTUCQfdrqCI7FjR9o MaW0c1shIP25Fwz8A1yegAbLbPSCZTV3gtUsy8TTQXGvNUexUElkQrL6nnuoiU/VZUi3sSeSR y4M1CpYvG72LaeL5nYELX3A1UcIAok3Hp3bp9KVgj6xwxdv0NA+k4Z5rBB4rjbfu3RdVHJe80 eAsKu2G1/XM+YuhEOKlMM+sFmwh8s+9TuNRsaeqgoiUM8xVz70=
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/r75riSKWZauB-jFDjPrGW8KJedo>
Subject: Re: [core] [Lwip] 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:37:44 -0000

Hi Zhen,

a few people have pointed out this problem and hence a solution will be
worked on (as agreed at the last TLS WG meeting).

Ciao
Hannes

On 08/18/2017 11:05 AM, Zhen Cao wrote:
> 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
> 
> _______________________________________________
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip
>

v2.23.0 | Report a Bug | By Email