Re: [Anima] [IANA #1229125] expert review for draft-ietf-anima-constrained-join-proxy (core-parameters)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 13 April 2022 17:46 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE43F3A1C76 for <anima@ietfa.amsl.com>; Wed, 13 Apr 2022 10:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 0OKTjEKYSJzF for <anima@ietfa.amsl.com>; Wed, 13 Apr 2022 10:46:46 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED783A1C72 for <anima@ietf.org>; Wed, 13 Apr 2022 10:46:45 -0700 (PDT)
Received: from dooku.sandelman.ca (desktop4.sandelman.ca [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 659FD1F4CB; Wed, 13 Apr 2022 17:41:05 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2C1601A0479; Wed, 13 Apr 2022 12:53:39 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Carsten Bormann <cabo@tzi.org>, anima@ietf.org
In-reply-to: <F0D00B7D-46F5-4793-AB7E-1FCE26554CB3@tzi.org>
References: <RT-Ticket-1229125@icann.org> <rt-4.4.3-25544-1649176784-236.1229125-9-0@icann.org> <rt-4.4.3-24361-1649176995-130.1229125-9-0@icann.org> <F0D00B7D-46F5-4793-AB7E-1FCE26554CB3@tzi.org>
Comments: In-reply-to Carsten Bormann <cabo@tzi.org> message dated "Tue, 05 Apr 2022 22:29:37 +0200."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 13 Apr 2022 12:53:39 -0400
Message-ID: <387436.1649868819@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/I3mXjmRHroqrwYqWvRrYUYgfBPo>
Subject: Re: [Anima] [IANA #1229125] expert review for draft-ietf-anima-constrained-join-proxy (core-parameters)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2022 17:46:51 -0000

Carsten Bormann <cabo@tzi.org> wrote:
    > IP address in the authority than the request address).  For brski.rjp,
    > this appears to be about discovering an entry point for a protocol that
    > I don’t seem to fully understand the description for.

    > I didn’t try to obtain a deep understanding of the protocol before
    > writing this, but I would prefer if the language used for the
    > description were understandable for other registrants in this registry,
    > i.e., discussing resources, not ports (port numbers?).

I think that it is a fair complaint that the way that we use brski.rjp is a
bit weird.

We aren't discoverying a thing we are going to speak *CoAP* or *CoAPS* to,
but rather something to which we are going to speak this stateless protocol
to.  (Having a good name for it might be a good idea)

Section 5.3 describes the protocol, but basically the Join Proxy encapsulate DTLS
messages from the Pledge in some CBOR:

       JPY_message =
       [
          ip      : bstr,
          port    : int,
          family  : int,
          index   : int
          content : bstr
       ]

This is solving the identical problem as RFC9031
   https://www.rfc-editor.org/rfc/rfc9031#name-statelessness-of-the-jp
but in the case of RFC9031, the security layer (OSCORE) is inside of CoAP,
so one can use the CoAP token to store the state.
In our case, the CoAP is *inside* the security layer (DTLS), so we can't do
that.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-