Valery Smyslov writes:
> > Both good points. So, it appears that we have the following choices:
> > 
> > - leverage IKE for exchanging probes and acks  (But risk sending probes and 
> > acks over a different path than
> > encrypted data)
> > - send probes and acks in-band. Try UDP probes first. If that doesn't work, 
> > try TCP probes.
> What about ICMP-only SAs (yeah, it's weird, but possible)?
> > Which do you think is better?
> Both don't look ideal. I slightly prefer the former, as it looks
> simpler to implement (at least for me), but the issue with different
> paths can outweigh all. One potential solution to this issue would
> be to always use UDP encapsulation, but I'm not sure we may impose
> such a requirement... Your opinion?

I would just use IKE packets, and ignore the cases where ESP and IKE
get different routes which have different MTUs. I would expect that in
most cases if there is something in the middle using different MTUs
then the routes are not equal cost anymore, thus routing will use only
one of the routes. Usually the issues with MTU comes with road
warriors connecting from random locations around the world, and in
most of the cases there will be NAT for IPv4 in the middle, which will
move all traffic to UDP anyways.

Do we have any real world examples where the ESP and IKE packets
consistently take different routes, and those different routes have
different MTUs? And does all ESP traffic follow always one route, and
all IKE traffic follow another route, or is it more random or based on
the SPI or something?

I do not know enough to really say whether such cases exists or do not
exists, but before we start to make complicated protocols to cope with
cases which are very rare, I want to get more information.

If those cases are very rare, I might still want to make sure IPsec
works somehow, even if it is not as efficient as it could be (i.e.,
there might be extra fragmentation happening or finding proper MTU
might take more time). 

IPsec mailing list

Reply via email to