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

[Andrew - Supernews]

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

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

2.4.2: "Note however, that the responses to CHECK are advisory; the
server MUST NOT rely on the client to behave as requested by these
responses."

I don't know if this is worth pointing out in the security
considerations too; the fact that you mentioned it might suggest it
_is_ worth it :-)

What practical applications do is usually: if a CHECK or IHAVE is
received from one connection, then send 431 responses to the same
CHECK (or IHAVE) on other connections until either the article is
received or a short timeout expires. This avoids receiving too many
copies of the same article while not reducing feed reliability unless
the 431 is consistently ignored by other feeding clients. In
pathological cases this can still cause a problem, but it's not
common in practice.

 Elwyn> or asking about or sending the same article repeatedly, or
 Elwyn> sending a stream of CHECKs for the same article that the
 Elwyn> malicious client knows the server has already.  These could
 Elwyn> waste quite a lot of your bandwidth!  I understand that the
 Elwyn> whole point is to provide a wide open pipe, but a wide open
 Elwyn> pipe can be a wide open opportunity for the malicious client -
 Elwyn> can he exploit it in this case?  Your response is fine where
 Elwyn> the client is well-behaved and sending a sensible set of
 Elwyn> requests... not every 'client' is necessarily well-behaved and
 Elwyn> my feeling was that you needed to at least mention how a
 Elwyn> server could protect itself against a deliberately malicious
 Elwyn> client, and maybe how a well-behaved client could be a better
 Elwyn> citizen by controlling its load.  CHECKs in particular are a
 Elwyn> way of making a server do unproductive work at little cost to
 Elwyn> the malicious client.

They are not nearly as bad in this respect as some of the commands in
the base spec - STAT, HDR and LISTGROUP for example, which are made
much more widely available than CHECK/TAKETHIS, which are invariably
restricted to specific IP addresses (some servers have tried a
halfhearted approach to password auth for feed connections, but it's
never caught on - however one can hope the AUTHINFO draft may help fix
this by providing a standard alternative to IP-based auth).

A well-behaved streaming client is one that transfers as much data as
possible using as few concurrent connections as possible. Any attempt
to limit things at the sending end is counterproductive.

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