Re: denial of service attack possible

[mouse () Collatz McRCIM McGill EDU (der Mouse)]

> > [Denial of service possible by remote host putting multiple
> >  connections to a port into the SYN_RCVD state, thereby precluding
> >  further (legitimate) connection attempts.]

> This problem is partly in the way how the interface on top of TCP/IP
> has been defined.  Had accept been defined in such a way that a
> connection request could be accepted and then rejected, there wuld
> not have been a problem.

It still could be done.  On (old) Ultrix, DECnet sockets could be put
into such a state, and there's no reason the same thing couldn't've
been done for TCP (indeed, perhaps it was and I just didn't notice).
As I recall, the interface was you did some setsockopt on the listening
socket, then accept() returned a socket in (the analog of) SYN_RCVD and
you had to do something - an ioctl, a setsockopt, something like that -
to accept or reject the connection before much else would work.  About
all you could do before doing the accept/reject was getsockname() and
getpeername(), I think - possibly some getsockopt/setsockopt calls
would work.

In TCP terms, accepting would release the kernel to generate the second
part of the three-way handshake; rejecting would probably produce an
RST, or maybe synthesize an ICMP Port Unreachable, though I don't like
the latter option because it amounts to telling a lie.  (It also could
cause trouble if the same machine sends you multiple SYN segments, some
of which you want to accept and some reject.)

> This backlog parameter also severely limits the number of
> connections/second an http server can accept.

Well, not quite: the listen backlog limit collaborates with network
round-trip delays and scheduling delays to produce the effective limit.

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu