Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis

Tom Henderson <tomhend@u.washington.edu> Fri, 16 September 2016 05:58 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 E479E12B0B6 for <hipsec@ietfa.amsl.com>; Thu, 15 Sep 2016 22:58:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Mc1vwaoWpb8p for <hipsec@ietfa.amsl.com>; Thu, 15 Sep 2016 22:58:12 -0700 (PDT)
Received: from mxout22.s.uw.edu (mxout22.s.uw.edu [128.95.242.222]) (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 7F893126FDC for <hipsec@ietf.org>; Thu, 15 Sep 2016 22:58:12 -0700 (PDT)
Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout22.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8G5vleY026560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2016 22:57:47 -0700
Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8G5vkBP014371; Thu, 15 Sep 2016 22:57:46 -0700
Received: from localhost (Unknown UID 5440@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8G5vkZi014368; Thu, 15 Sep 2016 22:57:46 -0700
X-Auth-Received: from [73.140.18.44] by hymn02.u.washington.edu via HTTP; Thu, 15 Sep 2016 22:57:45 PDT
Date: Thu, 15 Sep 2016 22:57:46 -0700 (PDT)
From: Tom Henderson <tomhend@u.washington.edu>
To: Robert Moskowitz <rgm@htt-consult.com>
In-Reply-To: <6afe4119-3f13-b39a-62d8-fe361cfb9c95@htt-consult.com>
Message-ID: <alpine.LRH.2.01.1609152257460.24569@hymn02.u.washington.edu>
User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.16.54819
X-PMX-Server: mxout22.s.uw.edu
X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0'
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/-9dOZaXC73p42L8ZtH9cpRbjMMg>
Cc: hipsec@ietf.org
Subject: Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis
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: Fri, 16 Sep 2016 05:58:14 -0000



On Thu, 15 Sep 2016, Robert Moskowitz wrote:

> 5206-bis specifies how to user RVS for the 'double-jump' mobility problem.
>
> 3.2.3 1) says:
>
> 1. The mobile host sending an UPDATE to the peer, and not receiving an ACK, 
> MAY resend the UPDATE to a rendezvous server (RVS) of the peer, if such a 
> server is known.
>
> But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC parameters 
> and it had created a VIA_RVS parameter to send in the R1.

Yes, but the responder may not know the initiator's RVS even if the the responder's RVS was used, and it also may be the case that neither host's RVS was involved in the session setup.

> This VIA_RVS provides the knowledge and locator of the peer's RVS.
>
> In fact an aggressive mobility UPDATE would be sent simultaneously to the 
> host and its RVS.  If the host had not moved itself, it gets both and drops 
> the one from the RVS.

I believe that Baris Boyvat on the InfraHIP project was looking a while back at such an approach to fast mobility; it was called 'shotgun' approach to mobility and multihoming (try all candidates simultaneously), if I remember correctly.

>
> This comment recommends changes to 5204-bis 4.2.3 that the main goal of 
> VIA_RVS is to facilitate support for the double-jump mobility problem and 
> secondarily "to allow operators ...".
>
> And to 5206-bis section 3.2.3 to use the VIA_RVS to 'know' that there is an 
> RVS for the host and to optionally aggressively send HIP mobility UPDATES to 
> the RVS.
>

It seems to me that we ought to state that hosts should be prepared to handle duplicate mobility updates sent in parallel to different locators (such as to RVS(es) and to more than one of the host's addresses).  We could also state that the aggressiveness of a host replicating its UPDATES to multiple destinations, to try them in parallel instead of serially, is a policy choice outside of the specification.  Any other comments on this possible change?

- Tom