Network Working Group T. Roessler draft-roessler-usefor-trace-00.txt April 2001 A Trace Header for Usenet Articles Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society 2001. All Rights Reserved. Abstract The present document suggests a simple alternative to much of the complexity in the Path and Injector-Info headers introduced in [1]. The Complaints-To header introduced in [1] and the NNTP-Posting-Host header introduced in [NNTP] are also replaced. The replacement suggested tries to pay due attention to posters' privacy, and at the same time provides a robust means to trace, correlate and prosecute abusive behaviour. 1. Introduction In order to trace forgeries, identify spam, and prosecute policy violations, various kinds of information are nowadays included in Roessler Expires October 2001 [Page 1] INTERNET-DRAFT A Trace Header for Usenet Articles April 2001 extra Usenet headers. In particular, the following sources of information are in use or have been suggested: o Path. This header keeps a record of the way an article took through Usenet. In [1], it additionally carries more detailed information about the injection/input process. o NNTP-Posting-Host. This header is used to publish the posting agent's IP address. It may be considered an invasion of users' privacy. o X-Trace. This header contains information such as a server- generated time stamp, the posting agent's IP address, and additional information which is poorly documented or even site- specific. It may, once again, be considered an invasion of users' privacy. o X-Complaints-To, Complaints-To. This header contains a contact e- mail address for the injecting agent, so users can complain about an article. o Injector-Info. This header has been suggested in [1] as a means to consolidate the tracing information. The format suggested is complex. The information published may be considered an invasion of users' privacy. The present document suggests to return Path to the simple semantics defined in [2], and commonly used on today's Usenet. At the same time, a Trace header is introduced which can be used to transport information on the posting agent of an article. The Trace header is used to associate the following information to each injecting agent which may have touched an article: o path-entry. This is used to identify the injecting agent. o complaints-address. This replaces X-Complaints-To and Complaints- To. o A time stamp. o A "rough" identifier for the posting agent. This can be any character string which can serve as evidence that any two postings carrying the same string and nearby time stamps were posted by the same entity. While this identifier basically takes the role of the tuple (NNTP-Posting-Host, Date), it does not have to identify the posting agent. Details are specified below. Roessler Expires October 2001 [Page 2] INTERNET-DRAFT A Trace Header for Usenet Articles April 2001 o Arbitrary opaque data. It is expected that the entity reachable at the complaints-address will know what this data means, and will find this data useful in dealing with possible abuse. This may just be the current X-Trace header's content, or it may be encrypted data which can be used to reliably identify the article's poster, and can only be decrypted by the entity reachable at complaints-address. Each injecting agent is expected to add a Trace header at the top of each article's header, and to leave any Trace headers already present intact. Implementations may, however, elect to perform consistency checks on Trace and Path headers, and elect to drop articles with incosistent headers (bad time stamps, Trace headers which are not associated with any entry on the Path header). The design of the Trace header is based on the observation that most of the information present in currently-used tracing headers is of little or no value to the general readership. A closer analysis shows that most of the trace information is only interesting to the injecting agent's administrators, and that the general Usenet public only needs to be able to recognize posters over a short interval of time in order to detect, for instance, mass postings. As a conclusion from this observation, a rough identifier is introduced which can be used to find mass posters. Any information which is of interest to administrators (whose addresses are given) can be put into the opaque data field of the Trace header. This field can possibly even be encrypted in order to protect users' privacy. 2. Path header 2.1. Syntax The following syntax is in line with [1]: path-content = *( path-identity [FWS] delimiter [FWS] ) tail-entry *FWS tail-entry = path-identity path-identity = 1 * (ALPHA / DIGIT / "-" / "." / ":" / "_" ) delimiter = "/" / "?" / "%" / "," / "!" 2.2. Implementation behaviour When an injecting, relaying, or serving agent receives an article, it MUST prepend its own path-identity followed by a delimiter to the beginning of the path-content. If the resulting header line Roessler Expires October 2001 [Page 3] INTERNET-DRAFT A Trace Header for Usenet Articles April 2001 (including the header tag) would exceed exceed 72 characters, agents SHOULD insert a CRLF sequence and whitespace after their path- identity. The path-identity used MUST be unique to the agent. The path- identity SHOULD be one of the following: o A fully qualified domain name which is controlled by the same organization or individual which controls the agent. Ideally, this should be the agent's fully qualified domain name. o A name registered with the UUCP maps database which is regularly posted to the Usenet group comp.mail.maps. Note that UUCP names do not contain any "." characters. o An encoding of an IP address - [3] or [4] (the requirement to be able to use an is the reason for including ':' as an allowed character within a path- identity). Implementations are free to use any delimiter valid according to the syntax description. However, the "!" character has generally been preferred over the last decade. It is common behaviour not to forward articles which contain a neighbour site's known path-identity to that site. It is also common behaviour for agents to drop articles which do already have a path entry which matches their path-identity. path-identities MUST be treated as case-insensitive data. 3. Trace header 3.1. Syntax trace-content = path-identity FWS timestamp FWS identifying-token FWS complaint-addr [ FWS opaque-data ] timestamp = 1* DIGIT ; seconds since the epoch identifying-token = text-without-spaces complaint-addr = "<" restricted-addrspec ">" opaque-data = text restricted-addrspec = atom *("." atom) "@" domain atom = ; see RFC 822 [5] text = ; see RFC 822 [5] domain = ; see RFC 822 [5] Roessler Expires October 2001 [Page 4] INTERNET-DRAFT A Trace Header for Usenet Articles April 2001 text-without-spaces = < any chars except SPACE, CR, LF, CTL > Note that every restricted-addrspec is an RFC 822 addr-spec, but that not every addr-spec is a restricted-addrspec. In particular, restricted-addrspec can not contain any white space, or angular brackets ("<" / ">"). This restriction is included so trace-content can be parsed as easily as possible. 3.2. Implementation behaviour Injecting agents MUST create a Trace header when they receive an article. Relaying or serving agents SHOULD generate a Trace header if none is present. They MAY generate an additional Trace header if the originator of an article can't be authenticated. They SHOULD NOT generate an additional Trace header if the direct originator of the article is a known and authenticated source. Agents MUST NOT modify or delete existing Trace headers. They MAY, however, elect to discard articles with obviously bad Trace headers. Any new Trace header MUST be inserted above any existing Trace headers. Note: The assumption on which these rules are based is that news transport generally happens between peers which authenticate each other. The topmost Trace header on an article would present the nearest breaking point in this chain which should ideally be identical to the injecting agent. An agent which creates a new Trace header MUST use the same path- identity it inserts into the Path header. As a special exception, agents which insert multiple subsequent Path entries may elect to use any one of these entries. A single agent SHOULD NOT insert more than a single Trace header, even when it inserts multiple subsequent Path entries. The timestamp MUST contain the time of the reception of the article, measured in seconds since the Epoch (00:00:00 UTC, January 1, 1970), as an integer value in decimal representation. The identifying-token MAY contain information which can be used to relate different articles injected by the same posting agent. Agents may elect to use the value "-" to indicate that they do not provide Roessler Expires October 2001 [Page 5] INTERNET-DRAFT A Trace Header for Usenet Articles April 2001 such information. If agents elect to provide such information, a single identifying- token MUST NOT be used for articles generated by different posting agents within 90 minutes. This means, in particular, that the following conclusion is possible: IF two articles carry Trace headers with identic path-identity and identifying-token fields (which differ from the special value "-"), and with timestamp fields which differ by no more than 3600, THEN the agent identified by path-identity received these articles from the same source, regardless of what any Path entries say. complaint-addr MUST be a valid electornic mail address which can be used to file comlaints about the posting agent's behaviour. The optional opaque-data field MAY contain any data a server operator considers useful in dealing with users' complaints. 4. Dropping Articles based on Trace headers With compliant implementations, there is a certain redundancy between Trace and Path headers. In particular, every Trace header's path- identifier also occurs on the Path header. Agents MAY elect to reject articles which carry Trace headers with no matching Path entries. Agents MAY also reject articles which have a topmost Trace header with a non-plausible timestamp (far in the past or future). However, agents SHOULD NOT drop articles solely based on small errors (less than 12 hours) in the timestamp field. 5. Examples Below, we reproduce some header snippets which could have been produced by software complying to this specification. Path: sdcsvax!dcdwest!ittvax!decvax!mcvax!moskvax! kremvax!chernenko Trace: mcvax 449618400 - cGlldEBtY3ZheC5VVUNQCg== Trace: kremvax 449610000 - VGhpcyBvbmUncyBhIGZha2UuCg== Path: uni-berlin.de!fu-berlin.de!newsfeed.r-kom.de! news-nue1.dfn.de!uni-erlangen.de!chico.franken.de! elvis.franken.de!news Trace: elvis.franken.de 986993151 - Roessler Expires October 2001 [Page 6] INTERNET-DRAFT A Trace Header for Usenet Articles April 2001 28518 193.174.159.67 6. Security Considerations The Trace and Path headers are not cryptographically authenticated, and can be changed in transit without notice by any relaying agent an article passes through. Even on a network where article and header integrity is generally warranted, only the topmost Trace header can be assumed to be authentic. The second Trace headers' value can only be assessed with the assistance of those who are in control of the agent which generated the topmost Trace header. (This consideration can be applied recursively.) Agents may wish to protect the possibly sensitive or private information contained in the identifying-token and opaque-data fields by appropriate cryptographic algorithms. Use of the Trace header may negatively impact humor on the net. 7. Address of the Author Thomas Roessler Nordstrasse 99 D-53111 Bonn Germany Tel: +49-228-638007 Email: roessler@does-not-exist.org References [1] Charles H. Lindsey, News Article Format. draft-ietf-usefor- article-04.txt, April 2001. [2] M. Horton and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, December 1987. [3] J. Postel and J. Vernon, Assigned Numbers, RFC 820, January 1983. [4] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [5] D. Crocker, "Standard for the Format of ARPA Internet Text Messages.", STD 11, RFC 822, August 1982. Roessler Expires October 2001 [Page 7] INTERNET-DRAFT A Trace Header for Usenet Articles April 2001 Full Copyright Notice Copyright (C) The Internet Society 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Roessler Expires October 2001 [Page 8]