[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