ietf-nntp new Draft available

Stan O. Barber sob at verio.net
Mon Nov 8 04:14:10 PST 1999



Andrew Gierth wrote:
> 
> >>>>> "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.

This is on the agenda for discussion today, which is why it is not in the draft.
I argue that it is an implementation issue and that adding lots of that to the
protocol document is a bad idea. However, if folks feel strongly about it, I can
be convinced.

> 
>  >> 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.)

Hmm. I thought it was standard practice for folks to review the current drafts
when they join the list. I guess I have higher expectations than I should. Sorry
about that.

> 
>  >> 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.

Okey. So your arguement is effectively that this description does not explicitly
point out this specific "spoof"? Providing specific text would make this all
much clearer to me.

> 
> 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.

Tracing information is part of the content of the articles, not part of the
protocol spec. This type of comment may belong in the USEFOR spec, not here.

> 
>  >> 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
       The latter here should have been former.
>  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.

Again, message-id uniqueness is some something that NNTP enforces per 
se. It is a standard feature of USENET (more or less) of which 
NNTP is one transport.

> 
> 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.

Again, specific proposals for changes to the text would make this all much
clearer. Saying that it is "woefully inadequate" is not very persuasive without
a concrete example.
> 
> --
> Andrew.



More information about the ietf-nntp mailing list