Re: Issue #83: Generation of ICMP responses for inbound packet requiring IPSEC protection

["Theodore Ts'o" <tytso@mit.edu>]

On Wed, Jan 28, 2004 at 05:56:30PM -0500, Stephen Kent wrote:
> Ted,
> 
> Issue #83 said:
> 
> 
> Title:		DROP'd inbound packet -- missing required IPsec protection

Um... that's interesting.  That's not what Karen had posted on
September 30th, nor what is currently in the roundup database here:

	https://roundup.machshav.com/ipsec/issue83

Was this proposed disposition of the issue (which you quoted below)
ever discussed on the mailing list?  

My search of the mailing list didn't discover much discussion
surrounding this issue, save Barbara's call for a working group last
call for the text as was stated in the Roundup issue tracker.

If it turns out that the proposed approach originally proposed in
Karen's e-mail of September 30th, and currently documented in the
roundup database is not right, we can certainly have that discussion
on the mailing list.

Would anyone on the mailing list like to comment?

						- Ted

> 
> Description
> ===========
> Should there be a defined ICMP response to be used (when dropping an 
> inbound packet that was not protected by IPsec) to indicate to the 
> sender that IPsec was required by the receiver who dropped the packet?
> 
> There is no text in 2401bis for this because it seems generally 
> impractical, at least as stated here.  It would require searching the 
> SPD for each inbound packet to see if the packet matches an SPD entry 
> that calls for application of IPsec. As stated above, this would be 
> done even for packets that already map to a valid bypass SA! The SPD 
> admin has a responsibility to create entries that do not conflict in 
> this fashion.  A vendor might choose to provide a facility to examine 
> an SPD and warn a user about such conflicts, but it makes more sense 
> to do so when the SPD is being managed, than when traffic arrives.
> 
> If one restricted this to encompass only inbound packets that will be 
> discarded, then we may still incur a non-trivial search penalty, and 
> we allow an attacker to probe the implementation to determine SPD 
> entries for IPsec-protected traffic, which hardly seems to be a good 
> idea, in general. So, while we agree that there would be some benefit 
> to notifying a peer when traffic is sent unprotected, when the 
> traffic should have been protected, it seems to be a costly feature 
> to implement and thus ought not be imposed as a requirement.
> 
> Steve