Network Working Group K.Mimura Internet-Draft: draft-ietf-fax-gateway-options-08.txt K.Yokoyama T.Satoh K.Watanabe C.Kanaide TOYO Communication Equipment January 21 2005 Guideline of optional services for Internet FAX Gateway Status Of This Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail based Internet Fax service (i-fax) an "Internet FAX Gateway" is required. This document provides guidelines for the optional functionality of Internet FAX Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; viceversa an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN. This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular it covers techniques to drop duplicated fax messages, automatic fax re-transmission, error, return notice and log handling and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways. 1. Introduction An Internet FAX Gateway can be classified as either an offramp gateway or an onramp gateway. This document provides guidelines for optional services and examples of an Internet FAX Gateway operations. In particular it covers techniques to drop duplicated fax messages, automatic fax re-transmission, error, return notice and log handling and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways. A more detailed definition of onramps and offramps is provided in [1]. Information on recommended behaviors for Internet FAX Gateway functions are defined in [2]. This document provides recommendations only for the specific case hereunder: 1) the operational mode of the Internet Fax is "store and forward", as defined in Section 2.5 of [1]. 2) The format of image data is the data format defined by "simple mode" in [3]. This document does not apply to the gateway functions for "real-time Internet Fax", as described and defined in [5]. 1.1 Key words The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [4]. 2. Optional Services for an Offramp Gateway 2.1 Drop duplicated GSTN fax transmission Electronic mail transport agents (MTA) deliver an Internet fax message either into the recipient's or an offramp gateway mailbox; hence the message is retrieved for further action, which in the case of the offramp gateway, will result in its delivery to the GSTN fax service. The offramp gateway mailbox will thus receive all messages which the gateway shall process, regardless of their final distinct GSTN destination. As such, addresses like Fax=+12224567654@example.com Fax=+38155234578@example.com Fax=+3904567437777@example.com will all end up into the offramp gateway mailbox corresponding to the "example.com" domain. The handling of e-mail messages (including Internet fax ones) containing more than one recipient, but directed to the same final MTA can however be different, depending on the MTA configuration or features: a single message with multiple recipients in the SMTP envelope [6] is likely to be the most common case on the mail transport system, but it may happen that multiple copies of the same message are transmitted, one per each recipient. Or it may happen that the final MTA is set to deliver a separate copy of the message per each recipient into the final mailbox, supposing it is delivering messages to real separate end user's mailboxes. It may thus happen that the offramp gateway receives multiple copies of the same Internet fax message, to be delivered to different GSTN destinations, all listed together, and repeatedly, into the e-mail message headers [7] of the Internet fax. In such cases, the offramp gateway SHOULD implement techniques to avoid duplicate or even multiple transmission over GSTN of the same fax message to the same recipient. Here are some possible, but non-exclusive examples of these techniques. 2.1.1 SMTP envelope addresses check Using the SMTP [6] envelope destination address given as "RCPT TO" field is usually the best technique to ensure that a received message must be delivered to that address, and to avoid duplicate deliveries. If the offramp gateway has the "RCPT TO" information still available during processing, then it MUST use it to determine the recipients over GSTN fax service. 2.1.2 Message-ID check If the SMTP "RCPT TO" information is not available, for example in the case the offramp gateway retrieves messages from its mailbox using either POP [8] or IMAP [9] protocols, the message header "Message-ID" (see [7]) MAY be used to check if a message has already been processed, and hence avoid retransmission to all its GSTN recipients handled by the offramp gateway. 2.2 Error handling 2.2.1 Recoverable errors Recoverable errors happening during GSTN transmission are those where there is good chance that the error may not occur at the next attempt. This category includes "busy signal", "no line/carrier signal", etc. For all these errors, the offramp gateway SHOULD re-queue the message and perform a retransmission attempt later on, as specified in section 2.3 2.2.2 Non-recoverable errors If the error occurring during GSTN transmission is likely to be a non recoverable one, such as for example remote device paper related errors (jam, empty tray, ...), no response from remote destination, voice response, data modem response, or a stop event error, the offramp gateway SHOULD NOT attempt retransmission, and an error Message Delivery Notification (MDN) with appropriate error codes MUST be generated for the Internet fax message sender. 2.3 Automatic re-transmission handling An offramp gateway SHOULD implement a function that automatically tries to send facsimile data again if recoverable delivery failure occurs. If this function is implemented, then: - the retry times and retry interval MAY be specified as options by the administrator of the offramp gateway; - any error return notice SHOULD be sent only when the number of retries has been completed without success; - if transmission is suspended due to an error, then the subsequent transmission attempt SHOULD avoid retransmitting the pages already delivered successfully, if any. 2.4 Multiple return notice handling An offramp gateway can receive an Internet fax for delivery to multiple GSTN recipients. If errors occur, thus requiring to inform the Internet fax sender about them, or if the Internet fax sender himself requested delivery notifications, then the offramp gateway has various possibilities to handle these multiple return notices: 1) an offramp gateway sends a return notice as soon as an error or a successful delivery occurs, per single GSTN recipient; 2) an offramp gateway gathers all information about the message, but sends a return notice only after all or a number of GSTN recipients have been handled (successfully or not); If case 2 is implemented, then the offramp gateway MAY choose also to send separate successful and failure notices, or to limit the number of GSTN recipients handled per single return note, for example no more than 10 recipients per return note. 2.5 Handling transmission errors for a return notice When an offramp gateway fails in the transmission of a return notice, the Internet FAX Gateway SHOULD process the notice in either of the following ways: 1) the return notices SHOULD be re-queued, and delivery retried later. The number of retry attempts and the time interval among then MAY be a feature configured by the offramp gateway administrator. This is preferred method to implement; however, if all the retransmission attempts fails, processing SHOULD continue as in case 2; 2) if the gateway does not have enough capabilities to handle notice re-queuing, but has a log information preservation function, the error information SHOULD be recorded to a log, and processing SHOULD end. At this time, the administrator of the gateway system SHOULD be notified of these errors using a specific method (for example by sending him an e-mail message). 3) If the gateway does not even have a log information preservation function, the administrator SHOULD be notified about the failure, for example via an e-mail message, and processing SHOULD end. 2.6 Offramp gateway log An offramp gateway SHOULD have a function which keeps information listed as a log, either specific to the fax gateway, or inside some other log file existing locally on the gateway itself or remotely. If the fax gateway or the remote system are equipped with a recording media the log information SHOULD be saved as a log file. As a last resort, if no recording media are available, the log MAY be printed. The information listed in the log MAY be the following: - Date and time when the Internet fax is received - Sender address - Recipient address(es) - Start date and time of transmission over GSTN - End date and time of transmission over GSTN - Number of actually transmitted pages - Number of actually transmitted bytes - Fax resolution used - Error codes/text occurred during transmission - Number of transmission attempts (retries) - Date and time of transmission of the (eventual) delivery notice 3. Optional Services for an Onramp Gateway 3.1 Examples of user authorization An onramp gateway MAY have a user authorization function to confirm that the user is authorized to transmit facsimile into the Internet fax service. For example, user authorization may be accomplished by getting a user-ID and password received by DTMF, or via a local authorization table based on the GSTN caller-ID. The following sub-sections give some possible examples, but other methods are also possible. 3.1.1 Authorization via GSTN caller-ID The most simple method to authenticate and authorize a GSTN fax service user is by using the GSTN caller-ID. If available, in fact, the caller-ID is generated by the GSTN network service itself, and it is quite difficult to produce fake ones. In other words, the security related to this authentication method rely on the confidence that the GSTN caller-ID service is secure by itself. The GSTN sender MAY be authorized via a lookup into a table managed by the onramp gateway administrator, both via complete or partial (wildcard) matches. 3.1.2 Authorization via GSTN fax "station ID" During the initial GSTN fax service negotiation, the sender fax can send to the onramp gateway various information, including the "station ID" alphanumeric string. This string MAY thus be used to transmit authentication and authorization information for subsequent lookup by the onramp gateway. Thus user-id and an eventual password MAY be sent inside this string. If used as the only authentication, this method is however much less secure than the caller-ID one, as the user of the calling GSTN station can decide which string to send, and the string itself travels in clear form over the GSTN. Given this security warning, this method however allows more flexibility to the GSTN user: in fact it is not tied to a single GSTN fax terminal, and authorization can be obtained from anywhere, provided the sender has the possibility to configure the "station ID" on the device being used. A combination of caller-ID and station ID check MAY, on the other hand, result in a greatly improved level of security. 3.1.3 Authorization via DTMF An onramp gateway MAY implement the Authorization function by requesting that a user ID and password information are sent over GSTN via DTMF. For example, this function MAY be accomplished requesting this DTMF information is send just after the connection over GSTN is established, before starting the GSTN fax negotiation, but other methods are also possible. 3.2 Onramp gateway log An onramp gateway SHOULD have a function which keeps information listed as a log, either specific to the fax gateway, or inside some other log file existing locally on the gateway itself or remotely. If the fax gateway or the remote system are equipped with a recording media the log information SHOULD be saved as a log file. As a last resort, if no recording media are available, the log MAY be printed. The information listed in the log MAY be the following: - Start date and time of transmission from GSTN - End date and time of transmission from GSTN - Number of actually received pages - Number of actually received bytes - Fax resolution used - Sender address (if available) - Recipient address(es) - Date and time when the Internet fax is sent - Error codes/text occurred during Internet fax transmission - Number of transmission attempts (retries) - Date and time of transmission of the (eventual) delivery notice 4. Security Considerations Refer to Section 3.1 (User authorization) for authentication for an onramp gateway. In particular, sending the user IDs and password in clear, as described in section 3.1.2 can pose high security risks, and thus is NOT RECOMMENDED. S/MIME [10][19][20][21][22] ]and OpenPGP [11] [18] can also be used to encrypt an Internet fax message. A signed or encrypted message is protected while transported along the network; however when a message reach an Internet fax gateway, either onramp or offramp, this kind of protection cannot be applied anymore. Security must rely here on trusted operations of the gateway itself. A gateway might have its own certificate/key to improve security operations when sending Internet faxes, but as any gateway it breaks the end to end security pattern of both S/MIME and OpenPGP. Other security mechanisms, like IPsec [12][13][14][15][16] or TLS [17] also do not ensure a secure gateway operation. 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. 5. References 5.1 Informative group [1] L. Masinter, "Terminology and Goals for Internet Fax", RFC 2542, March 1999. [10] R. Housley, "Cryptographic Message Syntax", RFC3852, July 2004. [11] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, , "OpenPGP Message Format", RFC2440, November 1998. [12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [13] Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402, November 1998. [14] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC3168, September 2001. [15] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [16] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC2411, November 1998. [17] Dierks, T. and C. Allen, "Transport Layer Security (TLS) Extensions", RFC3456, June 2003. [18] Elkins et. al., "MIME Security with OpenPGP", RFC 3156, August 2001. [19] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC2631, June 1999. [20] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling ", RFC3850, June 1999. [21] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification ", RFC3851, June 1999. [22] P. Hoffman, "Enhanced Security Services for S/MIME", RFC2634, June 1999. 5.2 Normative group [2] K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, "Internet FAX Gateway Requirements", draft-ietf-fax-gateway-protocol, January 2005. [3] K. Toyoda, H. Ohno, J. Murai, and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3965, December 2004. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [5] "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, June 1998. [6] Postel, J. "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [7] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [8] Myers, J., Rose, M. "Post Office Protocol - Version 3", RFC1939, May 1996 [9] Crispin, M. "Internet Message Access Protocol - Version 4rev1", RFC3501, March 2003. 6. 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. 7. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 8. Acknowledgments Thanks to Claudio Allocchio (Consortium GARR, Italy) for its final review of this document, and for contributing the authorization and security sections of this document. 9. Author's Address Katsuhiko Mimura TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., 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-pref., 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-pref., Japan Fax: +81 467 74 5743 Email: zsatou@toyocom.co.jp Ken Watanabe TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan Fax: +81 467 74 5743 Email: knabe@toyocom.co.jp Chie Kanaide TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan Fax: +81 467 74 5743 Email: kanaide@toyocom.co.jp Claudio Allocchio Consortium GARR Viale Palmiro Togliatti 1625 00155 Roma, Italy Fax: +39 040 3758565 Email: Claudio.Allocchio@garr.it Revision history (to be deleted before publication) 00a 31-Oct-2000 Initial draft. 01a 21-Feb-2001 Rebuild next definition 2.6 keep log 3.2 keep log Added next definition 2.5 When a transmitting error occurred in return notice 02a 22-May-2001 Rebuild next definition 2.6 keep log 3.2 keep log 4. Security Considerations 03a 28-June-2001 Rebuild next definition 3.1 Example of User authorization 04a 19-September-2001 Rebuild next definition 4. Security Considerations 4a 20-March-2002 Corrections and clarifications. Dropped reference to RFC2119. Moved Intellectual Property after section 1. Fixed Security considerations. 4b 25-March-2002 Reword first paragraph of section 2.1 Arrange 5. References again. 06 25-July 2004 Corrections and clarifications. 07 20-July-2004 5. References split to Informative and Normative 08 21-Jan-2005 Full review/rewrite to clean up language and address IESG "Discuss". Mimura, et. al. Expires January 2005 [Page9]