[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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