RFC1455 日本語訳

1455 Physical Link Security Type of Service. D. Eastlake 3rd. May 1993. (Format: TXT=12391 bytes) (Obsoleted by RFC2474) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                   D. Eastlake, III
Request for Comments: 1455                 Digital Equipment Corporation
                                                                May 1993

ワーキンググループのD.イーストレーク、コメントを求めるIII要求をネットワークでつないでください: 1455 DEC1993年5月

                 Physical Link Security Type of Service

物理的なリンクセキュリティタイプのサービス

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  Discussion and suggestions for improvement are requested.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This RFC documents an experimental protocol providing a Type of
   Service (TOS) to request maximum physical link security.  This is an
   addition to the types of service enumerated in RFC 1349: Type of
   Service in the Internet Protocol Suite.  The new TOS requests the
   network to provide what protection it can against surreptitious
   observation by outside agents of traffic so labeled.  The purpose is
   protection against traffic analysis and as an additional possible
   level of data confidentiality.  This TOS is consistent with all other
   defined types of service for IP version 4 in that it is based on link
   level characteristics and will not provide any particular guaranteed
   level of service.

このRFCは最大の物理的なリンクセキュリティを要求するためにService(TOS)のTypeを提供する実験プロトコルを記録します。 これはRFC1349で列挙されたサービスのタイプへの追加です: インターネットのサービスのタイプはスイートについて議定書の中で述べます。 新しいTOSは、それがそのようにラベルされたトラフィックの外部のエージェントによる秘密の観測に対してそうすることができるすべての保護を提供するようネットワークに要求します。 目的はトラヒック分析と追加可能なレベルのデータの機密性とした保護です。 リンク・レベルの特性に基づいていて、どんな特定の保証されたレベルのサービスも提供しないので、このTOSはIPバージョン4のための他のすべての定義されたタイプのサービスと一致しています。

1. Nature of Requirement

1. 要件の本質

   This Internet Protocol addition addresses two potential security
   requirements: resistance to traffic analysis and confidentiality.
   These are described in the two subsections below followed by a
   discussion of why links have different levels of physical security so
   that it is meaningful to request that more secure links be used.

このインターネットプロトコル追加は2つの潜在的セキュリティ要件を扱います: トラヒック分析と秘密性への抵抗。 これらは以下のリンクには異なったレベルの物理的なセキュリティがあるので、より安全なリンクが使用されるよう要求するのが重要である理由に関する議論があとに続いた2つの小区分で説明されます。

1.1 Traffic Analysis

1.1 トラヒック分析

   At this time all Internet Protocol (IP) packets must have most of
   their header information, including the "from" and "to" addresses, in
   the clear.  This is required for routers to properly handle the
   traffic even if a higher level protocol fully encrypts all bytes in
   the packet after the IP header.  This renders even end-to-end
   encrypted IP packets subject to traffic analysis if the data stream
   can be observed.  While traffic statistics are normally less
   sensitive than the data content of packets, in some cases activities
   of hosts or users are deducible from traffic information.

このとき、インターネットプロトコル(IP)パケットにはすべて、それらのヘッダー情報の大部分がなければなりません、“from"と“to"アドレスを含んでいて、明確で。 より高い平らなプロトコルがIPヘッダーの後にパケットですべてのバイトを完全に暗号化しても、ルータが適切にトラフィックを扱うのにこれが必要です。 データ・ストリームを観測できるなら、これはトラヒック分析を条件として終わりから終わりへのIP暗号化されたパケットさえレンダリングします。 トラフィック統計は通常パケットのデータほど機密でない内容ですが、いくつかの場合、ホストかユーザの活動は道路交通情報から推定可能です。

Eastlake                                                        [Page 1]

RFC 1455                   Link Security TOS                    May 1993

イーストレーク[1ページ]RFC1455はセキュリティTOS1993年5月にリンクします。

   It is essential that routers have access to header information, so it
   is hard to protect traffic statistics from an adversary with inside
   access to the network.  However, use of more secure physical links
   will make traffic observation by entities outside of the network more
   difficult thus improving protection from traffic analysis.

ネットワークへの内面のアクセスで敵からトラフィック統計を保護しにくくて、ルータがヘッダー情報に近づく手段を持っているのは、不可欠です。 しかしながら、より安全な物理的なリンクの使用で、ネットワークにおける外の実体によるトラフィック観測は、その結果、トラヒック分析から保護を改良しながら、より難しくなるでしょう。

   No doubt users would like to be able to request a guaranteed level of
   link security, just as they would like to be able to request a
   guaranteed bandwidth or delay through the network.  However, such
   guarantees require a resource reservation and/or policy routing
   scheme and are beyond the scope of the current IP Type of Service
   facility.

間違いなく、ユーザは保証されたレベルのリンクセキュリティを要求したがっています、ちょうど彼らがネットワークを通して保証された帯域幅か遅れを要求したがっているように。 しかしながら、そのような保証は、資源予約、そして/または、方針ルーティング体系を必要として、Service施設の現在のIP Typeの範囲を超えています。

   Although the TOS field is provided in all current Internet packets
   and routing based on TOS is provided in routing protocols such as
   OSPF [See 5,6,7], there is no realistic chance that all of the
   Internet will implement this additional TOS any time in the
   foreseeable future.  Nevertheless, users concerned about traffic
   analysis need to be able to request that the physical security of the
   links over which their packets will be pass be maximized in
   preference to other link characteristics.  The proposed TOS provides
   this capability.

すべての現在のインターネットパケットにTOS野原を提供します、そして、TOSに基づくルーティングをOSPFなどのルーティング・プロトコルに提供しますが[5、6、7を見てください]、インターネットのすべてが、この追加TOSが何時であることでもすぐに実装するというどんな現実的な見込みもありません。 それにもかかわらず、トラヒック分析に関して心配しているユーザは、それらのパケットがパスになるリンクの物理的なセキュリティが他のリンクの特性に優先して最大にされるよう要求できる必要があります。 提案されたTOSはこの能力を提供します。

1.2 Confidentiality

1.2 秘密性

   Use of physical links with greater physical security provides a layer
   of protection for the confidentiality of the data in the packets as
   well as traffic analysis protection.  If the content of the packets
   are otherwise protected by end-to-end encryption, using secure links
   makes it harder for an external adversary to obtain the encrypted
   data to attack.  If the content of the packets is unencrypted plain
   text, secure links may provide the only protection of data
   confidentiality.

よりすばらしい物理的なセキュリティとの物理的なリンクの使用はトラヒック分析保護と同様にパケットのデータの秘密性のための保護の層を提供します。 パケットの内容が別の方法で終端間暗号化で保護されるなら、安全なリンクを使用するのに、外部の敵が攻撃するために暗号化されたデータを得るのが、より困難になります。 パケットの内容が非暗号化されたプレーンテキストであるなら、安全なリンクはデータの機密性の唯一の保護を提供するかもしれません。

   There are cases where end-to-end encryption can not be used.
   Examples include paths which incorporate links within nations which
   restrict encryption, such as France or Australia, and paths which
   incorporate an amateur radio link, where encryption is prohibited.
   In these cases, link security is generally the only type of
   confidentiality available.  The proposed TOS will provide a way of
   requesting the best that the network can do for the security of such
   unencrypted data.

ケースが終端間暗号化を使用できないところにあります。 例は暗号化を制限する国の中にリンクを組み込む経路を含んでいます、アマチュア無線リンクを組み込むフランスやオーストラリアや、経路などのように。そこでは、暗号化が禁止されています。 これらの場合では、一般に、リンクセキュリティは唯一のタイプの利用可能な秘密性です。 提案されたTOSはネットワークがそのようなもののセキュリティのために尽くすことができるベストがデータを非暗号化したよう要求する方法を提供するでしょう。

   This TOS is required for improved confidentiality, especially in
   cases where encryption can not be used, despite the fact that it does
   not provide the guarantees that many users would like.  See
   discussion at the end of the Traffic Analysis section above.

このTOSが改良された秘密性に必要です、特に暗号化を使用できない場合で、多くのユーザが欲しい保証を提供しないという事実にもかかわらず。 Traffic Analysis部の端での議論が上であることを見てください。

Eastlake                                                        [Page 2]

RFC 1455                   Link Security TOS                    May 1993

イーストレーク[2ページ]RFC1455はセキュリティTOS1993年5月にリンクします。

1.3 Link Physical Security Characteristics

1.3 リンクの物理的なセキュリティの特性

   Physical links, which are composed of lines and routers, differ
   widely in their susceptibility to surreptitious observation of the
   information flowing over them.  For examples of line security see the
   following list:

物理的なリンク(系列とルータで構成される)は彼らの敏感さにおいてそれらの上を流れる情報の秘密の観測にはなはだしく異なります。 回線のセキュリティーの例に関しては、以下のリストを見てください:

      1) Land line media is usually harder to intercept than radio
         broadcast media.

1) 通常、陸線メディアはラジオがメディアを放送したより妨害しにくいです。

      2) Between different radio broadcast media, spread spectrum or
         other low probability of intercept systems, are harder to
         intercept than normal broadcast systems.  At the other extreme,
         systems with a large footprint on the earth, such as some
         satellite down links, may be particularly accessible.

2) 他の低捕捉性システムは. 他の極端、大きい足跡が地球にあるいくつかの衛星などのシステムが倒す通常の放送システムAtより困難なインタセプトにリンクされるということです、そして、異なったラジオ電波媒体の間に、スペクトルを広げてください、または特にアクセスしやすいかもしれません。

      3) Between land lines, point to point systems are generally harder
         to intercept than multi-point systems such as Ethernet or FDDI.

3) 一般に、陸線の間では、ポイント・ツー・ポイントシステムはイーサネットかFDDIなどのマルチポイントシステムより妨害しにくいです。

      4) Fiber optic land lines are generally harder to intercept than
         metallic paths because fiber is harder to tap.

4) 一般に、光ファイバー陸線は、ファイバーはより叩きにくいので、金属経路よりインタセプトに困難です。

      5) A secure land line, such as one in pressurized conduit with
         pressure alarms or one installed so as to be observable by
         guards, is harder to intercept than an unsecured land line.

5) 圧力アラームがある気密の経路における1か番人が観察可能になるようにインストールされたものなどの安全な陸線は非機密保護している陸線より妨害しにくいです。

      6) An encrypted link would be preferable to an unencrypted link
         because, even if it was accessed, it would be much more
         difficult to obtain any useful information.

6) それがアクセスされたとしても、どんな役に立つ情報も得るのがはるかに難しいので、暗号化されたリンクは非暗号化されたリンクより望ましいでしょう。

   Routers also have different levels of security against interception
   depending on the physical security of the router site and the like.

また、ルータはルータサイトの物理的なセキュリティによる妨害と同様のものに異なったレベルのセキュリティを抱きます。

   The above comparisons show that there are significant real
   differences between the security of the physical links in use in the
   Internet.  Choosing links where it is hard for an outside observer to
   observe the traffic improves confidentiality and protection against
   traffic analysis.

上の比較は、インターネットで使用中の物理的なリンクのセキュリティの間には、重要な本当の違いがあるのを示します。 傍観者がトラフィックを観測しにくいリンクを選ぶと、トラヒック分析に対する秘密性と保護は改良されます。

2. Protocol Specification

2. プロトコル仕様

   The value 15 decimal (F hex) in the four-bit Type of Service IP
   header field requests routing the packet to minimize the chance of
   surreptitious observation of its contents by agents external to the
   network.  (This value is chosen to be at the maximum hamming distance
   from the existing other TOS values.)

ネットワークへの外部のエージェントによるコンテンツの機会を最小にしてくださいService IPヘッダーフィールドのTypeがパケットを発送するのに要求する4ビットの秘密の観測における値15の小数(F十六進法)。 (他の既存のTOS値から距離をおおげさに演じて、この値は最大にはあるように選ばれています。)

Eastlake                                                        [Page 3]

RFC 1455                   Link Security TOS                    May 1993

イーストレーク[3ページ]RFC1455はセキュリティTOS1993年5月にリンクします。

3. Protocol Implementation

3. プロトコル実装

   This TOS can be implemented in routing systems that offer TOS based
   routing (as can be done with OSPF, see RFCs 1245 through 1247) by
   assigning costs to links.  Establishing the "cost" for different
   links for this TOS is a local policy function.

コストをリンクに割り当てることによってベースのルーティング(OSPFと共にすることができるように、RFCs1245を1247で見る)をTOSに提供するルーティングシステムでこのTOSを実装することができます。 このTOSのために「費用」を異なったリンクに設立するのは、地方の方針機能です。

   In principle services are incomparable when criterion such as those
   given in the Nature of Requirement section above conflict.  For
   example, a choice between an encrypted broadcast system and an
   unencrypted fiber optic land line.  In practice, link encryption
   would probably dominate all other forms of protection and physical
   security as mentioned in criterion 5 above would dominate other land
   line distinctions.

Requirement部のネイチャーで闘争の上に与えられたものなどの評価基準であるときに、原則として、サービスは比較にならないほどであっています。 例えば、暗号化された放送システムと非暗号化された光ファイバー陸線の選択。 実際には、評価基準5で他の陸線区別が上で支配されると言及するので、リンク暗号化はたぶん他のすべてのフォームの保護と物理的なセキュリティを支配しているでしょう。

   An example of "costs" at a hypothetical router could be as follows:

仮定しているルータにおける「コスト」の例は以下の通りであるかもしれません:

           Cost    Type
            1      Strong encryption with secure key distribution
            2      Physically secure point-to-point line
            6      Typical point-to-point line
            8      Typical local multi-point media
           12      Metropolitan area multi-point media
           24      Local radio broadcast
           32      Satellite link

二地点間系列6のTypicalの二地点間系列8のTypicalのローカルのマルチポイントメディア12首都圏地区マルチポイントメディア24Local無線放送32Satelliteリンク安全な主要な分配2Physicallyが安全のType1Strong暗号化にかかってください。

   Link costs should be chosen so as to be in the same ratio as the
   probability of interception.  Thus the above example costs imply a
   local policy assumption that interception is 32 times more likely on
   a satellite link and associated router than on a strongly encrypted
   line and its associated router.  It is not necessary to estimate the
   absolute probability of interception on any particular link.  It is
   sufficient to estimate the ratio between interception probabilities
   on different links.

リンクコストは、妨害の確率と同じ比率であるように選ばれるべきです。 したがって、上の例のコストは妨害が衛星中継でありそうで強く暗号化された系列とその関連ルータより何倍も関連している32ルータであるというローカルの方針仮定を含意します。 どんな特定のリンクの上にも妨害の絶対確率を見積もるのは必要ではありません。 異なったリンクの上に妨害確率の間の比率を見積もっているのは十分です。

   It should be noted that using costs such as the example given above
   could result in using many more links than if the default type of
   service were requested.  For example, the use of over 50 highly
   secure links could be better than using two insecure links, such as
   an unencrypted satellite hop and radio link.  However, if the costs
   have been properly set in proportion to the probability of
   interception, this larger number of links will be more secure than
   the shorter default routing.  This consideration should make it clear
   why it is necessary to estimate router security as well as link
   security.  An excessive cost ratio based solely on the security of a
   communications line could cause packets to go through many routers
   which were less secure than the lines in question.  This necessity to
   take router characteristics into account is also present for all

上に出された例などのコストを使用すると使用ずっと多くのリンクがサービスのタイプがデフォルトであるなら要求されたよりもたらされるかもしれないことに注意されるべきです。 例えば、50個以上の非常に安全なリンクの使用は2個の不安定なリンクを使用するより良いかもしれません、非暗号化された衛星ホップやラジオリンクのように。 しかしながら、コストが適切に妨害の確率に比例して設定されたなら、より多くのリンクが、より短いデフォルトルーティングよりさらに安全になるでしょう。 この考慮は、ルータセキュリティを見積もって、セキュリティをリンクするのがなぜ必要であるかを断言するべきです。 唯一コミュニケーション系列のセキュリティに基づく過度の費用比率で、パケットは問題の系列ほど安全でなかった多くのルータに直面するかもしれません。 また、ルータの特性を考慮に入れるこの必要性もすべてのために存在しています。

Eastlake                                                        [Page 4]

RFC 1455                   Link Security TOS                    May 1993

イーストレーク[4ページ]RFC1455はセキュリティTOS1993年5月にリンクします。

   other defined TOS values.

他の定義されたTOS値。

   It should also be noted that routing algorithms typically compute the
   sum of the costs of the links.  For this particular type of service,
   the product of the link probabilities of secure transmission would be
   more appropriate.  However, the same problem is present for the high
   reliability TOS and the use of a sum is an adequate approximation for
   most uses as noted in RFC 1349.

また、ルーティング・アルゴリズムがリンクのコストの合計を通常計算することに注意されるべきです。 この特定のタイプのサービスにおいて、安全なトランスミッションのリンク確率の製品は、より適切でしょう。 しかしながら、同じ問題は高信頼性TOSのために存在しています、そして、合計の使用はRFC1349に述べられるようにほとんどの用途のための適切な近似です。

References

参照

   [1] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
       Specification", STD 5, RFC 791, DARPA, September 1981.

[1] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、DARPA、1981年9月。

   [2] Braden, R., Editor, "Requirements for Internet Hosts --
       Communication Layers", STD 3, RFC 1122, IETF, October 1989.

[2] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、IETF、10月1989日

   [3] Braden, R., Editor, "Requirements for Internet Hosts --
       Application and Support", STD 3, RFC 1123, IETF, October 1989.

[3] ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、IETF、10月1989日

   [4] Almquist, P., "Type of Service in the Internet Protocol Suite",
       RFC 1349, Consultant, July 1992.

[4]Almquist、P.、「インターネットプロトコル群のサービスのタイプ」、RFC1349、コンサルタント、1992年7月。

   [5] Moy, J., Editor, "OSPF Protocol Analysis", RFC 1245, Proteon,
       Inc., July 1991.

[5]Moy、J.、エディタ、「OSPFプロトコル分析」、RFC1245、Proteon Inc.、1991年7月。

   [6] Moy, J., Editor, "Experience with the OSPF Protocol", RFC 1246,
       Proteon, Inc., July 1991.

Moy(J.、エディタ)が「OSPFプロトコルで経験する」[6]、RFC1246、Proteon Inc.、1991年7月。

   [7] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.

[7]Moy、J.、「OSPF、バージョン2インチ、RFC1247、Proteon Inc.、1991インチ年7月。

Eastlake                                                        [Page 5]

RFC 1455                   Link Security TOS                    May 1993

イーストレーク[5ページ]RFC1455はセキュリティTOS1993年5月にリンクします。

Security Considerations

セキュリティ問題

   The entirety of this memo concerns an Internet Protocol Type of
   Service to request maximum physical link security against
   surreptitious interception.

このメモの全体が、ServiceのインターネットプロトコルTypeが秘密の妨害に対して最大の物理的なリンクセキュリティを要求するのが関係があります。

Author's Address

作者のアドレス

   Donald E. Eastlake, III
   Digital Equipment Corporation*
   30 Porter Road, MS: LJO2/I4
   Littleton, MA 01460

ドナルド・E.イーストレーク、III DEC*30ポーター道路、MS: LJO2/I4リトルトン、MA 01460

   Phone: +1 508 486 2358 (w),  +1 617 244 2679 (h)
   Email: dee@ranger.enet.dec.com

以下に電話をしてください。 +1 +1 508 486 2358(w)、617 244 2679(h)メール: dee@ranger.enet.dec.com

   *Company affiliation given for identification only.  This document
   does not constitute a statement, official or otherwise, by Digital
   Equipment Corporation.

*識別だけのために与えられている会社提携。 このドキュメントはDECで公式の、または、そうでない声明を構成しません。

Eastlake                                                        [Page 6]

イーストレーク[6ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

SSDの現在のTBWを調べる方法 SSDの残り寿命 (Windows Linux CentOS)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る