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

Tom Henderson <tomhend@u.washington.edu> Mon, 19 September 2016 05:20 UTC

Return-Path: <tomhend@u.washington.edu>
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 5B1FE12B150 for <hipsec@ietfa.amsl.com>; Sun, 18 Sep 2016 22:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 M3YvHflrkUYw for <hipsec@ietfa.amsl.com>; Sun, 18 Sep 2016 22:20:06 -0700 (PDT)
Received: from mxout21.s.uw.edu (mxout21.s.uw.edu [140.142.32.139]) (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 53C6212B121 for <hipsec@ietf.org>; Sun, 18 Sep 2016 22:20:05 -0700 (PDT)
Received: from hymn03.u.washington.edu (hymn03.u.washington.edu [140.142.9.111]) by mxout21.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8J5JSQI030423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2016 22:19:28 -0700
Received: from hymn03.u.washington.edu (localhost [127.0.0.1]) by hymn03.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8J5JOY4010178; Sun, 18 Sep 2016 22:19:24 -0700
Received: from localhost (Unknown UID 24282@localhost) by hymn03.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8J5JOx3010173; Sun, 18 Sep 2016 22:19:24 -0700
X-Auth-Received: from [73.140.18.44] by hymn03.u.washington.edu via HTTP; Sun, 18 Sep 2016 22:19:23 PDT
Date: Sun, 18 Sep 2016 22:19:24 -0700 (PDT)
From: Tom Henderson <tomhend@u.washington.edu>
To: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <alpine.LRH.2.01.1609182219240.22396@hymn03.u.washington.edu>
User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.19.51218
X-PMX-Server: mxout21.s.uw.edu
X-Uwash-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, SINGLE_URI_IN_BODY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_PHRASE1_B 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_HIGHBIT 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0'
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/0Xl5I2CRNOGCdylhJGrQLjoItNA>
Cc: hipsec@ietf.org, Mirja Kuehlewind <ietf@kuehlewind.net>
Subject: Re: [Hipsec] =?iso-8859-15?q?Mirja_K=FChlewind=27s_No_Objection_on_dr?= =?iso-8859-15?q?aft-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 05:20:08 -0000

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

  
> 
> 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