[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ICMP messages and per-port selectors
On Wed, Feb 25, 2004 at 01:38:59PM -0500, Stephen Kent wrote:
> Michael,
>
> >The essential premise of the later documents it that an ICMP message
> >such as a port-unreachable should be examined - the "quoted" IP packet
> >examined, reversed (src<->dst address/ports) and an SA found for it.
>
> Ultimately we may need to deal with ICMP messages arriving via an SA
> by looking at the "quoted" packet, but I would not suggest that one
> do it literally as described above. I worry about the delays and
> added complexity imposed on receivers re what we might consider "fast
> path" processing. We need to pick out ICMP traffic to perform the
> more in depth inspection this traffic requires. That observation
> motivated the idea of a separate SA for all ICMP traffic between two
> IPsec peers, where we can make first order decisions about accepting
> or rejecting this traffic based on message type and code. Then, for
> acceptable traffic, we can look inside to see what we have in the way
> of a returned packet and what to do with it.
This sounds efficient but all ICMP error types will still carry original
data which would require appropriate protection (cf. thread 'Traffic
selectors, fragments, ICMP messages and security policy problems').
There are certainly no widely available statistics on the amount of ICMP
traffic of each type on the Internet, but I think errors (likely,
destination_unreachable) are the most common. Thus, except for
Echo/Echo_Reply, there is almost no message which could politically cope
with a SA for all ICMP traffic, given the original data being carried.
A way out would be to get rid of original data; that is: when
forwarding, the gateway would erase any original data after those
which should be available for upper layer selectors check (which should
also be in most cases the same required for a minimal treatment of the
error on the host). This way, information disclosure is limited.
> We're not guaranteed
> that the 64-bytes we get with an IPv4 ICMP message will have porty
> fields, for example, so it is not always as easy as reversing the
> addresses and ports to match against an extant SA.
Can you give an example of these 64 BITS not carrying the adequate
information for upper layer selectors check ? Note that non-initial
fragments are not allowed in ICMP errors, and that the original data
should be *at least* 64 bits (as for rfc1122).
--
Jean-Jacques Puig
[homepage] http://www-lor.int-evry.fr/~puig/
Soutenez le mouvement SAUVONS LA RECHERCHE :
http://recherche-en-danger.apinc.org/