Guidelines for Optional Services for Internet Fax Gateways
draft-ietf-fax-gateway-options-08

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]