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

From: Robert Moskowitz <[email-masked]>
Date: Fri, 3 Apr 2020 09:28:56 -0400

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.

Stay tuned...

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-moskowitz-hip-fast-mobility-03.txt
Date: 	Fri, 03 Apr 2020 06:24:02 -0700
From: 	[email-masked]
To: 	Stuart W. Card <[email-masked]>, Adam Wiethuechter 
<[email-masked]>, Robert Moskowitz 
<[email-masked]>, Stuart Card <[email-masked]>

A new version of I-D, draft-moskowitz-hip-fast-mobility-03.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-hip-fast-mobility
Revision: 03
Title: Fast HIP Host Mobility
Document date: 2020-04-03
Group: Individual Submission
Pages: 9
URL: 
https://www.ietf.org/internet-drafts/draft-moskowitz-hip-fast-mobility-03.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-hip-fast-mobility/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-hip-fast-mobility-03
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-fast-mobility
Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-fast-mobility-03

Abstract:
This document describes mobility scenarios and how to aggressively
support them in HIP. The goal is minimum lag in the mobility event.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Jeff Ahrenholz <[email-masked]>
Date: Mon, 6 Apr 2020 17:51:11 +0000

Bob,
Brief review below...

> 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."
with:
"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."
   
5.2
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

-Jeff

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 6 Apr 2020 14:12:45 -0400

Jeff,

Thanks for the feedback.  After Passover, I will incorporate what I pull 
out of this.

Bob