Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis
On 09/27/2016 04:58 AM, Miika Komu wrote: Hi, On 09/27/2016 03:56 AM, Robert Moskowitz wrote: On 09/26/2016 09:08 AM, Miika Komu wrote: Hi, On 09/16/2016 02:45 PM, Robert Moskowitz wrote: 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". do you actually need the initiator's RVS for double jump? I think the 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. 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. 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. 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 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. Basically the nat-traversal draft is about connectivity checks (that traverse NATs), nothing much IPv4 specific there. Feedback is still welcome. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis
Hi, On 09/27/2016 03:56 AM, Robert Moskowitz wrote: On 09/26/2016 09:08 AM, Miika Komu wrote: Hi, On 09/16/2016 02:45 PM, Robert Moskowitz wrote: 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". do you actually need the initiator's RVS for double jump? I think the 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. I see, you really want to avoid packets being dropped. 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. 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 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. Basically the nat-traversal draft is about connectivity checks (that traverse NATs), nothing much IPv4 specific there. Feedback is still welcome. smime.p7s Description: S/MIME Cryptographic Signature ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis
On 09/26/2016 09:08 AM, Miika Komu wrote: Hi, On 09/16/2016 02:45 PM, Robert Moskowitz wrote: 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". do you actually need the initiator's RVS for double jump? I think the 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. 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. 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 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 ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis
Hi, On 09/16/2016 02:45 PM, Robert Moskowitz wrote: 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". do you actually need the initiator's RVS for double jump? I think the responder's RVS is enough. 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. 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 smime.p7s Description: S/MIME Cryptographic Signature ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
[Hipsec] Comment on VIA_RVS parameter - 5204 & 06 -bis
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. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
