RFC1675 日本語訳
1675 Security Concerns for IPng. S. Bellovin. August 1994. (Format: TXT=8290 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Bellovin Request for Comments: 1675 AT&T Bell Laboratories Category: Informational August 1994
Bellovinがコメントのために要求するワーキンググループS.をネットワークでつないでください: 大西洋標準時1675とTベル研究所カテゴリ: 情報の1994年8月
Security Concerns for IPng
IPngのための安全上の配慮
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。
Overview and Rationale
概要と原理
A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective. While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse. Below, I outline a number of areas of concern. In some cases, there are features that would have a negative impact on security if nothing else is done. It may be desirable to adopt the features anyway, but in that case, the corrective action is mandatory.
IPngの多くの候補には、いくつかのセキュリティ見解からいくらか面倒な特徴があります。 IPngがIPv4の上の改良であることは必要ではありませんが、事態をより悪くしないのは、義務的です。 以下では、私が関心の多くの領域について概説します。 いくつかの場合、他に何もが完了していないならセキュリティでマイナスの影響がある特徴があります。 とにかく特徴を採用するのが望ましいかもしれませんが、その場合、修正措置は義務的です。
Firewalls
ファイアウォール
For better or worse, firewalls are very much a feature of today's Internet. They are not, primarily, a response to network protocol security problems per se. Rather, they are a means to compensate for failings in software engineering and system administration. As such, firewalls are not likely to go away any time soon; IPng will do nothing to make host programs any less buggy. Anything that makes firewalls harder to deploy will make IPng less acceptable in the market.
のるかそるか、ファイアウォールはたいへん今日のインターネットの特徴です。 それらは主としてそういうもののネットワーク・プロトコル警備上の問題への応答ではありません。 むしろ、それらはソフトウェア工学とシステム管理で欠点を補う手段です。 そういうものとして、ファイアウォールはすぐ、いつでも遠ざかりそうにはありません。 IPngはホストプログラムを少しもよりバギーでなくするようなことを何もしないでしょう。 ファイアウォールを配布するのをより困難にする何ででも、IPngは市場で、より許容できないようになるでしょう。
Firewalls impose a number of requirements. First, there must be a hierarchical address space. Many address-based filters use the structure of IPv4 addresses for access control decisions. Fortunately, this is a requirement for scalable routing as well.
ファイアウォールは多くの要件を課します。 まず最初に、階層的なアドレス空間があるに違いありません。 多くのアドレスベースのフィルタがアクセス制御決定にIPv4アドレスの構造を使用します。 幸い、これはまた、スケーラブルなルーティングのための要件です。
Bellovin [Page 1] RFC 1675 Security Concerns for IPng August 1994
セキュリティが1994年8月にIPngのために関するBellovin[1ページ]RFC1675
Routers, though, only need access to the destination address of the packet. Network-level firewalls often need to check both the source and destination address. A structure that makes it harder to find the source address is a distinct negative.
もっとも、ルータはパケットの送付先アドレスへのアクセスを必要とするだけです。 ネットワークレベルファイアウォールは、しばしばソースと送付先アドレスの両方をチェックする必要があります。 ソースアドレスを見つけるのをより困難にする構造は異なったネガです。
There is also a need for access to the transport-level (i.e., the TCP or UDP) header. This may be for the port number field, or for access to various flag bits, notably the ACK bit in the TCP header. This latter field is used to distinguish between incoming and outgoing calls.
また、輸送レベル(すなわち、TCPかUDP)ヘッダーへのアクセスの必要があります。 これはポートナンバー分野、または様々なフラグビット(著しくTCPヘッダーのACKビット)へのアクセスのためのものであるかもしれません。 この後者の分野は、送受信の呼び出しを見分けるのに使用されます。
In a different vein, at least one of the possible transition plans uses network-level packet translators [1]. Organizations that use firewalls will need to deploy their own translators to aid in converting their own internal networks. They cannot rely on centrally-located translators intended to serve the entire Internet community. It is thus vital that translators be simple, portable to many common platforms, and cheap -- we do not want to impose too high a financial barrier for converts to IPng.
異なった静脈では、少なくとも可能な変遷プランの1つはネットワークレベルパケット翻訳者[1]を使用します。 ファイアウォールを使用する組織は、それら自身の内部のネットワークを変換する際に支援するためにそれら自身の翻訳者を配布する必要があるでしょう。 彼らは全体のインターネットコミュニティに役立つことを意図する中心で位置している翻訳者に頼ることができません。 その結果、翻訳者が純真で、多くの一般的なプラットホームへの携帯用で、安いのは、重大です--転向者のために高過ぎる金融の垣根をIPngに課したいと思いません。
By the same token, it is desirable that such translation boxes not be usable for network-layer connection-laundering. It is difficult enough to trace back attacks today; we should not make it harder. (Some brands of terminal servers can be used for laundering. Most sites with such boxes have learned to configure them so that such activities are impossible.) Comprehensive logging is a possible alternative.
同様に、ネットワーク層接続洗浄には、そのような翻訳箱が使用可能でないことは、望ましいです。 今日、それはたどって戻すことができるくらい難しい攻撃です。 私たちはそれをより困難にするべきではありません。 (洗浄にターミナルサーバのいくつかのブランドを使用できます。 そのような箱があるほとんどのサイトが、それらを構成することを学んだので、そのような活動は不可能です。) 包括的な伐採は可能な代替手段です。
IPAE [1] does not have problems with its translation strategy, as address are (insofar as possible) preserved; it is necessary to avoid any alternative strategies, such as circuit-level translators, that might.
IPAE[1]には、アドレスが保存されるとき(可能である限り)、翻訳戦略に関する問題がありません。 代替のそうするかもしれない回路レベル翻訳者などのどんな戦略も避けるのが必要です。
Encryption and Authentication
暗号化と認証
A number of people are starting to experiment with IP-level encryption and cryptographic authentication. This trend will (and should) continue. IPng should not make this harder, either intrinsically or by imposing a substantial perforance barrier.
多くの人々がIP-レベル暗号化と暗号の認証を実験し始めています。 この傾向意志の(and should)は続きます。 IPngは、本質的かかなりのperforanceバリアを課すことによって、これをより困難にするはずがありません。
Encryption can be done with various different granularities: host to host, host to gateway, and gateway to gateway. All of these have their uses; IPng must not rule out any of them. Encapsulation and tunneling strategies are somewhat problematic, as the packet may no longer carry the original source address when it reaches an encrypting gateway. (This may be seen more as a constraint on network topologies. So be it, but we should warn people of the limitation.)
様々な異なった粒状で暗号化ができます: 接待するホスト、ゲートウェイへのホスト、およびゲートウェイへのゲートウェイ。 これらはすべて、役に立つことがあります。 IPngはそれらのいずれも除外してはいけません。 カプセル化とトンネリング戦略はいくらか問題が多いです、暗号化ゲートウェイに達する場合パケットがもう一次資料アドレスを運ばないとき。 (これはネットワークtopologiesでさらに規制と考えられるかもしれません。 それでよろしい、私たちは制限について人々に警告するべきです。)
Bellovin [Page 2] RFC 1675 Security Concerns for IPng August 1994
セキュリティが1994年8月にIPngのために関するBellovin[2ページ]RFC1675
Dual-stack approaches, such as in TUBA's transition plan [2], imply multiple addresses for each host. (IPAE has this feature, too.) The encryption and access control infrastructure needs to know about all addresses for a given host, belonging to whichever stack. It should not be possible to bypass authentication or encryption by asking for a different address for the same host.
TUBAの変遷プラン[2]などのデュアルスタックアプローチは各ホストのために複数のアドレスを含意します。 (IPAEには、この特徴もあります) どのスタックに属して、暗号化とアクセスは与えられたホストですべてのアドレスに関して知るインフラ需要を制御します。 同じホストのために異なったアドレスを求めることによって認証か暗号化を迂回させるのは可能であるべきではありません。
Source Routing and Address-based Authentication
ソースルート設定とアドレスベースの認証
The dominant form of host authentication in today's Internet is address-based. That is, hosts often decide to trust other hosts based on their IP addresses. (Actually, it's worse than that; much authentication is name-based, which opens up new avenues of attack. But if an attacker can spoof an IP address, there's no need to attack the name service.) To the extent that it does work, address-based authentication relies on the implied accuracy of the return route. That is, though it is easy to inject packets with a false source address, replies will generally follow the usual routing patterns, and be sent to the real host with that address. This frustrates most, though not all, attempts at impersonation.
今日のインターネットでの優位な形式のホスト認証はアドレスベースです。 すなわち、ホストは、しばしば彼らのIPアドレスに基づく他のホストを信じると決めます。 (実際に、それはそれより悪いです。 多くの認証が名前ベースです(攻撃の新しい大通りを開けます)。 しかし、攻撃者がIPアドレスを偽造することができるなら、サービスという名前を攻撃する必要は全くありません。) 働いているという範囲まで、アドレスベースの認証は戻り経路の暗示している精度を当てにします。 すなわち、誤ったソースアドレスをパケットに注射するのが簡単ですが、回答に一般に、普通のルーティングパターンに従って、そのアドレスをもっている本当のホストに送るでしょう。 ものまねへの試みではありませんが、これは最もだめにします。
Problems can arise if source-routing is used. A source route, which must be reversed for reply packets, overrides the usual routing mechanism, and hence destroys the security of address-based authentication. For this reason, many organizations disable source- routing, at least at their border routers.
ソースルーティングが使用されているなら、問題は起こることができます。 送信元経路(回答パケットのために逆にしなければならない)は、普通のルーティングメカニズムをくつがえして、したがって、アドレスベースの認証のセキュリティを破壊します。 この理由で、多くの組織が少なくともそれらの境界ルータでソースにルーティングを無効にします。
One candidate IPng -- SIPP -- includes source-routing as an important component. To the extent this is used, it is a breaks address-based authentication. This may not be bad; in fact, it is probably good. But it is vital that a more secure cryptographic authentication protocol be defined and deployed before any substantial cutover to source routing, if SIPP is adopted.
1候補IPng(SIPP)が、重要なコンポーネントとしてソースで掘るのを含んでいます。 これが使用されているという範囲に、aがアドレスベースの認証を壊すということです。 これは悪くないかもしれません。 事実上、それはたぶん良いです。 しかし、より安全な暗号の認証プロトコルがどんなかなりのカットオーバの前にもソースルーティングに定義されて、配布されるのは、重大です、SIPPが採用されるなら。
Accounting
会計
An significant part of the world wishes to do usage-sensitive accounting. This may be for billing, or it may simply be to accomodate quality-of-service requests. Either way, definitive knowledge of the relevant address fields is needed. To accomodate this, IPng should have a non-intrusive packet authentication mechanism. By "non-intrusive", I mean that it should (a) present little or no load to intermediate hops that do not need to do authentication; (b) be deletable (if desired) by the border gateways, and (c) be ignorable by end-systems or billing systems to which it is not relevant.
世界のかなりの地域は用法敏感な会計をしたがっています。 これは支払いのためのものであるかもしれませんかaccomodateサービスの質要求にはそれが単にあるかもしれません。 いずれにせよ、関連アドレス・フィールドに関する決定的な知識が必要です。 これをaccomodateするように、IPngには、非押しつけがましいパケット認証機構があるはずです。 それがそうするべきである「非押しつけがましい」I平均で、(a)はまず認証をする必要はない中間的ホップに負荷を提示しません。 (b) (c) 境界ゲートウェイのそばで削除可能であってください、そして、(望まれているなら)エンドシステムかそれが関連していない支払いシステムで無視可能であってください。
Bellovin [Page 3] RFC 1675 Security Concerns for IPng August 1994
セキュリティが1994年8月にIPngのために関するBellovin[3ページ]RFC1675
References
参照
[1] Gilligan, R., and E. Nordmark, "IPAE: The SIPP Interoperability and Transition Mechanism", Work in Progress, March 16, 1994.
[1] ギリガン、R.、およびE.Nordmark、「IPAE:」 「SIPP相互運用性と変遷メカニズム」は進歩、1994年3月16日に働いています。
[2] Piscitello, D., "Transition Plan for TUBA/CLNP", Work in Progress, March 4, 1994.
[2] D.、「チューバ/CLNPのための変遷プラン」というPiscitelloは進歩、1994年3月4日に働いています。
Security Consierations
セキュリティConsierations
This entire memo is about Security Considerations.
この全体のメモはSecurity Considerationsに関するものです。
Author's Address
作者のアドレス
Steven M. Bellovin Software Engineering Research Department AT&T Bell Laboratories 600 Mountain Avenue Murray Hill, NJ 07974, USA
マリー・ヒル、スティーブンM.Bellovinソフトウェア工学調査部AT&Tベル研究所600山のAvenueニュージャージー 07974、米国
Phone: +1 908-582-5886 Fax: +1 908-582-3063 EMail: smb@research.att.com
以下に電話をしてください。 +1 908-582-5886Fax: +1 908-582-3063 メールしてください: smb@research.att.com
Bellovin [Page 4]
Bellovin[4ページ]
一覧
スポンサーリンク