[nsd-users] NSD TCP performance

[nsd at dclg.ca]

>>>>> "Andrew" == Andrew Sullivan <andrew at ca.afilias.info> writes:

Andrew> On Fri, Nov 09, 2007 at 12:06:20PM -0500, nsd at dclg.ca wrote:
>> I'd like to have a look at this patch.  Maybe the patch can be
>> worked ina more acceptable manner.  My client is very concerned
>> about TCP performance because of DNSSEC being on the horizon.

Andrew> Of course, TCP isn't maybe the only way DNSSEC will get
Andrew> responses, but it's a concern for sure.  It also seems that
Andrew> this TCP issue is a DoS waiting to happen, since it imposes
Andrew> rather more overhead, AFAICT.  Unless I've misunderstood
Andrew> something (and it wouldn't be the first time).

Hrm.  Hadn't thought of this, but by my count, I can send three
packets (SYN, ACK, and the request) and get the host to occupy a TCP
slot and send at least 5 packets ... possibly more (SYN-ACK, ACK, 2
byte size, Reply, FIN (probably multiple FIN if I ignore them)).
That's not a large multiplier of packets, but it does occupy resources
while this is happening.

The byte multiplier is not bad (TCP has a lot of overhead).  Under
IPv4, I send 120 bytes + request and I cause the host to send 200
bytes plus the reply (or more).  Under IPv6, I send 180 bytes +
request and I cause the host to send 300 bytes plus the reply (or
more).

Fixing this bug takes the attack from 5+ packets to 4+ packets.  It
probably doesn't change the length of time that the TCP stack keeps
the slot open (for FINs) in any measurable way.

But from a byte count perspective it reduces the overhead transmission
from 200 bytes to 160 bytes (vs. 120 bytes from the attacker) for v4
and from 300 bytes to 240 (vs. 180 bytes from the attacker) for v6.

Dave.

-- 
============================================================================
|David Gilbert, Independent Contractor.       | Two things can be          |
|Mail:       dave at daveg.ca                    |  equal if and only if they |
|http://daveg.ca                              |   are precisely opposite.  |
=========================================================GLO================