home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-exp-rupp-01.txt < prev    next >
Text File  |  1997-06-06  |  20KB  |  523 lines
  1. INTERNET-DRAFT                EXPIRES DEC 1997      INTERNET-DRAFT
  2.  
  3. Network Working Group                                     Heiko W.Rupp
  4.  
  5. Experimental                                                27.05.1997
  6.  
  7.  
  8.          A Protocol for the Transmission of Net News Articles
  9.                            over IP multicast.
  10.             <draft-rfced-exp-rupp-01.txt>
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working
  15.    documents of the Internet Engineering task Force (IETF), its areas,
  16.    and its working groups.  Note that other groups may also distribute
  17.    working documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six
  20.    months and may be updated, replaced, or obsoleted by other
  21.    documents at any time.  It is inappropriate to use Internet-Drafts
  22.    as reference material or to cite them other than as "work in
  23.    progress".
  24.  
  25.    To learn the current status of any Internet-Draft, please check the
  26.    "1id-abstract.txt" listing contained in the Internet-Drafts Shadow
  27.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  28.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  29.    ftp.isi.edu (US West Coast).
  30.  
  31.  
  32. Abstract
  33.  
  34.    This protocol provides a way to use the IP multicast infrastructure
  35.    to transmit NetNews articles between news servers. Doing so will
  36.    reduce the bandwidth that is actually needed for transmission via
  37.    NNTP. This does not affect how news reading clients communicate with
  38.    servers.
  39.  
  40. Overview and Rationale
  41.  
  42.    NetNews are bulk data that are produced in large quantities every day
  43.    around the world. Distribution of NetNews on the Internet are usually
  44.    distributed with NNTP[1]. In order to get a fast and redundant
  45.    distribution many news servers communicate with many others, thus
  46.    imposing a higher load on the underlying network than necessary.
  47.  
  48.    Assume the following scenario:
  49.  
  50.                              +---------  R1
  51.                             /
  52.              S -- A ------- B  --------  R2
  53.                             \
  54.                               +--------- R3
  55.  
  56.    A sender S which wants to transmit articles via NNTP to receivers
  57.    R1...R3 will thus transmit them three times across the link from A to
  58.    B.
  59.  
  60.    With IP Multicast[2], an efficient way to distribute datagrams to
  61.    groups of users exists in the Internet. Thus articles would traverse
  62.    the link A to B only once, thus reducing load on that link.
  63.  
  64.    This cannot be done with existing news transfer technology, as it is
  65. Rupp                                                            [Page 1]
  66.  
  67. =0C
  68.                      NETNEWS OVER IP MULTICAST           29 April 1997
  69.  
  70.  
  71.    based on TCP[10] which cannot be multicasted.  The protocol described
  72.    in this memo is designed to put news articles into datagrams and
  73.    distribute them via IP multicast to receivers that are interested in
  74.    the specific newsgroup. For more information about NetNews, refer to
  75.    [7] and [1].
  76.  
  77.    In the rest of this memo I will refer to the protocol as ``Multicast
  78.    News Transport Protocol'' (Mcntp).
  79.  
  80. Protocol overview
  81.  
  82.    This paragraph will show how news articles are propagated with Mcntp.
  83.    Basically, three parties are involved:
  84.  
  85.  
  86.    +    Multicast directory service, MD, coordinates the assignment
  87.         between multicast and news groups.
  88.  
  89.    +    A Multicast sender, MS, that sends news articles over an
  90.         IP multicast infrastructure
  91.  
  92.    +    A Multicast receiver, MR, gets packets from the IP multicast
  93.         infrastructure and processes them further.
  94.  
  95.    So this can be seen as follows:
  96.  
  97.                directory       +---------+    directory
  98.              +------------- >  |         | ----------------+
  99.             \|/                |   MD    |                \|/
  100.          +---------+           |         |             +--------+
  101.          |         |           +---------+             |        |
  102.          |   MS    |                                   |   MR   |
  103.          |         | ------------ articles ------->    |        |
  104.          +---------+                                   +--------+
  105.  
  106.    MS and MR can be implemented into existing news server software, or
  107.    can be implemented as separate processes that communicate with the
  108.    news servers (e.g. via NNTP); this does not matter to the protocol.
  109.  
  110.    MD can either be implemented within MS, or as separate processes that
  111.    communicate with each other. A practical way is to have on MD per
  112.    sender host so that communication between MD and MS is fast and
  113.    reliable, while not too many resources are needed.
  114.  
  115.    The protocol itself consist of two parts that will be presented in
  116.    the next two chapters -- Distribution of articles and the directory
  117.    service.
  118.  
  119.  
  120.  
  121.  
  122. Rupp                                                            [Page 2]
  123.  
  124. nnnn               NETNEWS OVER IP MULTICAST           29 April 1997
  125.  
  126.  
  127. Packet format -- Distribution of articles
  128.  
  129.    To send articles via IP multicast, they have to be encapsulated into
  130.    UDP packets. The following diagram shows how this can be done:
  131.  
  132.          +---------------------------------------+
  133.          |                 Magic                 |
  134.          +----+----+----+----+---------+---------+
  135.          | Ver|Rev |Comp|Cryp|Reserved |  Offset |
  136.          +----+----+----+----+---------+---------+
  137.          |            Original length            |
  138.          +---------------------------------------+
  139.          |             Length as sent            |
  140.          +---------------------------------------+
  141.          |               Sender-ID               |
  142.          +---------------------------------------+
  143.          |              Message-id               |
  144.          +---------------------------------------+
  145.          |               Data                    |
  146.          +---------------------------------------+
  147.  
  148.    All entries are in network byte order.  The fields have the following
  149.    meaning and types:
  150.  
  151.  
  152.     +    Magic (32-bit): The String ``McNt''
  153.  
  154.     +    Ver (4-bit): Protocol version -- currently 1
  155.  
  156.     +    Rev (4-bit): Protocol revision -- currently 1
  157.  
  158.     +    Comp (4-bit): Compression method used. Currently are only 2
  159.          methods defined:
  160.  
  161.           0    Article is not compressed
  162.  
  163.           1    Article is compressed via zlib [8]
  164.  
  165.     +    Cryp (4-bit): Encryption method used. See below
  166.  
  167.     +    Reserved (8-bit): Reserved for future extensions.
  168.  
  169.     +    Offset (8-bit): Offset of article data from packet start
  170.  
  171.     +    Original length (32-bit): Length of article before compression,
  172.          encryption and signing.
  173.  
  174.     +    Length as sent (including digital signature) (32-bit): Size of
  175.  
  176.  
  177.  
  178. Rupp                                                            [Page 3]
  179.  
  180. =0C
  181.  nnnn               NETNEWS OVER IP MULTICAST           29 April 1997
  182.  
  183.  
  184.          the ``Data'' field (see below)
  185.  
  186.     +    Sender-ID: Identification of the sender host terminated by a
  187.          null byte (see below).
  188.  
  189.     +    Message-ID: The message id of the article in the form it is
  190.          defined in RFC 1036 [7], terminated by a null byte.
  191.  
  192.     +    Data: The signed article data after possible compression and
  193.          encryption.
  194.  
  195.    This memo does not specify a encryption method for the case that the
  196.    field ``Crypt'' is set to anything other than 0; the involved parties
  197.    (i.e. the senders of encrypted news and their receivers) have to
  198.    agree on a method they want to use. If encryption and compression is
  199.    used then the article data is first to be compressed and then the
  200.    result to be encrypted.
  201.  
  202.    All articles must be signed before sending them off the net. This is
  203.    accomplished by running the RIPEMD-160 message digest [11] algorithm
  204.    over the (possibly compressed and encrypted) article and then RSA-
  205.    encrypting the message digest with the private key that is suitable
  206.    for sender-id.  The receiver decrypts the signature of the article
  207.    with the public key of sender-id and runs RIPEMD-160 over the data to
  208.    see if it has been altered on the way. An article with an invalid
  209.    signature or a non matching message digest has to be thrown away. The
  210.    sender-id can be the path entry or the hostname of the sending site;
  211.    there can also be more than one key pair per site e.g. to have dif-
  212.    ferent keys for different newsgroups.  The sender-id has to be
  213.    treated in a case independent manner.
  214.  
  215.    Encryption of the message digest is done the following way. The 20
  216.    Bytes RIPEMD-160 message digest and the first 28 bytes of the
  217.    (possibly compressed and encrypted) message are tacked together to
  218.    form a 48 Bytes buffer. This buffer is then encrypted with the right
  219.    RSA private key and prepended to the original message without the
  220.    first 28 bytes:
  221.  
  222.          +----------------+---------------------------------+
  223.          | Message digest | message                         |
  224.          +----------------+-----------+---------------------+
  225.                            1         28                     n
  226.          |                    \
  227.  
  228.          +-----------------------+----------------------------------+
  229.          | Signature             |  message without first 28 Bytes  |
  230.          +-----------------------+----------------------------------+
  231.  
  232.  
  233.  
  234.  
  235. Rupp                                                            [Page 4]
  236.  
  237. =0C
  238.  nnnn               NETNEWS OVER IP MULTICAST           29 April 1997
  239.  
  240.  
  241.    To send an article off, it is encapsulated and then just sent to the
  242.    appropriate multicast group. There is no feedback from the receiver
  243.    to the sender when an article is received.
  244.  
  245. Directory service
  246.  
  247.    In order to get a relation between newsgroups and multicast groups, a
  248.    directory service exists; this has been referenced as MD above.  When
  249.    a sender MS wants to propagate a news group, it asks the directory
  250.    service for a multicast group it can use to distribute articles,
  251.    waits for the reply, and starts to send. The directory server
  252.    registers this group in its tables and periodically distributes this
  253.    table over IP multicast. For this purpose, the multicast group
  254.    ``mcntp-directory.mcast.net'' has been officially been assigned by
  255.    the IANA. The UDP port which announcements are sent to, has
  256.    officially been assigned by the IANA as UDP port number 5418 with the
  257.    name ``mcntp''.
  258.  
  259.    Announcements should not be sent too often to keep traffic low, but
  260.    often enough that new receivers don't have to wait to long to be able
  261.    to receive articles. Once a minute is assumed to be a good value
  262.    here.  Announcements can be sent less often if they are transmitted
  263.    immediately after a change in the directory.
  264.  
  265.    If more than one directory server is involved (e.g. if there is more
  266.    than one sender site), the directory servers have to listen to
  267.    announcement packets on ``mcntp-directory.mcast.net''. If it does not
  268.    receive a packet after five times the waiting period (e.g., five
  269.    minutes) it can consider itself alone on the net and can choose the
  270.    multicast groups as it wishes. If it does receive a packet, it must
  271.    register the contained groups in its tables and has to select new
  272.    groups so that different newsgroups are not mapped on the same
  273.    multicast group.
  274.  
  275.    When a receiver (MR) wants to receive a newsgroup, it listens on
  276.    ``mcntp-directory.mcast.net'' for announcements, parses them, and
  277.    then joins the appropriate multicast groups.
  278.  
  279.    Multicast groups that are no longer in use (e.g. because the sender
  280.    has stopped working) must be removed from the announcement.
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292. Rupp                                                            [Page 5]
  293.  
  294. =0C
  295. nnnn               NETNEWS OVER IP MULTICAST           29 April 1997
  296.  
  297.  
  298.    The format of those announcement packets is:
  299.  
  300.          +-----------+------+-----+--------+
  301.          |   Magic   | Vers | Rev | Offset |
  302.          +-----------+------+-----+--------+
  303.          |             Length              |
  304.          +---------------------------------+
  305.          |            rmd160               |
  306.          +---------------------------------+
  307.          |            Sender-ID            |
  308.          +-----------------+------+---+-----------+       -+
  309.          | Multicast group | Port |TTL| Newsgroup |        |
  310.          +-----------------+------+---+-----------+        |
  311.           ...  repeat ...                                  |  NG lines
  312.          +-----------------+------+---+-----------+        |
  313.          | Multicast group | Port |TTL| Newsgroup |        |
  314.          +-----------------+------+---+-----------+       -+
  315.  
  316.    All numbers are in network byte order.  The fields have the following
  317.    meaning and types:
  318.  
  319.  
  320.        +    Magic (16-bit): The Bytes 0xabba
  321.  
  322.        +    Vers (4-bit): Protocol version (see below)
  323.  
  324.        +    Rev (4-bit): Protocol revision (currently 1)
  325.  
  326.        +    Offset (8-bit): Offset of NG-lines from packet start.
  327.  
  328.        +    Length (32-bit): Total packet length.
  329.  
  330.        +    rmd160 (160-bit): RIPEMD-160 message digest over the rest of
  331.             the packet.
  332.  
  333.        +    Sender-ID  : Identification of sender host, terminated by a
  334.             null byte (see below).
  335.  
  336.        +    Multicast group (32-bit *): The associated multicast group
  337.  
  338.        +    Port (8-bit): UDP Port to use for this group
  339.  
  340.        +    TTL (8-bit): Time to live for multicast packets.
  341.  
  342.        +    Newsgroup: Name of the Newsgroup in wildmat(3) format,
  343.             terminated by a null byte.
  344.  
  345.    The protocol version (Vers) is currently 1 for IPv4 and 11 for IPv6.
  346.  
  347.  
  348.  
  349. Rupp                                                            [Page 6]
  350.  
  351. =0C
  352. nnnn               NETNEWS OVER IP MULTICAST           29 April 1997
  353.  
  354.  
  355.    The multicast group field (*) is 32 bit in size for IPv4 and 128-bit
  356.    for IPv6 in size.
  357.  
  358.    The length field is 32 bit in size to support IPv6 jumbo datagrams.
  359.  
  360.    The sender-ID is normally the fully qualified domain name of the
  361.    hosts that sends the announcement. As is common practice with
  362.    NetNews, this can also be the (possibly shorter) entry that the host
  363.    puts in the ``Path:'' header when an article passes through it. This
  364.    entry has to be treated in a case independent manner.
  365.  
  366.    The rmd160 is computed over the sender-id field and all lines with
  367.    newsgroup to multicast group relations in the packet with the
  368.    RIPEMD-160 message digest algorithm.
  369.  
  370.    The lines with newsgroup to multicast group relations are repeated as
  371.    often as needed to announce all groups. The TTL can be used by
  372.    clients to find out if packets that come from this source can reach
  373.    them, or if the sender is too far away.  Note that all entries have
  374.    to fit into one UDP packet.
  375.  
  376.    TTL values of articles have to be chosen, especially for use on the
  377.    MBONE, in a way that newsgroups that are only of local relevance
  378.    (e.g. campus groups or groups local to a town) are not distributed
  379.    out of their normal distribution area.
  380.  
  381. Reliability Considerations
  382.  
  383.    As UDP is a unreliable service, provisions for reliable distribution
  384.    of articles are needed. There exist some approaches to reliable
  385.    multicast (XTP [4], KLG [5] RMTP [6] and others) which all suffer
  386.    from some problem or other. Specifically, additional hard- or
  387.    software is needed and usually requires kernel modification.
  388.  
  389.    As there is already a reliable transport of NetNews via NNTP, there
  390.    is no need for a reliable transport via IP multicast: articles need
  391.    not be in order, so it is no problem if one is missing in the
  392.    multicast. Since articles need not arrive in order, lost or missing
  393.    articles can easily be transmitted via an additional NNTP feed.
  394.  
  395.    As UDP packets can be at maximum 64kBytes in size and every Mcntp
  396.    packet has to fit in one UDP packet, there is no provision given to
  397.    distribute news articles larger than about 63kBytes in size (other
  398.    than compressing them). This does not matter much in practise as
  399.    recent research has shown that more than 95% off all news articles
  400.    are smaller 64kBytes [9]. The remaining 5% can still be transferred
  401.    via NNTP. Some hosts may have problems in receiving UDP packets as
  402.    large as 64kBytes, so in practical use article sizes of 16kBytes
  403.  
  404.  
  405.  
  406. Rupp                                                            [Page 7]
  407.  
  408. =0C
  409. nnnn               NETNEWS OVER IP MULTICAST           29 April 1997
  410.  
  411.  
  412.    would be appropriate.
  413.  
  414. Summary
  415.  
  416.    The distribution of NetNews articles via IP multicast can be a way to
  417.    decrease the network bandwidth used to distribute them.  Articles are
  418.    delivered fast via a nonreliable protocol; later, the holes are
  419.    filled via a reliable, already existing protocol. Compression of
  420.    articles can further reduce the network Load. With encryption private
  421.    news groups can be established on a public IP multicast
  422.    infrastructure. A prototype of a reference implementation already
  423.    shows that Mcntp is fast and can be used as an alternative to
  424.    classical transports.
  425.  
  426. Security Considerations
  427.  
  428.    With the classical NNTP based distribution, every host on the path of
  429.    an article keeps track of it in the logfiles, making it possible to
  430.    find the sender of forged or abusive articles with the aid of the
  431.    administrators of the newshosts along the path.  For the distribution
  432.    of NetNews over IP multicast, this is no longer true: routers don't
  433.    log packets flowing by and as the sender address of IP packets can be
  434.    forged, a sender can't be traced. This fact can be used to inject
  435.    forged news articles without being traceable.
  436.  
  437.    To prevent the unnoticed injection of articles, a mcntp receiver only
  438.    accepts articles from senders that it trusts. This trust is build by
  439.    digitally signing the article with the private key of the sender and
  440.    verifying the signature at the receiver site.  Receivers have to
  441.    accept only articles with good signatures
  442.  
  443.    The RIPEMD-160 message digest algorithm has been chosen, as it is
  444.    more secure than MD5 while still being fast enough. The RSA
  445.    encryption algorithm has been chosen as there exist reference
  446.    implementations for usage inside US (from RSA Inc.) and outside
  447.    (rsaeuro by J.S.A.Kapp).
  448.  
  449.    The key size for the RSA algorithm must be at least 512 bit in size
  450.    to prevent cracking of the key.
  451.  
  452. References
  453.  
  454.  
  455. [1]  RFC 977 -- B. Kantor, P. Lapsley, "Network News Transfer Protocol:
  456.      A Proposed Standard for the Stream-Based Transmission of News".
  457.  
  458. [2]  RFC 1112 -- S. Deering, "Host extensions for IP multicasting",
  459.      08/01/1989.
  460.  
  461.  
  462.  
  463. Rupp                                                            [Page 8]
  464.  
  465. =0C
  466. nnnn               NETNEWS OVER IP MULTICAST           29 April 1997
  467.  
  468.  
  469. [3]  RFC 768 -- J. Postel, "User Datagram Protocol", 08/28/1980.
  470.  
  471. [4]  XTP -- W. T. Strayer, D.J. Dmepsey, B.C. Weaver, "XTP: The Xpress
  472.      Transfer Protocol", Addison-Wesley
  473.  
  474. [5]  KLG -- M. Hofmann, "Zuverlaessige Kommunikation in heterogenen
  475.      Netzen", Thesis at "Institut fuer Telematik, CS Dept. Univ
  476.      Karlsruhe"
  477.  
  478. [6]  RMTP -- Lin, John C., Paul Sanjoy, "RMTP: A Reliable Multicast
  479.      Transport Protocol".
  480.  
  481. [7]  RFC 1036 -- M. Horton, R. Adams, "Standard for interchange of
  482.      USENET messages", 12/01/1987.
  483.  
  484. [8]  RFC 1950 -- L. Deutsch, J. Gailly, "ZLIB Compressed Data Format
  485.      Specification version 3.3", 05/23/1996.
  486.  
  487. [9]  http://www.xlink.net/~hwr/histo/ -- Some Statistics about size dis-
  488.      tribution of NetNews
  489.  
  490. [10] RFC 793 -- J. Postel, "Transmission Control Protocol", 09/01/1981.
  491.  
  492. [11] H. Dobbertin, A. Bosselaers, B. Preneel, "RIPEMD-160: A
  493.      Strengthened Version of RIPEMD" 04/18/1996. An earlier version
  494.      appeared in "Fast Software Encryption,LNCS 1039" Springer Verlag,
  495.      1996, pp. 71-82.
  496.  
  497. Author's Address
  498.  
  499.    Heiko W.Rupp
  500.    Gerwigstr. 5
  501.    D-76131 Karlsruhe
  502.  
  503.    Phone: +49 721 9661524
  504.  
  505.    EMail: hwr@pilhuhn.de
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519. Rupp                                                            [Page 9]
  520.  
  521. INTERNET-DRAFT             EXP DEC 1997               INTERNET-DRAFT
  522.  
  523.