[NNTP] STREAMING diffs (take 2)

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:
> Russ Allbery wrote:

>>> Looks good to me.  I think we should go for it.

> What about the DoS discussions?  Have you decided that no new text is
> needed?

The only thing that really might be worth covering is a warning about
peers that send CHECK but never send the actual article, not for DoS
reasons so much as because this is something that happens anyway even
between well-meaning peers.  We do have the one sentence in the CHECK
description, but it's a bit confused (it's saying the client can't rely on
the TAKETHIS being accepted and that the server can't rely on the TAKETHIS
being sent, both at the same time).

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 responses to CHECK are advisory.  Even if the server returns 238
    to CHECK, it may still reject TAKETHIS for the same article.

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.

    TAKETHIS is designed to maximize the speed of article transfer and
    therefore is the only client command followed immediately by a
    multi-line data block.  Servers concerned with possible excessive
    bandwidth utilization by clients using TAKETHIS SHOULD restrict use of
    the STREAMING extension to trusted and authenticated clients.

What do people think of this?  If we go this route, we should probably add
an informative reference to the authinfo draft and cite it under the
mentions of authentication in the security considerations above.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>