Network Working Group K.Mimura Internet-Draft: draft-ietf-fax-gateway-protocol-11.txt K.Yokoyama T.Satoh C.Kanaide TOYO Communication Equipment July 20 2004 Internet FAX Gateway Functions 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 obsolete 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract An Internet FAX Gateway provides functions which translate facsimile between the general switched telephone network (GSTN) and the Internet. This document provides information on recommended behaviors for Internet FAX Gateway functions for email-based Internet Fax. In this context, an offramp means facsimile data transmission to the GSTN from the Internet, and onramp means facsimile data transmission to the Internet from the GSTN. This document covers the delivery process of data with equipment which may include Internet Fax terminals, PCs on the Internet, and Fax terminals on the GSTN. Table Of Contents 1. Introduction 1.1 Key words 1.2 Intellectual property 2. Internet FAX Gateway Protocol Mimura, et. al. Expires January 2005 [Page1] Internet Draft Internet FAX Gateway Functions July 2004 3. Offramp Gateway 3.1 Offramp functions 3.2 Addressing 3.2.1 Examples of local dialing rules 3.3 User authorization 3.4 Return notice 4. Onramp Gateway 4.1 Onramp functions 4.2 Address designation 4.2.1 Immediate address designation 4.2.2 Indirect address designation 4.2.3 Support subaddress 4.3 Relay function 4.4 File format conversion 4.5 User authorization 4.6 Return notice 5. Security Considerations 6. References 6.1 Informative groups 6.2 Normative groups 7. Full Copyright Statement 8. Author's Address 1. Introduction An Internet FAX Gateway plays the role of gateway between Fax operations built on a General Switched Telephone Network (GSTN) and the Internet. This document defines the potential behavior of devices and applications which support these Fax operations. Gateways can be classified as an onramp, where facsimile data is translated from the GSTN to the Internet, and as an offramp, where facsimile data is translated from the Internet to the GSTN. A more detailed definition of onramps and offramps for email-based Internet Fax is provided in [1]. Internet FAX Gateway functions for real-time Internet Fax are defined in [2]. The scope of the Internet FAX Gateway defined in this document is shown below. 1) The format of image data is the data format defined by "simple mode" in [3]. 2) The operational mode is "store and forward", as defined in Section 2.5 of [1]. 1.1 Key words The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [4]. 1.2 Intellectual property The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this Mimura, et. al. Expires January 2005 [Page2] Internet Draft Internet FAX Gateway Functions July 2004 document. For more information consult the online list of claimed rights in . 2. Internet FAX Gateway Protocol There are two kinds of gateway functions: an onramp gateway and an offramp gateway. An onramp gateway receives facsimile data from a facsimile device over the GSTN, then sends the facsimile data to an Internet Fax-capable device or application. An offramp gateway receives an Internet Fax over the Internet from Internet Fax-capable devices, which may include an onramp gateway and a PC, then sends the facsimile data to a facsimile device over the GSTN. In both of these cases, facsimile communication between a gateway and the Internet is based on [3]. The protocols which are discussed in this document are shown below, and other communication protocols should be referred to in [3]. 1) The communication protocol between the onramp gateway and the GSTN. 2) The communication protocol between the offramp gateway and the GSTN. 3. Offramp Gateway 3.1 Offramp functions An offramp gateway provides a translation function, which is used when the offramp gateway receives an Internet Fax and then sends the facsimile data to facsimile devices over the GSTN using a standard facsimile protocol [5]. The communication protocol between the offramp gateway and the submitting Internet Fax device will be based on [3] for standards-based store and forward operations. 3.2 Addressing An offramp gateway MUST process the mailbox string and convert it to a "local-phone" according to local dialing rules. 3.2.1 Examples of local dialing rules The first example shows how an offramp gateway changes a "global-phone" to a "local-phone" by removing "+" and the international country code. If an offramp gateway receives the "global-phone" +12223334444 The "local-phone" is the string remaining after removing "+" and the international country code "1" from "global-phone". Therefore, "local-phone" is 2223334444 Mimura, et. al. Expires January 2005 [Page3] Internet Draft Internet FAX Gateway Functions July 2004 The next example shows how an offramp gateway changes a "global-phone" to "local-phone" by removing "+" and the international country code. Then, the "exit-code" "0" is put at the head of the string. If the offramp gateway receives the "global-phone" +81355556666 The "local-phone" is the string remaining after removing "+" and the international country code "81". The "exit-code" "0" is then put at the head of the string, so that the result from "global-phone" indirectly and "local-phone" directly is 0355556666 "Global-phone" is defined in Section 2 of [6]. "Local-phone" is defined in Section 2 of [7]. "Exit-code" is defined in Section 2.1 of [7]. 3.3 User authorization An offramp gateway MAY have a user authorization function to confirm that a user is allowed to transmit data. Digital signatures can be used for the user authorization function. For example, S/MIME is one of the digital signatures. S/MIME is described in [8][9][10][11][12]. An onramp gateway or a client PC send digital-signed S/MIME Fax message to the offramp gateway. The function to verify signatures is required for the offramp gateway. And the signature information is used for determine authorization. 3.4 Return notice An offramp gateway SHOULD have a function which allows the offramp gateway to send a return notice to the source IFax device (defined in [3]) when a transmission error occurs and the facsimile data is not transmitted. When the offramp gateway fails to transmit the return notice, the error information MAY be recorded to a log, and processing MAY end, or the administrator of the gateway system MAY be notified of these errors through a specific process (for example, SMTP). An MDN is used for the return notice. Because of the Fax device is a User Agent. And the offramp gateway makes return notice in place of the facsimile device. A disposition-type is set as a processed and a disposition-modifier is set as an error. Mimura, et. al. Expires January 2005 [Page4] Internet Draft Internet FAX Gateway Functions July 2004 4. Onramp Gateway 4.1 Onramp functions An onramp gateway MUST have a function that allows the onramp gateway to receive facsimile data from a facsimile device over the GSTN, and then send the generated Internet Fax to the appropriate IFax devices or PC via mail transfer agents. The transmission of data from the onramp gateway to IFax devices MUST based on [3]. 4.2 Address designation An onramp gateway SHOULD have a function that allows the onramp gateway to analyze the destination address from the address data sent by the facsimile device over the GSTN. If a GSTN number is transmitted as part of the local portion of the email address, it SHOULD be in the global-phone format. There are two kinds of address data needed next from the Fax device over the GSTN. They are the immediate address designation and indirect address designation. 4.2.1 Immediate address designation Immediate address designation is address data from a facsimile device over the GSTN that specifies the destination number directly. It is used when the destination is specified every time. Example (1) An onramp gateway receives the destination telephone number "12223334444" from the source facsimile by DTMF (Dual Tone Multi-Frequency). 12223334444 (2) The destination number is used as a "global-phone", so "+" is added at the head of the string. +12223334444 (3) "FAX=" is added at the head of "global-phone" in order to change "global-phone" into "fax-mbox". FAX=+12223334444 (4) In this example "fax-mbox" is used as "fax-address". "Fax-email" is formed by adding "@" and the appropriate offramp domain "mta-I-fax" behind "fax-address". FAX=+12223334444@example.com The procedure for choosing the domain name of an offramp gateway is defined in Section 4.3 (Relay function). Mimura, et. al. Expires January 2005 [Page5] Internet Draft Internet FAX Gateway Functions July 2004 "Global-phone", "fax-mbox", and "fax-address" are defined in Section 2 of [6]. "Mta-I-fax" is defined in Section 3 of [6]. "Fax-email" is defined in Section 4 of [6]. 4.2.2 Indirect address designation The indirect address number is extracted from the address data from the facsimile device on the GSTN, and the onramp gateway looks up the destination address by using the address change table, and so on, from the indirect address number. This function is used for transmission to a mail terminal, transmission to an often-used address, multicast transmission, and so on. An onramp gateway keeps the indirect address information. Or, it is acquired from another server. Indirect address information contains the following information. - Indirect address number - The list of the destination facsimile number and e-mail address, which is looked up in the address change table using the indirect address number. Example (1) An onramp gateway receives the indirect address number "1234" from the source facsimile by DTMF. 1234 (2) The destination address "addr-spec" is looked up in the address change table. address change table 1234 : ifax@example.com (3) An Internet Fax is sent to an Internet Fax device by the onramp gateway. "ifax@example.com " "Addr-spec" is defined in Section 6.1 of [13]. 4.2.3 Support subaddress An onramp gateway SHOULD support the subaddress. In the case of immediate address designation, the subaddress is analyzed using the T.33 [14] protocol. In the case of indirect address designation, the T.33 protocol is not used; the subaddress is looked up using the address change table, and so on, from the indirect address number. Mimura, et. al. Expires January 2005 [Page6] Internet Draft Internet FAX Gateway Functions July 2004 4.3 Relay function The onramp gateway SHOULD have a function which chooses the destination offramp gateway by analyzing a specified destination facsimile number. The onramp gateway SHOULD keep the relay information of the offramp gateway to carry out this function. The onramp gateway keeps the following offramp gateway relay information, or acquires it from another server. 4.4 File format conversion An onramp gateway MUST convert the file format from a facsimile over the GSTN to the file format TIFF Profile-S for Internet Fax, as defined in [15]. 4.5 User authorization An onramp gateway MAY have a user authorization function to confirm that the user is authorized to transmit data. For example, user authorization is performed through a user ID and password extracted from DTMF. 4.6 Return notice When an onramp gateway receives and analyzes a return notice from the destination, an onramp gateway MAY have the means to send the delivery status to a suitable facsimile device user on the GSTN through an appropriate offramp gateway. When an onramp gateway fails in the transmission of the return notice, the error information MAY be recorded to a log, and processing MAY end, or the administrator of the gateway system MAY be notified of these errors with a specific process (for example, SMTP). 5. Security Considerations Refer to Section 3.3 (User authorization) for authentication for an offramp gateway. OpenPGP [16] can be used for the authorization instead of the S/MIME. Refer to Section 4.5 (User authorization) for authentication for an onrampgateway. S/MIME and OpenPGP are also used for the encryption message. A signed message is protected from tapping through the network system. IPsec [17][18][19][20][21] is IP layer encryption protocol. IPsec cannot protect tapping from MTA. Because of plaintext is remained in MTA. TLS [22] runs on TCP layer. TLS cannot protect tapping from MTA, either. S/MIME and OpenPGP are most suitable for authentication and encryption of IFax messages. Denial of Service attacks are beyond the scope of this document. Host Compromise caused by flaws in the implementation is beyond the scope of this document. Mimura, et. al. Expires January 2005 [Page7] Internet Draft Internet FAX Gateway Functions July 2004 6. References 6.1 Informative groups [1] L. Masinter, "Terminology and Goals for Internet Fax", RFC 2542, March 1999. [21] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. 6.2 Normative groups [2] "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, June 1998. [3] K. Toyoda, H. Ohno, J. Murai and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [5] "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, April 1999. [6] C. Allocchio, "Minimal FAX address format in Internet Mail", RFC 3192, October 2001. [7] C. Allocchio, "GSTN Address Element Extensions in E-mail Services", RFC 2846, June 2000. [8] R. Housley, "Cryptographic Message Syntax", RFC2630, June 1999. [9] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [10] B. Ramsdell, "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999. [11] B. Ramsdell, "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [12] P. Hoffman, "Enhanced Security Services for S/MIME", RFC2634, June 1999. [13] D. Crocker, "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [14] "Facsimile routing utilizing the subaddress", ITU recommendation T.33, July 1996. [15] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998. Mimura, et. al. Expires January 2005 [Page8] Internet Draft Internet FAX Gateway Functions July 2004 [16] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, , ?gOpenPGP Message Format?h, RFC2440, November 1998. [17] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [18] Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402, November 1998. [19] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [20] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [22] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 7. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Mimura, et. al. Expires January 2005 [Page9] Internet Draft Internet FAX Gateway Functions July 2004 8. Author's Address Katsuhiko Mimura TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan Fax: +81 467 74 5743 Email: mimu@macroware.co.jp Keiichi Yokoyama TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan Fax: +81 467 74 5743 Email: keiyoko@msn.com Takahisa Satoh TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan Fax: +81 467 74 5743 Email: zsatou@toyocom.co.jp Chie Kanaide TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan Fax: +81 467 74 5743 Email: c-miwa@mail.nissan.co.jp Mimura, et. al. Expires January 2005 [Page10] Internet Draft Internet FAX Gateway Functions July 2004 Revision history [[[RFC editor: Please remove this section on publication]]] 00a 10-Jul-2000 Initial draft. 01a 16-Aug-2000 Remove next section. Authentication Authentication toward Offramp gateway Option function Multicasts transmit request Rename next section to Relay function from Choice of Offramp gateway to User authorization from User authentication to Immediate address designation from Direct address designation Section Drop the duplicate mail was moved to a part of the section Offramp functions. Corrections and clarifications. 02a 30-Oct-2000 Title is changed from Internet FAX Gateway Protocol to Internet FAX Gateway Functions Remove next definition. Drop duplications for Broadcast When send return notice Automatic re-transmission keep log for offramp gateway Example of User authorization keep log for onramp gateway Rebuild next definition 3.2 Addressing 3.2.1 example of local dialing rules 4.2.1 Immediate address designation 4.2.2 Indirect address designation 4.4 File format conversion 03a 21-Feb-2001 Rebuild next definition 1. 1) 3.4 Return notice 4.6 Return notice Add next definition 3.3 User authorization 04a 22-May-2001 Rebuild next definition 3.4 Return notice 4.6 Return notice 5. Security Considerations 05a 28-June-2001 Rebuild next definition Abstract 1. Introduction 4.2 Address designation Add to References [2] Mimura, et. al. Expires January 2005 [Page11] Internet Draft Internet FAX Gateway Functions July 2004 06a 19-Septembert-2001 Rebuild next definition 5. Security Considerations 6a 20-March-2002 Corrections and clarifications. Moved Intellectual Property and keywords after section 1. Fixed Security considerations. 07 25-March-2002 Separate 6.References into 6.1 Normative groups and 6.2 Informative groups. 08 28-March-2002 Changed sentences in 3.3 user authorization, 4.1 Onramp Functions, 4.2 Address designation and 5 Security Considerations Rebuild 6. References 09 14-July 2004 Corrections and clarifications. 10 18-July-2004 Rebuild next definition 3.3 User authorization 3.4 Return notice 4.2.1 Immediate address designation 4.2.2 Indirect address designation 4.3 Relay function 5. Security Considerations 11 20-July-2004 6. References split to Informative and Normative Mimura, et. al. Expires January 2005 [Page12