watch problems

[Lee H]

Hey,

I noticed your watch implementation, and not sure if you're aware of the 
flooding implications that come from the fairly bad "design" behind it.

It was designed so that anything can be stacked together, which comes apart
if you get drones designed to exploit it.  Yet a number of clients rely on
this stacking and the ability to issue WATCH at will, which makes it hard 
to secure.


The main problem is you can easily stack watch lists together, ie: 
"watch l,l,l,l,l,..." and have the server return you an arbitrarily sized 
stream, depending on how many you stack together -- and as this can be done
in a single line any flooding penalties are irrelevant other than sendq.

I hacked up a program to test this way back when, had 5 (admittedly sendq
exempt) drones issue a huge stacked watch list every second, the return on 
traffic was quite amazing:

? Server send:  156.95 Megabytes (1868.8 K/s)
? Server recv: 56.00 Kilobytes ( 0.7 K/s)

You can do similar things with some of the other watch commands too, the
return on just adding a very long watch list (which you just intersperse
with a clear to keep the number down) is itself pretty hefty I think.


The WATCH protocol is massively wasteful on traffic, I ended up finding 
so many ways to abuse it I wrote a whole new protocol. ;-)

-- 
-                 Lee H // anfl
-        I code, therefore I break things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.ircd-hybrid.org/pipermail/hybrid/attachments/20051113/9e0c143c/attachment.pgp>