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: [email-masked]
Date: Thu, 13 May 2004 22:57:03 -0400

Mohan,

>Karen,
>
>Just one clarification below..
>

[snip]

>  > >  -  The phrase "to ensure that the enclosed packet is consistent
>>  >with its source" could use some elaboration.
>>
>>  Good point.  Consistent --> the selector fields in the enclosed
>>  packet match the selector fields for an existing SA.
>>
>You mean "the selector fields in the enclosed packet match the selector
>fields for an existing SA only if it is found". It is possible (and 
>valid) to have an
>SA for protocol = icmp, type,code but not for the enclosed packet.
>
>-mohan
>
	Yes, that is what I meant.  However, a colleague has pointed
	out that it would be better to say that the selector fields
	of the enclosed (triggering) packet should be looked up in
	the SPD (SPD-S and SPD-O, not SPD-I) as follows:

	Checking in the SPD-S:

	   If a matching SPD-S entry is found (indicating that IPsec
	   protection is required), then the selector fields from the
	   triggering packet should be matched against the SAD entries
	   linked to the SPD-S entry to see if there is a currently
	   active SA.  If no SA match is found, then the triggering
	   packet is unlikely to have been recently sent legitimately
	   and the ICMP packet MUST be dropped. If a matching SA is
	   found, then the ICMP packet passes this check and its
	   processing continues.

	Checking in the SPD-O:

	   If a matching SPD-O entry is found that indicates DROP, then
	   the triggering packet should have been dropped, so the ICMP
	   packet MUST be dropped.

	   If a matching SPD-O entry is found that indicates BYPASS,
	   then the ICMP packet passes this check and its processing
	   continues.

	   If no matching SPD-O entry is found, the packet is unlikely
	   to have been recently sent legitimately and the ICMP packet
	   MUST be dropped.

	Note that there is no way to detect the case where an ICMP
	packet is being sent as an attack, the ICMP packet's selectors
	match an active SA, and the packet it contains happens to match
	a legitimate, active SA or match an SPD-O entry indicating
	BYPASS.

Thank you,
Karen

---

From: [email-masked]
Date: Thu, 13 May 2004 22:57:03 -0400

Mohan,

[snip]

	Checking in the SPD-S:

	Checking in the SPD-O:

Thank you,
Karen