RE: Issue 83 will be withdrawn

[Stephen Kent <kent@bbn.com>]

At 5:06 PM -0500 4/1/04, William Dixon wrote:
>This concerns me greatly. It was originally a "MUST FIX". Steve, can we have
>an explanation of why this was withdrawn and what mechanisms should be used
>instead ? I don't see solutions in Issue 91 to compensate.

There was extensive discussion of this issue, mostly involving Tero 
and me, in February. The concerns I cited were that

	- this would impose a significant burden on a receiver who 
would now have to check to determine if a packet that was dropped 
would have been OK f the packet were received on an SA. note that, as 
stated, the check would have to be conducted even if there was an 
explicit SPD entry calling for the packet to be dropped. one wants an 
efficient means of discarding inbound packets that are not IPsec and 
not to be bypassed, and this makes such processing hard (or at least 
harder). Tero suggested that one might add another SPD field to allow 
an admin to decide whether sending an ICMP was appropriate, when a 
packet matched an SPD-I drop entry, but no detailed proposal for 
doing this was developed.

	- it also adds complexity, because one should offer rate 
limiting for responses, e.g., to prevent an attacker from using this 
feature to cause a receiver to send ICMP traffic to sites because the 
source address of the packet that triggers the ICMP was spoofed. Tero 
and I disagreed over the tradeoff re the added complexity vs. the 
benefit that accrues for debugging when one site is sending traffic 
to another, in the clear, due to SPD mismatches, something that the 
sending of an ICMP might help detect.

I think it fair to say that this issue hinges on a value judgement, 
i.e., is the benefit of alerting a peer to this reason for discarding 
the peer's unprotected traffic worth the added complexity required to 
prevent this feature from creating performance problems and DoS 
problems.


>What was the TCP/IP or IPsec deployment purpose of those ICMP codes ?

These code already exist; they are not new. they are appropriate 
responses, in general, to alert a sender to the fact that traffic is 
being discarded due to security restrictions. the issue was whether 
we should send such messages under these circumstances.

Steve