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

[Robert Moskowitz <[e-mail]>]

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.

I see now.  As currently speced, R has no way of learning I's RVS. The 
'easy' way to fix this is for I to include a VIA_RVS in the I2 packet 
for mobility support.

"If you every want to get back to me, I can always be reached at this 
number".

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