[Hipsec] Martin Duke's No Objection on draft-ietf-hip-dex-24: (with COMMENT)

Martin Duke via Datatracker <noreply@ietf.org> Tue, 16 March 2021 04:40 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: hipsec@ietf.org
Delivered-To: hipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4CD3A19C2; Mon, 15 Mar 2021 21:40:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-hip-dex@ietf.org, hip-chairs@ietf.org, hipsec@ietf.org, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, gonzalo.camarillo@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <161586963248.15578.17228311357709523869@ietfa.amsl.com>
Date: Mon, 15 Mar 2021 21:40:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/gPaSNo3_55PsLhH3jQDCMc0qUwE>
Subject: [Hipsec] Martin Duke's No Objection on draft-ietf-hip-dex-24: (with COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2021 04:40:33 -0000

Martin Duke has entered the following ballot position for
draft-ietf-hip-dex-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks for providing detailed data on why this sort of security compromise is
necessary. I am not a crypto expert, but wonder if there is some way to
leverage the potentially asymmetric capabilities of two HIP nodes to offload
more of the computation onto one of them.

- This is optional, but some suggest replacing the term "man in the middle"
with "on-path attacker". Please do it if you are amenable.

- Does HIP DEX always put version 2 in the version field, or is DEX somehow
orthogonal to HIP version?

- Thanks for the discussion of the I2 retransmission timeout in Sec 9. It
addressed my concerns in reading Section 4. The "reported delay + 1/2 maximum
RTT" formula seems like an odd heuristic for what ought to be "the reported
delay plus a little more", but it *does* limit a spoofed NOTIFY to no more than
doubling the retransmission rate.