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

Robert Moskowitz <rgm@htt-consult.com> Mon, 19 September 2016 06:47 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 CE4F312B13F for <hipsec@ietfa.amsl.com>; Sun, 18 Sep 2016 23:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.517
X-Spam-Level:
X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, 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 YumegYllQXDT for <hipsec@ietfa.amsl.com>; Sun, 18 Sep 2016 23:47:06 -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 6B6CA12B0A1 for <hipsec@ietf.org>; Sun, 18 Sep 2016 23:47:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2B2C762149; Mon, 19 Sep 2016 02:47:05 -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 cdAFyNRnS5Cd; Mon, 19 Sep 2016 02:46:57 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [185.34.11.162]) (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 ECFDA615D8; Mon, 19 Sep 2016 02:46:54 -0400 (EDT)
To: Tom Henderson <tomhend@u.washington.edu>
References: <alpine.LRH.2.01.1609182219240.22396@hymn03.u.washington.edu>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <adc50cdf-3351-bad7-0172-14a56c9508e6@htt-consult.com>
Date: Mon, 19 Sep 2016 07:46:44 +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: <alpine.LRH.2.01.1609182219240.22396@hymn03.u.washington.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/GVbSCPzh7Ioshnmk13Dcy5nPFgA>
Cc: hipsec@ietf.org, Mirja Kuehlewind <ietf@kuehlewind.net>
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: Mon, 19 Sep 2016 06:47:08 -0000


On 09/19/2016 06:19 AM, Tom Henderson wrote:
> Bob, sorry for the delay in replying (inline below)
>
> On 09/13/2016 02:14 AM, Robert Moskowitz wrote:
>> 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.
> Yes.
>
>> 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.
> Yes, actual data that implies that the mobile host received its previous message at the new address.
>
>> So I have two points.
>>
>> First does this only apply when there are new SPI?  What about a move
>> with no SPI changes?
> I think the original intent may have been to cover the case where the UPDATE with ACK (the third leg of the handshake) was lost or slow to return, and that data plane may be faster at picking up the address change and using it immediately.
>
> However, I am not seeing the scenario with a new SA where there is not a third UPDATE, as in:
>
>    Mobile             Peer
> 1)        --UPDATE ->
> 2)        <--UPDATE-
> 3)        --UPDATE ->
>
> If message 2) has "NEW SPI in ESP_INFO (UPDATE)", then it will need a SEQ and a retransmission timer to protect it, until the packet 3) arrives with the ACK.
>
> In a move with no SPI changes, the draft says that a nonce like an ECHO_REQUEST should be exchanged (Figure 3).
>   
>> Second, the actual figure should include the original HIP UPDATE from
>> Mobile Host to make it clear the nature of the mobility.
> OK, I agree.
>
> I would be inclined to modify it something along the lines below.
>
>      Mobile host                                   Peer host
>
>                      ESP_INFO, LOCATOR_SET (UPDATE)
>                  ---------------------------------->
>
>                                                     prepare incoming SA
>                        NEW SPI in ESP_INFO (UPDATE)
>                  <-----------------------------------
>     switch to new outgoing SA
>                             data on new SA
>                  ----------------------------------->
>                                                     mark address ACTIVE
>
>                      ACk (UPDATE) (later arrives)
>                  ------------------------------------>
>
>               Figure 7: Address Activation Via Use of a New SA

This is much better.   Thanks

>
>    
>> Sorry for the late review of this draft.
>>
>> I can submit an official comment if others think my questions raise
>> clarity issues.
>>
>> Bob
>>
>> _______________________________________________
>> Hipsec mailing list
>> Hipsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/hipsec
>
>