On Sat, 28 Mar 2015, su...@freescale.com wrote:
A new Internet Draft is posted to the working group. The draft addresses a problem where NAT is enabled dynamically (after IPsec SA is created) because of which traffic stops. The draft uses the existing IKEv2 framework (without defining any new payloads) and maintains backward compatibility with older implementations of IKEv2 that does not support this draft.
I was not aware this was a problem. So we should really support the use case. I'm not sure yet if this is the right approach. Does this typically happen "once" to a user, or these type of gateways keep switching the NATing on and off? If I'm correct, IKEv2 already requires peers to accept ESPinUDP even without NAT, and so an IKE peer could just enable that, upon which for at least tunnel mode, everything should keep on working. Detection of this based on ESP packets is a little tricky. It requires that the kernel makes a decision based on src/dst IP and existing policy to inform the IKE daemon in userland. Maybe this would be better attached to a liveness probe? There the IKE daemon itself becomes aware of the changed src/dst IP and could enable ESPinUDP. I think that would not even require a protocol change? Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
