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

From: Barbara Fraser <[email-masked]>
Date: Tue, 8 Jun 2004 09:47:03 -0700

Hi folks,

We're down to what we believe is the last remaining issue for 2401bis. 
Once we come to closure on this issue and changes are made to the 
document, we think we'll be finished with the work on 2401bis.

In the original 2401 there was text describing the handling of path MTU 
but the handling of other unprotected ICMP messages was left as a local 
matter.  On October 26, Karen posted the message included below that 
proposes a more complex algorithm for handling ICMP messages.  There 
has been little discussion to date on this so Ted and I would like to 
propose the following:

1. Default position: if no one is interested in discussing this issue, 
we fall back to the text as it existed in 2401 which covers path MTU 
but is silent on other types of unprotected ICMP messages.

2. If you believe there are deficiencies or ambiguities in the original 
text on path MTU in 2401 please speak up!

3. If you feel we should take a different approach, such as that 
proposed by Karen, then start voicing your opinions.

We plan to give the working group 1 week to begin discussion on this 
topic. If there is no discussion within 1 week, we will go with the 
default position.  Otherwise, if discussion commences, we're willing to 
invest a couple of weeks to reach a consensus direction on this issue.

Note: we're aware that the issue tracker is a little toasty at the 
moment, which is why I've included the text of Karen's Oct. 26 message 
below.

thanks,
Barb and Ted

Begin forwarded message:

> From: Karen Seo <[email-masked]>
> Date: October 26, 2003 6:00:02 PM PST
> To: ipsec mailingList <[email-masked]>
> Cc: [email-masked], [email-masked], "Angelos D. Keromytis" 
> <[email-masked]>, [email-masked], [email-masked]
> Subject: 2401bis issue 91 -- Handling ICMP error messages
>
> Folks,
>
> Here's a description and proposed approach for handling ICMP error 
> messages.  Any mistakes/confusion are mine.  Steve has again 
> maintained plausible deniability by having out-of-town much of last 
> week and this that prevented him from reviewing this draft :-).
>
>  Karen
>
>
> IPsec Issue #:  91
>
> Title:          Handling ICMP error messages -- receiving (local and
>                 transit) and generating
>
>
> Description:
> ============
> I. Receiving (local and transit) an ICMP error message -- How does an 
> IPsec system know whether an ICMP error message comes from a trusted 
> source or not?  And what should it do in each case?  Note: IKEv2 
> supports selectors for ICMP message type and code, which can be used 
> to classify the ICMP messages.
>
>    1. If it arrives without AH or ESP protection, what to do is
>       currently a matter of local policy.
>
>       We will clarify the existing text that addresses this case (see
>       proposed approach below.)
>
>    2. If an ICMP message arrives on an SA, then it must be consistent
>       with the selectors for the SA, otherwise it will not be delivered
>       (since it will fail the SA access control checks). In general,
>       this suggests that security gateways should establish a tunnel
>       mode SA between themselves to carry ICMP traffic, something that
>       can be accomplished using the extant SPD parameter for next
>       protocol. One might want to further restrict the types of ICMP
>       messages that are authorized to traverse an SA, using ICMP type
>       and code selectors. However, care still has to be taken when
>       processing ICMP traffic that arrives via an SA, even an
>       ICMP-specific SA. The concern is that an ICMP message includes
>       what purports to be the header of the packet that triggered that
>       ICMP message, but additional checks are needed to verify that the
>       returned header is consistent with the address space associated
>       with the SA via which the ICMP message was received. For example,
>       an SG for Net A might receive an ICMP Destination Unreachable via
>       a tunnel from the SG for Net B, but the triggering packet might
>       refer to an address in Net C! Thus an implementation needs to
>       perform consistency checks on the triggering packets in received
>       ICMP traffic to detect and reject such behavior. However,
>       depending on the complexity of the network topology, such checks
>       may not detect all possible inconsistencies.
>
>       By using ICMP type and code, receivers can achieve additional
>       control in dealing with ICMP messages received on SAs.
>
> II. Generating an ICMP error message -- What should an IPsec system 
> (host or SG) do when it generates an ICMP error message?  What to do 
> in each case is currently a matter of local policy and could depend on 
> the type of ICMP error message.
>
> When it is necessary to generate an (outbound to the blackside) ICMP 
> error message, it is desirable to transit it via an appropriate SA, 
> for the reasons noted above.
>
> NOTE: Generating an ICMP message in response to an ICMP message is 
> prohibited by the ICMP protocol specifications [ICMP -- RFC 792], 
> [ICMPv6 -- RFC 2463].
>
> NOTE: ICMP messages that are not *error* messages SHOULD be handled 
> like any other messages.
>
> Proposed approach:
> ==================
> A. Update the 2401bis text to say:
>
> "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 
> issue 78 for PMTU minimum size recommendations]
>
> "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."
>
> Processing ICMP messages (receiving (local and transit) and generating)
>
> Consider a topology along the lines of:
>
>  
>       Host    SG         Rtr         SG     Host
>         X === A  ======== B  ======== C === Y
>
>        <------><----------------------><----->
>          Red             Black           Red
>
> red = traffic within security perimeter, could be protected by an SA 
> or not
> black = traffic outside security perimeter, could be protected by an 
> SA or not
>
>
> The IPsec implementation at A or C MUST be able to handle the 
> following cases (tunnel indicates IPsec protection):
>
>
>                 black       |        red
>                   ----------|----------
>                   |         |         |
>                   |  local  |         |
>                   |  /      |         |
>    (1) ICMP --------------------------------->
>                   |  \      |         |
>                   |   \  -------------------
>                   |    \-------tunnel-------->
>                   |      -------------------
>                   |         |         |
>                   |         |         |
>                   |         |  local  |
>                   |         |    \
>             <----------------------<---------- (2) ICMP
>                   |         |    /    |           
>                ________________  /     |
>             <-------tunnel-----/      |
>               ----------------        |
>                   |         |         |
>                   |         |         |
>                   |         |  local  |
>               ________________  /     |
>    (3) ICMP -------tunnel----->-------------->  
>                ----------------  \     |
>                   |         |    \  ________
>                   |         |     \--tunnel-->
>                   |         |       --------
>                   |         |         |
>                   |         |         |
>                   |         |      <--------- trigger packet
>                   |         |    /
>                   |         |   /     |
>                   |         |  ICMP ---------> (4)
>                   |         |   \     |
>                   |         |    \  ________
>                   |         |     \--tunnel--> (4)
>                   |         |       --------
>                  ____________         |
>     trigger pkt ----tunnel---->       |
>                  ------------  \      |
>                   |         |   \     |
>         (5) <------------------ ICMP  |
>                   |         |    /    |
>               ________________  /     |
>         (5) <-------tunnel-----/      |
>               ----------------        |
>                   |         |         |
>                   |         |         |
>     trigger pkt ------------->        |
>                   |         |  \      |
>                   |         |   \     |
>         (6) <------------------ ICMP  |
>                   |         |    /    |
>               ________________  /     |
>         (6) <-------tunnel-----/      |
>               ----------------        |
>                   |         |         |
>                    ----------|---------
>                             |
>
> I Receiving an ICMP error message destined for local delivery or 
> transit service
>
> (1) An ICMP packet is received without IPsec protection from the black 
> side, i.e., it is unauthenticated and from an untrusted source.  In 
> this case, the IPsec system:
>
>    (a) MUST perform standard IPsec processing on the ICMP packet --
>        with possible results of DROP, BYPASS, or IPsec required.
>
>    (b) If the ICMP packet passes (a), then additional ICMP-specific
>        checks SHOULD be performed to:
>
>        i. verify that the IP addresses in the header of the triggering
>           packet are consistent with the address space associated with
>           the SPD entry that matches the selectors of the ICMP message.
>           If the protocol and ports information is available, these
>           SHOULD also be checked for consistency with the SPD entry.
>
>       ii. ensure, for ICMP "packet too big" messages, a minimum PMTU
>           for IPv4 and IPv6 traffic (perhaps on a per destination
>           basis), to prevent receipt of an unauthenticated ICMP from
>           setting the PMTU to a trivial size.  Note: This is done at
>           this step even if the ICMP packet is not destined locally, on
>           the assumption that the destination host may not be running
>           IPsec and hence this IPsec system should do this check.
>
>    (c) If the ICMP packet passes (b), then
>
>        i. if the ICMP message is destined locally, it is passed along
>           for ICMP processing.
>
>       ii. if the ICMP message is transiting this system, standard
>           IPsec processing is done and the message is handled as
>           defined by the SPD -- DROP'd, BYPASS'd or provided with
>           IPsec protection.
>
>
>  (2) An ICMP packet is received without IPsec protection from the red 
> side, i.e., is unauthenticated but from a trusted source.  In this 
> case, the IPsec system:
>
>    (a) MUST perform standard IPsec processing on the ICMP packet -- 
> with
>        possible results of DROP, BYPASS, or IPsec required.
>
>    (b) If the ICMP packet passes (a) and is destined locally,
>
>        i. SHOULD perform ICMP checks to:
>
>           - verify that the IP addresses in the header of the 
> triggering
>             packet are consistent with the address space associated 
> with
>             the SPD entry that matches the selectors of the ICMP 
> message.
>             If the protocol and ports information is available, these
>             SHOULD also be checked for consistency with the SPD entry.
>
>           - ensure, for ICMP "packet too big" messages, a minimum PMTU
>             for IPv4 or IPv6 traffic (perhaps on a per destination
>             basis), to prevent receipt of an unauthenticated ICMP from
>             setting the PMTU to a trivial size.  Note: This is done at
>             this step even if the ICMP packet is not destined locally,
>             on the assumption that the destination host may not be
>             running IPsec and hence this IPsec system should do this
>             check.
>
>       ii. If the ICMP packet passes (i), then it is passed along for
>           ICMP processing.
>
>     (c) If the ICMP packet passes (a) and is transiting this system,
>         then the ICMP checks are left to the destination IPsec system,
>         standard IPsec processing is done and the message is handled
>         as defined by the SPD -- DROP'd, BYPASS'd or provided with 
> IPsec
>         protection.  In the last case, there are two options:
>
>         i. a tunnel set up just for ICMP messages.
>        ii. an SA whose selectors include those of the ICMP message.
>
>
> (3) An ICMP packet is received with IPsec protection from the black 
> side, i.e., is authenticated. Same action as for case (1).
>
> II. Generating ICMP packets
>
> The following cases assume that the triggering packet has passed 
> standard IPsec checks, i.e., not been DROP'd by policy.
>
> (4) An ICMP packet is being generated by the IPsec system in response 
> to a packet which came from the red side, i.e., unauthenticated but 
> from a trusted source.  In this case, the IPsec system MUST perform 
> standard IPsec processing on the ICMP error message.   Possible 
> actions are DROP, BYPASS or provide with IPsec protection.  In the 
> last case there are two options:
>
>     (a) send the ICMP packet on an SA set up just for ICMP messages.
>     (b) send the ICMP packet on an SA whose selectors include those of
>         the ICMP message.
>
> (5) An ICMP packet is being generated by the IPsec system (red side) 
> in response to a packet which came from the black side and was 
> protected by IPsec, i.e., authenticated.  Same action as for case (4).
>
> (6) An ICMP packet is being generated by the IPsec system (red side) 
> in response to a packet which came from the black side and was 
> unprotected by IPsec, i.e., unauthenticated and from an untrusted 
> source. Same action as for case (4).
>
>
> B. Add to Security Considerations:
>
> NOTE: SPD entries for ICMP error messages SHOULD mandate security as 
> strong as or stronger than the security required for traffic that 
> might trigger an ICMP error message.
>
>
> C. Update the selector and SPD sections to reflect IKEv2's support for 
> ICMP message type and code -- Add ICMP message type and code to the 
> list of selectors supported in the SPD and in IKEv2 to enable better 
> IPsec policy definition for the handling of the different kinds of 
> ICMP error messages when generating or receiving (local or transit) 
> ICMP error messages. There should be one selector for the pair 
> <type,code>, not two selectors.  (I got this wrong in the recently 
> distributed 2401bis draft.)
>
> Thank you,
> Karen
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Karen Seo <[email-masked]>
Date: Tue, 8 Jun 2004 19:48:11 -0400

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: [email-masked]
>Date: Tue, 13 Apr 2004 19:54:27 -0400
>To: [email-masked]
>Subject: 2401bis -- Issue 91 -- handling ICMP error messages
>Cc: [email-masked]
>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

---

From: Mark Duffy <[email-masked]>
Date: Wed, 09 Jun 2004 19:23:23 -0400

Hi Barb,

Karen has since re-posted her ICMP proposal of April 13, so I suppose it is 
that one that should be on the table, rather than the older one from Oct 26 
2003.

Neither of those proposals covers the path MTU discovery.  So I think PMTUD 
needs to be carried forward from 2401 (modified or not) in any 
event.  Whether to act on Karen's proposal should be a separate 
issue.  (Your item #3 seems to me to suggest that Karen's proposal is an 
*alternative* to the PMTUD text.)

--Regards, Mark

>proposes a more complex algorithm for handling ICMP messages.  There has
>been little discussion to date on this so Ted and I would like to
>propose the following:
>
>we fall back to the text as it existed in 2401 which covers path MTU but
>is silent on other types of unprotected ICMP messages.
>

---

From: Karen Seo <[email-masked]>
Date: Wed, 9 Jun 2004 23:12:52 -0400

Hi Mark,

>Karen has since re-posted her ICMP proposal of April 13, so I 
>suppose it is that one that should be on the table, rather than the 
>older one from Oct 26 2003.

	Yes.  Thank you.

>Neither of those proposals covers the path MTU discovery.  So I 
>think PMTUD needs to be carried forward from 2401 (modified or not) 
>in any event.  Whether to act on Karen's proposal should be a 
>separate issue.  (Your item #3 seems to me to suggest that Karen's 
>proposal is an *alternative* to the PMTUD text.)

	I've been meaning to do an updated write up for handling
	PMTU discovery.   I will try to get something out by next
	week.

Karen