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

[Mark Duffy <mduffy@quarrytech.com>]

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:
>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
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec