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

From: Robert Moskowitz <[email-masked]>
Date: Thu, 15 Sep 2016 15:34:12 +0100

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.

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.

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.

---

From: Tom Henderson <[email-masked]>
Date: Thu, 15 Sep 2016 22:57:46 -0700 (PDT)

On Thu, 15 Sep 2016, Robert Moskowitz wrote:

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

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

> 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

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 16 Sep 2016 08:57:44 +0100

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

> 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

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 16 Sep 2016 12:45:27 +0100

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

---

From: Miika Komu <[email-masked]>
Date: Mon, 26 Sep 2016 16:08:19 +0300

Hi,

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

do you actually need the initiator's RVS for double jump? I think the 
responder's RVS is enough.

>> simultaneously), if I remember correctly.

Yes, the idea was to send I1 (or UPDATE) through all the available 
address pairs, but I think the idea is now achieved in a more controlled 
way in draft-ietf-hip-native-nat-traversal-13

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 26 Sep 2016 20:56:17 -0400

> responder's RVS is enough.

Then the Initiator's UPDATE must be successful before the Responder can 
perform its UPDATE successfully.  This way they can operate in parallel.

> address pairs, but I think the idea is now achieved in a more 
> controlled way in draft-ietf-hip-native-nat-traversal-13

I will look at that.  But what if there is no NATs to traverse? That 
there are 2+ interfaces, all native IPv6?

But I will review nat-traversal.

thanks

Bob

---

From: Miika Komu <[email-masked]>
Date: Tue, 27 Sep 2016 11:58:18 +0300

Hi,

> perform its UPDATE successfully.  This way they can operate in parallel.

I see, you really want to avoid packets being dropped.

> But I will review nat-traversal.

Basically the nat-traversal draft is about connectivity checks (that 
traverse NATs), nothing much IPv4 specific there. Feedback is still welcome.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 27 Sep 2016 05:25:29 -0400

> I see, you really want to avoid packets being dropped.

Draft on Fast Mobility schedule for publication on Wednesday. ;)

Just about finished with pre-draft reviews.

> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec