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

[Stephen Kent <kent@bbn.com>]

At 14:40 +0200 2/20/04, Tero Kivinen wrote:
>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.

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.

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

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.

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

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

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

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.

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

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

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

Then they are non-complaint.

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

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