[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