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

[Tero Kivinen <kivinen@iki.fi>]

Stephen Kent writes:
> >	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).

But that item was still accepted by the working group. 

> 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 

For example I didn't say anything, because I think the proposed action
was ok, and should be accepted (the default in Barbara's email).

> have even been on the issue list in the first place, for the reasons 
> cited below.

I do not agree you reasons.

> >Would anyone on the mailing list like to comment?

Yes...

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

Why is it impractical? 

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

No. The text says that if we are DROPPING the packet because of the
missing IPsec protection. If we are dropping the packet, we already
know at that point that we are dropping it because there was no bypass
rule for it (it would not be dropped if there is bypass rule) or drop
rule.

The cases left are:

	1) It was packet that should have had IPsec protection
	2) It was completely random packet which was not covered by
	   any rule.

Now as we are already dropping the packet we can do some extra work
and verify which of those cases the packet belongs and send ICMP if it
is the first case (which is actually very easy to verify in normal
vpn-style setup, check the source IP, and if it matches the other end
VPN machine, the packet should have had IPsec protection).

I do not see any reason to check the SPD for every packet if we are
only concerned about cases where are going to drop the packet. 

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

This is not about conflict in this end it is conflict in the other
end. I.e. if the host B is configured to use IPsec if SA is availble
and host A is configured to only allow IPsec traffic through, this
will cause annoying problems, i.e. the links works when host A sends
packet and creates SA, then the host B decided to remove the SA
(reboot, cleanup, expire etc), and it will not create new SA, it will
send the traffic in clear. Host A will drop those packets because they
do not have protection, but immediately when Host A then decides to
create SA again (for example next packet for the TCP stream is sent
out), the traffic starts working again.

If we get ICMP in those cases it will be clear from the Host B side
that when the adminstrator sees from the logs that it have received
ICMP telling that communication adminstratively prohibited that there
is something wrong with setup, not in the network (which usually is
the first one to blame in this cases). 

> >>  If one restricted this to encompass only inbound packets that will be
> >>  discarded, then we may still incur a non-trivial search penalty, and

The issue 83 was only about the packets that are to be dropped. It
does not say anywhere that you should do anything for the packets
which are not to be dropped. 

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

That is the reason why it is configurable by the adminstrator, i.e.
they can turn them on while debugging the setup, and turn it off when
everything works. 

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

It is not imposed as a requirement. In the proposed issue #83 text it
was SHOULD, and if you think this is too costly we can dowgrade it to
MAY. This way if it is hard to implement on some architectures, then
you can leave it out, and other implemenations can implement it if
they see it as an usefull option. 
-- 
kivinen@safenet-inc.com