Simplest proposal: do nothing

One simple answer to this problem is to ignore it: do not transmit ICMP messages at all through IPsec mediated virtual private networks. The purists would be unhappy, but would anyone notice?

One obvious stakeholder is network management people that would like to monitor branch office machines from a central location. The network management need for echo request/echo reply can be satisfied by the current system with either upper layer protocol agnostic tunnels, or with dedicated ICMP tunnels. One could also just use SNMP to determine uptime, however both ICMP and UDP based traceroute would no longer function.

In addition, if SG1/SG2 are providing an IP subnet to IP subnet tunnel (leased line emulation), which is by far the most common use of IPsec, then router R3 can easily indicate to E1 that E2 is down with ICMP unreachable messages, and E2 can quite clearly indicate that a given service is not available with an port unreachable message.

Router's R1 and R2 can not send any ICMP messages to E1, but that is a different problem, which will not be dealt with here. In the case of ICMP fragmentation needed, that is covered in detail in RFC2401.

So, the question is, under what circumstances does one need something better?

The answers is: whenever one is using more restrictive selectors than subnet/subnet. This applies to doing per-host SAs (because router R3 can not participate), and per-port SAs.

Per-port SAs are likely to be most common between end systems when no gateway's are involved.

What is the effect, in these cases, of simply forgetting about ICMP?

• with per-host SAs, one will not find out in a timely manner that the host with which one wishes to communicate is not online. Normally, this would be indicated by an ICMP host unreachable message from router R3. Given that IKE may have spent many miliseconds to seconds to set up the SA¹, and that TCP will try for up time a minute to reach the host, a user could wait a long time before a round robin DNS permits the user to connect to the backup machine.

• with per-port SAs, assuming that SG2 is the end point of the SA, not E2, all of the problems that occur with the per-host SA apply, plus, host E2 can not easily indicate that the host is up, but the service is not. While it is rare that a service is available on multiple ports with some kind of failureover, the situation where the host is alive, but the service is not becomes indistinguisable from the host being down. The end user, who has to wait for TCP to give up doesn't care about the distinction, but the people doing the trouble shooting may find reports that ``host X is down'' difficult to reconcile with what their network management tools say.

Again, the question is, what applications care the most about fail-overs, and would also use per-host or per-port SAs? The author suggests that any connection worth having failover machines for is also one which is of sufficient value that per-host or per-port SAs are warranted. That is, high value connections: online trading, airline reservations, etc.

At present, most high value transaction oriented exchanges use their own security systems (e.g. [TRADE], [SET]) but growing availability of IPsec on end systems may make it more desirable to use one system for all security needs.