[Last-Call] Opsdir telechat review of draft-ietf-anima-constrained-join-proxy-10

Jürgen Schönwälder via Datatracker <noreply@ietf.org> Mon, 13 June 2022 10:43 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5556EC15948D; Mon, 13 Jun 2022 03:43:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Jürgen Schönwälder via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: anima@ietf.org, draft-ietf-anima-constrained-join-proxy.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165511700134.52257.16347015184784617646@ietfa.amsl.com>
Reply-To: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>
Date: Mon, 13 Jun 2022 03:43:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/WTHP7bI_KURW0VoDq8lTsfYK1gc>
Subject: [Last-Call] Opsdir telechat review of draft-ietf-anima-constrained-join-proxy-10
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2022 10:43:21 -0000

Reviewer: Jürgen Schönwälder
Review result: Has Issues

Thanks for considering my comments.

I am still struggling with the fact that the constrained Join
Proxy does allow attackers to send packets to arbitrary link-local
endpoints. The new security considerations text gives this advice:

   If such scenario needs to be avoided, the constrained Join Proxy MUST
   encrypt the CBOR array using a locally generated symmetric key.  The
   Registrar is not able to examine the encrypted result, but does not
   need to.  The Registrar stores the encrypted header in the return
   packet without modifications.  The constrained Join Proxy can decrypt
   the contents to route the message to the right destination.

The usage of MUST surely looks promising, but then protection
against this kind of attacks still is entirely optional ("if such
scenario needs to be avoided"). This relates to the other main
concern I had, namely that it is not particularly clear what is
required to be implemented as an interoperable baseline so that
at deployment time appropriate decisions can be taken.