[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                        R. S. Brand
Internet-Draft                                                L. Sherzer
Expires: April 14, 2004                                    R. W. Rognlie
                                                        October 15, 2003


               Designated Relays Inquiry Protocol (DRIP)
                        draft-brand-drip-02.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

   This Internet-Draft will expire on April 14, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   The Designated Relays Inquiry Protocol, DRIP, is a method for domain
   name owners to specify the IP addresses that are authorized to relay
   mail as a domain name. The protocol provides a method for server MTAs
   to determine if the IP address of a client MTA is authorized to use a
   domain name.










Brand, et al.            Expires April 14, 2004                 [Page 1]


Internet-Draft                    DRIP                      October 2003


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Designating Relays . . . . . . . . . . . . . . . . . . . . . .  6
   3.1 Designation Record Template  . . . . . . . . . . . . . . . . .  6
   3.2 Default Designation Records  . . . . . . . . . . . . . . . . .  7
   3.3 IPv4 Designation Records . . . . . . . . . . . . . . . . . . .  7
   3.4 IPv6 Designation Records . . . . . . . . . . . . . . . . . . .  8
   3.5 Designation Examples . . . . . . . . . . . . . . . . . . . . .  9

   4.  MTA Operation  . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.1 DRIP Authorization Retrieval . . . . . . . . . . . . . . . . . 10
   4.2 DRIP Status Determination  . . . . . . . . . . . . . . . . . . 10
   4.3 DRIP Status Meanings . . . . . . . . . . . . . . . . . . . . . 11
   4.4 MTA Operation Examples . . . . . . . . . . . . . . . . . . . . 12

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14

       Normative References . . . . . . . . . . . . . . . . . . . . . 15

       Informative References . . . . . . . . . . . . . . . . . . . . 16

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17

   A.  Dictatorial Powers . . . . . . . . . . . . . . . . . . . . . . 18

   B.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19

       Intellectual Property and Copyright Statements . . . . . . . . 20

















Brand, et al.            Expires April 14, 2004                 [Page 2]


Internet-Draft                    DRIP                      October 2003


1. Introduction

   The Designated Relays Inquiry Protocol, DRIP, is a method for domain
   name owners to specify the IP addresses that are authorized to relay
   mail as a domain name in the SMTP HELO and EHLO commands. The
   protocol provides a method for server MTAs to determine if the IP
   address of a client MTA is authorized to use the domain name given in
   the SMTP HELO and EHLO commands.

1.1 Motivation

   Source verification information transmitted as part of a mail
   message, such as digital signatures, can permit MTAs, MDAs, and MUAs
   to verify that a messages is associated with a sender or gateway.
   However, those methods do not prevent malware authors from:

   o  Embedding a verifiable (signed) message in the malware.

   o  Embedding a verifier generator (private key) in the malware.

   Either technique permits malware afflicted machines to send
   verifiable messages.

   DRIP is designed to force malware authors to send the malware
   generated mail through the relays the afflicted systems are already
   configured and authorized use. Operators of those relays are very
   likely to have an existing relationship with the operators of the
   afflicted systems and can act to limit the damage to the internet
   caused by the malware.






















Brand, et al.            Expires April 14, 2004                 [Page 3]


Internet-Draft                    DRIP                      October 2003


1.2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   DNS
      Domain Name System. See [RFC1034] and [RFC1035].

   IPv4
      Internet Protocol version 4.

   IPv6
      Internet Protocol version 6.

   ISP
      Internet Service Provider.

   Malware
      Malicious software. See [RFC2828].

   MDA
      Mail Delivery Agent.

   Mail Relay
      See MTA.

   MTA
      Mail Transfer Agent.

   MUA
      Mail User Agent.

   Relay
      See MTA.

   SMTP
      Simple Mail Transfer Protocol. See [RFC2821]

   Standardese
      A peculiar dialect employed by authors of standards.










Brand, et al.            Expires April 14, 2004                 [Page 4]


Internet-Draft                    DRIP                      October 2003


2. Overview

   Domain name owners identify and record the IP addresses that are
   authorized to relay mail as their domain name. How the IP addresses
   are identified is beyond the scope of this document, but will likely
   involve consultation with the postmaster for the domain name. The IP
   address authorization records are recorded in DNS as described in
   Section 3.

   Server MTAs verify the domain name the client MTA submitted as
   identification, by querying for the IP address authorization records
   recorded by the domain name owner. Based on the result of the query,
   the server MTA can determine if the domain name is a DRIP
   participant. If the domain name is a DRIP participant, the result of
   the query will also indicate if the IP address of the client is
   authorized to use the domain name to relay mail. Section 4 specifies
   the operation of server MTAs following this protocol.


































Brand, et al.            Expires April 14, 2004                 [Page 5]


Internet-Draft                    DRIP                      October 2003


3. Designating Relays

   Domain name owners record the designated relays by adding a
   specifically formatted DNS record for each IP address that is
   authorized to use a domain name in the SMTP HELO or EHLO commands.
   Default records are also added to indicate DRIP participation by the
   domain name, and that the IP address used in the query is NOT
   authorized to use the domain name to relay mail.

3.1 Designation Record Template

   The template for the DNS records is:

      ${IPS}.${IPV}.relays._email_.${DOMAIN}.   IN   ${TYPE}   ${IP}

   With:

   ${IPS}
      The textual representation of the IP address.

   ${IPV}
      The textual representation of the IP protocol version used.

   ${DOMAIN}
      The domain name used in the SMTP HELO or EHLO commands.

   ${TYPE}
      The DNS record type corresponding to the IP protocol version of
      the IP address.

   ${IP}
      The IP address.

   See [RFC2782] for a discussion of the need for the underscores.

















Brand, et al.            Expires April 14, 2004                 [Page 6]


Internet-Draft                    DRIP                      October 2003


3.2 Default Designation Records

   The following default or "wildcard" records are added for each domain
   name and defined IP protocol version. These records, when returned as
   a result of a DRIP query, indicate DRIP participation by the domain
   name and that IP address used in the query is NOT authorized to use
   the domain name in the SMTP HELO or EHLO commands.

      *.${IPV}.relays._email_.${DOMAIN}.   IN   ${TYPE}   ${IPZ}

   Where ${IPZ} depends on the IP protocol version.

   A default record returned as the result of a DRIP query is identified
   by the value of the record, ${IPZ}, which is defined for each IP
   protocol version and corresponds to the "unspecified address".

   Both IPv4 and IPv6 default designation records SHOULD be added for
   each domain name.

3.3 IPv4 Designation Records

   For IP version 4 addresses, the following applies:

   ${IPS}
      Textual representation of the IPv4 address of the Designated Relay
      in "dotted quad", also known as "dotted decimal", notation but
      with the dots replaced by underscores.  This textual
      representation was chosen to be easy for both the wetware
      components and the software components to implement the protocol.

      The textual representation of the IPv4 loopback address,
      127.0.0.1, is

         127_0_0_1

   ${IPV}
      "IPv4".

   ${TYPE}
      "A".

   ${IP}
      The IP address of the the Designated Relay.

   ${IPZ}
      "0.0.0.0", the IPv4 "unspecified address". Chosen because it can
      not be a valid client IP address when used with TCP.




Brand, et al.            Expires April 14, 2004                 [Page 7]


Internet-Draft                    DRIP                      October 2003


3.4 IPv6 Designation Records

   For IP version 6 addresses, the following applies:

   ${IPS}
      Textual representation of the IPv6 address of the Designated Relay
      formatted as a sequence of 8 16bit words separated by underscores.
      Each word is represented by 4 hexadecimal digits. The words and
      the hexadecimal digits of a word are in network byte order. This
      IPv6 address representation is similar to the representation in
      [RFC3513] except that the colons have been replaced with
      underscores, and that leading zeros MUST be included.  This
      textual representation was chosen to be easy for both the wetware
      components and the software components to implement the protocol.

      The textual representation of the IPv6 loopback address, ::1, is:

         0000_0000_0000_0000_0000_0000_0000_0001

      The textual representation of the IPv6 address 2002:c000:201::1234
      is:

         2002_c000_0201_0000_0000_0000_0000_1234

   ${IPV}
      "IPv6".

   ${TYPE}
      "AAAA".

   ${IP}
      The IP address of the the Designated Relay.

   ${IPZ}
      "::", the IPv6 "unspecified address". Chosen because it can not be
      a valid client IP address when used with TCP.

   MTAs with IPv4-compatible IPv6 addresses [RFC3513] SHOULD also have
   an IPv4 DRIP record for the IPv4 part of each IPv4-compatible IPv6
   address.











Brand, et al.            Expires April 14, 2004                 [Page 8]


Internet-Draft                    DRIP                      October 2003


3.5 Designation Examples

3.5.1 Designation Example 1

   The owner of the domain name EXAMPLE.COM would add the following DNS
   records to the EXAMPLE.COM zone to indicate that the domain name
   EXAMPLE.COM is NOT valid for use in the SMTP HELO and EHLO commands.

      Default Designation Records:

         *.IPv4.relays._email_.EXAMPLE.COM.     IN    A      0.0.0.0

         *.IPv6.relays._email_.EXAMPLE.COM.     IN    AAAA   ::

      IPv4 Designation Records:

         None.

      IPv6 Designation Records:

         None.


3.5.2 Designation Example 2

   The owner of the domain name M.EXAMPLE.COM would add the following
   DNS records to the M.EXAMPLE.COM zone to indicate that ONLY the IPv4
   addresses 192.0.2.10, 192.0.2.11, and 127.0.0.1 are authorized to use
   the domain name in the SMTP HELO and EHLO commands.

      Default Designation Records:

         *.IPv4.relays._email_.M.EXAMPLE.COM.    IN    A      0.0.0.0

         *.IPv6.relays._email_.M.EXAMPLE.COM.    IN    AAAA   ::

      IPv4 Designation Records:

         192_0_2_10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10

         192_0_2_11.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.11

         127_0_0_1.IPv4.relays._email_.M.EXAMPLE.COM.   IN A  127.0.0.1

      IPv6 Designation Records:

         None.




Brand, et al.            Expires April 14, 2004                 [Page 9]


Internet-Draft                    DRIP                      October 2003


4. MTA Operation

   Server MTAs use the IP address of the client MTA from the SMTP
   connection and the domain name, which the client submitted as
   identification in the SMTP HELO or EHLO command, to verify that the
   IP address is authorized to use the domain name to relay mail. The
   process for doing this is:

   1.  Attempt to retrieve the DRIP authorization record for the IP
       address and the domain name via DNS.

   2.  Examine the result of the DNS retrieval attempt to determine the
       DRIP status.

   3.  Continue or terminate the SMTP transaction based on the DRIP
       status and local policy.

   DRIP authorization checks may be deferred until the MAIL command in
   the SMTP transaction or not be performed at all for SMTP transactions
   where relay authorization schemes are used. Examples of relay
   authorization schemes are, an ISP's use of the client's IP address to
   allow only the ISP's customers to relay; or a corporate server MTA
   using SMTP AUTH to allow roaming senders to relay.

4.1 DRIP Authorization Retrieval

   The DRIP authorization record to retrieve is the DNS record, as
   described in Section 3.1, corresponding to the IP address and domain
   name that the client MTA identified itself as.

   IPv6 server MTAs MUST perform the DRIP authorization retrieval using
   the IPv4 address of the "IPv4-mapped IPv6 address" [RFC3513] when
   clients connect from IPv4-mapped IPv6 addresses.

4.2 DRIP Status Determination

   A successful retrieval of a single record of the appropriate type
   with the IP address in the record matching the IP address of the
   client has a DRIP status of DRIP_OK. The requirement that the IP
   address in the authorization record be the IP address of the client,
   is to prevent malware authors from easily designating the entire IP
   address space as authorized to relay as a given domain name.

   A successful retrieval of a single record of the appropriate type
   with the IP address in the record not matching the IP address of the
   client has a DRIP status of DRIP_NOT_OK.





Brand, et al.            Expires April 14, 2004                [Page 10]


Internet-Draft                    DRIP                      October 2003


   Any type of temporary DNS retrieval or network failure has a DRIP
   status of DRIP_TEMP_FAIL.

   Any other type of DNS result, such as a permanent error, multiple
   records retrieved, retrieved record not of the correct record type,
   etc., has a DRIP status of DRIP_UNKNOWN.

4.3 DRIP Status Meanings

   The DRIP statuses have the following meanings:

   DRIP_OK
      This indicates that the IP address of the client is one of the
      authorized IP addresses for the domain name to use to relay mail.
      The SMTP transaction may continue.

   DRIP_NOT_OK
      This indicates that the IP address of the client is not one of the
      authorized IP addresses for the given domain name to use to relay
      mail.  Local policy of the server MTA determines if the SMTP
      transaction should continue or not. If the SMTP transaction is to
      be terminated, it SHOULD be terminated with a permanent failure,
      5XX, reply code.

   DRIP_TEMP_FAIL
      This indicates that the lookup could not be completed at this
      time. Local policy of the server MTA determines if the SMTP
      transaction should continue or not. If the SMTP transaction is to
      be terminated, it SHOULD be terminated with a temporary failure,
      4XX, reply code.

   DRIP_UNKNOWN
      This indicates that the given domain name is not a DRIP
      participant. Local policy of the server MTA determines if the SMTP
      transaction should continue or not.

      A RECOMMENDED local policy is for the server MTA to, iteratively,
      use the parent domain names to perform more DRIP authorization
      retrievals. If any of those retrievals result in either a DRIP_OK
      status or a DRIP_NOT_OK status, the server MTA SHOULD assume that
      the client is NOT authorized to relay mail as the given domain
      name.









Brand, et al.            Expires April 14, 2004                [Page 11]


Internet-Draft                    DRIP                      October 2003


4.4 MTA Operation Examples

   The following examples assume that the DNS records described in
   Section 3.5 exist and that no other DRIP related DNS records exist
   for the domain names used.

4.4.1 MTA Operation Example 1

   A server MTA accepts an SMTP connection from IP address 192.0.2.10
   and the client identifies itself as M.EXAMPLE.COM.

   1.  The server attempts to retrieve the DRIP authorization record

       192_0_2_10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10

       via a DNS lookup.

   2.  The DNS lookup retrieves a single A record with the IP address
       192.0.2.10.

   3.  Since only a single record was retrieved, it was of the correct
       type, and IP address in the record is the IP address of the
       client, the DRIP status is DRIP_OK.

   4.  The SMTP transaction continues.


4.4.2 MTA Operation Example 2

   A server MTA accepts an SMTP connection from IP address 192.0.2.99
   and the client identifies itself as S.EXAMPLE.COM.

   1.  The server attempts to retrieve the DRIP authorization record

       192_0_2_99.IPv4.relays._email_.S.EXAMPLE.COM.  IN A  192.0.2.99

       via a DNS lookup.

   2.  The DNS lookup results in a "Name Error", indicating that the
       record does not exist.

   3.  Since the DNS lookup resulted in a permanent lookup error, the
       the DRIP status is DRIP_UNKNOWN and the server uses local policy
       to determine if the SMTP transaction should continue or not.







Brand, et al.            Expires April 14, 2004                [Page 12]


Internet-Draft                    DRIP                      October 2003


   4.  If the server follows the RECOMMENDED local policy of performing
       DRIP authorization retrievals using parent domain names when a
       DRIP status of DRIP_UNKNOWN is encountered, the server attempts
       to retrieve the DRIP authorization record

       192_0_2_99.IPv4.relays._email_.EXAMPLE.COM.  IN A  192.0.2.99

       via a DNS lookup.

   5.  The DNS lookup retrieves a single A record with the IP address
       0.0.0.0.

   6.  Since only a single record was retrieved, and the record was of
       the correct type, and the IP address in the record is not the IP
       address of the client, the DRIP status is DRIP_NOT_OK.

   7.  Because this was a DRIP authorization retrieval of a parent
       domain and the status is of this retrieval is DRIP_OK or
       DRIP_NOT_OK, the server SHOULD assume that the client is NOT
       authorized to relay mail as the given domain name.

   8.  Based on local policy and the DRIP status, the server terminates
       the SMTP transaction with a permanent failure, 5XX, reply code.


4.4.3 MTA Operation Example 3

   A server MTA accepts an SMTP connection from IP address
   ::FFFF:C000:263 and the client identifies itself as S.EXAMPLE.COM.

   Because the IP address of the client is the IPv4-mapped IPv6 address
   of 192.0.2.99, the server MUST perform the same operations as in
   Section 4.4.2.


















Brand, et al.            Expires April 14, 2004                [Page 13]


Internet-Draft                    DRIP                      October 2003


5. Security Considerations

   This method relies on DNS to verify relay authorization and as such
   is vulnerable to the security issues of DNS. However, this is no
   different than mail, in general, being vulnerable to DNS security
   issues. Sites concerned about this should investigate implementing
   [RFC2401] and/or [RFC2535].

   A likely, and intended, response of malware authors to wide spread
   adoption of DRIP is to search afflicted systems for MUA settings and
   use the configured gateways, and possibly identities and credentials,
   to mail their payloads. It is hoped that the gateway operators will
   notice the undesirable traffic and be able to do something about it.
   The gateway operators already have a relationship with the
   operator(s) of the afflicted systems and are in a much better
   position, than the internet at large, to be able to correct the
   problem.

   DRIP is intended and designed to help protect your systems from the
   malware afflicted systems of others. Not to protect your systems from
   your own malware afflicted systems. Sites concerned about this should
   investigate the use of malware detectors on their systems.

   While not a security consideration, DRIP does not provide any
   assurances to the server MTA that the mail being relayed from the
   client is not SPAM; only that the IP address of the client MTA is
   authorized to relay mail as the domain name, the client identified
   itself as, in the SMTP EHLO or HELO command.























Brand, et al.            Expires April 14, 2004                [Page 14]


Internet-Draft                    DRIP                      October 2003


Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2782]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.


































Brand, et al.            Expires April 14, 2004                [Page 15]


Internet-Draft                    DRIP                      October 2003


Informative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1886]  Thomson, S. and C. Huitema, "DNS Extensions to support IP
              version 6", RFC 1886, December 1995.

   [RFC1925]  Callon, R., "The Twelve Networking Truths", RFC 1925,
              April 1996.

   [RFC1983]  Malkin, G., "Internet Users' Glossary", RFC 1983, August
              1996.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

   [RFC2828]  Shirey, R., "Internet Security Glossary", RFC 2828, May
              2000.


























Brand, et al.            Expires April 14, 2004                [Page 16]


Internet-Draft                    DRIP                      October 2003


Authors' Addresses

   Raymond S Brand
   P.O. Box 100486
   Ft. Lauderdale, FL  33310
   US

   EMail: rsbx@acm.org
   URI:   http://www.RSBX.com/


   Laurence Sherzer
   P.O. Box 5072
   Deerfield Beach, FL  33442
   US

   EMail: laurence@sherzer.net
   URI:   http://www.sherzer.net/


   Richard W Rognlie
   2782 Prince Harold Ct
   Oak Hill, VA  20171
   US

   EMail: ietf-drip-draft@spamblock.gamerz.net
   URI:   http://www.gamerz.net/rrognlie/
























Brand, et al.            Expires April 14, 2004                [Page 17]


Internet-Draft                    DRIP                      October 2003


Appendix A. Dictatorial Powers

   Any measure to control SPAM, if it is to be effective, must create or
   enhance the power of one or more entities involved in moving email
   from the source to the destination(s).

   The method described in this document enhances the ability of the
   domain name owner to control which MTAs may identify themselves as a
   domain name.










































Brand, et al.            Expires April 14, 2004                [Page 18]


Internet-Draft                    DRIP                      October 2003


Appendix B. Acknowledgments

   The authors gratefully acknowledges the contributions of: Robert M.
   Bownes III.















































Brand, et al.            Expires April 14, 2004                [Page 19]


Internet-Draft                    DRIP                      October 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). 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 assignees.

   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



Brand, et al.            Expires April 14, 2004                [Page 20]


Internet-Draft                    DRIP                      October 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Brand, et al.            Expires April 14, 2004                [Page 21]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/