Re: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-fast-mobility-03.txt

Jeff Ahrenholz <> Mon, 06 April 2020 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01C973A0DC7 for <>; Mon, 6 Apr 2020 10:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5J2cTQmqfTah for <>; Mon, 6 Apr 2020 10:51:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06C2D3A08D7 for <>; Mon, 6 Apr 2020 10:51:11 -0700 (PDT)
Received: from ( by MBX081-W5-CO-2 ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 10:51:11 -0700
Received: from ([]) by ([]) with mapi id 15.00.1497.006; Mon, 6 Apr 2020 10:51:11 -0700
From: Jeff Ahrenholz <>
To: Robert Moskowitz <>, HIP <>
Thread-Topic: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-fast-mobility-03.txt
Thread-Index: AQHWCbvi6DKOIFN7WEO0AAerAVw7NqhsZHEA
Date: Mon, 6 Apr 2020 17:51:11 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-fast-mobility-03.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Apr 2020 17:51:34 -0000

Brief review below...

> I have updated the hip-fast-mobility draft.
> I welcome review.
> It will be used in an upcoming DRIP N-RID secure transport draft that will also include secure C2 transport.

General comments:

- Overall I think the draft looks good, it is a short read and quite straightforward.
  The TLDR: 
  1) include VIA_RVS more often (always in R1/I2), so peers always know how to reach you,
  2) don't wait for complete address verification for using an address
  3) piggyback upper layer data when possible

- What about IPv4? There is no mention of it. And no extension header field like IPv6.

- Did you consider the Credit-Based Authorization technique in section 3.3.2 of RFC 8046? You could maybe mention in this draft that it could optionally be used here? (Plays well / same concept as the send-before-verified.)
Section 5.4.1
"the datagram is sent separately after receipt of the HIP UPDATE from Host B."

This implies buffering packets after you've sent an UPDATE but waiting for UPDATE-ACK; we almost need a new association state "moving" because how long will you wait and buffer packets? What if the UPDATE-ACK is lost or not sent -- need to tear down?

In practice, sometimes we're seeing dropped packets during mobility (depends on how quickly host can acquire a new address after losing the old address). Also we recently removed the initial-packet-embargo from our implementation (buffering packets while waiting for BEX to complete) as the complexity wasn't warranted (e.g. upper layers typically retransmit; packets likely to be stale.)

Consider also switching interfaces, which may have differing MTUs (e.g. cellular/Ethernet failover.)

Section 8 Security Considerations:

Adding the VIA_RVS parameter to more packets -- any security considerations, since this is typically outside the signature? RFC 8004 indicates "The main goal of using the VIA_RVS parameter is to allow operators to diagnose possible issues" but here you're suggesting to use the address during shotgunning.

Below are some editorial nits:

Section 5.1

consider replacing:
"An implementation may be able to adjust the
   transport window size downward so that the higher layer could still
   fill it and the whole piece then still fit within the MTU."
"An implementation may be able to adjust the
   transport window size downward so that the higher layer could
   fit its data plus the UPDATE payload within the MTU."
s/others RVS/other's RVS/
5.3 and 5.4
s/of new address/of a new address/

5.5.1 and 5.5.2
s/wait from HIP UPDATE/wait for HIP UPDATE/

7. IANA Considerations
there is no PAYLOAD_MIC used here