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

[Russ Allbery]

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

> The sort of thing I was thinking of was sending streams of CHECKs for
> articles and never sending TAKETHIS,

This *does* happen and does have a negative impact on the server due to
the standard practice of marking such messages as in progress and
deferring other offers of the same message.  I'm wondering if we should
say something about this, although I'm not quite sure what to say.

> or asking about or sending the same article repeatedly,

This is extremely fast for the server to deal with, so the only concern
would be bandwidth (and starvation in a poorly designed server, but
servers usually deal with that fairly well).

> or sending a stream of CHECKs for the same article that the malicious
> client knows the server has already.

This is also extremely fast for the server to deal with.

> These could waste quite a lot of your bandwidth!

I'm personally not sure it's worth worrying too much about bandwidth
attacks on TCP services, as I can consume lots of bandwidth with pretty
much any arbitrary TCP service (consider sending lots and lots of MAIL,
RCPT, RSET commands to an SMTP server, for instance).  NNTP STREAMING is
actually *less* vulnerable than something like SMTP because it's generally
only used with authenticated peers, so there's someone who's access can be
disabled if they abuse the privilege.

But then, I don't have a broad range of protocol experience.  Would you
raise the same issue with SMTP?  It feels to me like other protocols have
this same issue, so if there's some standard way of dealing with it, maybe
we could just copy that language.

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