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

Robert Moskowitz <> Fri, 16 September 2016 07:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26B0412B04D for <>; Fri, 16 Sep 2016 00:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.709
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PxzmX4WQYAuJ for <>; Fri, 16 Sep 2016 00:58:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 399E412B44C for <>; Fri, 16 Sep 2016 00:58:13 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B3B962221; Fri, 16 Sep 2016 03:58:12 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id FHyALP6i9h-J; Fri, 16 Sep 2016 03:57:55 -0400 (EDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3EEC36221C; Fri, 16 Sep 2016 03:57:51 -0400 (EDT)
To: Tom Henderson <>
References: <>
From: Robert Moskowitz <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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