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

[Robert Moskowitz <[e-mail]>]

Jeff,

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

Bob

On 4/6/20 1:51 PM, Jeff Ahrenholz wrote:
> 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
>