idnits 2.17.1 draft-rfced-exp-rupp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [4], [5], [6], [7], [8], [9], [10], [11], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 414, but no explicit reference was found in the text ** Obsolete normative reference: RFC 977 (ref. '1') (Obsoleted by RFC 3977) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1036 (ref. '7') (Obsoleted by RFC 5536, RFC 5537) ** Downref: Normative reference to an Informational RFC: RFC 1950 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 793 (ref. '10') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT EXPIRES DEC 1997 INTERNET-DRAFT 3 Network Working Group Heiko W.Rupp 5 Experimental 27.05.1997 7 A Protocol for the Transmission of Net News Articles 8 over IP multicast. 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This protocol provides a way to use the IP multicast infrastructure 33 to transmit NetNews articles between news servers. Doing so will 34 reduce the bandwidth that is actually needed for transmission via 35 NNTP. This does not affect how news reading clients communicate with 36 servers. 38 Overview and Rationale 40 NetNews are bulk data that are produced in large quantities every day 41 around the world. Distribution of NetNews on the Internet are usually 42 distributed with NNTP[1]. In order to get a fast and redundant 43 distribution many news servers communicate with many others, thus 44 imposing a higher load on the underlying network than necessary. 46 Assume the following scenario: 48 +--------- R1 49 / 50 S -- A ------- B -------- R2 51 \ 52 +--------- R3 54 A sender S which wants to transmit articles via NNTP to receivers 55 R1...R3 will thus transmit them three times across the link from A to 56 B. 58 With IP Multicast[2], an efficient way to distribute datagrams to 59 groups of users exists in the Internet. Thus articles would traverse 60 the link A to B only once, thus reducing load on that link. 62 This cannot be done with existing news transfer technology, as it is 64 =0C 65 NETNEWS OVER IP MULTICAST 29 April 1997 67 based on TCP[10] which cannot be multicasted. The protocol described 68 in this memo is designed to put news articles into datagrams and 69 distribute them via IP multicast to receivers that are interested in 70 the specific newsgroup. For more information about NetNews, refer to 71 [7] and [1]. 73 In the rest of this memo I will refer to the protocol as ``Multicast 74 News Transport Protocol'' (Mcntp). 76 Protocol overview 78 This paragraph will show how news articles are propagated with Mcntp. 79 Basically, three parties are involved: 81 + Multicast directory service, MD, coordinates the assignment 82 between multicast and news groups. 84 + A Multicast sender, MS, that sends news articles over an 85 IP multicast infrastructure 87 + A Multicast receiver, MR, gets packets from the IP multicast 88 infrastructure and processes them further. 90 So this can be seen as follows: 92 directory +---------+ directory 93 +------------- > | | ----------------+ 94 \|/ | MD | \|/ 95 +---------+ | | +--------+ 96 | | +---------+ | | 97 | MS | | MR | 98 | | ------------ articles -------> | | 99 +---------+ +--------+ 101 MS and MR can be implemented into existing news server software, or 102 can be implemented as separate processes that communicate with the 103 news servers (e.g. via NNTP); this does not matter to the protocol. 105 MD can either be implemented within MS, or as separate processes that 106 communicate with each other. A practical way is to have on MD per 107 sender host so that communication between MD and MS is fast and 108 reliable, while not too many resources are needed. 110 The protocol itself consist of two parts that will be presented in 111 the next two chapters -- Distribution of articles and the directory 112 service. 114 Packet format -- Distribution of articles 116 To send articles via IP multicast, they have to be encapsulated into 117 UDP packets. The following diagram shows how this can be done: 119 +---------------------------------------+ 120 | Magic | 121 +----+----+----+----+---------+---------+ 122 | Ver|Rev |Comp|Cryp|Reserved | Offset | 123 +----+----+----+----+---------+---------+ 124 | Original length | 125 +---------------------------------------+ 126 | Length as sent | 127 +---------------------------------------+ 128 | Sender-ID | 129 +---------------------------------------+ 130 | Message-id | 131 +---------------------------------------+ 132 | Data | 133 +---------------------------------------+ 135 All entries are in network byte order. The fields have the following 136 meaning and types: 138 + Magic (32-bit): The String ``McNt'' 140 + Ver (4-bit): Protocol version -- currently 1 142 + Rev (4-bit): Protocol revision -- currently 1 144 + Comp (4-bit): Compression method used. Currently are only 2 145 methods defined: 147 0 Article is not compressed 149 1 Article is compressed via zlib [8] 151 + Cryp (4-bit): Encryption method used. See below 153 + Reserved (8-bit): Reserved for future extensions. 155 + Offset (8-bit): Offset of article data from packet start 157 + Original length (32-bit): Length of article before compression, 158 encryption and signing. 160 + Length as sent (including digital signature) (32-bit): Size of 162 =0C 163 nnnn NETNEWS OVER IP MULTICAST 29 April 1997 165 the ``Data'' field (see below) 167 + Sender-ID: Identification of the sender host terminated by a 168 null byte (see below). 170 + Message-ID: The message id of the article in the form it is 171 defined in RFC 1036 [7], terminated by a null byte. 173 + Data: The signed article data after possible compression and 174 encryption. 176 This memo does not specify a encryption method for the case that the 177 field ``Crypt'' is set to anything other than 0; the involved parties 178 (i.e. the senders of encrypted news and their receivers) have to 179 agree on a method they want to use. If encryption and compression is 180 used then the article data is first to be compressed and then the 181 result to be encrypted. 183 All articles must be signed before sending them off the net. This is 184 accomplished by running the RIPEMD-160 message digest [11] algorithm 185 over the (possibly compressed and encrypted) article and then RSA- 186 encrypting the message digest with the private key that is suitable 187 for sender-id. The receiver decrypts the signature of the article 188 with the public key of sender-id and runs RIPEMD-160 over the data to 189 see if it has been altered on the way. An article with an invalid 190 signature or a non matching message digest has to be thrown away. The 191 sender-id can be the path entry or the hostname of the sending site; 192 there can also be more than one key pair per site e.g. to have dif- 193 ferent keys for different newsgroups. The sender-id has to be 194 treated in a case independent manner. 196 Encryption of the message digest is done the following way. The 20 197 Bytes RIPEMD-160 message digest and the first 28 bytes of the 198 (possibly compressed and encrypted) message are tacked together to 199 form a 48 Bytes buffer. This buffer is then encrypted with the right 200 RSA private key and prepended to the original message without the 201 first 28 bytes: 203 +----------------+---------------------------------+ 204 | Message digest | message | 205 +----------------+-----------+---------------------+ 206 1 28 n 207 | \ 209 +-----------------------+----------------------------------+ 210 | Signature | message without first 28 Bytes | 211 +-----------------------+----------------------------------+ 213 =0C 214 nnnn NETNEWS OVER IP MULTICAST 29 April 1997 216 To send an article off, it is encapsulated and then just sent to the 217 appropriate multicast group. There is no feedback from the receiver 218 to the sender when an article is received. 220 Directory service 222 In order to get a relation between newsgroups and multicast groups, a 223 directory service exists; this has been referenced as MD above. When 224 a sender MS wants to propagate a news group, it asks the directory 225 service for a multicast group it can use to distribute articles, 226 waits for the reply, and starts to send. The directory server 227 registers this group in its tables and periodically distributes this 228 table over IP multicast. For this purpose, the multicast group 229 ``mcntp-directory.mcast.net'' has been officially been assigned by 230 the IANA. The UDP port which announcements are sent to, has 231 officially been assigned by the IANA as UDP port number 5418 with the 232 name ``mcntp''. 234 Announcements should not be sent too often to keep traffic low, but 235 often enough that new receivers don't have to wait to long to be able 236 to receive articles. Once a minute is assumed to be a good value 237 here. Announcements can be sent less often if they are transmitted 238 immediately after a change in the directory. 240 If more than one directory server is involved (e.g. if there is more 241 than one sender site), the directory servers have to listen to 242 announcement packets on ``mcntp-directory.mcast.net''. If it does not 243 receive a packet after five times the waiting period (e.g., five 244 minutes) it can consider itself alone on the net and can choose the 245 multicast groups as it wishes. If it does receive a packet, it must 246 register the contained groups in its tables and has to select new 247 groups so that different newsgroups are not mapped on the same 248 multicast group. 250 When a receiver (MR) wants to receive a newsgroup, it listens on 251 ``mcntp-directory.mcast.net'' for announcements, parses them, and 252 then joins the appropriate multicast groups. 254 Multicast groups that are no longer in use (e.g. because the sender 255 has stopped working) must be removed from the announcement. 257 =0C 258 nnnn NETNEWS OVER IP MULTICAST 29 April 1997 260 The format of those announcement packets is: 262 +-----------+------+-----+--------+ 263 | Magic | Vers | Rev | Offset | 264 +-----------+------+-----+--------+ 265 | Length | 266 +---------------------------------+ 267 | rmd160 | 268 +---------------------------------+ 269 | Sender-ID | 270 +-----------------+------+---+-----------+ -+ 271 | Multicast group | Port |TTL| Newsgroup | | 272 +-----------------+------+---+-----------+ | 273 ... repeat ... | NG lines 274 +-----------------+------+---+-----------+ | 275 | Multicast group | Port |TTL| Newsgroup | | 276 +-----------------+------+---+-----------+ -+ 278 All numbers are in network byte order. The fields have the following 279 meaning and types: 281 + Magic (16-bit): The Bytes 0xabba 283 + Vers (4-bit): Protocol version (see below) 285 + Rev (4-bit): Protocol revision (currently 1) 287 + Offset (8-bit): Offset of NG-lines from packet start. 289 + Length (32-bit): Total packet length. 291 + rmd160 (160-bit): RIPEMD-160 message digest over the rest of 292 the packet. 294 + Sender-ID : Identification of sender host, terminated by a 295 null byte (see below). 297 + Multicast group (32-bit *): The associated multicast group 299 + Port (8-bit): UDP Port to use for this group 301 + TTL (8-bit): Time to live for multicast packets. 303 + Newsgroup: Name of the Newsgroup in wildmat(3) format, 304 terminated by a null byte. 306 The protocol version (Vers) is currently 1 for IPv4 and 11 for IPv6. 308 =0C 309 nnnn NETNEWS OVER IP MULTICAST 29 April 1997 311 The multicast group field (*) is 32 bit in size for IPv4 and 128-bit 312 for IPv6 in size. 314 The length field is 32 bit in size to support IPv6 jumbo datagrams. 316 The sender-ID is normally the fully qualified domain name of the 317 hosts that sends the announcement. As is common practice with 318 NetNews, this can also be the (possibly shorter) entry that the host 319 puts in the ``Path:'' header when an article passes through it. This 320 entry has to be treated in a case independent manner. 322 The rmd160 is computed over the sender-id field and all lines with 323 newsgroup to multicast group relations in the packet with the 324 RIPEMD-160 message digest algorithm. 326 The lines with newsgroup to multicast group relations are repeated as 327 often as needed to announce all groups. The TTL can be used by 328 clients to find out if packets that come from this source can reach 329 them, or if the sender is too far away. Note that all entries have 330 to fit into one UDP packet. 332 TTL values of articles have to be chosen, especially for use on the 333 MBONE, in a way that newsgroups that are only of local relevance 334 (e.g. campus groups or groups local to a town) are not distributed 335 out of their normal distribution area. 337 Reliability Considerations 339 As UDP is a unreliable service, provisions for reliable distribution 340 of articles are needed. There exist some approaches to reliable 341 multicast (XTP [4], KLG [5] RMTP [6] and others) which all suffer 342 from some problem or other. Specifically, additional hard- or 343 software is needed and usually requires kernel modification. 345 As there is already a reliable transport of NetNews via NNTP, there 346 is no need for a reliable transport via IP multicast: articles need 347 not be in order, so it is no problem if one is missing in the 348 multicast. Since articles need not arrive in order, lost or missing 349 articles can easily be transmitted via an additional NNTP feed. 351 As UDP packets can be at maximum 64kBytes in size and every Mcntp 352 packet has to fit in one UDP packet, there is no provision given to 353 distribute news articles larger than about 63kBytes in size (other 354 than compressing them). This does not matter much in practise as 355 recent research has shown that more than 95% off all news articles 356 are smaller 64kBytes [9]. The remaining 5% can still be transferred 357 via NNTP. Some hosts may have problems in receiving UDP packets as 358 large as 64kBytes, so in practical use article sizes of 16kBytes 360 =0C 361 nnnn NETNEWS OVER IP MULTICAST 29 April 1997 363 would be appropriate. 365 Summary 367 The distribution of NetNews articles via IP multicast can be a way to 368 decrease the network bandwidth used to distribute them. Articles are 369 delivered fast via a nonreliable protocol; later, the holes are 370 filled via a reliable, already existing protocol. Compression of 371 articles can further reduce the network Load. With encryption private 372 news groups can be established on a public IP multicast 373 infrastructure. A prototype of a reference implementation already 374 shows that Mcntp is fast and can be used as an alternative to 375 classical transports. 377 Security Considerations 379 With the classical NNTP based distribution, every host on the path of 380 an article keeps track of it in the logfiles, making it possible to 381 find the sender of forged or abusive articles with the aid of the 382 administrators of the newshosts along the path. For the distribution 383 of NetNews over IP multicast, this is no longer true: routers don't 384 log packets flowing by and as the sender address of IP packets can be 385 forged, a sender can't be traced. This fact can be used to inject 386 forged news articles without being traceable. 388 To prevent the unnoticed injection of articles, a mcntp receiver only 389 accepts articles from senders that it trusts. This trust is build by 390 digitally signing the article with the private key of the sender and 391 verifying the signature at the receiver site. Receivers have to 392 accept only articles with good signatures 394 The RIPEMD-160 message digest algorithm has been chosen, as it is 395 more secure than MD5 while still being fast enough. The RSA 396 encryption algorithm has been chosen as there exist reference 397 implementations for usage inside US (from RSA Inc.) and outside 398 (rsaeuro by J.S.A.Kapp). 400 The key size for the RSA algorithm must be at least 512 bit in size 401 to prevent cracking of the key. 403 References 405 [1] RFC 977 -- B. Kantor, P. Lapsley, "Network News Transfer Protocol: 406 A Proposed Standard for the Stream-Based Transmission of News". 408 [2] RFC 1112 -- S. Deering, "Host extensions for IP multicasting", 409 08/01/1989. 411 =0C 412 nnnn NETNEWS OVER IP MULTICAST 29 April 1997 414 [3] RFC 768 -- J. Postel, "User Datagram Protocol", 08/28/1980. 416 [4] XTP -- W. T. Strayer, D.J. Dmepsey, B.C. Weaver, "XTP: The Xpress 417 Transfer Protocol", Addison-Wesley 419 [5] KLG -- M. Hofmann, "Zuverlaessige Kommunikation in heterogenen 420 Netzen", Thesis at "Institut fuer Telematik, CS Dept. Univ 421 Karlsruhe" 423 [6] RMTP -- Lin, John C., Paul Sanjoy, "RMTP: A Reliable Multicast 424 Transport Protocol". 426 [7] RFC 1036 -- M. Horton, R. Adams, "Standard for interchange of 427 USENET messages", 12/01/1987. 429 [8] RFC 1950 -- L. Deutsch, J. Gailly, "ZLIB Compressed Data Format 430 Specification version 3.3", 05/23/1996. 432 [9] http://www.xlink.net/~hwr/histo/ -- Some Statistics about size dis- 433 tribution of NetNews 435 [10] RFC 793 -- J. Postel, "Transmission Control Protocol", 09/01/1981. 437 [11] H. Dobbertin, A. Bosselaers, B. Preneel, "RIPEMD-160: A 438 Strengthened Version of RIPEMD" 04/18/1996. An earlier version 439 appeared in "Fast Software Encryption,LNCS 1039" Springer Verlag, 440 1996, pp. 71-82. 442 Author's Address 444 Heiko W.Rupp 445 Gerwigstr. 5 446 D-76131 Karlsruhe 448 Phone: +49 721 9661524 450 EMail: hwr@pilhuhn.de