[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3rd try -- 2401bis issue 91 -- handling ICMP error messages
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Karen Seo
> Sent: Monday, October 27, 2003 1:20 PM
> To: ipsec mailingList
> Cc: John Kelley; byfraser@cisco.com; tytso@mit.edu; Angelos D.
> Keromytis; kivinen@ssh.fi; kseo@bbn.com
> Subject: 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.
It seems to me that in general the description of handling
ICMP messages must be divorced from the presumption of any
a-priori knowledge on the part of the IPsec implementation as to which
networks are red and which are black, or which hosts are trusted
and which aren't.
Although I haven't completed this part of my IPsec implementation yet,
it looking forward it seems to me that one of the fundamental keys to
deciding how to handle ICMP messages should be based on the following
four possibilities:
1. The ICMP message itself is protected by AH/ESP, i.e., is
received within an IP datagram where the outermost IP
header has ESP or AH as the protocol, but the IP datagram
encapsulated by the ICMP message is not protected by AH/ESP.
2. The ICMP message itself is not protected by AH/ESP, i.e.,
the IP header contains protocol IP_ICMP, but the IP datagram
encapsulated by the ICMP error message is of type AH or ESP.
3. The ICMP message itself and the IP datagram that it encapsulates
are both protected by AH and/or ESP.
4. Neither the ICMP error message itself, nor the IP datagram that
it encapsulates, are protected by AH/ESP.
To some extent we can infer from these four possibilites the "redness"
and "blackness" involved. For example, in case 2 it seems likely that the
ICMP message is being returned by a router on a black network, whereas in
case 4 it seems likely that the ICMP message is being returned from a router
or host on a black network.
Perhaps a description of how to handle the messages in each of these
cases would be the best tact. One objective would be be to avoid a
presumption
of some a priori knowledge by the IPsec implementation of which nets/hosts
are trusted/red and and which are not trusted/black.
>
> 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.
The above statement seems fundamentally incorrect to me. In the simplest
case
of an IPsec VPN created by two SGs as in
HostA ------- SGA -------------------- SGB -------- HostB
it is *anything* but generally desirable to ignore unauthenticated
ICMP error messages. In fact, it would seem to me to be generally
desirable for *all* ICMP error messages sent from HostA to HostB
and vice-versa to be transported across the tunnel between SGA and
SGB, and all such messages will arrive at SGA/B unauthenticated in the
case where the hosts themselves are not running IPsec.
In fact, given a more complex topopoly like
HostA ------- SGA ------------------ SGB -------- RouterB--------HostB
it would seem to be also to be generally desirable for *all* ICMP error
messages sent from RouterB in response to IP datagrams sent from HostA
to HostB to reach HostA.
Now whether IPsec can be used to achieve these aims without undue security
risks
is another matter. But to say that tossing all unauthenticated ICMP
messages
would be how we'd like it to work in an ideal world seems patently false.
The text further below attempts to deal with the case of unauthenticated
ICMP error
messages received from trusted (red) hosts and routers so why leave the
above language
in 2401bis? It was one of the pieces of text which most confused my when I
first
read 2401.
> 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