[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: