[要約] RFC 5383は、Lemonade準拠のモバイルメールの展開に関する考慮事項を提供するものであり、モバイルデバイスでのメールアクセスの最適化とセキュリティの向上を目的としています。
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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レモネードグループは、サーバーの動作を制限し、クライアントの使用法[プロファイル]を説明するプロファイルドキュメントとともに、IMAPおよびメッセージの送信の拡張セットを開発しました。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.)
歴史的に、メッセージユーザーエージェント（MUAS）はメッセージの提出にポート25を使用しており、[提出]はこれに対応しています。ただし、ISPと組織がアウトバウンドポート25を制限することがますます一般的になっています。さらに、ホテルやその他の公共施設は、目的地のホストに関係なく、ポート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に展開するのがより困難です。レモネードはいくつかの[提出]拡張機能をサポートする必要があるため、レモネードクライアントが使用することが非常に重要です。
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つは[ACAP]です。この場合、ポート674を利用できる必要があります。
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とメッセージの提出の両方が[TCP]を使用しています。したがって、クライアントシステムは、これらのサーバーへのTCP接続を確立および維持できる必要があります。メッセージ送信サーバーは、IMAPサーバーへの接続を開始できる必要があります。[TCP]のアプリケーション使用のサポートは、クライアントシステムとサーバーシステムの両方に必要です。
The requirements and advice in [HOST-REQUIREMENTS] SHOULD be followed.
[ホスト要求]の要件とアドバイスに従う必要があります。
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でそれを行う環境では、WebMailを展開することで電子メールを提供できることに注意してください。WebMailは、Web上の電子メールの一般的な用語であり、サーバーはクライアントにHTTPを話し、メールストアに電子メールプロトコル（多くの場合IMAP）を話します。その機能は、Webクライアント、Webメールサーバー、Webメールサーバーとクライアント（HTTPとHTMLなどのマークアップ言語）の間で使用されるプロトコル、およびWebmailサーバーとメールストアの間で使用されるプロトコルの機能によって必然的に制限されています。ただし、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.
このドキュメントでは、「アイドル」とは、[beave-tcp]の「確立された接続アイドルタイムアウト」のようにアイドル時間を指し、「持続時間」とは、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とメッセージの提出の両方のクライアントシステムとサーバーシステム間のTCP接続の期間は、arbitrarily意的に長くなる可能性があります。クライアントシステム、サーバー、およびすべての中間システムは、これらの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]を参照してください。）。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.
2時間は、ミドルボックスでかなり一般的な構成タイムアウトです。つまり、データが最後にどちらの方向に送信されてから2時間後にネットワークによってTCP接続が取り壊されるサイトがいくつかあります（たとえば、[beave-tcp]のreq-5）。したがって、レモネードのクライアントとサーバーは、より長い最大アイドル間隔を指定する特定の構成設定がない場合、TCP接続が2時間アイドル状態のままではないことを確認する必要があります。このルールにより、デフォルトでは、レモネードクライアントとサーバーが、アイドルTCP接続のために最大2時間で構成された環境で動作することが保証されます。ネットワークおよびサーバーのオペレーターは、IMAP接続が2時間を超えてアイドル状態を維持することを許可し、したがって、これを許可するためにレモネードクライアントとサーバー、およびネットワーク機器を構成することにより、休眠の利点を増やすことができます。
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 Keep-Alivesを有効にするかどうかを選択できますが、多くの場合、Keep-Aliveパケット間の時間、接続の前に送信されるパケット数など、TCP Keep-Alive操作の他の側面に影響を与えることができません。一部の環境では、これらはアプリケーション制御下にないオペレーティングシステムの調整パラメーターです。場合によっては、TCPの実装の違いまたはプラットフォームに固有の欠陥の結果である可能性があるTCP Keep-Aliveオプションのアプリケーション使用により、運用上の困難が報告されています。レモネードクライアントとサーバーシステムは、これが正しく機能し、そのようなパケットが2時間ごとに頻繁に送信されない環境で動作しない限り、TCPキープアライブソケットオプションを設定しないでください。アプリケーションレベルのKeep-Alives（IMAP NOOPなど）は、TCP Keep-Aliveオプションの代わりに使用できます。
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".
クライアント、サーバー、および中級システムは、[ホスト要請]のセクション4.2.3.9の「到達不可能な宛先 - コード0、1、5」テキストに準拠する必要があります。接続を中止しないでください」。
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.
休眠中のTCP接続のメンテナンスは、セクション4.1および4.2で説明されているように、クライアント、サーバー、および中間システムによってサポートされる必要があります。
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対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サーバーの間のパスには、1つ以上のファイアウォールが存在する可能性があります。適切な展開では、クライアントシステムからサーバー上のIMAPおよびメッセージ送信ポート、およびメッセージ送信サーバーからIMAPサーバーへのTCP接続を可能にする必要があります。これには、そのような使用を可能にするためにファイアウォールを構成する必要がある場合があります。
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接続の両方を許可する必要があります。ファイアウォールは、拡張交渉の片側を許可するなど、これらのプロトコルの拡張を部分的にブロックしてはなりません。そうすることで、2つの側が同期しなくなり、後の障害が発生します。詳細については、[ファイアウォール]を参照してください。
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].
新しいサービスの展開を希望するグループは、多くの場合、ファイアウォールポートを開くために必要な手順と内部政治をバイパスしようと誘惑されます。魅力的なKludgeは、ファイアウォール、通常はポート80のHTTPまたはポート25のSMTPのHTTPを通過することが許可されている既存のサービスで新しいサービスをトンネルすることです。
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.
このようなバイパスは、新しいサービスが展開しているように見えるため、すぐに成功するように見えることがあります。ただし、ネットワークセキュリティグループが有能であると仮定すると、Kludgeに気付くと、彼らの対応は一般に組織のセキュリティポリシーの違反をブロックすることです。[ファイアウォール]で説明されているように、ファイアウォールの透明性要件に違反することなく、このようなアクセス制御を提供できるアプリケーションレベルのプロキシ/ファイアウォールを設計することは困難です。これらの状況では、担保損傷が一般的です。新しいサービス（当初は成功裏に展開されたように見えました）と、新しいサービスをトンネルするために活用された既存のサービスは、arbitrary意的で予測不可能な障害の対象となります。これは、解決の試みを妨げる2つのグループ間の敵対的な関係を促進します。
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ボックスは、[beave-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およびメッセージの提出クライアントは、必要に応じてTCP接続を自動的に再開することに注意してくださいが、必要性を回避するために時間、パケット、処理を節約します。IMAPとメッセージの提出接続の再オープンは、一般に、認証、輸送層のセキュリティ（TLS）交渉、サーバー処理、およびWindowsなどのTCP動作のリセットのためのコストが発生します。また、特に休眠モードを倒す可能性があるため、NAT状態を維持するためだけにクライアントにNOOPコマンドを送信させることは無駄です。
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.
「Edge On the Edge」（つまり、オープンインターネットからアクセス可能）を展開する組織は、その環境で動作するように設計されたものを選択することをお勧めします。
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.
サーバーを1つ以上のDMZ（Perimeter Networksとも呼ばれる非武装ゾーン）内に配置すると、ネットワークの残りの部分を侵害されたサーバーから保護できます。リスクを軽減する追加の方法は、インターネットからアクセスできないシステムに認証資格情報を保存し、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.
クリス・ニューマンとフィル・カーンは非常に役立つテキストを提案しました。ブライアン・ロスとデイブ・クリッドランドはドラフトをレビューし、優れた提案を提供しました。
[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.
[beyave-tcp] Guha、S.、ed。、biswas、K.、Ford、B.、Sivakumar、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 -Requirements] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年11月。
[FIREWALLS] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[ファイアウォール] Freed、N。、「インターネットファイアウォールの行動と要件」、RFC 2979、2000年10月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[KLUDGE] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[Kludge] Moore、K。、「基質としてのHTTPの使用について」、BCP 56、RFC 3205、2002年2月。
[PROFILE] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.
[プロファイル] Maes、S。およびA. Melnikov、「多様なサービス環境（レモネード）プロファイルをサポートするインターネットメール」、RFC 4550、2006年6月。
[PROXIES] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, March 1996.
[プロキシ] Chatel、M。、「古典的と透明性のIPプロキシ」、RFC 1919、1996年3月。
[SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提出] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
Author's Address
著者の連絡先
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121
ランドールゲレンズクアルコムIncorporated 5775モアハウスドライブサンディエゴ、カリフォルニア92121
EMail: randy@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。