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).
Abstract
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
node.
E1---{G1}--{R1}--{G2}--{R2}--E2
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
E1/G1
is a network layer originator/target pair. NLO/NLT/
G1/G2
is a network layer originator/target pair.
G2/E2
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:
discard
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.
ISAKMP
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.
5. ICMP SA
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
IKE.
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
revealed.
The SPD for this SA should be configured to accept the union of all
sources and destinations for which communication is currently
configured.
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.
7. ISAKMP ICMP
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:
RFC-1825
R. Atkinson, "Security Architecture for the Internet Protocol",
RFC-1825, August 1995.
ICMPIPSEC
M. Richardson, "Options for handling ICMP messages that must be
forwarded" work in progress: draft-ietf-ipsec-icmp-options-00.txt,
September 1998
ICMPIPSECV4
M. Richardson, "IPv4 ICMP messages and IPsec security gateways"
work in progress: draft-ietf-ipsec-icmp-handle-v4.txt, September
1998
ICMPIPSECV6
M. Richardson, "IPv6 ICMP messages and IPsec security gateways"
work in progress: draft-ietf-ipsec-icmp-handle-v6-00.txt,
September 1998
ARCHSEC
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
RFC-1191
J. Mogul, S. Deering, "Path MTU Discovery", RFC-1191, November
1990.
KSM-AH
New AH draft.
Gupta97-1
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
Gupta97-2
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
RFC-1256
S. Deering, "ICMP Router Discovery Messages." Sep-01-1991.
RFC-1885
A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)." December 1995.
RFC-0791
J. Postel, "Internet Protocol." Sep-01-1981.
RFC-0792
J. Postel, "Internet Control Message Protocol.", Sep-01-1981.
RFC-0950
J.C. Mogul, J. Postel, "Internet Standard Subnetting Procedure."
Aug-01-1985.
Pip98
Piper, D., "The Internet IP Security Domain Of Interpretation for
ISAKMP", version 8, draft-ietf-ipsec-ipsec-doi-08.txt.
IKE
Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," draft-
ietf-ipsec-isakmp-oakley-06.txt.
9.1. Author's Address
Michael C. Richardson
Solidum Systems Corporation
940 Belfast Road
Ottawa, ON K1G 4A2
Canada
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]
