[NNTP] Fwd: Gen-art review of draft-ietf-nntpext-streaming-05

[Russ Allbery]

elwynd <elwynd at dial.pipex.com> writes:

> Maybe I am missing something here, but the original reason for my
> raising this query is that the streaming commands are different from the
> others.

> Unless I have totally misunderstood (and I may have), the non-streaming
> commands expect to generate a response from the server before the client
> sends another command (that was apparently the whole point of the
> streaming commands to get round this synchronicity).  My understanding
> was therefore that a server would be able to quickly discard commands
> (and maybe drop the connection) if another command arrived before it
> sent the response for commands other than the streaming ones because it
> would be a protocol error.

No, pipelining is supported for all NNTP commands except for a small
handful of exceptions.  That was added in the new protocol revision and is
documented in the base draft.

> The streaming ones on the other hand could be legitimately sent as fast
> as the client could make them thus leading to a potential drain on the
> server which it couldn't easily control.  As far as I am aware all the
> counterexamples cited recently are from synchronous protocols, rather
> than the asynchronous scheme which the streaming commands introduce.

I was specifically looking for security considerations in RFC 2920, which
seems equivalent.

However, the commands are a bit different in a few other respects.  I
proposed the following text this morning; would this help?

    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.

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