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

[Stephen Kent <kent@bbn.com>]

At 18:22 -0500 1/30/04, Theodore Ts'o wrote:
>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

you are right Ted, the proposed text that Karen submitted is not 
consistent with what I said we have put in 2401bis. That's because I 
revisited the issue and realized that the it was more or less ill 
formed and ought not have been raised in the first place (by us).

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

no, I just put in in the text during the last editing pass.

>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.

My impression was that nobody said anything about this issue the 
list. we (BBN) had put on the list, and in retrospect, it should not 
have even been on the issue list in the first place, for the reasons 
cited below.

>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