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

Robert Moskowitz <rgm@htt-consult.com> Fri, 16 September 2016 07:58 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 26B0412B04D for <hipsec@ietfa.amsl.com>; Fri, 16 Sep 2016 00:58:16 -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 PxzmX4WQYAuJ for <hipsec@ietfa.amsl.com>; Fri, 16 Sep 2016 00:58:14 -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 399E412B44C for <hipsec@ietf.org>; Fri, 16 Sep 2016 00:58:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 1B3B962221; Fri, 16 Sep 2016 03:58:12 -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 FHyALP6i9h-J; Fri, 16 Sep 2016 03:57:55 -0400 (EDT)
Received: from lx120e.htt-consult.com (199.sub-70-194-67.myvzw.com [70.194.67.199]) (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 3EEC36221C; Fri, 16 Sep 2016 03:57:51 -0400 (EDT)
To: Tom Henderson <tomhend@u.washington.edu>
References: <alpine.LRH.2.01.1609152257460.24569@hymn02.u.washington.edu>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <e18b89f7-61c3-afb0-dc13-03141a37d515@htt-consult.com>
Date: Fri, 16 Sep 2016 08:57: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.1609152257460.24569@hymn02.u.washington.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/cN0nQA55zhVRMVJT1vvLom62UaQ>
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 07:58:16 -0000


On 09/16/2016 06:57 AM, Tom Henderson wrote:
>
>
>
> 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.

Correct, but this would be a NAT/Firewall traversal case.  And right now 
I am not reviewing that work as my project is 5GPP mobility with IPv6.  
I am looking at the 5206 case with the Responder found via RVS.

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

OK.

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

No.  This is what I am looking for.  And I am putting together an ID for 
a set of policies for accelerated mobility.

>
> - Tom
>
>

Bob