[NNTP] STREAMING diffs (take 2)

Ken Murchison ken at oceana.com
Mon Jun 13 10:49:37 PDT 2005


Russ Allbery wrote:

> How about this -- what if we replace that last sentence of the paragraph
> with something like:
> 
>     Servers handling multiple streaming feeds MAY remember that one client
>     sent CHECK for an article and respond with 431 to other CHECK commands
>     for the same article from other clients, making the assumption that
>     the first client will send the article with TAKETHIS.  The client is
>     not required to send the eventual TAKETHIS, however, and the server
>     SHOULD therefore discard such information after a short timeout (a few
>     seconds is generally sufficient) and accept the article from another
>     client.

The above seems like we're treading into implementation details. 
Whether an implementation decides to cache CHECK message-ids or whether 
it treats connections individually (and has a race between TAKETHIS 
commands) really isn't a protocol matter.


> and then in security considerations, just for completeness, add:
> 
>     A malicious client with knowledge of the message-ids a server will be
>     receiving could use a flood of CHECK commands to cause the server to
>     defer offers of those articles from its other peers.  If client
>     authentication is not sufficient to protect against this attack, the
>     server SHOULD watch for clients that send excessive CHECK commands
>     without a following TAKETHIS and reject further CHECK commands (with
>     438 or 431) from that client.

This problem isn't really a protocol problem, but an implementation 
problem.  I'm not saying that we shouldn't discuss it, I'm just pointing 
out that the protocol itself doesn't necessarily create this problem.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



More information about the ietf-nntp mailing list