[Ipsec] new ICMP text for 2401bis

[Stephen Kent <kent@bbn.com>]

Folks,

The 2401bis text proposed below is based on a draft proposal sent on 
4/13 (plus some text from the original issue 91 write up in Oct 2003) 
and reflects list discussions with:
	- Mark Duffy about case 2 (whether or not the receiver should
	  be doing the kind of checking we propose) -- we believe the
	  receiver MUST do this checking.  (see Steve Kent's email of
	  May 7 and May 10)
	- Mark Duffy re: removal of text re: "fast path and slow path"
	  -- we agreed to remove it.
	- Rich Graveman re: clarifying that we believe this proposal
	  would work with ICMPv6
	- Mark Duffy and Mohan Parthasarathy re: clarifying what we
	  meant by checking "to ensure that the enclosed packet is
	  consistent with its source" and "to see if the selector
	  fields in the enclosed packet match those of an existing
	  SA, etc.
	- one BIG (but accommodating) change is that we dropped the requirement
	  to use a dedicated SA for ICMP error messages

--------

A. The following text will be placed in Section 6. "ICMP Processing".

This section discusses IPsec handling of ICMP traffic.  Please note that:

a. There are two categories of ICMP traffic -- error messages (e.g., 
type = destination unreachable) and non-error messages (e.g., type = 
echo). This section applies exclusively to error messages.  Non-error 
ICMP messages should be explicitly accounted for in the SPD.

b. This section applies to ICMPv6 as well as to ICMPv4.

c. A mechanism SHOULD be provided to allow an administrator to cause 
ICMP messages (selected, all, none) to be logged as an aid to problem 
diagnosis."


6.1 ICMP message not protected by IPsec

An ICMP message not protected by AH or ESP is unauthenticated and its 
processing and/or forwarding may result in denial or degradation of 
service.  This suggests that, in general, it would be desirable to 
ignore such messages. However, many ICMP messages will be received by 
hosts or security gateways from unauthenticated sources, e.g., 
routers in the public Internet. Ignoring these ICMP messages can 
degrade service, e.g., because of a failure to process PMTU message 
and redirection messages. Thus there is also a motivation for 
accepting and acting upon unauthenticated ICMP messages. To 
accommodate both ends of this  spectrum, a compliant IPsec 
implementation MUST permit a local administrator to configure an 
IPsec implementation to accept or reject unauthenticated ICMP 
traffic.  This control MUST be at the granularity of ICMP type and 
MAY be at the granularity of ICMP type and code.  Additionally, an 
implementation SHOULD incorporate mechanisms and parameters for 
dealing with such traffic. For example, there could be the ability to 
establish a minimum PMTU for traffic (perhaps on a per destination 
basis), to prevent receipt of an unauthenticated ICMP from setting 
the PMTU to a trivial size."  [See Section xxx for recommendations.]

6.2 ICMP messages protected by IPsec

(This section does NOT apply to ICMP traffic that is bypassed or 
consumed on the ciphertext side of the IPsec boundary.)

Both the payload of an ICMP error packet, and the header of the ICMP 
packet require checking from an access control perspective. If one of 
these packets is forwarded to a host behind a security gateway, the 
receiving host IP implementation will make decisions based on the 
payload, i.e., the header of the packet that purportedly triggered 
the error response. Thus an IPsec implementation SHOULD to try to 
ensure that this header information is consistent with the IPsec peer 
that transmitted the ICMP packet. If this sort of check is not 
performed, then for example, anyone with whom the receiving IPsec 
system (A) has an active SA could send an ICMP destination dead 
message that refers to any host/net with which A is currently 
communicating, and thus effect a highly efficient DoS attack re 
communication with other peers of A.  Normal IPsec receiver 
processing of traffic is not sufficient to protect against such 
attacks.

If no SA exists that matches the traffic selectors associated with an 
ICMP error packet, then an IPsec implementation MUST map an outbound 
ICMP error packet to the SA that would carry the return traffic 
associated with the packet that triggered the ICMP error packet. 
(This allows an administrator to explicitly account for ICMP error 
packets in SPD entries, causing them to bypass the payload check 
noted below. This results in reduced security for hosts, as noted 
above.) This requires an IPsec implementation to detect outbound ICMP 
error packets that map to no extant SA, and treat them specially with 
regard to SA creation and lookup. The implementation extracts the 
header for the packet that triggered the error (from the ICMP message 
payload), reverses the source and destination IP address fields, 
extracts the protocol field, and reverses the port fields (if 
accessible). it them uses this extracted information to locate an 
appropriate, active outbound SA. This implies that there must be an 
active SA for that traffic. An IPsec implementation MUST NOT create a 
new SA carry ICMP traffic error packets as a result of an attempt to 
transmit such packets.

If an IPsec implementation receives an IMCP error packet that does 
not match the SA traffic selectors, the receiver also MUST process 
the received message in a special fashion. Specifically, the receiver 
must extract the header of the triggering packet from the ICMP 
payload, and reverse fields as described above to determine if the 
packet is consistent with the selectors for the SA via which it was 
received. Only then is it safe to forward the ICMP message to the 
destination.

The sender and receiver MUST support the following processing when 
ICMP error packets are sent over SAs with selectors that DO NOT match 
these packets:

	a. If an IPsec implementation encounters an outbound ICMP error message
            for which no applicable SA exists, it extracts the header info from
            the payload, reverses the source and destination IP 
addresses, and, if
            accessible, the source and destination port fields. It 
uses the address,
            protocol, and port fields (if available) to perform an SPD 
lookup. If an
            appropriate, extant SA is found, the packet is transmitted 
via this SA.
            (No new SA will be created to carry an ICMP error packet.) 
If no suitable
            SA exists, the ICMP packet is dropped, an auditable event.

	b. If an IPsec implementation receives an ICMP error packet 
on an SA and the
            traffic selectors for that SA do not allow for the packet, 
a secondary
            check is performed. The receiver extracts the header info 
from the ICMP
            payload, reverses the source and destination IP addresses, and, if
            accessible, the source and destination port fields. The 
resulting values
            are compared to the selectors for the SA via which the 
ICMP packet was
            received. If the selectors match, the packet is forwarded, 
otherwise it
            it is discarded, and auditable event.

B. The following text will be added to Security Considerations:

An IPsec implementation is configured to pass ICMP error packets over 
SAs based on the ICMP header values, without checking the header info 
from the ICMP packet payload. For
example, a tunnel may be created between two sites that uses ANY for 
protocol and port fields and IP address ranges that encompass all 
systems behind the security gateways serving each site. In such 
cases, the hosts behind the security gateways will be vulnerable to 
DoS attacks that might be launched by other peers with which there 
are active SAs.

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec