Shibu <pshibun...@gmail.com> wrote:
> PMTUD over IKE is needed anyways for large IKE cert payloads, so if we do
> PMTUD over IKE, we could depend upon the same discovered MTU value for
ESP
> paths as well as a guidance value. This seems to work for most of the
> cases, and there seems to be interest in the group towards this option. So
> this looks to be a good option overall, if we tackle IKEv2 window nuances
> effectively.
I agree. This handles 90% of the cases, except for bigger more nuanced
environments.
> However, one caveat with above approach is that there is an implicit
> assumption that paths for control and data traffic are same (i.e. IP
> based, 3 tupple paths).
> With SDWAN use cases (wherein paths could be orchestrated based on proto,
> port, QoS, App ID etc), would it be a precise assumption to make? How
> would we handle these cases when the paths are build for ESP and IKE
> differently?
I suggest that in such a situation, that *IKE* negotiate (probably just
Notify's to announce actually) the existence of a TCP endpoint that is within
the tunnel, and do PLMUTD over TCP across that to test things.
In some situations the IKE daemon would be able to do the connection attempt
itself, but in other situations, some other entity might have to do this.
Much of this is a local implementation problem only the Notify needs to be
standarized.
There might be IPv6 sockets API extensions that might be desired to get TCP
MTU information out the kernel, but that's not ipsecme's problem :-)
The IKE then needs to update the ESP machinery to know what the MTU of the
inside of the tunnel appears to be, and it should generate ICMPs if it's
bigger.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
