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]