Draft specification for future X-Trace header

Russ Allbery rra at stanford.edu
Wed Jul 12 05:14:00 UTC 2000


Forrest J Cavalier <mibsoft at epix.net> writes:

> Before this discussion turns into flame, can Marco can clarify why the
> statement was "POST newsfeeds are evil" NNTP is a protocol which moves
> messages around, and as a tool, it is not evil of itself.

POST newsfeeds are evil from a standardization perspective, since they
make assignment of roles to various server entities much more difficult.
This has been a topic of a lot of discussion on USEFOR.

For the purposes of tracing and accountability, you want there to be one
and only one injecting site, which takes responsibility for the posting,
handling abuse reports regarding it, and the like, and then any number of
transit sites that have just relayed the article from its source.

The transit sites are absolutely forbidden to modify anything other than
Path and Xref (the latter being left in due to existing practice, although
it's rather ugly and Brad has a good point that a well-behaved news server
should probably strip it out on outgoing feeds except to servers that are
slaving off of it).  The injection site is responsible for adding all
necessary tracing information.

Under this model, you have one and only one set of tracing information,
and you know that the tracing information is generated by an entity at
least responsible enough that someone's been willing to peer with them
rather than just offer them a reading connection.

As soon as you have multiple sets of trace information, it becomes
significantly more difficult to figure out where the article came from,
and there's more of a risk of an attacker obfuscating the origin of the
post using fake trace information.

POST newsfeeds have also historically been evil due to various bad
decisions made by various news servers about what article munging is
allowed on POST.  Some servers did things like replace the Message-ID or
Date header, making POST newsfeeds an open invitation for loops.  This
isn't really the fault of the POST newsfeed so much as a bad
implementation of POST, but still double-injection (POSTing an article
that's already been POSTed to a server in the past) is at best a necessary
evil due to the problems with determining what sets of trace information
to keep.

> As Olaf points out, the benefit of running INN or other server locally,
> (and posting to it) is significant.

> What is the right way to get these posts propagated?  I don't think many
> ISPs are willing to to set up a newsfeed for every customer this
> way. POST seems to be the only option.

The right way to do it is with POST, but when setting this up, you have to
be careful to NEVER send back to your ISP's news server stuff you *got*
from your ISP's news server or some other news server.  POST is suitable
*only* for locally originating articles; as soon as you have multiple
feeds or misconfigure something and start feeding back articles you got
from your ISP, POST can potentially mean serious trouble.

> All that this needs to work is that the message-ID is not changed.

> That doesn't seem difficult to me.  I would say that a server that
> rewrites message-IDs on a POST is the problem, not the use of POST to
> propagate messages.

Sure, but even assuming that the server doesn't do this (and unfortunately
there are broken servers that do), suppose you're sucking news from
multiple sources and you get lucky on timing or your primary news server
is slow and you pull down something from one source that the other source
doesn't already have.  If you beat its regular news feed with your POST of
that article, now there are two copies of that article on Usenet with two
different sets of trace information since your ISP thinks you wrote that
post and just stuck a long Path on it.  This is Bad.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the inn-workers mailing list