idnits 2.17.1 draft-rfced-exp-rupp-02.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-16) 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 68 lines 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 398, 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: 13 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT EXPIRES DECEMBER 1997 INTERNET-DRAFT 3 Network Working Group Heiko W.Rupp 4 INTERNET-DRAFT 5 Experimental 8.06.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 63 based on TCP[10] which cannot be multicasted. The protocol described 64 in this memo is designed to put news articles into datagrams and 65 distribute them via IP multicast to receivers that are interested in 66 the specific newsgroup. For more information about NetNews, refer to 67 [7] and [1]. 69 In the rest of this memo I will refer to the protocol as ``Multicast 70 News Transport Protocol'' (Mcntp). 72 Protocol overview 74 This paragraph will show how news articles are propagated with Mcntp. 75 Basically, three parties are involved: 77 + Multicast directory service, MD, coordinates the assignment 78 between multicast and news groups. 80 + A Multicast sender, MS, that sends news articles over an 81 IP multicast infrastructure 83 + A Multicast receiver, MR, gets packets from the IP multicast 84 infrastructure and processes them further. 86 So this can be seen as follows: 88 directory +---------+ directory 89 +------------- > | | ----------------+ 90 \|/ | MD | \|/ 91 +---------+ | | +--------+ 92 | | +---------+ | | 93 | MS | | MR | 94 | | ------------ articles -------> | | 95 +---------+ +--------+ 97 MS and MR can be implemented into existing news server software, or 98 can be implemented as separate processes that communicate with the 99 news servers (e.g. via NNTP); this does not matter to the protocol. 101 MD can either be implemented within MS, or as separate processes that 102 communicate with each other. A practical way is to have on MD per 103 sender host so that communication between MD and MS is fast and 104 reliable, while not too many resources are needed. 106 The protocol itself consist of two parts that will be presented in 107 the next two chapters -- Distribution of articles and the directory 108 service. 110 Packet format -- Distribution of articles 112 To send articles via IP multicast, they have to be encapsulated into 113 UDP packets. The following diagram shows how this can be done: 115 +---------------------------------------+ 116 | Magic | 117 +----+----+----+----+---------+---------+ 118 | Ver|Rev |Comp|Cryp|Reserved | Offset | 119 +----+----+----+----+---------+---------+ 120 | Original length | 121 +---------------------------------------+ 122 | Length as sent | 123 +---------------------------------------+ 124 | Sender-ID | 125 +---------------------------------------+ 126 | Message-id | 127 +---------------------------------------+ 128 | Data | 129 +---------------------------------------+ 131 All entries are in network byte order. The fields have the following 132 meaning and types: 134 + Magic (32-bit): The String ``McNt'' 136 + Ver (4-bit): Protocol version -- currently 1 138 + Rev (4-bit): Protocol revision -- currently 1 140 + Comp (4-bit): Compression method used. Currently are only 2 141 methods defined: 143 0 Article is not compressed 145 1 Article is compressed via zlib [8] 147 + Cryp (4-bit): Encryption method used. See below 149 + Reserved (8-bit): Reserved for future extensions. 151 + Offset (8-bit): Offset of article data from packet start 153 + Original length (32-bit): Length of article before compression, 154 encryption and signing. 156 + Length as sent (including digital signature) (32-bit): Size of 157 the ``Data'' field (see below) 159 + Sender-ID: Identification of the sender host terminated by a 160 null byte (see below). 162 + Message-ID: The message id of the article in the form it is 163 defined in RFC 1036 [7], terminated by a null byte. 165 + Data: The signed article data after possible compression and 166 encryption. 168 This memo does not specify a encryption method for the case that the 169 field ``Crypt'' is set to anything other than 0; the involved parties 170 (i.e. the senders of encrypted news and their receivers) have to 171 agree on a method they want to use. If encryption and compression is 172 used then the article data is first to be compressed and then the 173 result to be encrypted. 175 All articles must be signed before sending them off the net. This is 176 accomplished by running the RIPEMD-160 message digest [11] algorithm 177 over the (possibly compressed and encrypted) article and then RSA- 178 encrypting the message digest with the private key that is suitable 179 for sender-id. The receiver decrypts the signature of the article 180 with the public key of sender-id and runs RIPEMD-160 over the data to 181 see if it has been altered on the way. An article with an invalid 182 signature or a non matching message digest has to be thrown away. The 183 sender-id can be the path entry or the hostname of the sending site; 184 there can also be more than one key pair per site e.g. to have dif- 185 ferent keys for different newsgroups. The sender-id has to be 186 treated in a case independent manner. 188 Encryption of the message digest is done the following way. The 20 189 Bytes RIPEMD-160 message digest and the first 28 bytes of the 190 (possibly compressed and encrypted) message are tacked together to 191 form a 48 Bytes buffer. This buffer is then encrypted with the right 192 RSA private key and prepended to the original message without the 193 first 28 bytes: 195 +----------------+---------------------------------+ 196 | Message digest | message | 197 +----------------+-----------+---------------------+ 198 1 28 n 199 | \ 201 +-----------------------+----------------------------------+ 202 | Signature | message without first 28 Bytes | 203 +-----------------------+----------------------------------+ 205 To send an article off, it is encapsulated and then just sent to the 206 appropriate multicast group. There is no feedback from the receiver 207 to the sender when an article is received. 209 Directory service 211 In order to get a relation between newsgroups and multicast groups, a 212 directory service exists; this has been referenced as MD above. When 213 a sender MS wants to propagate a news group, it asks the directory 214 service for a multicast group it can use to distribute articles, 215 waits for the reply, and starts to send. The directory server 216 registers this group in its tables and periodically distributes this 217 table over IP multicast. For this purpose, the multicast group 218 ``mcntp-directory.mcast.net'' has been officially been assigned by 219 the IANA. The UDP port which announcements are sent to, has 220 officially been assigned by the IANA as UDP port number 5418 with the 221 name ``mcntp''. 223 Announcements should not be sent too often to keep traffic low, but 224 often enough that new receivers don't have to wait to long to be able 225 to receive articles. Once a minute is assumed to be a good value 226 here. Announcements can be sent less often if they are transmitted 227 immediately after a change in the directory. 229 If more than one directory server is involved (e.g. if there is more 230 than one sender site), the directory servers have to listen to 231 announcement packets on ``mcntp-directory.mcast.net''. If it does not 232 receive a packet after five times the waiting period (e.g., five 233 minutes) it can consider itself alone on the net and can choose the 234 multicast groups as it wishes. If it does receive a packet, it must 235 register the contained groups in its tables and has to select new 236 groups so that different newsgroups are not mapped on the same 237 multicast group. 239 When a receiver (MR) wants to receive a newsgroup, it listens on 240 ``mcntp-directory.mcast.net'' for announcements, parses them, and 241 then joins the appropriate multicast groups. 243 Multicast groups that are no longer in use (e.g. because the sender 244 has stopped working) must be removed from the announcement. 246 The format of those announcement packets is: 248 +-----------+------+-----+--------+ 249 | Magic | Vers | Rev | Offset | 250 +-----------+------+-----+--------+ 251 | Length | 252 +---------------------------------+ 253 | rmd160 | 254 +---------------------------------+------+ 255 | Sender-ID | pad1 | 256 +-----------------+------+---+-----------+---+ -+ 257 | Multicast group | Port |TTL| Newsgroup |pad| | 258 +-----------------+------+---+-----------+---+ | 259 ... repeat ... | NG lines 260 +-----------------+------+---+-----------+---+ | 261 | Multicast group | Port |TTL| Newsgroup |pad| | 262 +-----------------+------+---+-----------+---+ -+ 264 All numbers are in network byte order. The fields have the following 265 meaning and types: 267 + Magic (16-bit): The Bytes 0xabba. 269 + Vers (4-bit): Protocol version (see below). 271 + Rev (4-bit): Protocol revision (currently 1). 273 + Offset (8-bit): Offset of NG-lines from packet start. 275 + Length (32-bit): Total packet length. 277 + rmd160 (160-bit): RIPEMD-160 message digest over the rest of 278 the packet. 280 + Sender-ID : Identification of sender host, terminated by a 281 null byte (see below). 283 + Pad1: Padding to next 4-Byte boundary filled with null 284 bytes. 286 + Multicast group (32-bit *): The associated multicast group. 288 + Port (16-bit): UDP Port to use for this group. 290 + TTL (8-bit): Time to live for multicast packets. 292 + Newsgroup: Name of the Newsgroup in wildmat(3) format, 293 terminated by a null byte. 295 + Pad: Padding of the string to the next 4-bytes boundary 296 filled with null bytes. 298 The protocol version (Vers) is currently 1 for IPv4 and 11 for IPv6. 299 The multicast group field (*) is 32 bit in size for IPv4 and 128-bit 300 for IPv6 in size. 302 The length field is 32 bit in size to support IPv6 jumbo datagrams. 304 The sender-ID is normally the fully qualified domain name of the 305 hosts that sends the announcement. As is common practice with 306 NetNews, this can also be the (possibly shorter) entry that the host 307 puts in the ``Path:'' header when an article passes through it. This 308 entry has to be treated in a case independent manner. 310 The rmd160 is computed over the sender-id field and all lines with 311 newsgroup to multicast group relations in the packet with the 312 RIPEMD-160 message digest algorithm. 314 The lines with newsgroup to multicast group relations are repeated as 315 often as needed to announce all groups. The TTL can be used by 316 clients to find out if packets that come from this source can reach 317 them, or if the sender is too far away. Note that all entries have 318 to fit into one UDP packet. 320 The sender-id and the newsgroups entries are padded to the next 321 4-bytes boundary in order to make processing easier. 323 TTL values of articles have to be chosen, especially for use on the 324 MBONE, in a way that newsgroups that are only of local relevance 325 (e.g. campus groups or groups local to a town) are not distributed 326 out of their normal distribution area. 328 Reliability Considerations 330 As UDP is a unreliable service, provisions for reliable distribution 331 of articles are needed. There exist some approaches to reliable 332 multicast (XTP [4], KLG [5] RMTP [6] and others) which all suffer 333 from some problem or other. Specifically, additional hard- or 334 software is needed and usually requires kernel modification. 336 As there is already a reliable transport of NetNews via NNTP, there 337 is no need for a reliable transport via IP multicast: articles need 338 not be in order, so it is no problem if one is missing in the 339 multicast. Since articles need not arrive in order, lost or missing 340 articles can easily be transmitted via an additional NNTP feed. 342 As UDP packets can be at maximum 64kBytes in size and every Mcntp 343 packet has to fit in one UDP packet, there is no provision given to 344 distribute news articles larger than about 63kBytes in size (other 345 than compressing them). This does not matter much in practise as 346 recent research has shown that more than 95% off all news articles 347 are smaller 64kBytes [9]. The remaining 5% can still be transferred 348 via NNTP. Some hosts may have problems in receiving UDP packets as 349 large as 64kBytes, so in practical use article sizes of 16kBytes 350 would be appropriate. 352 Summary 354 The distribution of NetNews articles via IP multicast can be a way to 355 decrease the network bandwidth used to distribute them. Articles are 356 delivered fast via a nonreliable protocol; later, the holes are 357 filled via a reliable, already existing protocol. Compression of 358 articles can further reduce the network Load. With encryption private 359 news groups can be established on a public IP multicast 360 infrastructure. A prototype of a reference implementation already 361 shows that Mcntp is fast and can be used as an alternative to 362 classical transports. 364 Security Considerations 366 With the classical NNTP based distribution, every host on the path of 367 an article keeps track of it in the logfiles, making it possible to 368 find the sender of forged or abusive articles with the aid of the 369 administrators of the newshosts along the path. For the distribution 370 of NetNews over IP multicast, this is no longer true: routers don't 371 log packets flowing by and as the sender address of IP packets can be 372 forged, a sender can't be traced. This fact can be used to inject 373 forged news articles without being traceable. 375 To prevent the unnoticed injection of articles, a mcntp receiver only 376 accepts articles from senders that it trusts. This trust is build by 377 digitally signing the article with the private key of the sender and 378 verifying the signature at the receiver site. Receivers have to 379 accept only articles with good signatures 381 The RIPEMD-160 message digest algorithm has been chosen, as it is 382 more secure than MD5 while still being fast enough. The RSA 383 encryption algorithm has been chosen as there exist reference 384 implementations for usage inside US (from RSA Inc.) and outside 385 (rsaeuro by J.S.A.Kapp). 387 The key size for the RSA algorithm must be at least 512 bit in size 388 to prevent cracking of the key. 390 References 392 [1] RFC 977 -- B. Kantor, P. Lapsley, "Network News Transfer Protocol: 393 A Proposed Standard for the Stream-Based Transmission of News". 395 [2] RFC 1112 -- S. Deering, "Host extensions for IP multicasting", 396 08/01/1989. 398 [3] RFC 768 -- J. Postel, "User Datagram Protocol", 08/28/1980. 400 [4] XTP -- W. T. Strayer, D.J. Dmepsey, B.C. Weaver, "XTP: The Xpress 401 Transfer Protocol", Addison-Wesley 403 [5] KLG -- M. Hofmann, "Zuverlaessige Kommunikation in heterogenen 404 Netzen", Thesis at "Institut fuer Telematik, CS Dept. Univ 405 Karlsruhe" 407 [6] RMTP -- Lin, John C., Paul Sanjoy, "RMTP: A Reliable Multicast 408 Transport Protocol". 410 [7] RFC 1036 -- M. Horton, R. Adams, "Standard for interchange of 411 USENET messages", 12/01/1987. 413 [8] RFC 1950 -- L. Deutsch, J. Gailly, "ZLIB Compressed Data Format 414 Specification version 3.3", 05/23/1996. 416 [9] http://www.xlink.net/~hwr/histo/ -- Some Statistics about size dis- 417 tribution of NetNews 419 [10] RFC 793 -- J. Postel, "Transmission Control Protocol", 09/01/1981. 421 [11] H. Dobbertin, A. Bosselaers, B. Preneel, "RIPEMD-160: A 422 Strengthened Version of RIPEMD" 04/18/1996. An earlier version 423 appeared in "Fast Software Encryption,LNCS 1039" Springer Verlag, 424 1996, pp. 71-82. 426 Author's Address 428 Heiko W.Rupp 429 Gerwigstr. 5 430 D-76131 Karlsruhe 432 Phone: +49 721 9661524 434 EMail: hwr@pilhuhn.de