RFC5383 日本語訳
5383 Deployment Considerations for Lemonade-Compliant Mobile Email. R.Gellens. October 2008. (Format: TXT=28290 bytes) (Also BCP0143) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Gellens Request for Comments: 5383 Qualcomm BCP: 143 October 2008 Category: Best Current Practice
Gellensがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5383クアルコムBCP: 143 2008年10月のカテゴリ: 最も良い現在の習慣
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
1. 序論…2 2. このドキュメントで中古のコンベンション…2 3. ポート…2 4. TCPコネクションズ…3 4.1. 生涯…4 4.2. 一時的な輸送の損失の間のメインテナンス…5 5. 休眠…6 6. ファイアウォール…6 6.1. ファイアウォール縦断…7 7. NATs…8 8. セキュリティ問題…8 9. 承認…10 10. 標準の参照…10 11. 有益な参照…10
Gellens Best Current Practice [Page 1] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[1ページ]RFC5383レモネード展開問題2008年10月
1. Introduction
1. 序論
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レモネードグループは1セットの拡大をIMAPとMessage Submissionに発生しました、サーバの振舞いを制限して、クライアント用法[PROFILE]を説明するプロフィールドキュメントと共に。
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.
レモネード対応することのモバイルメールのうまくいっている展開は一般に、想定されて、したがってメールRFCsでしばしばカバーされているというわけではない様々な機能性を必要とします。 問題が多いと報告されたものの上に焦点がある状態で、このドキュメントはこれらの追加問題のいくつかについて説明します。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?
3. Ports
3. ポート
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.
利用可能であるに違いないウェルノウンポート[IANA]をIMAPとMessage Submissionの両方に割り当ててあります。 IMAPはポート143を使用します。 メッセージSubmission用途は587を移植します。 クライアントがこれらのポートへサーバに連絡できるのは、REQUIREDです。 したがって、クライアント、サーバシステム、およびどんな仲介者システムもこれらのポートに関するコミュニケーションを許容しなければなりません。
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.)
歴史的に、Message Userエージェント(MUAs)はMessage Submissionにポート25を使用しました、そして、[SUBMISSION]はこれを収容します。 しかしながら、ISPと組織が外国行きのポート25を制限するのはますます一般的になりました。 さらに、宿泊設備が時々途中で捕らえるホテルと他の公衆は25の接続を移植します、あて先ホストにかかわらず、不意に3番目の未知の、そして、信頼されていないパーティーサーバに潜在的に機密のコミュニケーションを提出するユーザをもたらして。 ユーザはそのような妨害を通常、意識していません。 (そのような妨害は、[FIREWALLS]に違反して、多くの否定的結果を持っています。)
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の上で配布するのが、より難しいです。 レモネードがいくつかの[SUBMISSION]拡大に支持を要するので、クライアントが使用するレモネード、およびサーバが聴くレモネードがデフォルトで587を移植するのは、非常に重要です。
Gellens Best Current Practice [Page 2] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[2ページ]RFC5383レモネード展開問題2008年10月
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.
クライアントとサーバシステムとのコミュニケーションに加えてレモネードが、Message SubmissionサーバがTCP接続をIMAPサーバに確立できるのを必要とする、(フォワード、-、ダウンロード、) これはデフォルトでポート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]の使用であるとサポートしないシステムが完全なインターネットクライアントでないことに注意してください。 その結果、そのようなシステムはインターネットへの必ずデータ保全問題をもたらすゲートウェイを使用します。
4. TCP Connections
4. 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 Submissionの両方が[TCP]を使用します。 したがって、クライアントシステムは、これらのサーバにTCP接続を確立して、維持できなければなりません。 Message SubmissionサーバはIMAPサーバに接続を開始できなければなりません。[TCP]のアプリケーション使用のサポートはクライアントとサーバシステムの両方のREQUIREDです。
The requirements and advice in [HOST-REQUIREMENTS] SHOULD be followed.
[HOST-REQUIREMENTS]SHOULDでの要件とアドバイス、続かれてください。
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のためにそうする環境のためにウエブメールを配布することによってメールを提供できることに注意してください。 ウエブメールは、ウェブの上のメールのための一般的な用語とメール店へのメールプロトコル(しばしばIMAP)です。そこでは、サーバがHTTPをクライアントに話します。 機能性は必ずウェブクライアントの能力によって制限されます、ウエブメールサーバ、ウエブメールサーバとクライアント(HTMLなどのHTTPとマークアップ言語)と、ウエブメールサーバとメール店の間で中古のプロトコル。 しかしながら、環境がHTTPがアプリケーションに利用可能なすべてなら、定義上制限されて、その結果、ユーザに提供された機能性は、また、限らなければならなくて、レモネード対応するはずがありません。
Gellens Best Current Practice [Page 3] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[3ページ]RFC5383レモネード展開問題2008年10月
4.1. Lifetime
4.1. 生涯
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.
本書では、「怠けてください」は遊休時間を参照します、[BEHAVE-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とMessage Submissionの両方のクライアントとサーバシステムとの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とMessage Submission)で実施される使用されていないタイマによります: 期間以内にデータを全く受け取らないなら、どちらの側もプロトコルによって受入れられるように接続を終えるかもしれません([SUBMISSION]か[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時間はmiddleboxesのかなり一般的な構成タイムアウトです。 すなわち、最後にどちらの方向にもデータを送った2時間後にネットワークがTCP接続を取りこわす多くのサイト(例えば、[BEHAVE-TCP]のREQ-5)があります。 したがって、レモネードクライアントとサーバSHOULDは、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
いくつかのネットワークがHTTP以外のTCP接続にそれら自身の持続時間時間制限を課すと報告されました。 そのような振舞いはメールと他のすべてのTCPベースのプロトコルに有害です。 そのようなものが、振舞いがどれくらい広範囲であるかを報告するか、それがHTTPトラフィックのために最適化することへの試み、ファイアウォール、NATs、または対向機器での実装制限、または慎重な選択の偶然の結果であるかどうかが不明瞭です。 どのような場合でも、TCP接続へのそのようなバリアはそのようなネットワークのIETFプロトコルの増加する用法への重要なリスクです。 それが設計されているとき、TCPが、より効率的になるように設計されることに注意してください。
Gellens Best Current Practice [Page 4] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[4ページ]RFC5383レモネード展開問題2008年10月
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.
時間がたつにつれてデータを移すのにおいて、使用されています。 その結果、そのような接続を禁止すると、クライアントに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接続を終えたことができるままで残っていることに注意してください。 これらのメカニズムは、遊休時間を考慮に入れることが許可されていて、これらの要件で影響を受けません。
4.2. Maintenance during Temporary Transport Loss
4.2. 一時的な輸送の損失の間のメインテナンス
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は、低レベルの接続性の一時的な損失に耐えるように設計されています。 そのような一時的な損失はモバイルシステム(例えばhandoffs、フェードなどのため)で珍しくはありません。 TCP接続SHOULD、クライアントのIPアドレスが(例えば、モバイル機器のトラフィックチャンネルの短期間の損失か高いパケット損失の一区切り)を変えないとき、一時的な低レベルの損失を乗り切ることができてください。 したがって、クライアントの上のTCP/IPスタック、サーバ、およびすべての中間システムSHOULDが接続性の一時的な損失の間、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実装差かプラットホームに特定の欠陥の結果であるかもしれません)。 2時間毎より頻繁にこれが正しく働いている環境とそのようなパケットで作動するのを送るなら、レモネードクライアントとサーバシステムSHOULD NOTは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".
クライアント、サーバ、および中間システムが従わなければならない、「目的地Unreachable--、コード0、1、セクション4.2.3における5インチのテキスト、.9[HOST-REQUIREMENTS]、」。(それは、「これらのUnreachableメッセージがソフト・エラー状態を示すので、TCP MUST NOTは接続を中止します。」と述べます)。
Gellens Best Current Practice [Page 5] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[5ページ]RFC5383レモネード展開問題2008年10月
5. Dormancy
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.
メインテナンス、休眠SHOULDの間の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接続と共に、これで、定期的にチャンネルを育てて、次に、回を外と、再三それまで空費するでしょう。 しかしながら、それと反対な特定の設定情報がないとき、デフォルトで正しい操作を確実にするためにこれをするのが必要です。
6. Firewalls
6. ファイアウォール
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つの協会を維持することです。
Gellens Best Current Practice [Page 6] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[6ページ]RFC5383レモネード展開問題2008年10月
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.
1個以上のファイアウォールがクライアントとサーバシステムと、Message SubmissionとIMAPサーバの間の経路に存在するかもしれません。 クライアントシステムからIMAPとMessage Submissionまで. これを移植するTCP接続がサーバと、Message SubmissionサーバからIMAPサーバまで可能である適切な展開REQUIRESは、そのような用法を可能にするためにファイアウォールを構成するのを必要とするかもしれません。
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.
ネットワーク経路で配布されたファイアウォールはプロトコルトラフィックを破損してはいけません。 特に、クライアントからのMessage SubmissionとIMAP接続の両方を受入れなければなりません。 ファイアウォールはこれらのプロトコルに拡大を部分的に妨げてはいけません、拡大交渉の半面を許容するのなどように、同時性から脱していながら2つの側でそう結果をするとして、後の失敗で。 より多くの議論に関して[FIREWALLS]を見てください。
Application proxies, which are not uncommon mechanisms, are discussed in [PROXIES].
[PROXIES]でアプリケーションプロキシ(珍しいメカニズムでない)について議論します。
6.1. Firewall Traversal
6.1. ファイアウォール縦断
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].
しばしば新しいサービスを配布したがっているグループがファイアウォールポートを開けるのに必要な手順と内部の政治を迂回させるように誘惑されます。 魅力的なクラッジは新しいサービスオーバーのファイアウォールを通り抜けることが既に許可されている、既存のサービス、通常ポート80の上のHTTPまたは時々ポート25の上のSMTPにトンネルを堀ることです。 [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
新しいサービスが展開するように思えるので、そのような迂回はすぐにうまくいくように見えることができます。 しかしながら、彼らの応答は一般に、クラッジを意識するようになるとネットワークセキュリティグループが十分であると仮定して、組織的な安全保障政策の違反を妨げることです。 ファイアウォールの透明要件に違反しないでそのようなアクセスコントロールを提供できるアプリケーションレベルプロキシ/ファイアウォールを設計するのは難しいです、[FIREWALLS]で説明されるように。 巻き添え被害はこういう事情ですから一般的です。 それがそれらの既存のサービスであったことと同様に新しいサービス(初めは、首尾よく配布されたように見えた)が新しいサービスにトンネルを堀るために利用されて、任意で予測できないのを受けることがあるようになってください。
Gellens Best Current Practice [Page 7] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[7ページ]RFC5383レモネード展開問題2008年10月
failures. This encourages an adversarial relationship between the two groups, which hinders attempts at resolution.
失敗。 これは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.
しばしば繰り返された公理はネットワークに接続されるどんなコンピュータも不安定であるということです。 セキュリティと有用性は組織が両方で許容できる測定を達成することに関する選択を領域にしている両方の問題です。 新種業務を配布するのは、適切な保護でサービスで使用されるポートへのアクセスを可能にすると決めるのを通常必要とします。 新しくサービスの含意を見直すのに必要な遅れはいらだたしいかもしれませんが、結局、それはクラッジほど高価でない傾向があります。
7. NATs
7. NATs
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箱も[BEHAVE-TCP]でREQ-5に従わなければなりません。(それが、「'確立した接続アイドルタイムアウト'の値は2時間4分より少ないはずがありません。」が必要です)。
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 Submissionクライアントが必要に応じて自動的にTCP接続を再開きますが、そうする必要性を避けるために時間、パケット、および処理を節約することに注意してください。 IMAPとMessage Submission接続を再開させると、一般に、コストは認証、Transport Layer Security(TLS)交渉、およびサーバ処理のために被られます、TCPの振舞いのリセットと同様に、窓などのように。 また、クライアントにまさしくNAT状態を維持するコマンドをNOOPに送らせるのも、無駄です、特にこれが休眠モードを破ることができるので。
8. Security Considerations
8. セキュリティ問題
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ポートの上で明らかにモバイルメール接続を可能にするためにファイアウォール構成変更を作るのを避ける試みでメールトラフィックを背負うと、この重要なステップが迂回して、システムの総合的なセキュリティは下げられるでしょう。
Gellens Best Current Practice [Page 8] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[8ページ]RFC5383レモネード展開問題2008年10月
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.
1DMZs(また、周辺ネットワークと呼ばれる非武装地帯)にサーバを置くと、感染しているサーバからネットワークの残りを保護できます。危険を減少させる追加方法はクライアントから受け取られて、認可された/を受けるのが応答を認可しなかったのでインターネットからアクセスしやすくなく、単に資格証明書を送ることによって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か多くの同期プロトコルのいずれも使用するかもしれないゲートウェイのようにする一投がセキュリティ局面を変えるとわかるのは重要です。 そのようなゲートウェイを加えることによって、システムの総合的なセキュリティ、およびメールサーバの脆弱性は、変わりがないか、またはかなり悪化させられるかもしれません。 特定の危険から守るのに分離と間接指定を使用できますが、有効に、なるように、そのようなステップは、脅威分析の、後と問題の理解がかかわっていてする必要があります。
Gellens Best Current Practice [Page 9] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[9ページ]RFC5383レモネード展開問題2008年10月
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".
組織SHOULDはすべての接続のためにTLSの使用をサポートして、TLSを必要とするように任意に構成できるサーバを配布します。 いつTLSは使用されているか、そして、それはSHOULDです。代替のポートメソッドよりむしろ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.
新しいサービスがセキュリティ問題を関連づけていないのは、まれです。 モバイル機器を使用することでメールを組織のメンバーにとって利用可能にすると、重要な利益を提供できます。
9. Acknowledgments
9. 承認
Chris Newman and Phil Karn suggested very helpful text. Brian Ross and Dave Cridland reviewed drafts and provided excellent suggestions.
クリス・ニューマンとフィルKarnは非常に役立っているテキストを勧めました。 ブライアン・ロスとデーヴCridlandは草稿を見直して、素晴らしい提案を提供しました。
10. Normative References
10. 引用規格
[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.
[TCPを反応させます]のグーハ、S.(エド)とビスワスとK.とフォードとB.とSivakumar、S.とP.Srisuresh、「TCPのためのNATの行動の要件」BCP142、RFC5382(2008年10月)。
[HOST-REQUIREMENTS] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[ホスト要件] ブレーデン、R.、エド、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、10月1989日
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[IANA] IANA Port Number Registry, <http://www.iana.org/assignments/port-numbers>
[IANA]IANAポートナンバー登録、<http://www.iana.org/課題/ポートナンバー>。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
11. Informative References
11. 有益な参照
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
Gellens Best Current Practice [Page 10] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[10ページ]RFC5383レモネード展開問題2008年10月
[FIREWALLS] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
解放された[ファイアウォール]、N.、「インターネットのための振舞いと要件ファイアウォール」、RFC2979、2000年10月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[KLUDGE] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[KLUDGE]ムーア、K. 「SubstrateとしてのHTTPの使用」のBCP56、RFC3205、2002年2月。
[PROFILE] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.
[輪郭を描きます] 2006年6月のメース、S.とA.メリニコフ、「環境(レモネード)が輪郭を描くさまざまのサービスを支持するインターネットメール」RFC4550。
[PROXIES] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, March 1996.
「透明なIPプロキシに対して古典的である」[プロキシ]シャテル、M.、RFC1919、1996年3月。
[SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[服従] GellensとR.とJ.Klensin、「メールのためのメッセージ提案」、RFC4409、2006年4月。
Author's Address
作者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121
ランドル・Gellensのクアルコムの法人組織の5775モアハウス・Driveサンディエゴ、カリフォルニア 92121
EMail: randy@qualcomm.com
メール: randy@qualcomm.com
Gellens Best Current Practice [Page 11] RFC 5383 Lemonade Deployment Considerations October 2008
最も良い現在のGellensの練習[11ページ]RFC5383レモネード展開問題2008年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Gellens Best Current Practice [Page 12]
Gellensの最も良い現在の習慣[12ページ]
一覧
スポンサーリンク