On Sat, 13 Sep 2014, Daniel Migault wrote:
In the Toronto meeting, we agreed that MOBIKE versionning must be removed in the next version of the draft. We also agreed that Security Consideration should discuss more in detail the exposure of the IP addresses. All these will be part of the next version.
Okay, good to know.
As a result, currently, when one receives USE_TRANSPORT_MODE and MOBIKE_SUPPORTED, it has to chose between supporting MOBIKE or the transport mode.
That makes sense to me, because combining the two does not really make sense.
Motivations for this are UDP (mostly DNS) but also GRE tunnels. In our opinion, for the DNS use case, saving bytes matters especially when only the responses is returned over a degraded link like WLAN.
What kind of differences do you meassure? Is it latency? less packet drops and retransmits? I take it that mobike ensures the DNS response still comes in on the correct IP, even if you have changed links. However, I would expect the DNS answer to get lost anyway if you are switching links and have to wait on a new IKE SA to be (re)established to re-gain an active IPsec SA that has your 'inner' IP on it. I would expect those delays to matter much more than shaving of a few bytes using transport mode instead of tunnel mode. I do need to readup on MOBIKE to further understand how one could even use transport mode SA's for something that's clearly meant as a tunnel mode SA. I do not understand how the outer IP is used while protecting the mobike inner IP. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
