ietf-nntp new Draft available

Andrew Gierth andrew at erlenstar.demon.co.uk
Sun Nov 7 22:08:37 PST 1999


>>>>> "Stan" == Stan O Barber <sob at verio.net> writes:

 >> Here are my comments on the draft (in addition to my previous
 >> comments on the PAT command):

 Stan> Specifically, what of your previous comments were not addressed
 Stan> in the draft?

It is unclear what response to return to the client in the event that
PAT is supported for some headers but not others. The examples suggest
that the response should be 502, which seems inappropriate, but the
text merely states "A 502 response shall be returned if the client
only has permission to transfer articles.".

Current practice (as regards XPAT) is to either return an empty
response, or a 501 error. Both of these have been criticised by client
authors; the first with considerable justification, which indeed is
why INN was changed to return 501 (I believe this was discussed some
time ago on n.s.nntp between Mark Burkley, author of nfilter, and
Clayton O'Neill).

The fact that this has been a problem in practice leads me to the
conclusion that it will continue to be a problem unless the new
specification is clear. I believe that none of the major news server
packages currently support XPAT on non-overview headers; there is no
reason to believe that they will behave any differently for PAT.

 >> 9.3.2 IHAVE

 Stan> Did you comment this from the previous draft?

No.

(This is the first announcement of a draft since I joined this list.)

 >> 14. Security considerations
 >> 
 >> Firstly, I suggest that the order should be reversed, with the
 >> paragraphs on access control etc. coming before the ones on logging
 >> and proprietary info.

 Stan> Suggestion noted. I will wait to hear from others on this
 Stan> before making this change.

Fine. While I think it would be an improvement, I have no major
problem either way provided the substance is satisfactory.

 >> The section on DNS spoofing, while it touches on the issue of
 >> mismatched forward/reverse lookups, should, IMO, spell out
 >> explicitly the requirement that reverse DNS lookups should be
 >> confirmed by performing the forward lookup before the returned
 >> name is used for either access control or logging or trace
 >> information (including trace headers added to posted articles).

 Stan> Hmm. Evidently, those that reviewed the HTTP 1.1 spec didn't
 Stan> see this as an important enough issues since the text here is
 Stan> based on that spec.

I'm quite sure that the HTTP people have their own priorities that
do not necessarily coincide with ours.

It is nevertheless a fact that there are many people who both control
their own reverse DNS and have an active desire to exploit and abuse
NNTP servers, and deceive the administrators of those servers as to
their origins.

It is also a fact that simple errors in reverse DNS have, in the past,
caused articles to be incorrectly traced and users to be wrongfully
accused of abuses.

 >> An additional section to the security considerations should be
 >> added pointing out the effect that a single insecure site can have
 >> on the larger NNTP network(s) of which it is part (whether the
 >> global Usenet or some other network).

 Stan> Does this affect the performance of the protocol or just the
 Stan> data shipped around by the protocol? If the latter, I was
 Stan> attempting to address that in the first part of the this
 Stan> section. If the latter, I'd be very interested in further
 Stan> exposition on this.

Well, there's message-id preemption, where I read articles from your
server and inject articles elsewhere using the same message-ids to
prevent your articles from propagating. There have been complaints of
this being done as abuse against the Russian-language hierarchies,
though I don't have any details; it's also done as a defence against
the cancel/supersede attacks carried out through insecure servers that
have been common of late.

Even if you (quite reasonably) consider spamming, flooding, rogue
cancelling etc. to all be "just the data shipped around by the
protocol", then the wording in the draft is still woefully inadequate
in the face of real-world experience of the level of abuse which is
committed through insecure servers.

-- 
Andrew.



More information about the ietf-nntp mailing list