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

Robert Moskowitz <rgm@htt-consult.com> Mon, 06 April 2020 18:12 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BE93A0E19 for <hipsec@ietfa.amsl.com>; Mon, 6 Apr 2020 11:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abjkHMGQDS-B for <hipsec@ietfa.amsl.com>; Mon, 6 Apr 2020 11:12:53 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937713A0E12 for <hipsec@ietf.org>; Mon, 6 Apr 2020 11:12:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id B6A0E62196; Mon, 6 Apr 2020 14:12:51 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EK+e5ZjZA5xQ; Mon, 6 Apr 2020 14:12:47 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id EEEF66218E; Mon, 6 Apr 2020 14:12:46 -0400 (EDT)
To: Jeff Ahrenholz <j.ahrenholz@Tempered.io>, HIP <hipsec@ietf.org>
References: <187f5430-1c5f-1ebe-7c81-1938fc7b9cd7@htt-consult.com> <245D00B8-98D9-4D3A-AAF6-DB16BE4C74FB@tempered.io>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <0242b8df-50a6-fb8d-02fc-8a3f76a1836e@htt-consult.com>
Date: Mon, 6 Apr 2020 14:12:45 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <245D00B8-98D9-4D3A-AAF6-DB16BE4C74FB@tempered.io>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/BXyuDYgjHGCB7FgPBS7yDGz1NMU>
Subject: Re: [Hipsec] Fwd: New Version Notification for draft-moskowitz-hip-fast-mobility-03.txt
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Mon, 06 Apr 2020 18:12:55 -0000

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
>