Hi, On Wed, Mar 27, 2024, at 8:24 PM, Panwei (William) wrote: > Thanks for your and Michael’s clarifications. I’m much clearer now and I’m > convinced this is an useful draft. > I think it would be useful to add one or two sentences in the introduction. > An example is given below. > > However, because ESP packets do not share fate with IKE packets, it > is possible for the network to allow IKE packets but not ESP packets. > For example, the on-path firewall may allow UDP packets but discard ESP > packets, and IKE negotiation isn’t able to detect this. When NAT function is > not used as well, which is common in IPv6 networks, the IPsec session will by > default use unencapsulated IPv6 ESP. > This leads to the IPsec session not being able to exchange any > packets even though IKE negotiation succeeded. >
I wonder if ESP-ping can solve the opposite problem. It is also possible that because IKE and ESP are not tracked as same connection, on-path firewall may allow initial IKE SA setup and ESP to flow, but disallow rekeying. It is common in IPv6 networks to use unencapsulated IPv6 ESP, so the flow does not keep the UDP port used by IKE open. See https://github.com/strongswan/strongswan/issues/1759 for examples of this problem. I'm just a user amused by the fact that IPsec now works better on IPv4 than IPv6. Please excuse me if this is not a place to raise this question. Kan-Ru _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
