Subject: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages

From: Stephen Kent <[email-masked]>
Date: Fri, 7 May 2004 15:26:46 -0400

mark,

Sorry for the delay in replying, but a two week vacation creates a 
mountain of mail. I disagree with Karen's offer to reduce the ICMP 
checking requirement to a MAY.  Let me explain my reasoning:

We already require a receiver to check selector values for each 
packet received via an SA to ensure that the received traffic is 
consistent with the selector values used to negotiate the SA.  At the 
highest level do this because we don't want to deliver traffic via an 
SA that is not consistent with the SA parameters. But, of course, the 
real reason is that we don't want to subject the hosts behind an 
IPsec implementation to attacks that would be feasible if we failed 
to do these checks on IP and transport layer headers.

For ICMP traffic you suggest that we have fulfilled this sort of 
protection requirement if we match the traffic against the IP address 
selectors, verify that the protocol is ICMP, and that the type and 
code fields, are acceptable, relative to the specified selectors. 
However, if we look to the underlying reason for the checks we 
perform, we see that it is the payload of the ICMP packet, in the 
case of error messages, that has the data we really want to check. 
The argument is that the host will make decisions based on the header 
of the packet that purportedly triggered the error response, and so 
we ought to try to ensure that this header info is consistent with 
the SA via which it is received. If we don't then, for example, 
anyone with whom we have an active SA could send us an ICMP 
destination dead message that refers to any host/net with which we 
may communicate, and effect a pretty efficient DoS attack.  So, the 
motivation for routing such traffic to a process in an IPsec 
implementation where this extended examination can be performed is 
motivated by this concern. One could choose to reject error messages 
using traffic selectors, to protect against such attacks, but that 
would diminish functionality considerably.

Also note that this is not a new notion.  Michael Richardson 
described this sort of processing in a memo some time ago.

Steve

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Mark Duffy <[email-masked]>
Date: Mon, 10 May 2004 18:08:31 -0400

Hi Steve,

I do not question that the checks on the icmp payload packet would provide 
an added measure of security -- I agree that they would.

However I would like to understand where we are drawing the line about what 
an  "IPsec implementation" should check.  Should it check for invalid 
combinations of control bits in a tcp header (e.g. SYN and FIN)?  Or for 
packets with src addr == dest addr?   Etc.

Is there something fundamentally different about checking the payload of an 
ICMP packet that is sent on an SA negotiated for protocol=icmp than there 
is about doing the other checks I mentioned?

--Mark

At 03:26 PM 5/7/2004 -0400, Stephen Kent wrote:
>We already require a receiver to check selector values for each packet 
>received via an SA to ensure that the received traffic is consistent with 
>the selector values used to negotiate the SA.  At the highest level do 
>this because we don't want to deliver traffic via an SA that is not 
>consistent with the SA parameters. But, of course, the real reason is that 
>we don't want to subject the hosts behind an IPsec implementation to 
>attacks that would be feasible if we failed to do these checks on IP and 
>transport layer headers.
>
>selectors, verify that the protocol is ICMP, and that the type and code 
>fields, are acceptable, relative to the specified selectors. However, if 
>we look to the underlying reason for the checks we perform, we see that it 
>is the payload of the ICMP packet, in the case of error messages, that has 
>the data we really want to check. The argument is that the host will make 
>decisions based on the header of the packet that purportedly triggered the 
>error response, and so we ought to try to ensure that this header info is 
>consistent with the SA via which it is received. If we don't then, for 
>example, anyone with whom we have an active SA could send us an ICMP 
>destination dead message that refers to any host/net with which we may 
>communicate, and effect a pretty efficient DoS attack.  So, the motivation 
>for routing such traffic to a process in an IPsec implementation where 
>this extended examination can be performed is motivated by this concern. 
>One could choose to reject error messages using traffic selectors, to 
>protect against such attacks, but that would diminish functionality 
>considerably.
>
>Also note that this is not a new notion.  Michael Richardson described 
>this sort of processing in a memo some time ago.
>
>Steve

---

From: Mark Duffy <[email-masked]>
Date: Mon, 10 May 2004 18:08:31 -0400

Hi Steve,

--Mark

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 May 2004 22:00:59 -0400

At 6:08 PM -0400 5/10/04, Mark Duffy wrote:
>Hi Steve,
>
>I do not question that the checks on the icmp payload packet would 
>provide an added measure of security -- I agree that they would.
>
>However I would like to understand where we are drawing the line 
>about what an  "IPsec implementation" should check.  Should it check 
>for invalid combinations of control bits in a tcp header (e.g. SYN 
>and FIN)?  Or for packets with src addr == dest addr?   Etc.
>
>Is there something fundamentally different about checking the 
>payload of an ICMP packet that is sent on an SA negotiated for 
>protocol=icmp than there is about doing the other checks I mentioned?
>
>--Mark

yes, Mark, there is. A single ICMP error message can disable all 
communication from the host that receives it to anther host or net, 
something a set of bad TCP control flags cannot do.

Steve

P.S. a reasonable SPD WOULD catch your source addrs = dest addr 
example in most cases since, to be delivered, the dest address would 
have to be behind the SG and that would not be a valid source address 
to traffic.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 May 2004 22:00:59 -0400

Steve