[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ipsec] Issue 91 - ICMP error message handling
Hi folks,
We're down to what we believe is the last remaining issue for 2401bis. Once we come to closure on this issue and changes are made to the document, we think we'll be finished with the work on 2401bis.
In the original 2401 there was text describing the handling of path MTU but the handling of other unprotected ICMP messages was left as a local matter. On October 26, Karen posted the message included below that proposes a more complex algorithm for handling ICMP messages. There has been little discussion to date on this so Ted and I would like to propose the following:
1. Default position: if no one is interested in discussing this issue, we fall back to the text as it existed in 2401 which covers path MTU but is silent on other types of unprotected ICMP messages.
2. If you believe there are deficiencies or ambiguities in the original text on path MTU in 2401 please speak up!
3. If you feel we should take a different approach, such as that proposed by Karen, then start voicing your opinions.
We plan to give the working group 1 week to begin discussion on this topic. If there is no discussion within 1 week, we will go with the default position. Otherwise, if discussion commences, we're willing to invest a couple of weeks to reach a consensus direction on this issue.
Note: we're aware that the issue tracker is a little toasty at the moment, which is why I've included the text of Karen's Oct. 26 message below.
thanks,
Barb and Ted
Begin forwarded message:
From: Karen Seo <kseo@bbn.com>
Date: October 26, 2003 6:00:02 PM PST
To: ipsec mailingList <ipsec@lists.tislabs.com>
Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" <angelos@cs.columbia.edu>, kivinen@ssh.fi, kseo@bbn.com
Subject: 2401bis issue 91 -- Handling ICMP error messages
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 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
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec