[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Network Working Group      Michael Richardson mcr@sandelman.ottawa.on.ca
INTERNET-DRAFT                                  Sandelman Software Works
<draft-ietf-ipsec-icmp-options-00.txt>              v1.0, September 1998
Expires in six months

       Options for handling ICMP messages that must be forwarded

Status of This memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast),
or ftp.isi.edu (US West Coast).


This document discusses three options for securely communicating ICMP
messages from one IPsec security gateway to another. This document
expands upon section 6 of the IPsec architecture draft.

Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 1]

INTERNET-DRAFT                                      v1.0, September 1998

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
  1.1.  Definition of terminology   . . . . . . . . . . . . . . . . .  2
  1.2.  The end-to-end and transport cases  . . . . . . . . . . . . .  3
2.  Introduction to the problem   . . . . . . . . . . . . . . . . . .  3
3.  Why is this not a simple problem  . . . . . . . . . . . . . . . .  3
4.  Discard   . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
5.  ICMP SA   . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
6.  Implicit ICMP   . . . . . . . . . . . . . . . . . . . . . . . . .  4
7.  ISAKMP ICMP   . . . . . . . . . . . . . . . . . . . . . . . . . .  5
8.  Security Considerations:  . . . . . . . . . . . . . . . . . . . .  5
9.  References:   . . . . . . . . . . . . . . . . . . . . . . . . . .  5
  9.1.  Author's Address  . . . . . . . . . . . . . . . . . . . . . .  6
  9.2.  Expiration and File Name  . . . . . . . . . . . . . . . . . .  6

1.  Introduction

1.1.  Definition of terminology

Here is a network of two security gateways, a client node and a server


            E1 and E2 are end nodes using TCP or UDP.
            G1/G1 are security gateways.
            Rx are routers.

There are both application endpoints and security association endpoints,
they will be distinguished with the following terms:

   E1 is the transport layer originator. TLO

   E2 is the transport layer target.     TLT

      is a network layer originator/target pair. NLO/NLT/

      is a network layer originator/target pair.

      is a network layer originator/target pair.

In addition, it is necessary to distinguish three interfaces of the
security gateways at which a forwarding decision may need to be made:

   red interface
      is the interface that is exposed to the Internet
   black interface

Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 2]

INTERNET-DRAFT                                      v1.0, September 1998

      is the interface that is connected only to the internal network

   tunnel interface
      is the logical interface that results from a packet traversing an
      encrypted/authenticated tunnel and then decrypted. In general
      AH/ESP packets arrive on the red interface, are
      authenticated/decrypted (i.e. decapulated). The inner packet, once
      decapsulated can logically be thought to have arrived on a third
      interface for the purposes of forwarding policy.

1.2.  The end-to-end and transport cases

In the case where security gateways are not involved (i.e. the end-to-
end case), then the two end nodes (E1,E2) and the black interface can
simply be considered to be the on-board protocol stack.

2.  Introduction to the problem

The Internet Control Message Protocol (ICMP) is a protocol carried by IP
networks that is unlike  traditional protocols like TCP, UDP. ICMP deals
with meta information about the network. As such, ICMP messages are
really an integral part of a TCP/UDP flow and should get a similar
treatment by security gateways as the TCP/UDP flows themselves.

Consider a per-host ARCHSEC, section 4.4.2 or per-host keyed SA between
G1 and G2 on behalf of hosts E1 and E2. For reasons outlined in SMB96,
it is should be considered typical for gateways to implement per-host or
per-port keying.

Gateway G2 can receive ICMP messages from four places: G1, R1, R2 and
E2. Some of these hosts should legitimately be able to send ICMP
messages to host E1 or host E2. ICMPIPSECV4 and ICMPIPSECV6 makes a
determination of which of these hosts may be able to send which kinds of
ICMP messages.

This document describes three possible mechanisms by which gateways G1
and G2 may arrange for these reasonable ICMP message to be related to
either hosts E1 or E2.

3.  Why is this not a simple problem

The IPsec SPD defined in ARCHSEC and negotiated by IKE Pip98,  provides
for a set of selectors to determine the policy for determining admission
into an IPsec SA. An ICMP message from E2 to E1, from R2 to E1 and from
G2 to E1 will not satisfy the admission policy of G2.

Trivially G2 could be modified to permit ICMP messages to be transmitted
if they arrive on its black interface, or are generated internally.
However, upon exit from the tunnel at G1, G1 would consider these ICMP
messages to be violations of the SPD and would refuse to forward them.
It is for this reason that a more sophisticated solution must be
described, standardized and possibly negotiated with IKE.

Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 3]

INTERNET-DRAFT                                      v1.0, September 1998

Four methods of handling ICMP messages are described herein:

      the ICMP message is dropped

   explicit ICMP SA
      where a seperate SA is established for ICMP messages.

   implicit ICMP SA
      where the selector mechanism is modified to accept ICMP messages.

      where the pre-existing ISAKMP SA is used to relay information that
      would normally be carried by ICMP.

4.  Discard

The ICMP packet is dropped. The section on that type may give
suggestions about other actions that may be desireable for heuristic
reasons (i.e. do an PMTU probe), however, a compliant system may
completely ignore this ICMP packet.


Upon receiving an ICMP message from R2 or E2, G2 forward it using t an
SA configured to accept ICMP messages of this type/code. If no such SA
exists, it should, policy permitting, be created and negotiated with

The proposal parameters for this SA, if not explicitely configured,
should be at least as strong as any other SA that is currently being
used between the set of end-points. In particular, if encryption (ESP)
is being used for any data might be exchanged by the two security
gateways, then the same or better encryption should be used for this SA.
This restriction is because some ICMP messages echo parts of an
offending packet as part of their error processing. Should a weaker
encryption algorithm (or no encryption) be used, then data may get

The SPD for this SA should be configured to accept the union of all
sources and destinations for which communication is currently
The creation and subsequent use of this SA may reveal patterns of
traffic which one would not always want to reveal.

6.  Implicit ICMP

Upon receiving an ICMP message from R2 or E2, G2 forward it using the
SA-pair that was used to send the offending packet.  The difficulty is
in finding the right SA to associate with the ICMP message.

In many cases it is possible to use the copied packet that ICMP messages
will returns as a payload. The data contained as payload of the ICMP

Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 4]

INTERNET-DRAFT                                      v1.0, September 1998

message is to be treated as a packet. The tunnel exit SPD is to be
applied to this packet. This will result in the incoming SA on which the
packet arrived.  The corresponding outgoing SA should then be used to
send the packet.

At G1, (the other end of the tunnel), the ICMP message will be received.
It will fail the exit criteria of the tunnel. Noting that it is an ICMP
message of a type that should be put through the tunnel, G1 should be
able to again use the contained packet to lookup at SA. It can then
verify that the ICMP packet was received using the corresponding
incoming SA.

As an alternative, G2 could take the offending packet from the ICMP
message and swap the src/dst and src-port/dst-port and attempt to locate
an SA based upon this information.


Upon receiving an ICMP message from R2 or E2, G2 does not forward it.
Instead, it forwards this packet via the key management interface to the
key management system. The key management daemon will send an ISAKMP
Notify message to the other end. The definition of appropriate Notify
messages is left to the individual ICMP messages.

8.  Security Considerations:

This entire document discusses a security protocol.

9.  References:

      R. Atkinson, "Security Architecture for the Internet Protocol",
      RFC-1825, August 1995.

      M. Richardson, "Options for handling ICMP messages that must be
      forwarded" work in progress: draft-ietf-ipsec-icmp-options-00.txt,
      September 1998

      M. Richardson, "IPv4 ICMP messages and IPsec security gateways"
      work in progress: draft-ietf-ipsec-icmp-handle-v4.txt, September

      M. Richardson, "IPv6 ICMP messages and IPsec security gateways"
      work in progress: draft-ietf-ipsec-icmp-handle-v6-00.txt,
      September 1998

      R. Atkinson, S. Kent, "Security Architecture for the Internet
      Protocol", work in progress: draft-ietf-ipsec-arch-sec-07.txt,
      July 1998

Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 5]

INTERNET-DRAFT                                      v1.0, September 1998

      J. Mogul, S. Deering, "Path MTU Discovery", RFC-1191, November

      New AH draft.

      V. Gupta, S. Glass, "Firewall Traversal for Mobile IP: Goals and
      Requirements", draft-ietf-mobileip-ft-req-00.txt, work in
      progress: Jan. 20, 1997

      V. Gupta, S. Glass, "Firewall Traversal for Mobile IP: Guidelines
      for Firewalls and Mobile IP entities", draft-ietf-mobileip-
      firewall-trav-00.txt, work in progress: March 17, 1997

      S. Deering, "ICMP Router Discovery Messages." Sep-01-1991.

      A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6)
      for the Internet Protocol Version 6 (IPv6)." December 1995.

      J. Postel, "Internet Protocol." Sep-01-1981.

      J. Postel, "Internet Control Message Protocol.", Sep-01-1981.

      J.C. Mogul, J. Postel, "Internet Standard Subnetting Procedure."
      Piper, D., "The Internet IP Security Domain Of Interpretation for
      ISAKMP", version 8, draft-ietf-ipsec-ipsec-doi-08.txt.

      Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," draft-

9.1.  Author's Address

             Michael C. Richardson
             Solidum Systems Corporation
             940 Belfast Road
             Ottawa, ON K1G 4A2

             Telephone:   +1 613 244-4804
             EMail:       mcr@sandelman.ottawa.on.ca

Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 6]

INTERNET-DRAFT                                      v1.0, September 1998

9.2.  Expiration and File Name

This draft expires February 1999

Its file name is draft-ipsec-icmp-options-00.txt

Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 7]