[NNTP] STREAMING diffs (take 2)
Russ Allbery
rra at stanford.edu
Mon Jun 13 10:51:59 PDT 2005
Ken Murchison <ken at oceana.com> writes:
> 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.
Er, it sure seems like a protocol issue to me....
>> 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.
Same here. I don't understand. Surely the use of deferrals and the
interaction between CHECK and TAKETHIS are protocol issues?
--
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the ietf-nntp
mailing list