Draft specification for future X-Trace header

[Olaf Titz]

This is an attempt at a formal specification for a better X-Trace
header (and a draft for an implementation in INN which I'm going to
do when I have too much time on my hands :-). Any comments welcome.

1. Purpose

Any news system which an article crosses MAY insert an X-Trace header.
However, this SHOULD NOT be done in the normal forwarding of articles,
but only at injection points and gateways (of any kind).
Recommendation: insert this header when an article is received via the
NNTP POST command or a local program.

The X-Trace header serves the purposes of
- identifying injection points and gateways,
- giving the administrator at each injection point enough information
  to determine the precise circumstances how the article entered the
  system,
- giving every news system enough information to detect potential
  trouble from malfunctioning software or misbehaving users.

When this header becomes standardized by RFC it should be renamed to "Trace".

2. Syntax

header          = "X-Trace:" LWSP systemid *(LWSP item)
systemid        = domain-name
item            = ctoken | ntoken | comment
ctoken          = ":" data
ntoken          = data
data            = (any data in base64 encoding)
comment         = "(" *pchar ")"
pchar           = (any printable character except "(" and ")")
LWSP            = linear-white-space

with the following meanings:
systemid        = the hostname of the generating system. This MUST be the
                  same name the system puts in the Path header.
ctoken          = Data item which is suitable to compare against the ctoken
                  parts of other X-Trace headers generated by the same
                  system to detect multiple postings.
ntoken          = any other data, usually only relevant to the local admin.
comment         = readable comment.

The total length of the X-Trace header including header name and
terminating newline SHOULD NOT exceed 255 octets.

Example:
X-Trace: g212.hadiko.de :7F0quBAr148= riniJg54iM4= (complaints to usenet at bigred.inka.de)
         systemid       ctoken        ntoken       comment

3. Generating the headers

3.1. Postings by local users

For local postings, the injection point SHOULD generate a /ctoken/
which is the same for all postings of one user over a certain period
of time (recommendation: about one day) and always different for
postings by different users. To prevent privacy problems, this token
SHOULD be encrypted or hashed.

For a single-user client system, this can be achieved by combining the
posting IP address and the upper 16 bits of the Unix system time into
an 8-byte block and encrypting this block using a block cipher with a
secret key. When authenticated user info is available, use this user
ID in place of the IP address. In case of a HTTP-based injection
point, use the HTTP client IP address. See the appendix for detailed
packing format.

Additional /ntoken/ parts SHOULD be generated if necessary in a way
that it is possible for the local admin, and for the local admin only,
to find out the identity of the poster. This may include the precise
system time, process IDs or other info. This info SHOULD be encrypted
if its knowledge is otherwise useful to outside parties.

3.2. Mailinglist to news gateways

The first /ctoken/ SHOULD always be the base64 encoding of the original
mail's Message-ID. If no such header is present, the news Message-ID
generated by the gateway should be used. All gateways SHOULD use this
information to prevent loops.

This recommendation also holds for other gateways, e.g. BBS to news.
If the originating system provides authenticated user information this
should be used to construct an additional /ctoken/ as of section 3.1.

3.3. Posting robots

Bulk postings by legitimate robots (e.g. weather reports, NoCeM
notices) SHOULD generate no /ctoken/ at all, to exempt these posters
from rate-limiting done by comparing /ctoken/ values. Additional
information MAY be encoded into /ntoken/ items.

4. Processing and analyzing the headers

4.1. Handling of incoming articles

Any X-Trace header present in an article coming in, whether by POST or
regular feed, MUST NOT be changed or deleted. One additional X-Trace
header MAY be added. An article SHOULD NOT be rejected just because of
the presence of an X-Trace header. (Note this is changed from current
practice.)

4.2. Analyzing

The X-Trace header can be analyzed by any system where the article
arrived, giving information such as:

- Any X-Trace header present indicates and identifies an original
  injection point, gateway or POST feed.

- If an X-Trace header is present with the same /systemid/ as the local
  system, a message loop has occurred. (The only cause can be that
  some kind of gateway or POST feed was crossed which changes or
  deletes the Path or Message-ID headers. The present X-Trace headers
  then give a hint on where that failure occurred.)

- The presence of identical /ctoken/ fields in corresponding X-Trace
  headers of different articles in short succession indicate multiple
  postings by the same user or POST feed. Each /ctoken/ field should
  be compared by itself for that purpose.
  This information can be used for rate-limiting. However, if more
  than one X-Trace header is present, a rejection caused by comparing
  only one of them SHOULD NOT be noted in the article history (because
  it may have come from a legitimate POST feed).

- The /ntoken/ fields are not relevant except to the generating system.

4.3. Reporting

When reporting trouble (such as malfunctioning systems or misbehaving
users), the reports always should include the complete set of headers.
Each system administrator should be able to get all relevant
information out of his own X-Trace header. Systems generating X-Trace
headers MAY insert a relevant reporting address into a comment item,
this is especially encouraged when the address differs from the system
name.

5. Other headers

The header presented here includes the information present in the
existing INN-type X-Trace header, the NNTP-Posting-Host and (possibly)
NNTP-Posting-Date headers, the X-Complaint-To header (as comment) and
the "<address>.POSTED" Path entries. Generation of these items may
therefore be omitted.

The additional loop-prevention properties MUST NOT be taken as an
excuse to violate the strict prohibition of changing or deleting any
existing Message-ID or Date header or manipulating the existing part
of the Path header.

Appendix: Recommendation for generating /ctoken/ from client info

The client info is encoded into an 64 bit or 128 bit block as given
below and encrypted using a 64 bit block cipher. Use the first
available method from this list.

If the client gives an authenticated user ID:
  bits 0..15:   Upper 16 bits of Unix system time. (I.e. this changes
                approximately every 18 hours.)
  bit  16..19:  0001 (indicative of user ID and reserved bits).
  bits 20..63:  User ID of client. If the user ID is non-numeric, an
                injective function should be used if possible to map
                it to a number.

If the client is only identified by an IPv4 address:
  bits 0..15:   Upper 16 bits of Unix system time.
  bits 16..19:  0010 (indicative of IP address and reserved bits).
  bits 20..31:  Unused.
  bits 32..63:  IPv4 address of client. (Use the HTTP client in case of
                HTTP based gateways!)

If the client is only identified by an IPv6 address:
  Find the rightmost 16-bit word consisting of all zeros in the
  address and replace that with the upper 16 bit of the Unix system
  time. If the address contains no all-zeros word use the leftmost
  word instead. Use the widest-scope address available.
Rationale for this method: this yields a 128-bit block which is good
for block encryption.

$Id: xtrace-protocol,v 1.1 2000/07/04 17:29:23 olaf Exp $