[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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