Network Working Group R. Gellens
Request for Comments: 5383 Qualcomm
BCP: 143 October 2008
Category: Best Current Practice
Deployment Considerations for Lemonade-Compliant Mobile Email
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Abstract
抽象
This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in the IETF lemonade documents.
この文書では、展開の問題について説明し、IETFレモネード文書で暗黙的で携帯メールを正常に展開するための要件について説明します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Ports ...........................................................2
4. TCP Connections .................................................3
4.1. Lifetime ...................................................4
4.2. Maintenance during Temporary Transport Loss ................5
5. Dormancy ........................................................6
6. Firewalls .......................................................6
6.1. Firewall Traversal .........................................7
7. NATs ............................................................8
8. Security Considerations .........................................8
9. Acknowledgments ................................................10
10. Normative References ..........................................10
11. Informative References ........................................10
The IETF lemonade group has developed a set of extensions to IMAP and Message Submission, along with a profile document that restricts server behavior and describes client usage [PROFILE].
IETFのレモネード・グループは、サーバーの動作を制限し、クライアントの使用状況[PROFILE]を記述するプロフィール文書と一緒に、IMAPとMessage提出の拡張セットを開発しました。
Successful deployment of lemonade-compliant mobile email requires various functionality that is generally assumed and hence not often covered in email RFCs. This document describes some of these additional considerations, with a focus on those that have been reported to be problematic.
レモネード準拠のモバイル電子メールの展開を成功さは、一般的に想定し、したがって、多くの場合、電子メールのRFCで覆われていない様々な機能を必要とします。この文書では、問題があると報告されているものに焦点を当て、これらの追加の考慮事項のいくつかを説明します。
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 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
Both IMAP and Message Submission have been assigned well-known ports [IANA] that MUST be available. IMAP uses port 143. Message Submission uses port 587. It is REQUIRED that the client be able to contact the server on these ports. Hence, the client and server systems, as well as any intermediary systems, MUST allow communication on these ports.
IMAPおよびメッセージの送信の両方が利用可能でなければならない周知のポート[IANA]に割り当てられています。 IMAPはポート143メッセージ送信は、ポート587を使用していますクライアントがこれらのポートでサーバにアクセスできることが必要である使用しています。したがって、クライアントとサーバシステム、ならびに任意の仲介システムは、これらのポート上で通信を許可する必要があります。
Historically, Message User Agents (MUAs) have used port 25 for Message Submission, and [SUBMISSION] does accommodate this. However, it has become increasingly common for ISPs and organizations to restrict outbound port 25. Additionally, hotels and other public accommodations sometimes intercept port 25 connections, regardless of the destination host, resulting in users unexpectedly submitting potentially sensitive communications to unknown and untrusted third-party servers. Typically, users are not aware of such interception. (Such interception violates [FIREWALLS] and has many negative consequences.)
歴史的に、メッセージのユーザエージェント（のMUA）は、これを収容ないメッセージ提出用ポート25、及び[提出]を使用しています。しかし、それが突然、未知と信頼できないサードに機密性の高い通信を提出し、ユーザーにその結果、さらにアウトバウンドポート25を制限するISPや組織のために関係なく、宛先ホストの時々ポート切片ホテルなどの公共宿泊施設25台の接続、ますます一般的になってきましたパーティのサーバ。一般的に、ユーザーは、傍受を認識していません。 （このような傍受は、[ファイアウォール]に違反し、多くの負の影響を持っています。）
Due to endemic security vulnerabilities in widely deployed SMTP servers, organizations often employ application-level firewalls that intercept SMTP and permit only a limited subset of the protocol. New extensions are therefore more difficult to deploy on port 25. Since lemonade requires support for several [SUBMISSION] extensions, it is extremely important that lemonade clients use, and lemonade servers listen on, port 587 by default.
広く展開されているSMTPサーバで流行セキュリティの脆弱性に、組織は多くの場合、SMTPを傍受し、プロトコルの限られたサブセットを許可するアプリケーションレベルのファイアウォールを採用しています。新しい拡張機能は、レモネードは、いくつかの[提出]の拡張機能のサポートを必要とするので、レモネードクライアントが使用することが非常に重要であり、レモネードサーバがリッスンポート25上で展開するため、デフォルトではポート587より困難です。
In addition to communications between the client and server systems, lemonade requires that the Message Submission server be able to establish a TCP connection to the IMAP server (for forward-without-download). This uses port 143 by default.
クライアントとサーバのシステム間の通信に加えて、レモネードは、メッセージ送信サーバは、（フォワードなし - ダウンロード用）IMAPサーバへのTCP接続を確立できる必要があります。これは、デフォルトではポート143を使用しています。
Messaging clients sometimes use protocols to store, retrieve, and update configuration and preference data. Functionality such as setting a new device to use the configuration and preference data of another device, or having a device inherit default configuration data from a user account, an organization, or other source, is likely to be even more useful with small mobile devices. Various protocols can be used for configuration and preference data; most of these protocols have designated ports. It is important that clients be able to contact such servers on the appropriate ports. As an example, one protocol that can be used for this purpose is [ACAP], in which case port 674 needs to be available.
メッセージングクライアントは、時々の構成や好みのデータを格納、取得、および更新するためのプロトコルを使用します。そのようなユーザアカウント、組織、または他のソースからデバイスの継承デフォルトのコンフィギュレーションデータを他の装置の構成及び嗜好データを使用する新しいデバイスを設定する、または有するような機能は、小型モバイルデバイスとさらに便利である可能性があります。様々なプロトコルは、構成及び嗜好データのために使用することができます。これらのプロトコルのほとんどは、ポートを指定しています。クライアントが適切なポート上で、このようなサーバーに接続できることが重要です。一例として、この目的のために使用できる1つのプロトコルは、その場合、ポート674は、利用可能である必要がある、[ACAP]です。
Note that systems that do not support application use of [TCP] on arbitrary ports are not full Internet clients. As a result, such systems use gateways to the Internet that necessarily result in data integrity problems.
任意のポート上で、[TCP]のアプリケーションの使用をサポートしていないシステムでは、完全なインターネットクライアントではないことに注意してください。その結果、このようなシステムは、必ずしもデータの整合性の問題が発生するインターネットへのゲートウェイを使用しています。
Both IMAP and Message Submission use [TCP]. Hence, the client system MUST be able to establish and maintain TCP connections to these servers. The Message Submission server MUST be able to initiate a connection to the IMAP server. Support for application use of [TCP] is REQUIRED of both client and server systems.
IMAPとMessage提出の両方が[TCP]を使用します。したがって、クライアント・システムは、これらのサーバーへのTCP接続を確立し、維持できなければなりません。メッセージ送信サーバはIMAPサーバへの接続を開始できる必要があります。 [TCP]のアプリケーションの使用のためのサポートは、クライアントとサーバの両方のシステムに要求されます。
The requirements and advice in [HOST-REQUIREMENTS] SHOULD be followed.
[HOST-要件]における要件やアドバイスに従う必要があります。
Note that, for environments that do not support application use of [TCP] but do so for HTTP, email can be offered by deploying webmail. Webmail is a common term for email over the web, where a server speaks HTTP to the client and an email protocol (often IMAP) to the mail store. Its functionality is necessarily limited by the capabilities of the web client, the webmail server, the protocols used between the webmail server and the client (HTTP and a markup language such as HTML), and between the webmail server and the mail store. However, if HTTP is all that is available to an application, the environment is by definition limited and thus, functionality offered to the user must also be limited, and can't be lemonade compliant.
[TCP]のアプリケーションの使用をサポートしていますが、HTTPのためにそうしない環境のために、電子メールはウェブメールを配備することによって提供することができ、ことに注意してください。 Webメールは、サーバーがクライアントとメールストアへの電子メールプロトコル（多くの場合、IMAP）にHTTPを話すウェブ、以上の電子メールのための一般的な用語です。その機能は必ずしもWebクライアント、Webメールサーバ、Webメールサーバとクライアント（HTTPやHTMLなどのマークアップ言語）の間、およびWebメールサーバとメールストアの間で使用されるプロトコルの能力によって制限されます。 HTTPはすべてのことをアプリケーションに提供されている場合は、環境が定義によって制限されているので、利用者に提供される機能も制限しなければならない、と互換レモネードすることはできません。
In this document, "idle" refers to the idle time, as in the "established connection idle-timeout" of [BEHAVE-TCP], while "duration" refers to the total time that a TCP connection has been established.
「期間」は、TCP接続が確立されていることを総時間を指す。この文書では、「アイドル」、[BEHAVE-TCP]の「確立された接続アイドルタイムアウト」のように、アイドル時間を指します。
The duration of the TCP connections between the client and server systems for both IMAP and Message Submission can be arbitrarily long. The client system, the server, as well as all intermediate systems MUST NOT terminate these TCP connections simply because of their duration (that is, just because of how long they have been open).
IMAPとMessage提出の両方のために、クライアントとサーバのシステム間のTCP接続の持続期間は、任意の長することができます。クライアントシステム、サーバー、およびすべての中間システムは、（それが理由だけで、彼らがオープンされているどのくらいの、ある）単にため、その期間のこれらのTCP接続を終了してはなりません。
Lemonade depends on idle timers being enforced only at the application level (IMAP and Message Submission): if no data is received within a period of time, either side MAY terminate the connection as permitted by the protocol (see [SUBMISSION] or [IMAP]). Since IMAP permits unsolicited notifications of state changes, it is reasonable for clients to remain connected for extended periods with no data being exchanged. Being forced to send data just to keep the connection alive can prevent or hinder optimizations such as dormancy mode (see Section 5).
（[提出]または[IMAP]を参照してもデータが一定期間内に受信されない場合、いずれかのプロトコルによって許されるよう側が接続を終了することができる：レモネードは、アプリケーションレベル（IMAPとMessage提出）で適用され、アイドルタイマーに依存します）。 IMAPは、状態変化の任意通知を可能にするので、クライアントがデータを交換しなかった状態で長期間接続を維持するのが合理的です。 （第5節を参照）、まさにこのような休眠モードなどの最適化を防止または妨げることができアライブ接続を維持するためにデータを送ることを余儀なくされています。
Two hours is a fairly common configuration timeout at middleboxes. That is, there are a number of sites at which TCP connections are torn down by the network two hours after data was last sent in either direction (for example, REQ-5 in [BEHAVE-TCP]). Thus, lemonade clients and servers SHOULD make sure that, in the absence of a specific configuration setting that specifies a longer maximum idle interval, the TCP connection does not remain idle for two hours. This rule ensures that, by default, lemonade clients and servers operate in environments configured with a two-hour maximum for idle TCP connections. Network and server operators can still permit IMAP connections to remain idle in excess of two hours and thus increase the benefits of dormancy, by configuring lemonade clients and servers, and network equipment, to allow this.
二時間は、ミドルボックスで、かなり一般的な構成のタイムアウトです。すなわち、TCP接続がいずれかの方向に送信されたデータが最後に更新された2時間後に、ネットワークによって解体されるサイトの数があり、ある（例えば、REQ-5 [BEHAVE-TCP]で）。このように、レモネードクライアントとサーバは、長い最大アイドル時間間隔を指定し、特定の構成設定が存在しない場合に、TCP接続が2時間アイドル状態のままではない、ということを確認する必要があります。この規則は、デフォルトでは、レモネードクライアントとサーバがアイドルTCP接続のための2つの時間の最大値で構成された環境で動作することを保証します。ネットワークおよびサーバー事業者はまだこれを許可するために、レモネードクライアントとサーバ、およびネットワーク機器を構成することで、2時間を超えてアイドル状態のままにIMAP接続を許可するため、休眠の利益を増やすことができます。
It has been reported that some networks impose duration time restrictions of their own on TCP connections other than HTTP. Such behavior is harmful to email and all other TCP-based protocols. It is unclear how widespread such reported behavior is, or if it is an accidental consequence of an attempt at optimizing for HTTP traffic, implementation limitations in firewalls, NATs, or other devices, or a deliberate choice. In any case, such a barrier to TCP connections is a significant risk to the increasing usage of IETF protocols on such networks. Note that TCP is designed to be more efficient when it is used to transfer data over time. Prohibiting such connections thus imposes hidden costs on an operator's network, forcing clients to use TCP in inefficient ways. One way in which carriers can inadvertently force TCP connections closed, resulting in users wasting packets by reopening them, is described in Section 7.
いくつかのネットワークがHTTP以外のTCPコネクション上で、独自の継続時間の制限を課すことが報告されています。このような挙動は、電子メールや他のすべてのTCPベースのプロトコルに有害です。広範な報告行動があるかは不明である、またはそれは、HTTPトラフィック、ファイアウォール、NATの、または他の機器への実装上の制限、または意図的な選択のために最適化する試みの偶然の結果である場合。いずれの場合も、TCP接続に、このような障壁は、このようなネットワーク上のIETFプロトコルの増加の使用に重大なリスクです。それは時間をかけてデータを転送するために使用されている場合、TCPは、より効率的になるように設計されていることに注意してください。このような接続を禁止するため、非効率的な方法でTCPを使用するようにクライアントを強制的に、オペレータのネットワーク上の隠れたコストを課します。キャリアが誤っTCP接続を強制することができる1つの方法は、それらを再開することによってパケットを無駄にユーザーをもたらす、閉じ、第7章に記載されています。
Note that systems remain able to terminate TCP connections at any time based on local decisions, for example, to prevent overload during a denial-of-service attack. These mechanisms are permitted to take idle time into consideration and are not affected by these requirements.
システムは、サービス拒否攻撃中に過負荷を防ぐために、例えば、ローカルの意思決定に基づいて、任意の時点でのTCP接続を終了することが残っていることに注意してください。これらのメカニズムを考慮にアイドル時間を取ることが許可されており、これらの要件の影響を受けません。
TCP is designed to withstand temporary loss of lower-level connectivity. Such transient loss is not uncommon in mobile systems (for example, due to handoffs, fade, etc.). The TCP connection SHOULD be able to survive temporary lower-level loss when the IP address of the client does not change (for example, short-duration loss of the mobile device's traffic channel or periods of high packet loss). Thus, the TCP/IP stack on the client, the server, and all intermediate systems SHOULD maintain the TCP connection during transient loss of connectivity.
TCPは、下位レベルの接続性の一時的な損失に耐えるように設計されています。そのような過渡損失は（等ハンドオフ、フェードに起因例えば、）モバイルシステムでは珍しいことではありません。 TCP接続は、クライアントのIPアドレスは、（例えば、モバイルデバイスのトラフィック・チャネルまたは高パケット損失の期間の短期間の損失）を変更しない場合に、一時的な低レベルの損失を生き残ることができるべきです。このように、クライアント上のTCP / IPスタック、サーバー、およびすべての中間システムは、接続の一時的損失の間にTCPコネクションを維持する必要があります。
In general, applications can choose whether or not to enable TCP keep-alives, but in many cases are unable to affect any other aspect of TCP keep-alive operation, such as time between keep-alive packets, number of packets sent before the connection is aborted, etc. In some environments, these are operating system tuning parameters not under application control. In some cases, operational difficulties have been reported with application use of the TCP keep-alive option, which might be the result of TCP implementation differences or defects specific to a platform. Lemonade client and server systems SHOULD NOT set the TCP keep-alive socket option unless operating in environments where this works correctly and such packets will not be sent more frequently than every two hours. Application-level keep-alives (such as IMAP NOOP) MAY be used instead of the TCP keep-alive option.
一般に、アプリケーションは、TCPキープアライブを有効にするかどうかを選択することができ、多くの場合、接続する前に送信されるパケットの数は、そのようなキープアライブパケット間の時間として、キープアライブ操作TCPの他の側面に影響を与えることができません一部の環境ではなど、中止され、これらはいないアプリケーションの制御下で、システムのチューニングパラメータを操作しています。いくつかのケースでは、運用の困難は、プラットフォームに固有のTCP実装の違いや欠陥の結果である可能性があるTCPキープアライブオプションのアプリケーションを使用して報告されています。これが正常に動作すると、このようなパケットが二時間おきよりも頻繁に送信されることはありませんな環境で動作していない限りレモネードクライアントとサーバーシステムは、TCPキープアライブソケットオプションを設定しないでください。 （例えばIMAP NOOPなど）アプリケーションレベルのキープアライブは、代わりにTCPキープアライブオプションを用いてもよいです。
Client, server, and intermediate systems MUST comply with the "Destination Unreachable -- codes 0, 1, 5" text in Section 4.2.3.9 of [HOST-REQUIREMENTS], which states "Since these Unreachable messages indicate soft error conditions, TCP MUST NOT abort the connection".
「 - 0、1、5コード宛先到達不能」これらUnreachableメッセージは、ソフトエラー状態を示しているので」と述べ[HOST-要件]のセクション4.2.3.9でテキスト、TCPのMUSTクライアント、サーバー、および中間システムを遵守しなければなりません接続「を中止しません。
Cellular data channels are connection-oriented (they are brought up or down to establish or tear down connections); it costs network resources to establish connections. Generally speaking, mobile device battery charges last longer when the traffic channel is used less.
携帯電話のデータチャネルは、接続指向（彼らが育っているか、ダウン接続を確立するか、取り壊すために）です。接続を確立するために、ネットワークリソースがかかります。トラフィックチャネルは、以下を使用した場合に一般的に言って、モバイルデバイスのバッテリの充電は長持ち。
Some mobile devices and networks support dormant mode, in which the traffic channel is brought down during idle periods, yet the PPP or equivalent level remains active, and the mobile retains its IP address.
一部のモバイルデバイスやネットワークは、トラフィックチャネルがアイドル期間中に倒され、まだPPPまたは同等のレベルがアクティブのままで、モバイルは、そのIPアドレスを保持している休止モードをサポートしています。
Maintenance of TCP connections during dormancy SHOULD be supported by the client, server, and any intermediate systems, as described in Sections 4.1 and 4.2.
セクション4.1および4.2に記載のように休眠中のTCP接続の維持は、クライアント、サーバ、および任意の中間システムによってサポートされるべきです。
Sending packets just to keep the session active causes unnecessary channel establishment and timeout; with a long-idle TCP connection, this would periodically bring up the channel and then let it idle until it times out, again and again. However, in the absence of specific configuration information to the contrary, it is necessary to do this to ensure correct operation by default.
ただアクティブが不要なチャネルの確立、タイムアウトが発生し、セッションを維持するためにパケットを送信します。長いアイドルTCP接続で、これは定期的にチャンネルを立ち上げ、その後、それがタイムアウトし、何度も何度もそれまでアイドル状態にしましょうだろう。しかし、逆に特定の設定情報が存在しない場合には、デフォルトでは、正しい動作を保証するために、これを行うことが必要です。
New services must necessarily have their traffic pass through firewalls in order to be usable by corporate employees or organization members connecting externally, such as when using mobile devices. Firewalls exist to block traffic, yet exceptions must be made for services to be used. There is a body of best practices based on long experience in this area. Numerous techniques exist to help organizations balance protecting themselves and providing services to their members, employees, and/or customers. (Describing, or even enumerating, such techniques and practices is beyond the scope of this document, but Section 8 does mention some.)
新サービスは、必ずしも彼らのトラフィックは、このようなモバイル機器を使用するときのように、外部接続の企業の従業員や組織のメンバーによって使用できるようにするために、ファイアウォールを通過している必要があります。ファイアウォールは、トラフィックをブロックするために存在し、まだ例外が使用されるサービスのために作られなければなりません。この分野での長年の経験に基づいたベスト・プラクティスのボディがあります。多くの技術は、自分自身を保護し、そのメンバー、従業員、および/または顧客にサービスを提供する組織のバランスを助けるために存在します。 （記述、あるいは列挙し、そのような技術や慣行は、このドキュメントの範囲を超えているが、第8節は、いくつかを言及しません。）
It is critical that protocol design and architecture permit such practices, and not constrain them. One key way in which the design of a new service can aid its secure deployment is to maintain the one-to-one association of services and port numbers.
これは、そのプロトコルの設計と建築許可証ような慣行重要であり、それらを拘束しません。新サービスの設計は、その安全な展開を支援することが可能な一つの重要な方法は、サービスとポート番号の1対1の関連を維持することです。
One or more firewalls might exist in the path between the client and server systems, as well as between the Message Submission and IMAP servers. Proper deployment REQUIRES that TCP connections be possible from the client system to the IMAP and Message Submission ports on the servers, as well as from the Message Submission server to the IMAP server. This may require configuring firewalls to permit such usage.
一つまたは複数のファイアウォールは、メッセージ提出し、IMAPサーバの間だけでなく、クライアントとサーバのシステム間のパス内に存在している場合があります。適切な展開は、TCP接続がサーバー上のIMAPおよびメッセージ送信ポートに、だけでなく、IMAPサーバーへのメッセージ送信サーバーからクライアントシステムから可能であることが必要です。これは、このような使用を許可するようにファイアウォールを設定する必要があります。
Firewalls deployed in the network path MUST NOT damage protocol traffic. In particular, both Message Submission and IMAP connections from the client MUST be permitted. Firewalls MUST NOT partially block extensions to these protocols, such as by allowing one side of an extension negotiation, as doing so results in the two sides being out of synch, with later failures. See [FIREWALLS] for more discussion.
ネットワークパスで展開ファイアウォールはプロトコルトラフィックを傷つけてはなりません。特に、メッセージ提出し、クライアントからのIMAP接続の両方が許可されなければなりません。ファイアウォールMUST NOTこのような後障害に、双方の結果は同期外であるようにすることとして、拡張ネゴシエーションの片側を可能にするなど、これらのプロトコルの部分ブロックの拡張、。より多くの議論のための[ファイアウォール]を参照してください。
Application proxies, which are not uncommon mechanisms, are discussed in [PROXIES].
稀機構ないアプリケーションプロキシは、[プロキシ]で議論されています。
An often-heard complaint from those attempting to deploy new services within an organization is that the group responsible for maintaining the firewall is unable or unwilling to open the required ports. The group that owns the firewall, being charged with organizational network security, is often reluctant to open firewall ports without an understanding of the benefits and the security implications of the new service.
組織内で新しいサービスを展開しようとしたものから、よく聞いた苦情は、ファイアウォールの維持を担当するグループが必要なポートを開くことができない、または不本意であるということです。組織のネットワークセキュリティで起訴されているファイアウォールを所有しているグループは、多くの場合、利点と新サービスのセキュリティへの影響を理解せずに、ファイアウォールのポートを開くには消極的です。
The group wishing to deploy a new service is often tempted to bypass the procedure and internal politics necessary to open the firewall ports. A tempting kludge is to tunnel the new service over an existing service that is already permitted to pass through the firewall, typically HTTP on port 80 or sometimes SMTP on port 25. Some of the downsides to this are discussed in [KLUDGE].
新しいサービスを展開したいグループは、多くの場合、ファイアウォールのポートを開くために必要な手順や内部の政治をバイパスするように誘惑されます。魅力的なその場しのぎこれに欠点のいくつかの25ポートのポート80または時々SMTP上のトンネルに既にファイアウォールを通過することが許可されている既存のサービス、典型的には、HTTP上の新しいサービスである[KLUDGE]に記載されています。
Such a bypass can appear to be immediately successful, since the new service seems to deploy. However, assuming the network security group is competent, when they become aware of the kludge, their response is generally to block the violation of organizational security policy. It is difficult to design an application-level proxy/firewall that can provide such access control without violating the transparency requirements of firewalls, as described in [FIREWALLS]. Collateral damage is common in these circumstances. The new service (which initially appeared to have been successfully deployed) as well as those existing services that were leveraged to tunnel the new service, become subject to arbitrary and unpredictable failures. This encourages an adversarial relationship between the two groups, which hinders attempts at resolution.
新しいサービスを展開すると思われるので、そのようなバイパスは、すぐに成功したように見えることができます。しかし、ネットワークのセキュリティグループと仮定すると、彼らはその場しのぎに気付いたとき、その応答は、組織のセキュリティポリシーの違反をブロックすることが一般的で、有能です。 [ファイアウォール]に記載されているように、ファイアウォールの透明性要件に違反することなく、このようなアクセス制御を提供することができるアプリケーションレベルのプロキシ/ファイアウォールを設計することは困難です。担保損傷はこのような状況では一般的です。 （最初は正常に配備されているように見えた）新しいサービス、ならびにトンネルに新しいサービスを活用し、それらの既存のサービスは、任意の及び予測不可能な障害の対象になります。これは解像度での試みを妨げる二つのグループの間で敵対関係を奨励します。
Even more serious is what happens if a vulnerability is discovered in the new service. Until the vulnerability is corrected, the network security group must disable both the new service and the (typically mission-critical) existing service on which it is layered.
さらに深刻な脆弱性が新たなサービスに発見された場合に何が起こるかです。脆弱性が修正されるまで、ネットワークのセキュリティグループは、新たなサービス、それが積層されている（一般的にミッションクリティカルな）既存のサービスの両方を無効にする必要があります。
An often-repeated truism is that any computer that is connected to a network is insecure. Security and usefulness are both considerations, with organizations making choices about achieving acceptable measures in both areas. Deploying new services typically requires deciding to permit access to the ports used by the service, with appropriate protections. While the delay necessary to review the implications of a new service may be frustrating, in the long run, it is likely to be less expensive than a kludge.
頻繁に繰り返される自明の理は、ネットワークに接続されているすべてのコンピュータが安全でないということです。セキュリティと有用性は、組織が両方の領域で許容できる対策を実現に関する選択を行うと、両方の考慮事項です。新しいサービスを展開すると、典型的には、適切な保護と、サービスが使用するポートへのアクセスを許可することを決定する必要があり。新サービスの影響を検討するために必要な遅延はイライラするかもしれないが、長い目で見れば、その場しのぎよりも安価である可能性が高いです。
Any NAT boxes that are deployed between client and server systems MUST comply with REQ-5 in [BEHAVE-TCP], which requires that "the value of the 'established connection idle-timeout' MUST NOT be less than 2 hours 4 minutes".
クライアントとサーバのシステムの間に配備されているすべてのNATボックスは、「『確立された接続のアイドルタイムアウト』の値が2時間未満で4分にすることはできません」ことを要求され、[BEHAVE-TCP]にREQ-5に準拠しなければなりません。
See Section 5 for additional information on connection lifetimes.
接続寿命に関する追加情報については、セクション5を参照してください。
Note that IMAP and Message Submission clients will automatically re-open TCP connections as needed, but it saves time, packets, and processing to avoid the need to do so. Re-opening IMAP and Message Submission connections generally incurs costs for authentication, Transport Layer Security (TLS) negotiation, and server processing, as well as resetting of TCP behavior, such as windows. It is also wasteful to force clients to send NOOP commands just to maintain NAT state, especially since this can defeat dormancy mode.
必要に応じてそのIMAPとMessage提出クライアントが自動的に再オープンTCP接続に注意してください、それは時間、パケット、及びそうする必要性を回避するための処理を節約できます。再オープンIMAPおよびメッセージ送信接続は、一般的に認証のためのコストを負担、Windowsなどのトランスポート層セキュリティ（TLS）ネゴシエーション、およびサーバ処理と同様に、TCPの挙動のリセット、。休眠モードを倒すことができ、特に以来、NOOPはちょうどNAT状態を維持するためにコマンドを送信するようにクライアントを強制的にも無駄です。
There are numerous security considerations whenever an organization chooses to make any of its services available via the Internet. This includes email from mobile clients.
組織がインターネット経由のサービスのいずれかが利用できるようにすることを選択したときに、多くのセキュリティ上の考慮事項があります。これは、モバイルクライアントからのメールが含まれています。
Sites concerned about email security should perform a threat analysis, get relevant protections in place, and then make a conscious decision to open up this service. As discussed in Section 6.1, piggybacking email traffic on the HTTP port in an attempt to avoid making a firewall configuration change to explicitly permit mobile email connections would bypass this important step and reduce the overall security of the system.
電子メールのセキュリティが心配サイトは、脅威分析を行う場所に関連した保護を取得し、このサービスを開くために意識的な決定を行う必要があります。 6.1節で述べたように、明示的に携帯メールの接続を許可するようにファイアウォールの設定変更をすることを避けるための試みでHTTPポート上で電子メールトラフィックをピギーバックすることは、この重要なステップをバイパスし、システム全体のセキュリティを低下させるであろう。
Organizations deploying a messaging server "on the edge" (that is, accessible from the open Internet) are encouraged to choose one that has been designed to operate in that environment.
（つまり、オープンなインターネットからアクセス可能である）「エッジ上の」メッセージングサーバーを展開する組織は、その環境で動作するように設計されたものを選択することをお勧めします。
This document does not attempt to catalogue either the various risks an organization might face or the numerous techniques that can be used to protect against the risks. However, to help illustrate the deployment considerations, a very small sample of some of the risks and countermeasures appear below.
このドキュメントは、組織が直面するかもしれない様々なリスクやリスクから保護するために使用することができ、多くの技術のいずれかをカタログしようとしません。しかし、展開の考慮事項を説明するのを助けるために、リスクと対策のいくつかの非常に小さなサンプルを以下に示します。
Some organizations are concerned that permitting direct access to their mail servers via the Internet increases their vulnerability, since a successful exploit against a mail server can potentially expose all mail and authentication credentials stored on that server, and can serve as an injection point for spam. In addition, there are concerns over eavesdropping or modification of mail data and authentication credentials.
一部の組織では、成功したが、潜在的にそのサーバーに保存されているすべてのメールと認証資格情報を公開することができ、メールサーバーに対して不正利用、およびスパムのための注入点としての役割を果たすことができるので、インターネットを経由して、メールサーバーへの直接アクセスを許可すると、その脆弱性を増大させることを懸念しています。また、メールデータや認証資格情報の盗聴や修正が懸念されています。
A large number of approaches exist that can mitigate the risks while allowing access to mail services via mobile clients.
アプローチは多数のモバイルクライアントを経由してメールサービスへのアクセスを可能にしながら、それがリスクを軽減することができますが存在します。
Placing servers inside one or more DMZs (demilitarized zones, also called perimeter networks) can protect the rest of the network from a compromised server. An additional way to reduce the risk is to store authentication credentials on a system that is not accessible from the Internet and that the servers within the DMZ can access only by sending the credentials as received from the client and receiving an authorized/not authorized response. Such isolation reduces the ability of a compromised server to serve as a base for attacking other network hosts.
一の以上のDMZ（も境界ネットワークと呼ばれる非武装地帯）内のサーバーを配置すると、妥協のサーバからネットワークの残りの部分を保護することができます。リスクを軽減するための追加の方法は、インターネットからアクセスすることはできませんし、DMZ内のサーバは、クライアントから受信した認証情報を送信し、許可/許可しませ応答を受信することによってのみアクセスできるようにシステムへの認証資格情報を格納することです。そのような分離は、他のネットワークホストを攻撃するためのベースとして機能する妥協サーバーの能力を低下させます。
Many additional techniques for further isolation exist, such as having the DMZ IMAP server have no mail store of its own. When a client connects to such a server, the DMZ IMAP server might contact the authentication server and receive a ticket, which it passes to the mail store in order to access the client's mail. In this way, a compromised IMAP server cannot be used to access the mail or credentials for other users.
さらに単離するための多くの追加の技術がそれ自身のメール・ストアを持たないようなDMZ IMAPサーバを有するものとして、存在します。クライアントは、サーバに接続すると、DMZ IMAPサーバーが認証サーバーに接続し、クライアントのメールにアクセスするために、メールストアに渡すチケットを、受け取ることがあります。このように、侵害IMAPサーバは、他のユーザーのメールや資格情報にアクセスするために使用することはできません。
It is important to realize that simply throwing an extra box in front of the mail servers, such as a gateway that may use HTTP or any of a number of synchronization protocols to communicate with clients, does not itself change the security aspects. By adding such a gateway, the overall security of the system, and the vulnerability of the mail servers, may remain unchanged or may be significantly worsened. Isolation and indirection can be used to protect against specific risks, but to be effective, such steps need to be done after a threat analysis, and with an understanding of the issues involved.
単に、そのようなクライアントとの通信にHTTPまたは同期プロトコルの数のいずれかを使用することができるゲートウェイとして、メールサーバーの前に余分なボックスを投げ、それ自体がセキュリティの側面を変更しないことを理解することが重要です。そのようなゲートウェイを追加することで、システム全体のセキュリティ、およびメールサーバの脆弱性は、変わらないままであってもよく、または大幅に悪化することができます。単離と間接が特定のリスクから保護するために使用することができますが、有効であるために、このようなステップは脅威分析の後に行われる必要があり、関連する問題の理解と。
Organizations SHOULD deploy servers that support the use of TLS for all connections and that can be optionally configured to require TLS. When TLS is used, it SHOULD be via the STARTTLS extensions rather than the alternate port method. TLS can be an effective measure to protect against specific threats, including eavesdropping and alteration, of the traffic between the endpoints. However, just because TLS is deployed does not mean the system is "secure".
組織は、すべての接続のためのTLSの使用をサポートするサーバーを展開する必要があり、それは、必要に応じてTLSを必要とするように設定することができます。 TLSを使用する場合、それはSTARTTLS拡張機能ではなく、代替ポート方法を介してであるべきです。 TLSは、エンドポイント間のトラフィックの盗聴や改ざん、などの具体的な脅威から保護するために有効な対策することができます。しかし、ちょうどTLSが展開されているため、システムが「安全」であることを意味しません。
Attempts at bypassing current firewall policy when deploying new services have serious risks, as discussed in Section 6.1.
6.1節で述べたように、新たなサービスを展開する際に、現在のファイアウォールポリシーをバイパスする試みは、深刻なリスクを持っています。
It's rare for a new service to not have associated security considerations. Making email available to an organization's members using mobile devices can offer significant benefits.
新サービスは、関連するセキュリティの考慮事項を持っていないことはまれです。モバイルデバイスを使用して、組織のメンバーに利用できる電子メールを作ることは大きなメリットを提供することができます。
Chris Newman and Phil Karn suggested very helpful text. Brian Ross and Dave Cridland reviewed drafts and provided excellent suggestions.
クリス・ニューマンとフィル・カーンは非常に役立つテキストを示唆しました。ブライアン・ロスとDave Cridlandはドラフトをレビューし、優れた提案を提供しました。
[BEHAVE-TCP] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[BEHAVE-TCP]グハ、S.編、ビスワス、K.、フォード、B.、シバクマー、S.、およびP. Srisuresh、 "TCPのためのNAT行動要件"、BCP 142、RFC 5382、2008年10月。
[HOST-REQUIREMENTS] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[HOST-要件]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IANA] IANA Port Number Registry, <http://www.iana.org/assignments/port-numbers>
[IANA] IANAポート番号レジストリ、<http://www.iana.org/assignments/port-numbers>
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[FIREWALLS] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[ファイアウォール]フリード、N.、 "の行動とインターネットファイアウォールの要件"、RFC 2979、2000年10月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[KLUDGE] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[KLUDGE]ムーア、K.、BCP 56、RFC 3205、2002年2月 "基板としてのHTTPの使用について"。
[PROFILE] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.
、RFC 4550、2006年6月 "多様なサービス環境（レモネード）プロファイルをサポートするインターネット電子メール" [PROFILE]マース、S.およびA.メルニコフ、。
[PROXIES] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, March 1996.
[プロキシ]シャテル、M.、RFC 1919、1996年3月 "透明IPプロキシ対クラシック"。
[SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提出] Gellens、R.とJ. Klensin、 "メールのメッセージの提出"、RFC 4409、2006年4月。
Author's Address
著者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121
ランドールGellens QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121
EMail: randy@qualcomm.com
メールアドレス：randy@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。