Re: [Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-rfc5206-bis-13: (with COMMENT)

Robert Moskowitz <rgm@htt-consult.com> Tue, 13 September 2016 09:14 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 C913C12B25C for <hipsec@ietfa.amsl.com>; Tue, 13 Sep 2016 02:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.709
X-Spam-Level:
X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, 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 z3Wyjm0fuLGK for <hipsec@ietfa.amsl.com>; Tue, 13 Sep 2016 02:14:20 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 6E05A12B25B for <hipsec@ietf.org>; Tue, 13 Sep 2016 02:14:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9BCDE62175; Tue, 13 Sep 2016 05:14:19 -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 qFmzZEo17fP6; Tue, 13 Sep 2016 05:14:14 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [5.148.40.66]) (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 3458662126; Tue, 13 Sep 2016 05:14:13 -0400 (EDT)
To: Mirja Kuehlewind <ietf@kuehlewind.net>
References: <147369048095.8941.13027964102448014990.idtracker@ietfa.amsl.com>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <8a78c1eb-25c2-ccd4-2276-6f4ac962273e@htt-consult.com>
Date: Tue, 13 Sep 2016 10:14:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <147369048095.8941.13027964102448014990.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/M7f5ys62ZdXYQu5IFSyQ1Pyu4f4>
Cc: hipsec@ietf.org
Subject: Re: [Hipsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-hip-rfc5206-bis-13=3A_=28with_COMMENT=29?=
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 13 Sep 2016 09:14:22 -0000

I have one question on sec 5.4 before I enter a comment...

On 09/12/2016 03:28 PM, Mirja Kuehlewind wrote:
> 5) section 5.4: How long will an address be in UNVERIFIED state in case
> the verification is not successful (no reply). Is there a timer? How
> often will the peer retry the verification test? How long does the peer
> wait until resending the verification packet?
>

It took me a couple readings of 5.4 to THINK I understand fig 7.

I THINK this occurs after Mobile Host has sent its HIP UPDATE with the 
new locator information.

I believe the implication of this figure is that the stationary node 
(peer host) sends its address validation HIP UPDATE and instead of 
receiving the HIP UPDATE with ACK, it receives actual data which it may 
interpret as the ACK.

So I have two points.

First does this only apply when there are new SPI?  What about a move 
with no SPI changes?

Second, the actual figure should include the original HIP UPDATE from 
Mobile Host to make it clear the nature of the mobility.

Sorry for the late review of this draft.

I can submit an official comment if others think my questions raise 
clarity issues.

Bob