icmp echo_user

[Matus Harvan]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20071031/3445fc05/attachment.pgp