Re: icmp echo_user

On Sat, Oct 27, 2007 at 03:56:29AM +0100, Bruce M. Simpson wrote:
Matus Harvan wrote:
Hi,

I was wondering if I could get some feedback about the patch and
whether others think it could be committed.


Thanks for your hard work on mtund. I'm not keen on this patch going into
a mainline kernel, though.

In any case your feedback is appreciated.

It stomps on bandwidth limitation if that's in effect -- which is a
possible DoS vector -- and also stops updating icmp protocol counters.

I am not sure bandwidth limitation should be enforced for
receiving an icmp echo. ip_icmp.c:471
if (badport_bandlim(BANDLIM_ICMP_ECHO) < 0)
goto freeit;
was meant to limit sending out echo replies or for limiting the
receiving of echo requests?

I believe we should track echo requests in netstat -p regardless of whether
the kernel calls icmp_reflect() or not, as it can readily be inferred if a)
your diversion to SOCK_RAW is in effect or b) the kernel processed the echo
request.

I do not have a strong opinion about updating the counters so I
updating them is fine.

You mean only icmpstat.icps_bmcastecho? Or is there another counter
getting updated somewhere else?

I also believe that a user who installs and configures the tunneling daemon
is in a position to know that the ICMP thresholds need to be changed.

Assuming the tunneling daemon doesn't process echoes unrelated to its
tunneling (I haven't read the code), then the fact that rip_input() may
exhaust its socket input buffer will provide a basic form of hysteresis,
however I would suggest that if you intend to deploy this on the open
Internet that the daemon either a) provides its own hysteresis too, b)
tunes itself around the bandwidth limit in effect or c) tunes the bandwidth
limit itself.

Currently mtund tries to process anything it receives on its
socket. The first byte of the received payload is used to determine
the type of the traffic, so some random garbage would be discarded
while other random garbage would be interpreted as a tunneled packet
and passed into the tun interface. Later on it would probably fail a
(higher laer protocol) checksum.

The daemon tries to process as much traffic as it can. To me the
bandwidth limit did not seem very useful in the mtund case. If there
is "legitimate" (tunneled) traffic via ICMP then I don't think it
makes sense to enforce a limit on it.

In general my feeling was that the amount of data or rate of packets
received on a raw socket should not be bandwidth limited. Is there a
bandwidth limit on receiving for example (legitimate) UDP or TCP
traffic?

A better approach would be to conditionalise the 'goto raw' next to the
'goto reflect'.

So what you're suggesting is the following, right?

case ICMP_ECHO:
if (!icmpbmcastecho
&& (m->m_flags & (M_MCAST | M_BCAST)) != 0) {
icmpstat.icps_bmcastecho++;
break;
}
icp->icmp_type = ICMP_ECHOREPLY;
if (badport_bandlim(BANDLIM_ICMP_ECHO) < 0)
goto freeit;
else {
if (icmpechouser)
goto raw;
else
goto reflect;
}


In case icmpechouser is enabled

* should the packet be dropped if it was multicast/broadcast and
icmpbcastecho is disabled?

I guess yes.

* should the packet be subject to bandwidth limitations from
badport_bandlim(BANDLIM_ICMP_ECHO)?

IMHO not as it is passed to a raw socket rather than the kernel
producing an icmp echo reply in response.

Matus

Attachment: pgpr3nALLOZhN.pgp
Description: PGP signature

Relevant Pages