[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