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

Reply via email to