Re: [core] [Anima] constrained resources at root for debugging connectivity

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 21 July 2021 19:36 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 013013A2694; Wed, 21 Jul 2021 12:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 amvgCUy8WEzw; Wed, 21 Jul 2021 12:36:26 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158013A2692; Wed, 21 Jul 2021 12:36:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 87BFE389FC; Wed, 21 Jul 2021 15:39:47 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9h8GnRfpkx2u; Wed, 21 Jul 2021 15:39:43 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DF8A7389FB; Wed, 21 Jul 2021 15:39:42 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9049154A; Wed, 21 Jul 2021 15:36:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>, "anima\@ietf.org" <anima@ietf.org>, "core\@ietf.org" <core@ietf.org>
In-Reply-To: <AM8P190MB097925B04E575071242002CFFDE39@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
References: <AM8P190MB097901225CE72EF7973ADCC4FD139@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM> <AM8P190MB09791181A1D8F74ECDC6F04FFD129@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM> <d2da849f46f57a410d28f47d4ed32f97@bbhmail.nl> <AM8P190MB0979B2CB8DEDB7E9FDCF9C73FDE19@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM> <6b1b6fc38752b6f0598d4289c7cfeb31@bbhmail.nl> <AM8P190MB0979C689144DE6989C5D33E7FDE29@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM> <8c3348a5adb2b2c0d0a4b615cadc75a6@bbhmail.nl> <AM8P190MB0979EC82DA418ECF74440BA9FDE29@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM> <57da5e79b97eeca3967da119a60b0ed6@bbhmail.nl> <AM8P190MB0979EBF594EA31877BFBED5DFDE29@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM> <18975.1626788349@localhost> <AM8P190MB097925B04E575071242002CFFDE39@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 21 Jul 2021 15:36:18 -0400
Message-ID: <25674.1626896178@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/6o4tikZUDKQDh0lnhpFOsSQezJo>
Subject: Re: [core] [Anima] constrained resources at root for debugging connectivity
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 21 Jul 2021 19:36:33 -0000

Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
    > There is already a "CoAP ping" described in RFC 7252 that can be
    > used. It does not access any resource, just the CoAP server endpoint at
    > CoAP message layer. As a side effect of this ping your DTLS stack will
    > set up the connection which is handy.

I recalled that later in the day that CoAP "ping" is not connected to CoAP
"echo" :-)
I think that there is also potentially a need for a way to debug possible MTU
issues.
Is there a way to use Olaf's "coap-client" to do the ping?
I don't see an option, and it also doesn't seem to be commonly built with DTLS.
We also have the issue of CCM8 vs OpenSSL that I thought got solved, but it
appears that it has not been, so one needs a tool built with mbedtls or wolfSSL.

    > So I don't think we need a resource at / that produces 2.05 , this is
    > for the maintainer of the server to decide how to allocate that
    > resource space.

    > Besides we have already defined some well-known resources accessible
    > with GET ( in core/est/brski) that the client could make use of to test
    > connectivity.

    > Even a non-existing resource in the /.well-known/X space could be used
    > just to get a 4.04 which confirms the server is working properly. This
    > is even better that trying to GET a resource of who knows how large
    > size.

BTW, I've changed my /version.json so that it now looks for and returns the
client certificate that it saw:

curl
        --cert spec/files/product/00-D0-E5-02-00-2E/device.crt
        --key  spec/files/product/00-D0-E5-02-00-2E/key.pem
        https://masa.honeydukes.sandelman.ca/version.json

->

{"version":"1.1.0","revision":"582044cfc536fd295e8bdcd3b90f30453d7784d3","Hostname":"masa.honeydukes.sandelman.ca","client_certificate":"-----BEGIN CERTIFICATE-----\nMIICBjCCAYugAwIBAgIEXKnlyDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQB\nGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3Ry\ndW5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa\nMBwxGjAYBgNVBAUMETAwLWQwLWU1LTAyLTAwLTJlMFkwEwYHKoZIzj0CAQYIKoZI\nzj0DAQcDQgAEey+I0TtIhm8ivRJY36vF5ZRHs/IwhQWRc2Ql70rN+aYLZPOIXYc6\nZzlO62kDYBo3IPrcjkiPVnhoCosUBpTzbqOBhzCBhDAdBgNVHQ4EFgQU/g+KaX9o\nDEKY2K3NGe7Vr/9geDAwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S\nAaATDBEwMC1EMC1FNS0wMi0wMC0yRTArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l\neWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNpADBmAjEAuEwTKPMzS/Xm\nAhR4tFtDo3YHoPoBsaw/6UUYDHot4EoKy2L8AlriFzti/iNmH67/AjEAnRjH2R0T\n98DZjBIhz7W8LM52AeymMdCtsJyuDRjtVuncGEfMO/OWuFFx5qwYR63I\n-----END CERTIFICATE-----\n"}

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide