[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ipsec] new ICMP text for 2401bis
Stephen Kent writes:
> 6.1 ICMP message not protected by IPsec
If I understood correctly this section covers the ICMP messages coming
from the "internet" side, i.e from the interface where we normally
receive ESP traffic?
So this section does not cover the unprotected ICMP messges coming
from the "insde" side, right?
Having picture here would really make things easier understand.
Something like:
(1) (3) (5) (7)
+------+/ +---------+/ \+---------+ \+------+
|Host A|------|SGW A(3a)|=== Internet ===|(5a)SGW B|-------|HOST B|
+------+ /+---------+ // +---------+\ +------+
(2) // (6)
(4) //
+----------------+/ //
|IPsec HOST C(4a)|=======//
+----------------+
Where Host A and B are non IPsec hosts, and SGW A and B are IPsec
Gateways, and IPsec HOST C is a host capable of talking IPsec itself
(but not a gateway). Numbers near the boxes refer to the interface at
that point. A double line "=" is used to mark IPsec connection (ESP
tunnel or similar) and number inside the box like "(3a)" refers a
traffic exiting from tunnel after decryption and authentication.
And then say that section 6.1 covers cases (3), (4), and (5).
> 6.2 ICMP messages protected by IPsec
Especially this title is hard to understand. I think it should say
something like "6.2 ICMP messages protected by or to be protected by
IPsec".
So this section covers traffic on numbers (2) and (6). And probably
also (3a), (4a) and (5a)?
> (This section does NOT apply to ICMP traffic that is bypassed or
> consumed on the ciphertext side of the IPsec boundary.)
>
> Both the payload of an ICMP error packet, and the header of the ICMP
> packet require checking from an access control perspective. If one of
> these packets is forwarded to a host behind a security gateway, the
> receiving host IP implementation will make decisions based on the
> payload, i.e., the header of the packet that purportedly triggered
> the error response. Thus an IPsec implementation SHOULD to try to
> ensure that this header information is consistent with the IPsec peer
> that transmitted the ICMP packet. If this sort of check is not
> performed, then for example, anyone with whom the receiving IPsec
> system (A) has an active SA could send an ICMP destination dead
> message that refers to any host/net with which A is currently
> communicating, and thus effect a highly efficient DoS attack re
> communication with other peers of A. Normal IPsec receiver
> processing of traffic is not sufficient to protect against such
> attacks.
Ok, this talks about the (3a), (4a) and (5a).... I.e. tunnel exit
checks.
> If no SA exists that matches the traffic selectors associated with an
> ICMP error packet, then an IPsec implementation MUST map an outbound
> ICMP error packet to the SA that would carry the return traffic
> associated with the packet that triggered the ICMP error packet.
> (This allows an administrator to explicitly account for ICMP error
> packets in SPD entries, causing them to bypass the payload check
> noted below. This results in reduced security for hosts, as noted
> above.) This requires an IPsec implementation to detect outbound ICMP
> error packets that map to no extant SA, and treat them specially with
> regard to SA creation and lookup. The implementation extracts the
> header for the packet that triggered the error (from the ICMP message
> payload), reverses the source and destination IP address fields,
> extracts the protocol field, and reverses the port fields (if
> accessible). it them uses this extracted information to locate an
> appropriate, active outbound SA. This implies that there must be an
> active SA for that traffic. An IPsec implementation MUST NOT create a
> new SA carry ICMP traffic error packets as a result of an attempt to
> transmit such packets.
And this talks packets coming at (2) and (6).
> If an IPsec implementation receives an IMCP error packet that does
^^^^ Typo
> not match the SA traffic selectors, the receiver also MUST process
I assume here "SA traffic selectors" referes to the normal traffic
selectors, like SA only for TCP 22 receiving ICMP host unreachable
with internal packet having TCP 22.
> the received message in a special fashion. Specifically, the receiver
> must extract the header of the triggering packet from the ICMP
> payload, and reverse fields as described above to determine if the
> packet is consistent with the selectors for the SA via which it was
> received. Only then is it safe to forward the ICMP message to the
> destination.
And this is again for the (3a), (4a) and (5a).
> The sender and receiver MUST support the following processing when
> ICMP error packets are sent over SAs with selectors that DO NOT match
> these packets:
"... DO NOT match these ICMP packets (but the packet inside the ICMP
message matches)"?
> a. If an IPsec implementation encounters an outbound ICMP
> error message for which no applicable SA exists, it
> extracts the header info from the payload, reverses the
> source and destination IP addresses, and, if accessible,
> the source and destination port fields. It uses the
> address, protocol, and port fields (if available) to
> perform an SPD lookup. If an appropriate, extant SA is
> found, the packet is transmitted via this SA. (No new SA
> will be created to carry an ICMP error packet.) If no
> suitable SA exists, the ICMP packet is dropped, an
> auditable event.
Looks good. So this covers packets coming from (2), and (6).
> b. If an IPsec implementation receives an ICMP error packet on
> an SA and the traffic selectors for that SA do not allow
> for the packet, a secondary check is performed. The
> receiver extracts the header info from the ICMP payload,
> reverses the source and destination IP addresses, and, if
> accessible, the source and destination port fields. The
> resulting values are compared to the selectors for the SA
> via which the ICMP packet was received. If the selectors
> match, the packet is forwarded, otherwise it it is
> discarded, and auditable event.
And this (3a), (4a) and (5a).
> B. The following text will be added to Security Considerations:
>
> An IPsec implementation is configured to pass ICMP error packets over
> SAs based on the ICMP header values, without checking the header info
> from the ICMP packet payload.
I think that needs some kind of rewording like "An IPsec
implementation can be configured ..." or similar.
> For example, a tunnel may be created between two sites that uses ANY
> for protocol and port fields and IP address ranges that encompass
> all systems behind the security gateways serving each site. In such
> cases, the hosts behind the security gateways will be vulnerable to
> DoS attacks that might be launched by other peers with which there
> are active SAs.
Perhaps we should describe the situation more here?
BTW, what about the old PMTU text? Do we copy the old RFC2401 PMTU/DF
processing stuff from there (section 6 and appendix B)?
--
kivinen@safenet-inc.com
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec