Ron Bonica writes: > Hi Valery, > > I am thinking like this....... > > - If we do nothing, tunnel performance is acceptable but > suboptimal. We can prevent blackholing by statically configuring > the tunnel MTU to a sufficiently low value. However, we cannot > take advantage of tunnels with larger PMTUs. > > - If we use IKE to exchange probes and acks, tunnel performance may > become totally unacceptable. In the situation where a) IKE > messages traverse a different path than encrypted payloads and b) > the PMTU associated with the IKE path is greater than the PMTU > associated with encrypted payload path, we may produce an inflated > estimate of the Tunnel MTU. This may lead to black holing.
And same happens, if the ESP packet path gots broken, but IKE path does not. This will lead to black holing. Or if the IKE path is broken but ESP works, the IKE will tear down the whole IKE SA (along with all Child SAs) and start over. Also as we are running TCP or similar inside the IPsec tunnel, that will most likely also notice that packets do not go through with that big MTU and will make packets smaller, or does something here disable end to end PMTUD... > So, our probe and acks have to be exchanged over the IPSEC tunnel. > At first I thought that the best way to do this was by exchanging > UDP messages. But you have a point. If we exchanged encrypted ICMP > Echo / Echo Response messages instead of UDP messages, there would > be slightly less code to write. Furthermore, we wouldn't need to > allocate a new UDP port. I am not really convinced about that yet. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec