Subject: ICMP messages and per-port selectors

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Feb 2004 13:21:09 -0500

-----BEGIN PGP SIGNED MESSAGE-----

Along time ago, I wrote a number of drafts about ICMP messages:

PMTU messages:
      draft-richardson-ipsec-pmtu-discovery.txt
      http://www.sandelman.ca/SSW/ietf/draft-richardson-ipsec-pmtu-discovery-00.txt

more recent ideas (discussed with the re-chartered PMTUD group already):
      draft-richardson-ipsec-fragment-00.txt
      http://www.sandelman.ca/SSW/ietf/ipsec/fragment/draft-richardson-ipsec-fragment-00.txt
      
on other ICMP messages:
      http://www.sandelman.ca/SSW/ietf/ipsec-icmp-handle-v4-01.txt
and   http://www.sandelman.ca/SSW/ietf/ipsec-icmp-options-01.txt

Tero Kivinen asked me to repost references to them. 

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.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Feb 2004 13:38:59 -0500

Michael,

>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.  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.

Steve

---

From: Jean-Jacques Puig <[email-masked]>
Date: Thu, 26 Feb 2004 10:07:44 +0100

On Wed, Feb 25, 2004 at 01:38:59PM -0500, Stephen Kent wrote:
> 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 

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/

---

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Feb 2004 09:36:16 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:
    >> 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.

    Stephen> Ultimately we may need to deal with ICMP messages arriving
    Stephen> via an SA by looking at the "quoted" packet, but I would
    Stephen> not suggest that one do it literally as described above. I

  That's fine.

    Stephen> returned packet and what to do with it.  We're not
    Stephen> guaranteed that the 64-bytes we get with an IPv4 ICMP
    Stephen> message will have porty fields, for example, so it is not
    Stephen> always as easy as reversing the addresses and ports to
    Stephen> match against an extant SA.

  No, but packets that are too small are probably also *not* useful to the
original sender. While a human might guess what they mean from tcpdump,
they won't get returned to any application that might be looking for the
hint that they should failover, etc.

  I generally like the idea of a seperate SA, but I don't think it
scales very well. I don't see the fast-path argument. The ICMP messages
that arrive will fail the fast-path checks - that's fine. 

  Like any packet that failed the fast-path checks, they should then go
somewhere to be logged/audited. That's already the slowpath, so no
difference. In fact, doing it this way gives us a better guarantee that
the fast-path is implemented/tested correctly, since we would regularly
be excersizing the slow-path.