Re: [Tsv-art] [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 17 May 2022 15:31 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582D9C159823; Tue, 17 May 2022 08:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhnR13f96v58; Tue, 17 May 2022 08:31:48 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75488C159821; Tue, 17 May 2022 08:31:48 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id d22so19060838vsf.2; Tue, 17 May 2022 08:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fNrPI3gNlAIjlfrlgPw+BJSPlxhHtQ6S7ZR3GYTvCOw=; b=mE5FhlX50xqkJhgyQU3rHz4t8eZAqw/whUIviVBAwEgQNFn9batqkn1jURzdMNXkHF 3EC/1SYw/HjyjMnkf1SOE+tIIFFrXU42x+6g/fZ4W974dn6dZ3t8fM2oVeAegetdyOn+ zSu664KucEm86EBB/LOE7ITZ3KuijV8iefBF/E41hPXM1byGL4tTjvz6g2uwirqg3RY1 iTU/tPwRaWDpz+M9ied6j+0CqDSJ3a8Gd3nPZAhLVNd3/Nsv7VyE0YWR7zoPz9VtN+2Q vWU28Lyec/WPq9+089E2/hBOtkCXcMKtqk0vMPjBT0BFMYGradknhjxyWUUaZPUi1pHy VLDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fNrPI3gNlAIjlfrlgPw+BJSPlxhHtQ6S7ZR3GYTvCOw=; b=Tk484/TW1KBOvYvEfUBfyjIUjHqu2Lt0pe57l+MKielhG04LvEzQuuD0E+AEnVQrAl U/KHtDixndRUmWz7vOdIx0aAqq7p3QIx+eYH8BkWSbfFQH3sOhoP/OE0s255VQTYh4zB Ha+8srXbpenUbc/lZnWwKu6s4p3XyMUD6tdDvMNCYEGt/oCDbLNP6auvR1vyZCSF0OmR CJMzGoCExmINjb1I/V7vu8+Aqo0dCz0JQnt5s2xEmreaxqOr+yMOsmRNIuXiRQ6EEaqZ 9L8z71eox2cvQOc1vP2r0YMug6gpBCmHmQ1HR3YgT9xuitXCSpr/YDMhapNvzzi9TUzs 1lFA==
X-Gm-Message-State: AOAM5314Qt/+VCOk7I2M7CYUtOcExmkFxdpcVejQLVucODydDizN0/22 k9MUzBkrF3h8GZaGCtger6ye7oXyE/6BYQktGlk=
X-Google-Smtp-Source: ABdhPJxAKUKhniNNtxu/P4hweryn14GK7d0b5A2ONypTaNJ8kvh/QkJebLR4+9kljY2ANYD0KNUc5mcNWHt9yVzhtm4=
X-Received: by 2002:a05:6102:3a76:b0:32c:e483:3e45 with SMTP id bf22-20020a0561023a7600b0032ce4833e45mr9600157vsb.19.1652801507270; Tue, 17 May 2022 08:31:47 -0700 (PDT)
MIME-Version: 1.0
References: <165274254631.62630.11102982778020349578@ietfa.amsl.com> <61693ee0f53d9398b55d000231b06325@bbhmail.nl> <DU0P190MB197859A7987DFFDF4041A165FDCE9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <DU0P190MB197859A7987DFFDF4041A165FDCE9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 17 May 2022 10:31:21 -0500
Message-ID: <CAKKJt-eJva8imG3VXiONp3r88gNqDYfWx_U01RdeW38cLwh4QA@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: "stokcons@bbhmail.nl" <stokcons@bbhmail.nl>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "anima@ietf.org" <anima@ietf.org>, "draft-ietf-anima-constrained-join-proxy.all@ietf.org" <draft-ietf-anima-constrained-join-proxy.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b9a33905df36d6ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/ewppnpSIKvDh5vDd-OpLdHeJGvM>
Subject: Re: [Tsv-art] [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2022 15:31:52 -0000

Hi, Esko,

On Tue, May 17, 2022 at 4:37 AM Esko Dijk <esko.dijk@iotconsultancy.nl>
wrote:

> Hi Peter, Spencer,
>
>
>
> For some more detail on Peter’s ‘No’ answer:
>

I was expecting that answer. 😉

Thanks for the additional details!


> Since the Pledge communicates (link-local) with the Join Proxy using
> DTLS-over-UDP on a network that is likely 6LoWPAN (1280 byte MTU limit)
> mesh, it could happen in theory that the Pledge sends out a DTLS handshake
> UDP packet with a length that brings the carrying IPv6 packet length at
> 1280.
>
> In this case the DTLS record size is also something close to 1280. (We
> never did the exact calculations.)
>
>
>
> This may pose a problem for the stateless Join Proxy that appends a few
> bytes to the DTLS record (to relay it further to the Registrar) so the
> total length of the IPv6 packet sent to Registrar could exceed 1280. (And
> the Join Proxy is still on the mesh network with 1280 byte MTU).
>
> But in any case in the constrained-voucher draft we have written about
> this:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher#section-6.7
>
>
>
> So even though we don’t know for sure it is a problem, as we haven’t done
> the calculations in detail, it’s preemptively solved by recommending the
> Pledge to break up the handshake into smaller parts. Then,  the Join Proxy
> doesn’t need to do anything special anymore and it always works.
>
> That also helps with performance on the mesh network due to reduction of
> 6LoWPAN fragmentation.
>
>
> @Spencer do you think the Constrained Join Proxy draft should mention the
> potential issue also?  E.g. a reference to above section 6.7 is easy to
> make.
>

The reference you described is exactly what I was thinking of (I was more
familiar with COAP before blockwise transfer was specified in
https://datatracker.ietf.org/doc/rfc7959/, but I knew it had been
standardized).

If you can preemptively avoid a potential problem by adding a reference to
the document and section you provided, without slowing this document down,
that would be great.

And thanks again for a quick response to a really late directorate review.

(I know we're not talking about
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher,
but I didn't see RFC 7959 listed as a reference there, and it seems like
that should be normative. But do the right thing, of course!

Best,

Spencer


> Regards
>
> Esko
>
>
>
> *From:* Anima <anima-bounces@ietf.org> *On Behalf Of * Peter van der Stok
> *Sent:* Tuesday, May 17, 2022 10:22
> *To:* Spencer Dawkins <spencerdawkins.ietf@gmail.com>
> *Cc:* tsv-art@ietf.org; anima@ietf.org;
> draft-ietf-anima-constrained-join-proxy.all@ietf.org; last-call@ietf.org
> *Subject:* Re: [Anima] Tsvart last call review of
> draft-ietf-anima-constrained-join-proxy-10
>
>
>
> Hi Spencer,
>
> thanks for your kind words.
>
> Indeed the answer is no. (at least for the coming 20 years).
>
> Greetings and thanks,
>
> Peter
>
> Spencer Dawkins via Datatracker schreef op 2022-05-17 01:09:
>
> Reviewer: Spencer Dawkins
> Review result: Ready
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
>
> This is a well-written specification. My only question - and I expect the
> answer will be “no” - is whether there is any concern that sizes of the
> resources that are being passed around might exceed the MTU between the
> pledge
> and the registrar, and whether there should be a mention of this
> possibility in
> the specification.
>
> Best,
>
> Spencer
>
>