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

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Feb 2004 09:42:00 -0500

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Feb 2004 20:35:15 +0200

> formed and ought not have been raised in the first place (by us).

But that item was still accepted by the working group. 

> 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 

I do not agree you reasons.

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

Yes...

> >>  impractical, at least as stated here.

Why is it impractical? 

> >>  It would require searching the

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. 

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

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

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

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. 
-- 
[email-masked]

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 19 Feb 2004 08:56:38 -0800

If such an ICMP message is added, then the rate limiting
feature for this message must be a MUST requirement
and should not be left to the administrator.

One can not expect people that do not update virus definitions
to configure IPSEC related ICMP message rates.

Regards,

Bora

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 20 Feb 2004 14:40:43 +0200

Stephen Kent writes:
> So, if we don't adopt this proposal, each inbound, non-IPsec packet 
> that does not match an explicit bypass OR drop entry in the SPI-I 
> cache, triggers a check of the SPD-I. But if we adopt the proposal, 
> then every packet that is dropped, even if in response to an explicit 
> SPD-I cache entry, requires an SPD-S search.

Or the SPD-I cache entry can have information whether the ICMP will
need to be sent or not.

> you are right, in that I misunderstood the proposal. The searches are 
> triggered only for dropped traffic. But, that still imposes an 
> additional burden, as noted above.  also, the proposed text requires 
> that we be prepared to send an ICMP. At this point the proposed text 
> has allowed an attacker to cause a receiver to do a lot more work 
> than we currently do, and it could even turn the receiver into a DoS 
> source, by having it generate ICMP messages based on bogus source IP 
> addresses. Yes, the text called for this to be configurable, but we 
> should be aware that this allows a careless admin at site A to turn 
> his IPsec device into an ICMP generator that will affect Site C, 
> which strikes me as a bad idea, in general.

Thats why the sending of ICMP (or any other error messages) must be
rate limited (not per entry/peer, but per gateway), and the rate limit
must be configurable. The careless admin can do quite a lot of other
things, he might even have boxes root password as "root" and allow
attackers to use the machine as an attack box :-)

I do not think we can protect the careless adminstrators compeltely.
We as an implementators can but sensible defaults to those limits, and
for example disallow setting the limit too high (i.e. set the maximum
limit which can be configured to 10 ICMP messages / second and default
to 1 ICMP message / second). 

> I do not understand your example. How does one specify an SPD entry 
> that says put this traffic on an SA IF the SA exists, but don't 
> create one otherwise and just send the traffic in the clear?

This is the setup which is mostly used for opportunistic cases, i.e.
if you have SA up you use it, if you don't you can send the traffic
clear, or you can even try to create SA, and if it fails you send it
in clear.

This kind of setup can be used for normal web-traffic etc, where you
actually do not normally need to create IPsec SAs, but if you happen
to have SA up, you can use it (it does not cause any harm either). 

> I don't 
> think the SPD has ever been described in a way that would allow such 
> behavior.

Might be true, but there are implemenations which support this kind of
operations. 

> But the admin can't trust the source address for the ICMP messages, 
> so if he acts on them he is subject to spoofing. I agree that under 
> the right circumstances this feature could be a debugging aid, but it 
> also could be an attack tool.

The initiator will most likely simply log the ICMP and do nothing more
based on that. That will be enough to help debugging.

> That's a fair suggestion. the WG should ask whether the debugging 
> benefits that might accrue warrant a SHOULD or a MAY, vs. the added 
> performance hit for dropped traffic and the potential DoS concerns I 
> cited.

I think now that we should say it is MAY. 
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2004 09:38:35 -0500

>Or the SPD-I cache entry can have information whether the ICMP will

That might be a good alternative, but it's not at all what the 
proposed text said, and I thought your argument was that I had 
dismissed the proposed text without cause.  This constitutes a 
different proposal.  Not saying we can't consider it but just being 
clear about the scope.

>attackers to use the machine as an attack box :-)

yes, but assurance issues like that have always been outside the 
scope of what we specify in a standard.  this is different in that we 
are creating a feature that otherwise would not be present and which 
can be be mismanaged to the detriment of others.  again, I'm not 
saying the WG can't do this, but rather that the analogy you make it 
not quite parallel.

>to 1 ICMP message / second).

it's not the careless admin we are protecting, but rather protecting 
others from the carelessness of that admin.

>clear, or you can even try to create SA, and if it fails you send it

Sorry, but my comment still stands, i.e., I do not recall ANY way to 
specify such behavior via the SPD in 2401. This is something to which 
I do object, i.e., a fundamentally new access control behavior, not 
consistent with the long standing definition of what the SPD does.

>to have SA up, you can use it (it does not cause any harm either).

it makes behavior non-deterministic, which is generally a bad thing 
from a security perspective.

>Might be true, but there are implemenations which support this kind of

Then they are non-complaint.

>I think now that we should say it is MAY.

I think our discussion shows at least two things, neither of which 
lead me to the same conclusion :-)

	- the proposed text is defective in some respects
	- some of the supporting analysis is based on a change to the semantics
	  of the SPD, which I think is WAY out of scope for this discussion

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 21 Feb 2004 00:02:38 +0200

> from a security perspective.

In those cases the encryption is not for the real security, but simply
encryption just because it is fun, and it will cause more traffic in
the net to be encrypted, making large scale traffic analysis harder. 

> Then they are non-complaint.

Does the RFC2401 really say, that you cannot expand the SPD at all,
and all implementations MUST only support what is defined there. I
thought that it specified mostly the minimum requirements not exact
requirements what can and cannot be implemented (i.e. I would not call
those extended versions non-complaint, I would call them IPsec +
extensions versions :-).
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Feb 2004 11:22:53 -0500

>the net to be encrypted, making large scale traffic analysis harder.

this is a commonly cited notion, but there are analysis techniques 
that show that the notion is not valid in most cases :-)

>those extended versions non-complaint, I would call them IPsec +

we agree that 2401 specifies a minimum access control capability, but 
we may disagree about whether a non-deterministic SPD function 
represents an enhancement or a regression :-)

Steve