[NNTP] Fwd: Gen-art review of draft-ietf-nntpext-streaming-05
Elwyn Davies
elwynd at dial.pipex.com
Thu Jun 9 03:39:04 PDT 2005
The sort of thing I was thinking of was sending streams of CHECKs for
articles and never sending TAKETHIS, or asking about or sending the
same article repeatedly, or sending a stream of CHECKs for the same
article that the malicious client knows the server has already. These
could waste quite a lot of your bandwidth! I understand that the whole
point is to provide a wide open pipe, but a wide open pipe can be a wide
open opportunity for the malicious client - can he exploit it in this
case? Your response is fine where the client is well-behaved and
sending a sensible set of requests... not every 'client' is necessarily
well-behaved and my feeling was that you needed to at least mention how
a server could protect itself against a deliberately malicious client,
and maybe how a well-behaved client could be a better citizen by
controlling its load. CHECKs in particular are a way of making a server
do unproductive work at little cost to the malicious client.
Don't forget I am not an expert in NNTP things - part of the job of
gen-art is to think the unthinkable from another point of view, to
challenge (apparently undocumented) assumptions and apply experience
from other fields. If you guys are *really* sure that this is not a
problem and you can show I am talking from the wrong part of my anatomy
then that is cool with me. All I (we) ask is that you get past the knee
jerk, and spend at least a couple of seconds checking that you haven't
had a collective blind spot!
Regards,
Elwyn
Andrew - Supernews wrote:
>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.
>
>
>
More information about the ietf-nntp
mailing list