Re: [Ipsec] Issue 91 - ICMP error message handling

[Karen Seo <kseo@bbn.com>]

Folks,

Please note that we sent the following message on April 13 with 
subsequent exchanges with:
	- Mark Duffy about case 2 (whether or not the receiver should
	  be doing the kind of checking we propose).
	- Rich Graveman re: clarifying that we believe this proposal
	  would work with ICMPv6.
	- Mohan Parthasarathy re: clarifying what we meant by checking
	  to see if the selector fields in the enclosed packet match
	  those of an existing SA, etc.

Karen

>X-Sender: kseo@po2.bbn.com
>Date: Tue, 13 Apr 2004 19:54:27 -0400
>To: ipsec@lists.tislabs.com
>From: Karen Seo <kseo@bbn.com>
>Subject: 2401bis -- Issue 91 -- handling ICMP error messages
>Cc: kseo@bbn.com
>X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
>Status:  
>
>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

>


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