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

[Jeff Ahrenholz <[e-mail]>]

Bob,
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."
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