2401bis -- Issue 91 -- handling ICMP error messages

[Karen Seo <kseo@bbn.com>]

Folks,

Following up on a discussion at the end of February/early March re: 
how to handle ICMP traffic... We were talking about how to carry ICMP 
traffic via an SA between two IPsec implementations.  This did NOT 
involve ICMP traffic that might be bypassed or consumed on the 
ciphertext side of the IPsec boundary.  Also, there are two 
categories of ICMP traffic -- error messages (e.g., type = 
destination unreachable) and non-error messages (e.g., type = echo). 
This discussion covered ONLY error messages.  Non-error ICMP messages 
should be explicitly accounted for in the SPD.

Two approaches were discussed:
	1. The sender of ICMP error message uses the (return) SA for the
	   packet that resulted in the ICMP error message.  In this
	   discussion, the SA was assumed to not be configured to
	   carry ICMP error messages.
	2. The sender of ICMP error message uses an SA that is configured
	   to handle ICMP error messages of the relevant type and code.
	   Note that while this case was viewed in the discussion
	   as being a different/separate SA from case 1 above, this SA
	   could be the same as case 1, if that SA were configured to
	   carry ICMP error taffic (in addition to user traffic). Note
	   also that the ICMP Type and Code for this SA could be set to
	   ANY, if there is no need to restrict the type of ICMP traffic
	   that it is allowed to carry.

Here's what needs to happen at the sender and receiver, to make each case work:
	For case 1:
		a. The sender notices that the packet is an ICMP error
		   message and diverts it to slow path processing. It
		   examines the enclosed packet (or portion thereof),
		   swaps the source and destination addresses and
		   ports, and performs an SPD lookup to find the SA
		   to use.  Then the ICMP packet is sent via the
		   the selected SA.

		b. The receiver notices that a packet has failed the
		   selector check (e.g., the source address or the
		   protocol does not match).  The packet is diverted
		   to slow path processing where it is observed to be
		   an ICMP error message and the enclosed packet
		   is examined.  The source and destination addresses
		   and ports are swapped and matched against the
		   selectors for the SA via which the ICMP packet was
		   received.  If they match, the ICMP message is passed
		   on for further processing, e.g., PMTU check.

		This case assumes that no further access control checks
		are desired for the ICMP packet.

	For case 2:
		a. The sender extracts ICMP type and code and does an
		   SPD lookup to find an appropriate SA. (The Sender
		   only does fast path processing.)
		b. The receiver processes the ICMP packet on the SA
		   via which it was received, verifying that the ICMP
		   type and code of the message match the selectors
		   for the SA. If they do, then the receiver passes
		   the ICMP message to slow path processing.  The
		   selectors of the enclosed packet are extracted
		   and matched against the SPD-S cache, to ensure
		   that the enclosed packet is consistent with its
		   source.  If they do, the ICMP message is passed
		   along for further processing, e.g., PMTU check.
		   (The receiver does both fast path and slow path
		   processing.)

		Note that an ICMP packet may arrive on an SA unrelated
		to the SA used for the triggering packet. The sender
		will use the first SPD or SPD-S cache entry that it
		comes to that is configured to carry ICMP traffic of
		the given type and code. Even if the SA for the
		triggering packet is configured to carry ICMP traffic,
		there may be an earlier entry in the SPD that matches
		the ICMP message's type and code. So one has
		to search the outbound SPD-S cache to verify whether
		or not there's an extant SA for the enclosed
		(triggering) packet.

Proposed approach
	To simplify the processing done by the Sender (of the ICMP
	message) to find the SA to use for sending the ICMP message
	and to support access control checks on the ICMP messages
	(using ICMP Message Type and Code) by the Receiver,
	we propose to use the second approach.

	Note: In the second approach, there is no requirement that
	the SA used for the ICMP message be dedicated only to ICMP
	messages. To minimize the number of SAs between two IPsec
	systems, an administrator may wish to configure the SPD such
	that the ICMP messages may be combined with other traffic,
	i.e., by specifying SPD entries that carry both normal
	traffic and ICMP traffic.

Comments?  Thank you,
Karen