[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