Re: [Hipsec] Relaying to non-hip aware servers
Hi Robert, On 09/27/2016 04:46 PM, Robert Moskowitz wrote: Where did we describe connections from a mobile hip-aware host to a legacy non-HIP 'stable' server. I thought it was HIPBONE (as it is not what HIP nat traversal is about), but I am not seeing this function there. Basically, the Mobile host has its HIP SA with a relay that decapsulates the ESP traffic onto legacy Internet. This can cause some nasty routing scenarios unless the HIP host can treat a group of relays as multihome interfaces or the like and use the best relay for any connection. Which would drive TCP/UDP crazy though? I recall through the window, darkly, that we had these discussions. But my search foo is weak and I am not finding them. proxy HIP: https://tools.ietf.org/html/draft-melen-hip-proxy-02 https://tools.ietf.org/html/draft-irtf-hiprg-proxies-05 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/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
