[Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-native-nat-traversal-31: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 16 July 2020 01:32 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 486EE3A0865; Wed, 15 Jul 2020 18:32:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-hip-native-nat-traversal@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.8.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159486313728.32101.12876601376848387572@ietfa.amsl.com>
Date: Wed, 15 Jul 2020 18:32:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/u44giWmBKxvVtBPDrWfZcDH0HKY>
Subject: [Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-native-nat-traversal-31: (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: Thu, 16 Jul 2020 01:32:17 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-hip-native-nat-traversal-31: 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 addressing the potential "cross-message" attack on the HMAC
contents of RELAY_HMAC/RVS_HMAC by prohibiting the Control Relay Server
from offering the rendezvous services.  I think in order for the
protection against the attack to be complete, though, we need to say
that a HIP peer attempting to reach a Control Relay Server MUST reject
any messages appearing to originate from that server, that contain an
RVS_HMAC parameter.  That is, the current text will keep honest actors
from generating the bad situation, but we also want to protect ourselves
against accepting input from a bad actor attempting to cause the bad

Thank you as well for addressing all of my other comments on the -30.
They seem generally satisfactory, and my apologies for not responding to
them sooner.  I just have two remaining remarks:

Section 1

   tunneling overhead).  Another solution is specified in [RFC5770],
   which will be referred to "Legacy ICE-HIP" in this document.  The

nit: s/to/to as/

Section 4.6.2

   [RFC7401] section 5.3.5 states that UPDATE packets have to include
   either a SEQ or ACK parameter (but can include both).  According to
   the RFC, each SEQ parameter should be acknowledged separately.  In

I don't see anything to support "acknowledged separately"; on the
contrary, I see "A host MAY choose to acknowledge more than one UPDATE
packet at a time; e.g., the ACK parameter may contain the last two SEQ
values received, for resilience against packet loss."  Perhaps the
intent was "each SEQ parameter needs to be explicitly acknowledged"?