Introduction

[RFC2401], a Security Architecture for the Internet Protocol describes the requirements of an IPsec implementation -- it specifically provides a set of selectors for use in a the Security Policy Database (SPD, section 4.4.1). The selectors are used to determine to which flows a security association (SA) will be applied to.

It seems trivial that ICMP flows can be protected by simply setting the ``protocol'' selector to that of the ICMP protocol (1 for IPv4), but it does not mandate any standard way to select which ICMP types and codes are to be included in the flow.

Similarly, RFC2407, The Internet IP Security Domain of Interpretation for ISAKMP, describes a way in which the contents of these selectors may be agreed upon by ISAKMP (RFC2408). Figure 2 in section 4.6.2 also includes a protocol ID which could easily be set to ICMP, but no clear method of communicating a desired ICMP code/type.

Given this situation, it is clear that two machines or security gateways could easily establish a security association that would permit them to exchange traffic of ICMP type.

The problem, which will be expanded upon in the next section, is that it is seldom useful to exchange all types of ICMP traffic in isolation of other network traffic. The exception is diagnostics messages (e.g. echo request/reply aka ping packets). It is here that we see that ICMP is not like the other protocols and needs special treatment.

Following the explanation of ICMPs uniqueness, a section will address the question of what whether or not it is worth fixing this limitation in IPsec.

It is assumed one will answer this question in the affirmative, the rest of this paper deals with pieces of the solution: extensions to the SPD, simple extensions to IKE, moderate complexity extensions to IKE, and full scale extensions to both the SPD and to IKE.

In order to adequately describe the problem, some network diagram must be assumed. It is presented in figure . This figure represents a situation with two security gateways that are seperate from the end-hosts. The case where one or both IPsec endpoints are in fact end-systems (the ``host to host'' case rather than the ``gateway to gateway'' case) can be for the purposes of this discussion to be understood by allowing the end systems E1 and E2 to simply be the upper layer (UDP/TCP/etc.) protocol stacks of the end hosts, while the SG1 and SG2 pieces are the lower layers of the protocol stacks.