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

[Stephen Kent <kent@bbn.com>]

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