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

[Andrew - Supernews]

I took a guess at the best CC list to use for this response; forward
if appropriate. This response is aimed mainly at an area where I think
the review missed the point, rather than real problems with the
documents.

 >> Date: Thu, 02 Jun 2005 10:41:19 +0100
 >> From: Elwyn Davies <elwynd at dial.pipex.com>
 >> To: gen-art at alvestrand.no
 >> CC: Mary Barnes <mary.barnes at nortel.com>, vinocur at cs.cornell.edu,
 >> ken at oceana.com, Russ Allbery <rra at stanford.edu>,
 >> Scott Hollenbeck <sah at 428cobrajet.net>
 >> Subject: Gen-art review of draft-ietf-nntpext-streaming-05

 [...]

 >> I noted that the potentiality for pipelined commands to be used
 >> fos DoS attacks was not mentioned in the Security Considerations
 >> of this or the base document (draft-ietf-nntpext-base-26).

 [...]

 >> S5: Security Considerations: I suspect that pipelined commands
 >> (espcially CHECK) offer an opportunity for DoS attacks on NNTP
 >> servers.  This is not discussed either in this document or the
 >> base specification to which it refers.  Maybe some notes about
 >> rate limiting generation of CHECK requests by clients (over and
 >> above the requirement to consider buffer sizes), and possibly the
 >> use of 431 responses as a way to control overloading by servers,
 >> might help.

Both of the above comments rather miss the point that the CHECK and
TAKETHIS commands exist _specifically_ for the purpose of transferring
large volumes of data (the Usenet feed is around two terabytes per day
at the moment) at the fastest possible rate that the receiving server
can handle. It's very important that implementations _not_
artificially impose limits on the rate at the sending (client) end,
and it's up to the receiving end to decide how to handle the load.
Servers have not historically used 431 responses to manage load, and
it's unlikely that it would have been successful (one older
implementation treated 431 as though it were 239, which would have
rather defeated any such attempt).

Real implementations typically allow the number of concurrent
connections (total and/or from a single feed site) to be limited
(which is a precaution not in any way specific to streaming feeds).
Some also allow the accepted bytes/second from a given feed source to
be limited at the server too, but this isn't done to protect the
server, but more typically to provide bandwidth management options to
the administrator (when dealing with a 200 megabit traffic flow such
things are often important).

So I am (and I suspect most of the rest of the NNTP group are)
somewhat puzzled by what you think the specific security issue with
CHECK is.

-- 
Andrew, Supernews
http://www.supernews.com