Subject: 3rd try -- 2401bis issue 91 -- handling ICMP error messages

From: Karen Seo <[email-masked]>
Date: Mon, 27 Oct 2003 16:20:22 -0500

The first 2 attempts seem to have failed.  Trying again to get this 
message distributed by the list server.... The previous 2 attempts 
had "bold" characters in it and this one doesn't.  Apologies if 
you've received 3 copies.

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 engagements 
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

---

From: "Mike Taylor" <[email-masked]>
Date: Tue, 28 Oct 2003 09:00:46 -0800

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Karen Seo
> Sent: Monday, October 27, 2003 1:20 PM
> To: ipsec mailingList
> Cc: John Kelley; [email-masked]; [email-masked]; Angelos D.
> Keromytis; [email-masked]; [email-masked]
> Subject: 3rd try -- 2401bis issue 91 -- handling ICMP error messages
>
>

It seems to me that in general the description of handling
ICMP messages must be divorced from the presumption of any
a-priori knowledge on the part of the IPsec implementation as to which
networks are red and which are black, or which hosts are trusted
and which aren't.

Although I haven't completed this part of my IPsec implementation yet,
it looking forward it seems to me that one of the fundamental keys to
deciding how to handle ICMP messages should be based on the following
four possibilities:

	1. The ICMP message itself is protected by AH/ESP, i.e., is
	received within an IP datagram where the outermost IP
	header has ESP or AH as the protocol, but the IP datagram
	encapsulated by the ICMP message is not protected by AH/ESP.

	2. The ICMP message itself is not protected by AH/ESP, i.e.,
	the IP header contains protocol IP_ICMP, but the IP datagram
	encapsulated by the ICMP error message is of type AH or ESP.

	3. The ICMP message itself and the IP datagram that it encapsulates
	are both protected by AH and/or ESP.

	4. Neither the ICMP error message itself, nor the IP datagram that
	it encapsulates, are protected by AH/ESP.

To some extent we can infer from these four possibilites the "redness"
and "blackness" involved.  For example, in case 2 it seems likely that the
ICMP message is being returned by a router on a black network, whereas in
case 4 it seems likely that the ICMP message is being returned from a router
or host on a black network.

Perhaps a description of how to handle the messages in each of these
cases would be the best tact.  One objective would be be to avoid a
presumption
of some a priori knowledge by the IPsec implementation of which nets/hosts
are trusted/red and and which are not trusted/black.

>     be desirable to ignore such messages.

The above statement seems fundamentally incorrect to me.  In the simplest
case
of an IPsec VPN created by two SGs as in

	HostA ------- SGA -------------------- SGB -------- HostB

it is *anything* but generally desirable to ignore unauthenticated
ICMP error messages.  In fact, it would seem to me to be generally
desirable for *all* ICMP error messages sent from HostA to HostB
and vice-versa to be transported across the tunnel between SGA and
SGB, and all such messages will arrive at SGA/B unauthenticated in the
case where the hosts themselves are not running IPsec.

In fact, given a more complex topopoly like

	HostA ------- SGA ------------------ SGB -------- RouterB--------HostB

it would seem to be also to be generally desirable for *all* ICMP error
messages sent from RouterB in response to IP datagrams sent from HostA
to HostB to reach HostA.

Now whether IPsec can be used to achieve these aims without undue security
risks
is another matter.  But to say that tossing all unauthenticated ICMP
messages
would be how we'd like it to work in an ideal world seems patently false.

The text further below attempts to deal with the case of unauthenticated
ICMP error
messages received from trusted (red) hosts and routers so why leave the
above language
in 2401bis?  It was one of the pieces of text which most confused my when I
first
read 2401.

>     However, many ICMP messages

---

From: Stephen Kent <[email-masked]>
Date: Fri, 31 Oct 2003 13:08:04 -0500

>networks are red and which are black, or which hosts are trusted

Mike,

In general, IPsec provides a barrier wihtin a device (host, BITW, or 
SG), with red (friendly) interfaces on one side of the barrier and 
black (hostile) interfaces on the other. The SPD controls what we 
allow across the barrier, and whether we protect it or not.

If one wants to provide security services for each, individual 
interface, then one needs to think of applying IPsec to each 
interface independently, nominally replicating the Ipsec instance for 
each interface.  For example, if one has a security gateway with four 
interfaces, you could out IPsec on each interface card or you could 
have one Ipsec instance for the device as a whole, consistent with 
the model.

In most cases, the single instance, red/black model works pretty well.

the terms "trusted" and "untrusted" are not ones I like to use here. 
for example, we may establish a tunnel to an SG at a site, but that 
does not mean that we just trust the site. We apply selector checks 
on the packets that emerge from the tunnel precisely because we do 
not just trust the site or the remote SG.

Steve