[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fragmentation
Michael,
> >>>>> "Sami" == Sami Vaarala <sami.vaarala@netseal.com> writes:
> Sami> Since you can't rely on getting an icmp when your packet
> Sami> is too large, and you can't be certain that frags pass
> Sami> through routers, what is left?
>[...]
> This fails if there is ICMP hole between the near gateway and the
> originator. This is actually a very common occurance when one has an extruded
> host/subnet (i.e. the default route for the road warrior is through the
> tunnel) since the "other side" is the entire Internet.
Exactly. What I was saying was that maybe we shouldn't rely on
icmp. Yes, you can always say it's the clueless X that's the fault,
but the end result is that the tunnel isn't working as it's supposed
to be.
What I proposed was using an encrypted, ping-like protocol. Don't
rely on any icmp information (or lack of it) that you get from between
the IPsec endpoints. Instead, to ensure that you can pass a packet
of 1234 bytes between the endpoints, send an encrypted ping (or whatever)
of that size; if you get a reply, you can do that. Otherwise, you
can't (have to send a few retries, of course). No need to rely on icmp.
> There are various blackhole discovery protocols that have been written
> about. I don't have reference on them, sorry. The problem is usually that the
> stupid web-hosting company that you are trying to reach isn't clueful enough
> to turn it on.
Yes, exactly. For IPsec purposes, maybe one shouldn't rely too much on
the behavior of a third party. Moreover, icmp is unprotected, so you
will have to have heuristics for dealing with fake icmp messages.
I'm not too comfortable with defining a new mechanism that has
a function similar to an existing one. Yet, having dealt with enough
problems of this nature in practice, it is starting to seem
attractive.
-Sami
Follow-Ups:
References: