RFC2401 日本語訳
2401 Security Architecture for the Internet Protocol. S. Kent, R.Atkinson. November 1998. (Format: TXT=168162 bytes) (Obsoletes RFC1825) (Obsoleted by RFC4301) (Updated by RFC3168) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Kent
Request for Comments: 2401 BBN Corp
Obsoletes: 1825 R. Atkinson
Category: Standards Track @Home Network
November 1998
コメントを求めるワーキンググループS.ケント要求をネットワークでつないでください: 2401BBN Corpは以下を時代遅れにします。 1825年のR.アトキンソンカテゴリ: 1998年標準化過程@Home Network11月
Security Architecture for the Internet Protocol
インターネットプロトコルのためのセキュリティー体系
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Table of Contents
目次
1. Introduction........................................................3
1.1 Summary of Contents of Document..................................3
1.2 Audience.........................................................3
1.3 Related Documents................................................4
2. Design Objectives...................................................4
2.1 Goals/Objectives/Requirements/Problem Description................4
2.2 Caveats and Assumptions..........................................5
3. System Overview.....................................................5
3.1 What IPsec Does..................................................6
3.2 How IPsec Works..................................................6
3.3 Where IPsec May Be Implemented...................................7
4. Security Associations...............................................8
4.1 Definition and Scope.............................................8
4.2 Security Association Functionality..............................10
4.3 Combining Security Associations.................................11
4.4 Security Association Databases..................................13
4.4.1 The Security Policy Database (SPD).........................14
4.4.2 Selectors..................................................17
4.4.3 Security Association Database (SAD)........................21
4.5 Basic Combinations of Security Associations.....................24
4.6 SA and Key Management...........................................26
4.6.1 Manual Techniques..........................................27
4.6.2 Automated SA and Key Management............................27
4.6.3 Locating a Security Gateway................................28
4.7 Security Associations and Multicast.............................29
1. 序論…3 ドキュメントのコンテンツの1.1概要…3 1.2聴衆…3 1.3 ドキュメントについて話します…4 2. 目的を設計してください…4 2.1Goals/Objectives/Requirements/問題記述…4 2.2の警告と仮定…5 3. システム概要…5 3.1 どんなIPsecはそうするか…6 3.2 どのようにIPsecは働いているか…6 3.3 IPsecが実装されるかもしれないところ…7 4. セキュリティ協会…8 4.1の定義と範囲…8 4.2 セキュリティ協会の機能性…10 4.3 セキュリティ協会を合併します…11 4.4 セキュリティ協会データベース…13 4.4 .1 安全保障政策データベース(SPD)…14 4.4 .2個のセレクタ…17 4.4 .3セキュリティ協会データベース(悲しい)…21 4.5 セキュリティ協会の基本的な組み合わせ…24 4.6 SAと主要な管理…26 4.6 .1 手動のテクニック…27 4.6 .2 自動化されたSAとKey Management…27 4.6 .3 セキュリティゲートウェイの場所を見つけます…28 4.7のセキュリティ協会とマルチキャスト…29
Kent & Atkinson Standards Track [Page 1] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[1ページ]。
5. IP Traffic Processing..............................................30
5.1 Outbound IP Traffic Processing..................................30
5.1.1 Selecting and Using an SA or SA Bundle.....................30
5.1.2 Header Construction for Tunnel Mode........................31
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode...........31
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode...........32
5.2 Processing Inbound IP Traffic...................................33
5.2.1 Selecting and Using an SA or SA Bundle.....................33
5.2.2 Handling of AH and ESP tunnels.............................34
6. ICMP Processing (relevant to IPsec)................................35
6.1 PMTU/DF Processing..............................................36
6.1.1 DF Bit.....................................................36
6.1.2 Path MTU Discovery (PMTU)..................................36
6.1.2.1 Propagation of PMTU...................................36
6.1.2.2 Calculation of PMTU...................................37
6.1.2.3 Granularity of PMTU Processing........................37
6.1.2.4 PMTU Aging............................................38
7. Auditing...........................................................39
8. Use in Systems Supporting Information Flow Security................39
8.1 Relationship Between Security Associations and Data Sensitivity.40
8.2 Sensitivity Consistency Checking................................40
8.3 Additional MLS Attributes for Security Association Databases....41
8.4 Additional Inbound Processing Steps for MLS Networking..........41
8.5 Additional Outbound Processing Steps for MLS Networking.........41
8.6 Additional MLS Processing for Security Gateways.................42
9. Performance Issues.................................................42
10. Conformance Requirements..........................................43
11. Security Considerations...........................................43
12. Differences from RFC 1825.........................................43
Acknowledgements......................................................44
Appendix A -- Glossary................................................45
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.....48
B.1 DF bit..........................................................48
B.2 Fragmentation...................................................48
B.3 Path MTU Discovery..............................................52
B.3.1 Identifying the Originating Host(s)........................53
B.3.2 Calculation of PMTU........................................55
B.3.3 Granularity of Maintaining PMTU Data.......................56
B.3.4 Per Socket Maintenance of PMTU Data........................57
B.3.5 Delivery of PMTU Data to the Transport Layer...............57
B.3.6 Aging of PMTU Data.........................................57
Appendix C -- Sequence Space Window Code Example......................58
Appendix D -- Categorization of ICMP messages.........................60
References............................................................63
Disclaimer............................................................64
Author Information....................................................65
Full Copyright Statement..............................................66
5. IPトラフィック処理…30 5.1 外国行きのIPトラフィック処理…30 5.1 .1 SAかSAを選択して、使用するのは荷物をまとめます…30 5.1 .2 トンネル・モードのためのヘッダー工事…31 5.1 .2 .1 IPv4--トンネル・モードのためのヘッダー工事…31 5.1 .2 .2 IPv6--トンネル・モードのためのヘッダー工事…32 5.2 処理の本国行きのIPトラフィック…33 5.2 .1 SAかSAを選択して、使用するのは荷物をまとめます…33 5.2 .2 AHと超能力の取り扱いはトンネルを堀ります…34 6. ICMP処理(IPsecに関連している)…35 6.1 PMTU/DF処理…36 6.1 .1 DFは噛み付きました…36 6.1 .2 経路MTU発見(PMTU)…36 6.1 .2 .1 PMTUの伝播…36 6.1 .2 .2 PMTUの計算…37 6.1 .2 PMTU処理の.3粒状…37 6.1 .2 .4 PMTUの年をとること…38 7. 監査します。39 8. 情報流動がセキュリティであるとサポートするシステムでは、使用します。39 セキュリティ関係の間の8.1関係とデータ感度.40 8.2感度一貫性の照合…40 8.3 セキュリティ協会データベースのための追加MLS属性…41 8.4 追加本国行きの処理はMLSネットワークのために踏まれます…41 8.5 追加外国行きの処理はMLSネットワークのために踏まれます…41 8.6 セキュリティゲートウェイのための追加MLS処理…42 9. パフォーマンス問題…42 10. 順応要件…43 11. セキュリティ問題…43 12. RFC1825からの違い…43の承認…44 付録A(用語集)…45 付録B--PMTU/DF/断片化問題の分析/議論…48 B.1 DFは噛み付きました…48 B.2断片化…48 B.3経路MTU発見…52 起因することを特定するB.3.1が(s)を接待します…53 PMTUのB.3.2計算…PMTUデータを保守する55B.3.3粒状…PMTUデータのソケットメインテナンスあたりの56B.3.4…57 トランスポート層へのPMTUデータのB.3.5配送…57 PMTUデータで老朽化しているB.3.6…57 付録C--系列スペース窓のコードの例…58 付録D--ICMPメッセージの分類…60の参照箇所…63注意書き…64 情報を書いてください…65 完全な著作権宣言文…66
Kent & Atkinson Standards Track [Page 2] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[2ページ]。
1. Introduction
1. 序論
1.1 Summary of Contents of Document
1.1 ドキュメントのコンテンツの概要
This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Additional RFCs (see Section 1.3 for pointers to other documents) define the protocols in (a), (c), and (d).
このメモはIPsec対応することのシステムにベースアーキテクチャを指定します。アーキテクチャの目標はIP層のトラフィックのための様々なセキュリティー・サービスを提供することです、IPv4とIPv6環境の両方で。 このドキュメントはそのようなシステムと、自己のコンポーネントとそれらがどう互いとIP環境の中に合うかに関する目標について説明します。 また、それはIPsecプロトコルによって提供されたセキュリティー・サービスと、IP環境でどうこれらのサービスを使うことができるかを説明します。 このドキュメントはIPsecアーキテクチャの全面を扱いません。 その後のドキュメントは、より高度な自然の追加建築詳細、例えばNAT環境と、より完全なサポートにおける、IPsecのIPマルチキャストの使用を扱うでしょう。 それらの基本的で、必要な機能性でIPsecセキュリティー体系の以下の基本要素について議論します。 追加RFCs(指針に関して他のドキュメントにセクション1.3を見る)は(a)、(c)、および(d)でプロトコルを定義します。
a. Security Protocols -- Authentication Header (AH) and
Encapsulating Security Payload (ESP)
b. Security Associations -- what they are and how they work,
how they are managed, associated processing
c. Key Management -- manual and automatic (The Internet Key
Exchange (IKE))
d. Algorithms for authentication and encryption
a。 セキュリティプロトコル--認証Header(AH)とEncapsulating Security有効搭載量(超能力)b。 彼らはそうであり、どのようにが彼らであるか。セキュリティAssociations--、こと、仕事、彼らはどう管理されて、関連している処理cであるか。 Key Management--手動の、そして、自動(インターネット・キー・エクスチェンジ(IKE))であるd。 認証と暗号化のためのアルゴリズム
This document is not an overall Security Architecture for the Internet; it addresses security only at the IP layer, provided through the use of a combination of cryptographic and protocol security mechanisms.
このドキュメントはインターネットへの総合的なSecurity Architectureではありません。 それは暗号とプロトコルセキュリティー対策の組み合わせの使用で提供されたIP層だけでセキュリティを扱います。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
キーワードが解釈しなければならない、本書では現れるとき、RFC2119[Bra97]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
1.2 Audience
1.2 聴衆
The target audience for this document includes implementers of this IP security technology and others interested in gaining a general background understanding of this system. In particular, prospective users of this technology (end users or system administrators) are part of the target audience. A glossary is provided as an appendix
このドキュメントのための対象者はこのIPセキュリティー技術とこのシステムの一般的なバックグラウンド理解を獲得したがっていた他のもののimplementersを入れます。 この技術(エンドユーザかシステム管理者)の将来のユーザは特に、対象者の一部です。 付録として用語集を提供します。
Kent & Atkinson Standards Track [Page 3] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[3ページ]。
to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol, related networking technology, and general security terms and concepts.
助けるには、バックグラウンド/ボキャブラリーの不足に記入してください。 このドキュメントは、読者がインターネットプロトコル、関連するネットワーク・テクノロジー、総合証券用語、および概念に詳しいと仮定します。
1.3 Related Documents
1.3 関連ドキュメント
As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their inter-relationship. They include RFCs on the following topics:
以上のように、他のドキュメントはIPsecのいくつかの部品とそれらの相互関係での詳細な定義を提供します。 彼らは以下の話題のRFCsを含んでいます:
a. "IP Security Document Roadmap" [TDG97] -- a document
providing guidelines for specifications describing encryption
and authentication algorithms used in this system.
b. security protocols -- RFCs describing the Authentication
Header (AH) [KA98a] and Encapsulating Security Payload (ESP)
[KA98b] protocols.
c. algorithms for authentication and encryption -- a separate
RFC for each algorithm.
d. automatic key management -- RFCs on "The Internet Key
Exchange (IKE)" [HC98], "Internet Security Association and
Key Management Protocol (ISAKMP)" [MSST97],"The OAKLEY Key
Determination Protocol" [Orm97], and "The Internet IP
Security Domain of Interpretation for ISAKMP" [Pip98].
a。 「IP Security Document Roadmap」TDG97--暗号化について説明する仕様と認証アルゴリズムのためのガイドラインを提供するドキュメントはこのシステムで. b.セキュリティプロトコルを使用しました--Encapsulating Security有効搭載量(超能力)KA98bプロトコル認証と暗号化のためのAuthentication Header(AH)KA98aについて説明するRFCsとc.アルゴリズム; 管理を合わせてください--「インターネット・キー・エクスチェンジ(IKE)」HC98の上のRFCs、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べる」という各アルゴリズムの. d.の自動MSST97のための別々のRFC、「オークリーKey Determinationプロトコル」Orm97、および「ISAKMPのための解釈のインターネットIPセキュリティー領域」Pip98。
2. Design Objectives
2. 設計目標
2.1 Goals/Objectives/Requirements/Problem Description
2.1の目標/目的/要件/問題記述
IPsec is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper layer protocols.
IPsecが共同利用できて、高い品質を提供するように設計されている、暗号で、ベース、IPv4とIPv6のためのセキュリティ。 サービスが提供したセキュリティのセットはアクセスコントロール、コネクションレスな保全、データ発生源認証、再生(部分的な系列保全のフォーム)に対する保護、秘密性(暗号化)、および限られた交通の流れ秘密性を含んでいます。 IP、そして/または、上側の層のプロトコルのために保護を提供して、IP層でこれらのサービスを提供します。
These objectives are met through the use of two traffic security protocols, the Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and protocols. The set of IPsec protocols employed in any context, and the ways in which they are employed, will be determined by the security and system requirements of users, applications, and/or sites/organizations.
これらの目的は2つのトラヒック保全プロトコル、Authentication Header(AH)、およびEncapsulating Security有効搭載量(超能力)の使用を通して暗号化キー管理手順とプロトコルの使用を通して満たされます。 どんな文脈でも使われたIPsecプロトコルのセット、およびそれらが採用している方法はユーザ、アプリケーション、そして/または、サイト/組織に関するセキュリティとシステム要求で決定するでしょう。
When these mechanisms are correctly implemented and deployed, they ought not to adversely affect users, hosts, and other Internet components that do not employ these security mechanisms for
いつの間、これらのメカニズムは、正しく実装されて、配布されて、それらはユーザ、ホスト、およびこれらのセキュリティー対策を使わない他のインターネットコンポーネントに悪影響を与えるべきではありませんか。
Kent & Atkinson Standards Track [Page 4] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[4ページ]。
protection of their traffic. These mechanisms also are designed to be algorithm-independent. This modularity permits selection of different sets of algorithms without affecting the other parts of the implementation. For example, different user communities may select different sets of algorithms (creating cliques) if required.
それらのトラフィックの保護。 これらのメカニズムも、アルゴリズムから独立しているように設計されています。 実装の他の部品に影響しないで、このモジュール方式は異なったセットのアルゴリズムの品揃えを可能にします。 例えば、必要なら、異なったユーザーコミュニティは異なったセットのアルゴリズム(徒党を創設する)を選択するかもしれません。
A standard set of default algorithms is specified to facilitate interoperability in the global Internet. The use of these algorithms, in conjunction with IPsec traffic protection and key management protocols, is intended to permit system and application developers to deploy high quality, Internet layer, cryptographic security technology.
デフォルトアルゴリズムの標準セットは、世界的なインターネットで相互運用性を容易にするために指定されます。 IPsecトラフィック保護とかぎ管理プロトコルに関連して、これらのアルゴリズムの使用が、システムとアプリケーション開発者が高い品質を配布することを許可することを意図します、インターネット層、暗号のセキュリティー技術。
2.2 Caveats and Assumptions
2.2 警告と仮定
The suite of IPsec protocols and associated default algorithms are designed to provide high quality security for Internet traffic. However, the security offered by use of these protocols ultimately depends on the quality of the their implementation, which is outside the scope of this set of standards. Moreover, the security of a computer system or network is a function of many factors, including personnel, physical, procedural, compromising emanations, and computer security practices. Thus IPsec is only one part of an overall system security architecture.
IPsecプロトコルと関連デフォルトアルゴリズムのスイートは、高品質のセキュリティをインターネットトラフィックに提供するように設計されています。 しかしながら、結局これらのプロトコルの使用で提供されたセキュリティを品質に依存する、それらの実装。(このセットの規格の範囲の外にその実装はあります)。 そのうえ、コンピュータ・システムかネットワークのセキュリティは多くの要素の関数です、人員を含んでいて、物理的です、手続き上です、エマナチオン、およびコンピュータセキュリティ習慣に感染して。 したがって、IPsecは総合体系セキュリティー体系の一部にすぎません。
Finally, the security afforded by the use of IPsec is critically dependent on many aspects of the operating environment in which the IPsec implementation executes. For example, defects in OS security, poor quality of random number sources, sloppy system management protocols and practices, etc. can all degrade the security provided by IPsec. As above, none of these environmental attributes are within the scope of this or other IPsec standards.
最終的に、IPsecの使用で都合されたセキュリティはIPsec実装が実行するもので批判的に操作環境の多くの局面に依存しています。 例えば、OSセキュリティにおける欠陥と乱数ソースの劣った品質とずさんなシステム管理プロトコルと習慣などはIPsecによって提供されたセキュリティをすべて下がらせることができます。 同じくらい上には、これか他のIPsec規格の範囲の中にこれらの環境属性のいずれもありません。
3. System Overview
3. システム概要
This section provides a high level description of how IPsec works, the components of the system, and how they fit together to provide the security services noted above. The goal of this description is to enable the reader to "picture" the overall process/system, see how it fits into the IP environment, and to provide context for later sections of this document, which describe each of the components in more detail.
このセクションはIPsecがどのように働くか、そして、システムの部品とそれらが上に述べられたセキュリティー・サービスを提供するためにどのように一緒に合うかに関する高い平らな記述を提供します。 この記述の目標が読者が総合的なプロセス/システムについて「描写すること」を可能にすることであり、それがどうIP環境に収まるかを見てください、そして、このドキュメントの後のセクションに文脈を供給するために、どれがさらに詳細にそれぞれのコンポーネントについて説明しますか?
An IPsec implementation operates in a host or a security gateway environment, affording protection to IP traffic. The protection offered is based on requirements defined by a Security Policy Database (SPD) established and maintained by a user or system administrator, or by an application operating within constraints
IPトラフィックに保護して、IPsec実装はホストかセキュリティゲートウェイ環境で作動します。 提供された保護はユーザかシステム管理者、または規制の中で手術されるアプリケーションで設立されて、維持されたSecurity Policy Database(SPD)によって定義された要件に基づいています。
Kent & Atkinson Standards Track [Page 5] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[5ページ]。
established by either of the above. In general, packets are selected for one of three processing modes based on IP and transport layer header information (Selectors, Section 4.4.2) matched against entries in the database (SPD). Each packet is either afforded IPsec security services, discarded, or allowed to bypass IPsec, based on the applicable database policies identified by the Selectors.
上記のどちらかで、設立されます。 一般に、パケットはデータベース(SPD)でエントリーに取り組まされるIPに基づく3つの処理モードとトランスポート層ヘッダー情報(セレクタ、セクション4.4.2)の1つのために選択されます。 各パケットは、IPsecセキュリティー・サービスを提供するか、捨てられるか、またはIPsecを迂回させることができます、Selectorsによって特定された適切なデータベース方針に基づいて。
3.1 What IPsec Does
3.1 IPsecがすること
IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. (The term "security gateway" is used throughout the IPsec documents to refer to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway.)
システムが必要なセキュリティプロトコルを選択して、サービスのために使用へのアルゴリズムを決定して、要求されたサービスを提供するのに必要である暗号化キーを適所に置くのを可能にすることによって、IPsecはIP層でセキュリティー・サービスを提供します。 1組のホストか、1組のセキュリティゲートウェイか、セキュリティゲートウェイとホストの間の1「経路」を保護するのにIPsecを使用できます。 (「セキュリティゲートウェイ」という用語は、IPsecにプロトコルを実装する中間システムについて言及するのにIPsecドキュメント中で使用されます。 例えば、ルータかIPsecを実装するファイアウォールがセキュリティゲートウェイです。)
The set of security services that IPsec can provide includes access control, connectionless integrity, data origin authentication, rejection of replayed packets (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. Because these services are provided at the IP layer, they can be used by any higher layer protocol, e.g., TCP, UDP, ICMP, BGP, etc.
IPsecが提供できるセキュリティー・サービスのセットはアクセスコントロール、コネクションレスな保全、データ発生源認証、再演されたパケット(部分的な系列保全のフォーム)、秘密性(暗号化)、および限られた交通の流れ秘密性の拒絶を含んでいます。 これらのサービスがIP層では、どんなより高い層のプロトコルでもそれらを使用できるかどうかということであるので、例えば、TCP、UDP、ICMP、BGPですなど。
The IPsec DOI also supports negotiation of IP compression [SMPT98], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers.
また、IPsec DOIは暗号化がIPsecの中で使われるとき、低級プロトコル層で有効な圧縮を防ぐという観測で一部動機づけられたIP圧縮[SMPT98]の交渉をサポートします。
3.2 How IPsec Works
3.2 IPsecはどう働いているか。
IPsec uses two protocols to provide traffic security -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in more detail in their respective RFCs [KA98a, KA98b].
IPsecはトラヒック保全を提供するのに2つのプロトコルを使用します--認証Header(AH)とEncapsulating Security有効搭載量(超能力)。 両方のプロトコルはさらに詳細にそれらのそれぞれのRFCs[KA98a、KA98b]で説明されます。
o The IP Authentication Header (AH) [KA98a] provides
connectionless integrity, data origin authentication, and an
optional anti-replay service.
o The Encapsulating Security Payload (ESP) protocol [KA98b] may
provide confidentiality (encryption), and limited traffic flow
confidentiality. It also may provide connectionless
o IP Authentication Header(AH)[KA98a]はコネクションレスな保全、データ発生源認証、および任意の反再生サービスを提供します。○ Encapsulating Security有効搭載量(超能力)プロトコル[KA98b]は秘密性(暗号化)、および限られた交通の流れ秘密性を提供するかもしれません。 また、それが提供されるかもしれない、コネクションレス
Kent & Atkinson Standards Track [Page 6] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[6ページ]。
integrity, data origin authentication, and an anti-replay
service. (One or the other set of these security services
must be applied whenever ESP is invoked.)
o Both AH and ESP are vehicles for access control, based on the
distribution of cryptographic keys and the management of
traffic flows relative to these security protocols.
保全、データ発生源認証、および反再生サービス。 (超能力が呼び出されるときはいつも、1かこれらのセキュリティー・サービスのもう片方のセットを適用しなければなりません。) o AHと超能力の両方がアクセスコントロールのための手段です、暗号化キーの分配とこれらのセキュリティプロトコルに比例した交通の流れの管理に基づいて。
These protocols may be applied alone or in combination with each other to provide a desired set of security services in IPv4 and IPv6. Each protocol supports two modes of use: transport mode and tunnel mode. In transport mode the protocols provide protection primarily for upper layer protocols; in tunnel mode, the protocols are applied to tunneled IP packets. The differences between the two modes are discussed in Section 4.
これらのプロトコルは、単独か互いと組み合わせて必要なセキュリティー・サービスをIPv4とIPv6に供給するために適用されるかもしれません。 各プロトコルは使用の2つの方法をサポートします: モードとトンネルモードを輸送してください。 交通機関に、プロトコルは主として上側の層のプロトコルのための保護を提供します。 トンネルモードで、プロトコルはトンネルを堀られたIPパケットに適用されます。 セクション4で2つのモードの違いについて議論します。
IPsec allows the user (or system administrator) to control the granularity at which a security service is offered. For example, one can create a single encrypted tunnel to carry all the traffic between two security gateways or a separate encrypted tunnel can be created for each TCP connection between each pair of hosts communicating across these gateways. IPsec management must incorporate facilities for specifying:
IPsecはユーザ(または、システム管理者)にセキュリティー・サービスが提供される粒状を制御させます。 例えば、1つが2セキュリティ門の間まですべてのトラフィックを運ぶために単一の暗号化されたトンネルを作成できますか、またはこれらのゲートウェイの向こう側に交信するそれぞれの組のホストの間のそれぞれのTCP接続のために別々の暗号化されたトンネルは作成できます。 IPsec経営者側は指定するために施設を取り入れなければなりません:
o which security services to use and in what combinations
o the granularity at which a given security protection should be
applied
o the algorithms used to effect cryptographic-based security
o どのセキュリティが使用とどんな組み合わせoに与えられた機密保持が○ 適用されて、アルゴリズムが暗号ベースのセキュリティを効果に使用したということであるべきである粒状を修理しますか。
Because these security services use shared secret values (cryptographic keys), IPsec relies on a separate set of mechanisms for putting these keys in place. (The keys are used for authentication/integrity and encryption services.) This document requires support for both manual and automatic distribution of keys. It specifies a specific public-key based approach (IKE -- [MSST97, Orm97, HC98]) for automatic key management, but other automated key distribution techniques MAY be used. For example, KDC-based systems such as Kerberos and other public-key systems such as SKIP could be employed.
これらのセキュリティー・サービスが共有秘密キー値(暗号化キー)を使用するので、IPsecはこれらのキーを適所に置くために別々のセットのメカニズムを当てにします。 (キーは認証/保全と暗号化サービスに使用されます。) このドキュメントは手動のものとキーの同様に自動である分配に支持を要します。 それは自動かぎ管理のための特定の公開鍵に基づいているアプローチ(イケ--[MSST97、Orm97、HC98])を指定しますが、他の自動化された主要な分配技法は使用されるかもしれません。 例えば、ケルベロスなどのKDCベースのシステムとSKIPなどの他の公開鍵システムを使うことができました。
3.3 Where IPsec May Be Implemented
3.3 IPsecが実装されるかもしれないところ
There are several ways in which IPsec may be implemented in a host or in conjunction with a router or firewall (to create a security gateway). Several common examples are provided below:
IPsecがホストかルータかファイアウォールに関連して実装されるかもしれない(セキュリティゲートウェイを作成する)いくつかの方法があります。 いくつかの一般的な例を以下に提供します:
a. Integration of IPsec into the native IP implementation. This
requires access to the IP source code and is applicable to
both hosts and security gateways.
a。 ネイティブのIP実装へのIPsecの統合。 これは、IPソースコードへのアクセスを必要として、ホストとセキュリティゲートウェイの両方に適切です。
Kent & Atkinson Standards Track [Page 7] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[7ページ]。
b. "Bump-in-the-stack" (BITS) implementations, where IPsec is
implemented "underneath" an existing implementation of an IP
protocol stack, between the native IP and the local network
drivers. Source code access for the IP stack is not required
in this context, making this implementation approach
appropriate for use with legacy systems. This approach, when
it is adopted, is usually employed in hosts.
b。 「スタックでの隆起」(BITS)実装、IPsecが“underneath"であると実装されるところでIPプロトコルの既存の実装は積み重ねられます、ネイティブのIPと企業内情報通信網のドライバーの間で。 IPスタックのためのソースコードアクセスはこのような関係においては必要ではありません、レガシーシステムでこの実装アプローチを使用に適切にして。それが採用されるとき、通常、このアプローチはホストで使われます。
c. The use of an outboard crypto processor is a common design
feature of network security systems used by the military, and
of some commercial systems as well. It is sometimes referred
to as a "Bump-in-the-wire" (BITW) implementation. Such
implementations may be designed to serve either a host or a
gateway (or both). Usually the BITW device is IP
addressable. When supporting a single host, it may be quite
analogous to a BITS implementation, but in supporting a
router or firewall, it must operate like a security gateway.
c。 船外の暗号プロセッサの使用はまた、軍によって使用されたネットワークセキュリティシステム、およびいくつかの商業の体系の一般的な設計上の特徴です。 それは時々「ワイヤでの隆起」(BITW)実装と呼ばれます。 そのような実装は、ホストかゲートウェイのどちらかに役立つ(ともに)ように設計されるかもしれません。 通常、BITWデバイスはアドレス可能なIPです。 独身のホストをサポートするとき、BITS実装に全く類似しているかもしれませんが、ルータかファイアウォールをサポートする際に、それはセキュリティゲートウェイのように作動しなければなりません。
4. Security Associations
4. セキュリティ協会
This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both. The concept of a "Security Association" (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a major function of IKE is the establishment and maintenance of Security Associations. All implementations of AH or ESP MUST support the concept of a Security Association as described below. The remainder of this section describes various aspects of Security Association management, defining required characteristics for SA policy management, traffic processing, and SA management techniques.
このセクションはすべてのIPv6実装とそれらのIPv4実装のためのAH、超能力、または両方を実装するSecurity Association管理要件を定義します。 「セキュリティ協会」(SA)の概念はIPsecに基本的です。 IKEの主要な機能は、Security AssociationsのAHと超能力の両方がSAsを利用して、設立とメインテナンスです。 AHか超能力のすべての実装が以下で説明されるようにSecurity Associationの概念をサポートしなければなりません。 このセクションの残りはSecurity Association管理の種々相について説明します、SA政策管理、トラフィック処理、およびSA管理技術のために必要な特性を定義して。
4.1 Definition and Scope
4.1 定義と範囲
A Security Association (SA) is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection is applied to a traffic stream, then two (or more) SAs are created to afford protection to the traffic stream. To secure typical, bi-directional communication between two hosts, or between two security gateways, two Security Associations (one in each direction) are required.
Security Association(SA)はそれによって運ばれたトラフィックへのセキュリティー・サービスを提供するシンプレクス「接続」です。 セキュリティー・サービスをAH、または超能力の使用でSAに都合しますが、ともに都合するというわけではありません。 AHと超能力の両方であるなら、保護はトラフィックストリームに適用されて、次に、2(さらに)SAsが、トラフィックストリームに保護するために作成されます。 2人のホスト、または2セキュリティ門、2Security Associationsの安全な典型的で、双方向のコミュニケーション、(あるコネ、各方向) 必要です。
A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. In principle, the Destination Address may be a unicast address, an IP broadcast address, or a multicast group address. However, IPsec SA management mechanisms currently are defined only for unicast SAs. Hence, in the
セキュリティ協会はSecurity Parameter Index(SPI)、IP Destination Address、およびセキュリティプロトコル(AHか超能力)識別子から成る三重によって唯一特定されます。 原則として、Destination Addressはユニキャストアドレス、IP放送演説、またはマルチキャストグループアドレスであるかもしれません。 しかしながら、IPsec SA管理メカニズムは現在、ユニキャストSAsのためだけに定義されます。 したがって中
Kent & Atkinson Standards Track [Page 8] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[8ページ]。
discussions that follow, SAs will be described in the context of point-to-point communication, even though the concept is applicable in the point-to-multipoint case as well.
続く議論、SAsは二地点間コミュニケーションの文脈で説明されるでしょう、概念がまた、ポイントツーマルチポイント場合で適切ですが。
As noted above, two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts. In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any higher layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and extensions, but may appear before or after destination options, and before higher layer protocols. In the case of ESP, a transport mode SA provides security services only for these higher layer protocols, not for the IP header or any extension headers preceding the ESP header. In the case of AH, the protection is also extended to selected portions of the IP header, selected portions of extension headers, and selected options (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or IPv6 Destination extension headers). For more details on the coverage afforded by AH, see the AH specification [KA98a].
上で述べたように、SAsの2つのタイプが定義されます: モードとトンネルモードを輸送してください。 交通機関SAは2人のホストの間のセキュリティ協会です。 IPv4では、交通機関セキュリティプロトコルヘッダーはIPヘッダーとどんなオプション直後、どんなより高い層のプロトコル(例えば、TCPかUDP)の前にも現れます。 IPv6では、目的地オプションの前または後と、より高い層のプロトコルの前に現れるかもしれないのを除いて、セキュリティプロトコルヘッダーはベースIPヘッダーと拡大の後に現れます。 超能力の場合では、モードSAがセキュリティを提供する輸送はIPヘッダーかどんな拡大のためにもサービスを提供するのではなく、これらのより高い層のプロトコルのためだけに超能力ヘッダーに先行するヘッダーにサービスを提供します。 AHの場合では、また、IPヘッダーの選択された部分、拡張ヘッダーの選択された部分、および選択されたオプション(IPv4ヘッダー、ホップによるIPv6 Hop拡張ヘッダー、またはIPv6 Destination拡張ヘッダーでは、含まれている)に広げられて、保護はそうです。 AHによって提供された適用範囲に関するその他の詳細に関しては、AH仕様[KA98a]を見てください。
A tunnel mode SA is essentially an SA applied to an IP tunnel. Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. Thus an SA between two security gateways is always a tunnel mode SA, as is an SA between a host and a security gateway. Note that for the case where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed. But in that case, the security gateway is not acting as a gateway, i.e., not transiting traffic. Two hosts MAY establish a tunnel mode SA between themselves. The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways.
トンネルモードSAは本質的にはIPトンネルに適用されたSAです。 セキュリティ協会のどちらかの終わりがセキュリティゲートウェイ、SA MUSTであるときはいつも、トンネルモードになってください。 したがって、いつも2セキュリティ門の間のSAはホストとセキュリティゲートウェイの間のSAのようにトンネルモードSAです。 トラフィックがセキュリティゲートウェイに運命づけられているケースのために、例えば、SNMPが命令するというメモ、ホストと交通機関が許容されているとき、セキュリティゲートウェイは作動しています。 しかし、すなわち、その場合、セキュリティゲートウェイは、トラフィックを通過しないことでゲートウェイとして作動していません。 2人のホストが自分たちの間にトンネルモードSAを設立するかもしれません。 トンネルSAになるようにセキュリティゲートウェイにかかわるどんな(トランジットトラフィック)SAのための要件もIPsecパケットの断片化と再アセンブリに関して潜在的な問題を避ける必要性、および複数の経路(例えば、異なったセキュリティゲートウェイを通した)がセキュリティゲートウェイの後ろに同じ目的地に存在する事情に起こります。
For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing destination, plus an "inner" IP header that specifies the (apparently) ultimate destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packet (i.e., all of the inner IP header is protected, as well as higher layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header.
トンネルモードSAを支持して、IPsec処理の目的地を指定する「外側」のIPヘッダー、および(明らかに)最終仕向地をパケットに指定する「内側」のIPヘッダーがあります。 セキュリティプロトコルヘッダーは外側のIPヘッダーの後、および内側のIPヘッダーの前に現れます。 トンネルモードでAHを使うなら、外側のIPヘッダーの一部に保護(as above)を都合します、トンネルを堀られたIPパケットのすべてと同様に(すなわち、内側のIPヘッダーのすべてが保護されます、より高い層のプロトコルと同様に)。 超能力が採用しているなら、外側のヘッダーではなく、トンネルを堀られたパケットだけに保護を提供します。
Kent & Atkinson Standards Track [Page 9] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[9ページ]。
In summary,
a) A host MUST support both transport and tunnel mode.
b) A security gateway is required to support only tunnel
mode. If it supports transport mode, that should be used
only when the security gateway is acting as a host, e.g.,
for network management.
概要、a)で ホストはトンネルモード輸送とb)の両方をサポートしなければなりません。 セキュリティゲートウェイが、トンネルモードだけをサポートするのに必要です。 セキュリティゲートウェイがホストとして務めているときだけ、輸送がモードであるとサポートするなら、それは使用されるべきです、例えば、ネットワークマネージメントのために。
4.2 Security Association Functionality
4.2 セキュリティ協会の機能性
The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and on the election of optional services within the protocol. For example, AH provides data origin authentication and connectionless integrity for IP datagrams (hereafter referred to as just "authentication"). The "precision" of the authentication service is a function of the granularity of the security association with which AH is employed, as discussed in Section 4.4.2, "Selectors".
SAによって提供されたセキュリティー・サービスのセットは選択されたセキュリティプロトコル、SAモード、SAの終点と、そして、任意にプロトコルの中のサービスの選挙に依存します。 例えば、AHはIPデータグラム(今後まさしく「認証」と呼ばれる)にデータ発生源認証とコネクションレスな保全を供給します。 認証サービスの「精度」はAHが採用しているセキュリティ協会の粒状の関数です、セクション4.4.2、「セレクタ」で議論するように。
AH also offers an anti-replay (partial sequence integrity) service at the discretion of the receiver, to help counter denial of service attacks. AH is an appropriate protocol to employ when confidentiality is not required (or is not permitted, e.g , due to government restrictions on use of encryption). AH also provides authentication for selected portions of the IP header, which may be necessary in some contexts. For example, if the integrity of an IPv4 option or IPv6 extension header must be protected en route between sender and receiver, AH can provide this service (except for the non-predictable but mutable parts of the IP header.)
また、AHは、カウンタサービス不能攻撃を助けるために受信機の裁量で反再生(部分的な系列保全)サービスを提供します。 秘密性は必要でないときに、AHが使うのが適切であるプロトコルである、(政府制限のために、受入れられて、e.gで、オンでない、暗号化の使用) また、AHはいくつかの文脈で必要であるかもしれないIPヘッダーの選択された部分のための認証を提供します。 例えば、途中で送付者と受信機の間にIPv4オプションかIPv6拡張ヘッダーの保全を保護しなければならないなら、AHはこのサービスを提供できます。(IPヘッダーの非予測できますが、無常の一部を除いた。)
ESP optionally provides confidentiality for traffic. (The strength of the confidentiality service depends in part, on the encryption algorithm employed.) ESP also may optionally provide authentication (as defined above). If authentication is negotiated for an ESP SA, the receiver also may elect to enforce an anti-replay service with the same features as the AH anti-replay service. The scope of the authentication offered by ESP is narrower than for AH, i.e., the IP header(s) "outside" the ESP header is(are) not protected. If only the upper layer protocols need to be authenticated, then ESP authentication is an appropriate choice and is more space efficient than use of AH encapsulating ESP. Note that although both confidentiality and authentication are optional, they cannot both be omitted. At least one of them MUST be selected.
超能力は任意に秘密性をトラフィックに提供します。 (秘密性サービスの強さを使われた暗号化アルゴリズムに一部依存します。) 超能力も任意に認証を提供するかもしれません(上で定義されるように)。 認証がESP SAのために交渉されるなら、受信機も、AH反再生サービスと同じ特徴で反再生サービスを実施するのを選ぶかもしれません。 超能力によって提供された認証の範囲はAHより狭いです、すなわち、IPヘッダー。「外では、」超能力ヘッダーが保護されません(あります)。 上側の層のプロトコルだけが、認証される必要があるなら、超能力認証は、超能力をカプセル化するAHの使用より適当な選択であり、より多くのスペース効率的です。 秘密性と認証の両方が任意ですが、ともにそれらを省略できないことに注意してください。 少なくともそれらの1つを選択しなければなりません。
If confidentiality service is selected, then an ESP (tunnel mode) SA between two security gateways can offer partial traffic flow confidentiality. The use of tunnel mode allows the inner IP headers to be encrypted, concealing the identities of the (ultimate) traffic source and destination. Moreover, ESP payload padding also can be
秘密性サービスが選択されるなら、2セキュリティ門の間の超能力(トンネルモード)SAは部分的な交通の流れ秘密性を提供できます。 トンネルモードの使用は、内側のIPヘッダーが暗号化されるのを許容します、(究極)のトラフィックソースと目的地のアイデンティティを隠して。 そのうえ、また、超能力ペイロード詰め物はそうであることができます。
Kent & Atkinson Standards Track [Page 10] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[10ページ]。
invoked to hide the size of the packets, further concealing the external characteristics of the traffic. Similar traffic flow confidentiality services may be offered when a mobile user is assigned a dynamic IP address in a dialup context, and establishes a (tunnel mode) ESP SA to a corporate firewall (acting as a security gateway). Note that fine granularity SAs generally are more vulnerable to traffic analysis than coarse granularity ones which are carrying traffic from many subscribers.
パケットのサイズを隠すために、さらにトラフィックの外部の特性を隠して、呼び出されます。 モバイルユーザが動的IPアドレスがダイアルアップ文脈で割り当てられて、(トンネルモード)ESP SAを法人のファイアウォールに設立するとき(セキュリティゲートウェイとして機能して)、同様の交通の流れ秘密性サービスを提供するかもしれません。 一般に、すばらしい粒状SAsが多くの加入者からトラフィックを運ぶ粗い粒状ものよりトラヒック分析に被害を受け易いことに注意してください。
4.3 Combining Security Associations
4.3 セキュリティ協会を合併すること。
The IP datagrams transmitted over an individual SA are afforded protection by exactly one security protocol, either AH or ESP, but not both. Sometimes a security policy may call for a combination of services for a particular traffic flow that is not achievable with a single SA. In such instances it will be necessary to employ multiple SAs to implement the required security policy. The term "security association bundle" or "SA bundle" is applied to a sequence of SAs through which traffic must be processed to satisfy a security policy. The order of the sequence is defined by the policy. (Note that the SAs that comprise a bundle may terminate at different endpoints. For example, one SA may extend between a mobile host and a security gateway and a second, nested SA may extend to a host behind the gateway.)
個々のSAの上に送られたIPデータグラムに、まさに1つのセキュリティプロトコル(AHか超能力のどちらか)で保護を提供しますが、ともに提供するというわけではありません。 時々、安全保障政策は独身のSAと共に達成可能でない特定の交通の流れのためのサービスの組み合わせを求めるかもしれません。 そういった場合にはそれは、必要な安全保障政策を実装するのに複数のSAsを使うために必要になるでしょう。 「セキュリティ協会バンドル」か「SAバンドル」という用語は安全保障政策を満たすためにトラフィックを処理しなければならないSAsの系列に適用されます。 方針で系列の注文を定義します。 (バンドルを包括するSAsが異なった終点で終わるかもしれないことに注意してください。 例えば、1SAがモバイルホストと、セキュリティゲートウェイと1秒の間で広がるかもしれなくて、入れ子にされたSAはゲートウェイの後ろでホストに達するかもしれません。)
Security associations may be combined into bundles in two ways: transport adjacency and iterated tunneling.
セキュリティ協会は2つの方法でバンドルに合併されるかもしれません: 隣接番組と繰り返されたトンネリングを輸送してください。
o Transport adjacency refers to applying more than one
security protocol to the same IP datagram, without invoking
tunneling. This approach to combining AH and ESP allows
for only one level of combination; further nesting yields
no added benefit (assuming use of adequately strong
algorithms in each protocol) since the processing is
performed at one IPsec instance at the (ultimate)
destination.
o 輸送隣接番組はトンネリングを呼び出さないで1つ以上のセキュリティプロトコルを同じIPデータグラムに適用するのを示します。 AHと超能力を結合することへのこのアプローチは1つのレベルの組み合わせだけを考慮します。 処理が(究極)の目的地の1つのIPsecインスタンスで実行されるので、さらなる巣篭もりは付加利益(各プロトコルにおける適切に強いアルゴリズムの使用を仮定する)を全くもたらしません。
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -----Security Association 1 (ESP transport)------- |
| |
-------Security Association 2 (AH transport)----------
ホスト1--- セキュリティ---- インターネット--セキュリティ--- ホスト2| | Gwy1Gwy2| | | | | | | -----セキュリティAssociation1(超能力輸送)------- | | | -------セキュリティAssociation2(AH輸送)----------
o Iterated tunneling refers to the application of multiple
layers of security protocols effected through IP tunneling.
This approach allows for multiple levels of nesting, since
each tunnel can originate or terminate at a different IPsec
o 繰り返されたトンネリングはIPトンネリングを通して作用する複数の層のセキュリティプロトコルの応用について言及します。 このアプローチは各トンネルが異なったIPsecで起因するか、または終わることができるので巣ごもる複数のレベルを考慮します。
Kent & Atkinson Standards Track [Page 11] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[11ページ]。
site along the path. No special treatment is expected for
ISAKMP traffic at intermediate security gateways other than
what can be specified through appropriate SPD entries (See
Case 3 in Section 4.5)
経路に沿ったサイト。 どんな特別な処理も適切なSPDエントリーで指定できること以外の中間的セキュリティゲートウェイのISAKMPトラフィックのために予想されません。(セクション4.5でケース3を見ます)
There are 3 basic cases of iterated tunneling -- support is
required only for cases 2 and 3.:
繰り返されたトンネリングの3つの基本的なケースがあります--サポートがケース2と3.にだけ必要です:
1. both endpoints for the SAs are the same -- The inner and
outer tunnels could each be either AH or ESP, though it
is unlikely that Host 1 would specify both to be the
same, i.e., AH inside of AH or ESP inside of ESP.
1. SAsのための両方の終点は同じです--内側の、そして、外側のトンネルは、それぞれAHか超能力のどちらかであるかもしれません、Host1がともに同じになるように指定するのが、ありそうもないのですが、すなわち、超能力のAHか超能力内部のAH内部。
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -------Security Association 1 (tunnel)---------- | |
| |
---------Security Association 2 (tunnel)--------------
ホスト1--- セキュリティ---- インターネット--セキュリティ--- ホスト2| | Gwy1Gwy2| | | | | | | -------セキュリティ協会1(トンネル)---------- | | | | ---------セキュリティ協会2(トンネル)--------------
2. one endpoint of the SAs is the same -- The inner and
uter tunnels could each be either AH or ESP.
2. SAsの1つの終点が同じです--内側とuterトンネルは、それぞれAHか超能力のどちらかであるかもしれません。
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 |
| | | |
| ----Security Association 1 (tunnel)---- |
| |
---------Security Association 2 (tunnel)-------------
ホスト1--- セキュリティ---- インターネット--セキュリティ--- ホスト2| | Gwy1Gwy2| | | | | | ----セキュリティ協会1(トンネル)---- | | | ---------セキュリティ協会2(トンネル)-------------
3. neither endpoint is the same -- The inner and outer
tunnels could each be either AH or ESP.
3. どちらの終点も同じではありません--内側の、そして、外側のトンネルは、それぞれAHか超能力のどちらかであるかもしれません。
Host 1 --- Security ---- Internet -- Security --- Host 2
| Gwy 1 Gwy 2 |
| | | |
| --Security Assoc 1 (tunnel)- |
| |
-----------Security Association 2 (tunnel)-----------
ホスト1--- セキュリティ---- インターネット--セキュリティ--- ホスト2| Gwy1Gwy2| | | | | | --セキュリティAssoc1(トンネル)、-| | | -----------セキュリティ協会2(トンネル)-----------
These two approaches also can be combined, e.g., an SA bundle could be constructed from one tunnel mode SA and one or two transport mode SAs, applied in sequence. (See Section 4.5 "Basic Combinations of Security Associations.") Note that nested tunnels can also occur where neither the source nor the destination endpoints of any of the tunnels are the same. In that case, there would be no host or security gateway with a bundle corresponding to the nested tunnels.
これらの2つのアプローチも結合できる、例えば、SAバンドルは連続して1つのトンネルのモードSAと1か2交通機関SAsから組み立てて、適用できました。 (「セキュリティ協会の基本的な組み合わせ」というセクション4.5を見てください。) また、入れ子にされたトンネルがソースもトンネルのどれかの目的地終点も同じでないところに現れることができることに注意してください。 その場合、入れ子にされたトンネルに対応するバンドルがあるどんなホストもセキュリティゲートウェイもないでしょう。
Kent & Atkinson Standards Track [Page 12] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[12ページ]。
For transport mode SAs, only one ordering of security protocols seems appropriate. AH is applied to both the upper layer protocols and (parts of) the IP header. Thus if AH is used in a transport mode, in conjunction with ESP, AH SHOULD appear as the first header after IP, prior to the appearance of ESP. In that context, AH is applied to the ciphertext output of ESP. In contrast, for tunnel mode SAs, one can imagine uses for various orderings of AH and ESP. The required set of SA bundle types that MUST be supported by a compliant IPsec implementation is described in Section 4.5.
交通機関SAsに関しては、セキュリティプロトコルを注文する人だけが適切に見えます。 そして、AHが両方の上側の層のプロトコルに適用される、(離れている、)、IPヘッダー。 したがって、AHが交通機関で超能力に関連して使用されるなら、AH SHOULDはIPの後に最初のヘッダーとして現れます、超能力の外観の前に。 その文脈では、AHは超能力の暗号文出力に適用されます。 対照的に、トンネルモードSAsのために、人はAHと超能力の様々な受注業務への用途を想像できます。 対応するIPsec実装でサポートしなければならないSAの必要なバンドルタイプはセクション4.5で説明されます。
4.4 Security Association Databases
4.4 セキュリティ協会データベース
Many of the details associated with processing IP traffic in an IPsec implementation are largely a local matter, not subject to standardization. However, some external aspects of the processing must be standardized, to ensure interoperability and to provide a minimum management capability that is essential for productive use of IPsec. This section describes a general model for processing IP traffic relative to security associations, in support of these interoperability and functionality goals. The model described below is nominal; compliant implementations need not match details of this model as presented, but the external behavior of such implementations must be mappable to the externally observable characteristics of this model.
IPsec実装における処理IPトラフィックに関連している詳細の多くが標準化への対象ではなく、主に地域にかかわる事柄です。 しかしながら、相互運用性を確実にして、IPsecの生産用途に、不可欠の最小の管理能力を提供するために処理のいくつかの外面を標準化しなければなりません。 このセクションは処理IPトラフィックのためにセキュリティ協会に比例して一般的なモデルについて説明します、これらの相互運用性と機能性目標を支持して。 以下で説明されたモデルは名目上です。 対応する実装は提示されるようにこのモデルの細部に合う必要はありませんが、そのような実装の外部の振舞いはこのモデルの外部的に観察可能な特性にmappableであるに違いありません。
There are two nominal databases in this model: the Security Policy Database and the Security Association Database. The former specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host, security gateway, or BITS or BITW IPsec implementation. The latter database contains parameters that are associated with each (active) security association. This section also defines the concept of a Selector, a set of IP and upper layer protocol field values that is used by the Security Policy Database to map traffic to a policy, i.e., an SA (or SA bundle).
このモデルには2つの名目上のデータベースがあります: 安全保障政策データベースとセキュリティ協会データベース。 前者はホスト、セキュリティゲートウェイ、またはBITSからの本国行きの、または、外国行きのすべてのIPトラフィックかBITW IPsec実装の気質を決定する方針を指定します。 後者のデータベースはそれぞれの(アクティブ)のセキュリティ関係に関連しているパラメタを含んでいます。 また、このセクションはトラフィックを方針に写像するのにSecurity Policy Databaseによって使用される1セットのSelectorの概念、IP、および上側の層のプロトコル分野値を定義します、すなわち、SA(SAは荷物をまとめます)。
Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD), because of the directionality of many of the fields that are used as selectors. Typically there is just one such interface, for a host or security gateway (SG). Note that an SG would always have at least 2 interfaces, but the "internal" one to the corporate net, usually would not have IPsec enabled and so only one pair of SADs and one pair of SPDs would be needed. On the other hand, if a host had multiple interfaces or an SG had multiple external interfaces, it might be necessary to have separate SAD and SPD pairs for each interface.
IPsecが有効にされる各インタフェースは名目上は別々の外国行きに対して本国行きのデータベース(SADとSPD)を必要とします、セレクタとして使用される分野の多くの方向性のために。 ホストかセキュリティゲートウェイ(SG)にはちょうどそのようなインタフェースの1つが通常あります。 SGには少なくとも2つのインタフェースがいつもあることに注意してください、法人のネットへの「内部」のもの、通常、IPsecを有効にさせないでしょう、しかし、したがって、1組のSADsと1組のSPDsだけが必要でしょう。 他方では、ホストには複数のインタフェースがあったか、またはSGに複数の外部のインタフェースがあるなら、各インタフェースへの別々のSADとSPD組があるのが必要でしょうに。
Kent & Atkinson Standards Track [Page 13] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[13ページ]。
4.4.1 The Security Policy Database (SPD)
4.4.1 安全保障政策データベース(SPD)
Ultimately, a security association is a management construct used to enforce a security policy in the IPsec environment. Thus an essential element of SA processing is an underlying Security Policy Database (SPD) that specifies what services are to be offered to IP datagrams and in what fashion. The form of the database and its interface are outside the scope of this specification. However, this section does specify certain minimum management functionality that must be provided, to allow a user or system administrator to control how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway.
結局、セキュリティ協会はIPsec環境における安全保障政策を実施するのに使用される管理構造物です。 したがって、SA処理の必須元素はどんなサービスがデータグラムとどんなファッションでIPに提供されるかことであるかと指定する基本的なSecurity Policy Database(SPD)です。 この仕様の範囲の外にデータベースのフォームとそのインタフェースがあります。 しかしながら、このセクションはユーザかシステム管理者がIPsecがどうホストによって伝えられたか、または受け取られたトラフィックに適用されるかを制御するのを許容するために提供しなければならないか、またはセキュリティゲートウェイを通過しなければならないある最小の管理の機能性を指定します。
The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. In order to support this, the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). In addition, a nominally separate SPD must be provided for each IPsec-enabled interface.
非IPsecトラフィックを含んでいて、すべてのトラフィック(INBOUNDとOUTBOUND)の処理の間、SPDに相談しなければなりません。 SPDがこれをサポートするために異なったエントリーを必要とする、本国行き、そして、アウトバウンドトラフィック。 人は別々のSPDs(外国行きに対して本国行きの)としてこれを考えることができます。 さらに、それぞれのIPsecによって可能にされたインタフェースに名目上は別々のSPDを提供しなければなりません。
An SPD must discriminate among traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec. This applies to the IPsec protection to be applied by a sender and to the IPsec protection that must be present at the receiver. For any outbound or inbound datagram, three processing choices are possible: discard, bypass IPsec, or apply IPsec. The first choice refers to traffic that is not allowed to exit the host, traverse the security gateway, or be delivered to an application at all. The second choice refers to traffic that is allowed to pass without additional IPsec protection. The third choice refers to traffic that is afforded IPsec protection, and for such traffic the SPD must specify the security services to be provided, protocols to be employed, algorithms to be used, etc.
SPDはIPsec保護が提供されているトラフィックとIPsecを迂回させることができるトラフィックの中で差別しなければなりません。 これは、送付者と、そして、受信機に出席するに違いないIPsec保護に適用されるのをIPsec保護に適用します。どんな外国行きの、または、本国行きのデータグラムに関しても、3つの処理選択が可能です: 捨てるか、IPsecを迂回させるか、またはIPsecを適用してください。 最初の選択はホストを出ることができないか、セキュリティゲートウェイを横断できないか、全くアプリケーションに提供できないトラフィックについて言及します。 第二希望は追加IPsec保護なしで通ることができるトラフィックについて言及します。 3番目の選択はIPsec保護が提供されているトラフィックについて言及します、そして、そのようなトラフィックとして、SPDは提供されるセキュリティー・サービス、使われるべきプロトコル、使用されるべきアルゴリズムなどを指定しなければなりません。
For every IPsec implementation, there MUST be an administrative interface that allows a user or system administrator to manage the SPD. Specifically, every inbound or outbound packet is subject to processing by IPsec and the SPD must specify what action will be taken in each case. Thus the administrative interface must allow the user (or system administrator) to specify the security processing to be applied to any packet entering or exiting the system, on a packet by packet basis. (In a host IPsec implementation making use of a socket interface, the SPD may not need to be consulted on a per packet basis, but the effect is still the same.) The management interface for the SPD MUST allow creation of entries consistent with the selectors defined in Section 4.4.2, and MUST support (total) ordering of these entries. It is expected that through the use of wildcards in various selector fields, and because all packets on a
あらゆるIPsec実装のために、ユーザかシステム管理者がSPDを管理できる管理インタフェースがあるに違いありません。 明確に、あらゆる本国行きの、または、外国行きのパケットがIPsecによる処理を受けることがあります、そして、SPDはどんな行動がその都度取られるかを指定しなければなりません。 したがって、ユーザ(または、システム管理者)はシステムを入るか、または出るどんなパケットにも適用されるために管理インタフェースでセキュリティ処理を指定できなければなりません、パケット基礎によるパケットの上で。 (ソケットインタフェースを利用するホストIPsec実装ではパケット基礎あたりのaに関してSPDは相談される必要はないかもしれませんが、効果はまだ同じです。) セクション4.4.2で定義して、SPD MUSTがセレクタと一致したエントリーの作成を許容するので、管理インタフェースはこれらのエントリーのサポート(総)注文を定義しなければなりませんでした。 それは予想されます。そして、様々なセレクタにおけるワイルドカードの使用によるそれがさばく、aのすべてのパケット
Kent & Atkinson Standards Track [Page 14] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[14ページ]。
single UDP or TCP connection will tend to match a single SPD entry, this requirement will not impose an unreasonably detailed level of SPD specification. The selectors are analogous to what are found in a stateless firewall or filtering router and which are currently manageable this way.
独身のUDPかTCP接続が、単一のSPDエントリーに合っている傾向があって、この要件は無分別に詳細なレベルのSPD仕様を課さないでしょう。 セレクタはこのように何が状態がないファイアウォールかフィルタリングルータで見つけられるか、そして、どれが現在見つけられるかに処理しやすい状態で類似しています。
In host systems, applications MAY be allowed to select what security processing is to be applied to the traffic they generate and consume. (Means of signalling such requests to the IPsec implementation are outside the scope of this standard.) However, the system administrator MUST be able to specify whether or not a user or application can override (default) system policies. Note that application specified policies may satisfy system requirements, so that the system may not need to do additional IPsec processing beyond that needed to meet an application's requirements. The form of the management interface is not specified by this document and may differ for hosts vs. security gateways, and within hosts the interface may differ for socket-based vs. BITS implementations. However, this document does specify a standard set of SPD elements that all IPsec implementations MUST support.
ホストシステムでは、アプリケーションは、どんなセキュリティ処理がそれらが生成して、消費するトラフィックに適用されるかことであるかを選択できるかもしれません。 (この規格の範囲の外にIPsec実装にそのような要求に合図する手段があります。) しかしながら、システム管理者は、ユーザかアプリケーションが(デフォルト)システム方針をくつがえすことができるかどうか指定できなければなりません。 アプリケーション特約保険証券がシステム要求を満たすかもしれないことに注意してください、システムがアプリケーションの必要条件を満たすのに必要であるそれを超えて追加IPsec処理ができる必要はないように。 管理インタフェースのフォームは、このドキュメントによって指定されないで、ホスト対セキュリティゲートウェイのために異なるかもしれません、そして、ホストの中では、インタフェースはBITSに対するソケットベースの実装のために異なるかもしれません。 しかしながら、このドキュメントはすべてのIPsec実装が支えなければならないSPD要素の標準セットを指定します。
The SPD contains an ordered list of policy entries. Each policy entry is keyed by one or more selectors that define the set of IP traffic encompassed by this policy entry. (The required selector types are defined in Section 4.4.2.) These define the granularity of policies or SAs. Each entry includes an indication of whether traffic matching this policy will be bypassed, discarded, or subject to IPsec processing. If IPsec processing is to be applied, the entry includes an SA (or SA bundle) specification, listing the IPsec protocols, modes, and algorithms to be employed, including any nesting requirements. For example, an entry may call for all matching traffic to be protected by ESP in transport mode using 3DES-CBC with an explicit IV, nested inside of AH in tunnel mode using HMAC/SHA-1. For each selector, the policy entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors):
SPDは方針エントリーの規則正しいリストを含んでいます。 それぞれの方針エントリーはこの方針エントリーで取り囲まれたIPトラフィックのセットを定義する1個以上のセレクタによって合わせられます。 (必要なセレクタタイプはセクション4.4.2で定義されます。) これらは方針かSAsの粒状を定義します。 各エントリーは捨てられるか、またはIPsec処理を条件としたこの方針に合っているトラフィックが迂回するかどうかしるしを含んでいます。 エントリーはIPsec処理が適用されていることであるなら、SA(SAは荷物をまとめる)仕様を含んでいます、使われるためにIPsecプロトコル、モード、およびアルゴリズムを記載して、どんな巣篭もり要件も含んでいて。 例えば、エントリーは、すべての合っているトラフィックが交通機関における超能力によって保護されるように明白なIVと3DES-CBCを使用することで求めるかもしれません、HMAC/SHA-1を使用するトンネルモードによるAHの入れ子にされた内部。 各セレクタとして、方針エントリーはSPDとパケットのそれらから換算値を新しいSecurity Association Database(SAD、セクション4.4.3を見る)エントリーに引き出す方法を指定します(現在のところ、範囲はIPアドレスのためにサポートされるだけです; しかし、すべてのセレクタのためにwildcardingを言い表すことができることに注意してください):
a. use the value in the packet itself -- This will limit use
of the SA to those packets which have this packet's value
for the selector even if the selector for the policy entry
has a range of allowed values or a wildcard for this
selector.
b. use the value associated with the policy entry -- If this
were to be just a single value, then there would be no
difference between (b) and (a). However, if the allowed
values for the selector are a range (for IP addresses) or
パケット自体で値を使用してください--方針エントリーのためのセレクタにさまざまな許容値かこのセレクタのためのワイルドカードがあっても、これはセレクタのためにSAの使用をこのパケットの値を持っているそれらのパケットに制限するでしょう。a. 値がこれがただただ一つの値であることのためのものであったなら方針エントリーに関連づけたb.使用、次に、(b)と(a)の間には、違いが全くないでしょう。 またはしかしながら、セレクタのための許容値がaであるなら及んでください、(IPアドレスのために)。
Kent & Atkinson Standards Track [Page 15] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[15ページ]。
wildcard, then in the case of a range,(b) would enable use
of the SA by any packet with a selector value within the
range not just by packets with the selector value of the
packet that triggered the creation of the SA. In the case
of a wildcard, (b) would allow use of the SA by packets
with any value for this selector.
ワイルドカード、そして、1つの範囲の場合では、SAの作成の引き金となったパケットのセレクタ値があるパケットだけでないのによる範囲の中にセレクタ値がある状態で、(b)はどんなパケットでもSAの使用を可能にするでしょう。 ワイルドカードの場合では、(b)はこのセレクタのためのどんな値があるパケットでもSAの使用を許すでしょう。
For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10). And suppose that a packet is to be sent that has a source address of 192.168.2.3. The value to be used for the SA could be any of the sample values below depending on what the policy entry for this selector says is the source of the selector value:
例えば、SPDエントリーがソースアドレスのための許容値がさまざまなホストのいずれでもあるところにあると仮定してください、(192.168、.2、.1、192.168 .2 .10)。 そして、.2がソースが.3に192.168を扱うaを持っているパケットが送られることになっていると仮定してください。 SAに使用されるべき値はこのセレクタのための方針エントリーがセレクタ価値の源であると言うことによる下の標本値のいずれであるかもしれませんも:
source for the example of
value to be new SAD
used in the SA selector value
--------------- ------------
a. packet 192.168.2.3 (one host)
b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts)
価値に関する例がSAセレクタ価値に使用される新しいSADであるソース--------------- ------------ a.パケット192.168.2.3(1人のホスト)b。 SPDエントリー192.168.2の.1〜192.168、.2、.10(ホストの範囲)
Note that if the SPD entry had an allowed value of wildcard for the source address, then the SAD selector value could be wildcard (any host). Case (a) can be used to prohibit sharing, even among packets that match the same SPD entry.
SPDエントリーにソースアドレスのためのワイルドカードの許容値があるならSADセレクタ価値がワイルドカードであるかもしれないこと(どんなホストも)に注意してください。 同じSPDエントリーに合っているパケットの中でさえ共有するのを禁止するのにケース(a)を使用できます。
As described below in Section 4.4.3, selectors may include "wildcard" entries and hence the selectors for two entries may overlap. (This is analogous to the overlap that arises with ACLs or filter entries in routers or packet filtering firewalls.) Thus, to ensure consistent, predictable processing, SPD entries MUST be ordered and the SPD MUST always be searched in the same order, so that the first matching entry is consistently selected. (This requirement is necessary as the effect of processing traffic against SPD entries must be deterministic, but there is no way to canonicalize SPD entries given the use of wildcards for some selectors.) More detail on matching of packets against SPD entries is provided in Section 5.
以下でセクション4.4.3で説明されるように、セレクタは「ワイルドカード」エントリーを含むかもしれません、そして、したがって、2つのエントリーのためのセレクタは重なるかもしれません。 (これはルータかパケットフィルタリングファイアウォールにACLsかフィルタエントリーで起こるオーバラップに類似しています。) したがって、いつも一貫して、予測できる処理、エントリーを注文しなければならないSPD、およびSPD MUSTを確実にするために、同次で捜されてください、最初の合っているエントリーが一貫して選択されるように。 (SPDエントリーに対する処理トラフィックの効果が決定論的であるに違いないようにこの要件が必要ですが、ワイルドカードのいくつかのセレクタの使用を考えて、canonicalize SPDエントリーへの道が全くありません。) SPDエントリーに対するパケットのマッチングに関するその他の詳細をセクション5に提供します。
Note that if ESP is specified, either (but not both) authentication or encryption can be omitted. So it MUST be possible to configure the SPD value for the authentication or encryption algorithms to be "NULL". However, at least one of these services MUST be selected, i.e., it MUST NOT be possible to configure both of them as "NULL".
超能力が指定されるなら、(ともにない)認証か暗号化のどちらかを省略できることに注意してください。 それで、SPD値は認証か暗号化アルゴリズムが「ヌルであること」を構成するのが可能であるに違いありません。 しかしながら、少なくともこれらのサービスの1つを選択しなければなりません、すなわち、「ヌル」としてそれらの両方を構成するのは可能であるはずがありません。
The SPD can be used to map traffic to specific SAs or SA bundles. Thus it can function both as the reference database for security policy and as the map to existing SAs (or SA bundles). (To accommodate the bypass and discard policies cited above, the SPD also
特定のSAsかSAバンドルにトラフィックを写像するのにSPDを使用できます。 したがって、それは安全保障政策のためのリファレンスデータベースとして地図として既存のSAsに機能できます(SAは荷物をまとめます)。 (迂回を収容して、上で引用された方針、SPDも捨てます。
Kent & Atkinson Standards Track [Page 16] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[16ページ]。
MUST provide a means of mapping traffic to these functions, even though they are not, per se, IPsec processing.) The way in which the SPD operates is different for inbound vs. outbound traffic and it also may differ for host vs. security gateway, BITS, and BITW implementations. Sections 5.1 and 5.2 describe the use of the SPD for outbound and inbound processing, respectively.
IPsecが処理する場合、そういうものとしてそれらがそうでないのにもかかわらずの、これらの機能にトラフィックを写像する手段を提供しなければなりません。) SPDが作動する方法が異なっている、本国行き、また、アウトバウンドトラフィックとそれに対して、セキュリティゲートウェイ、BITS、およびホスト対BITW実装のために異なるかもしれません。 セクション5.1と5.2はそれぞれSPDの外国行きの、そして、本国行きの処理の使用について説明します。
Because a security policy may require that more than one SA be applied to a specified set of traffic, in a specific order, the policy entry in the SPD must preserve these ordering requirements, when present. Thus, it must be possible for an IPsec implementation to determine that an outbound or inbound packet must be processed thorough a sequence of SAs. Conceptually, for outbound processing, one might imagine links (to the SAD) from an SPD entry for which there are active SAs, and each entry would consist of either a single SA or an ordered list of SAs that comprise an SA bundle. When a packet is matched against an SPD entry and there is an existing SA or SA bundle that can be used to carry the traffic, the processing of the packet is controlled by the SA or SA bundle entry on the list. For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA.
安全保障政策が、1SAが指定されたセットのトラフィックに適用されるのを必要とするかもしれないので、特定の順序で、SPDの方針エントリーは要件を命令しながら、これらを保存しなければなりません、存在しているとき。 したがって、IPsec実装が、外国行きの、または、本国行きのパケットがSAsの処理徹底的なa系列であるに違いないことを決定するのは、可能であるに違いありません。 概念的に、外国行きの処理のために、人はアクティブなSAsがあるSPDエントリーからリンク(SADへの)を想像するかもしれません、そして、各エントリーはSAバンドルを包括するSAsの独身のSAか規則正しいリストのどちらかから成るでしょう。 パケットがSPDエントリーに取り組まされて、トラフィックを運ぶのに使用できる既存のSAかSAバンドルがあるとき、パケットの処理はリストの上のSAかSAバンドルエントリーで制御されます。 どの複数のIPsec SAsが適用されていることになっていたらよいかためには本国行きのIPsecパケット、送付先アドレスに基づくルックアップのために、IPsecは議定書を作ります、そして、SPIは独身のSAを特定するはずです。
The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry in the SPD for ESP packets or providing proxy key exchange. In the latter case, the traffic would be internally routed to the key management module in the security gateway.
SPDはIPsecシステムを通したすべてのトラフィックの流れを制御するのに使用されます、セキュリティゲートウェイの後ろの/から実体までのセキュリティとかぎ管理トラフィック(例えば、ISAKMP)を含んでいて。 これは、SPDで明らかにISAKMPトラフィックを説明しなければならなくて、ほかに、それが捨てられることを意味します。 セキュリティゲートウェイがいろいろ暗号化されたパケットの縦断を禁止するかもしれなくて、例えば、有が超能力パケットかプロキシ主要な交換を供給するためのSPDのDISCARDエントリーであることに注意してください。 後者の場合では、トラフィックは内部的にセキュリティゲートウェイのかぎ管理モジュールに発送されるでしょう。
4.4.2 Selectors
4.4.2 セレクタ
An SA (or SA bundle) may be fine-grained or coarse-grained, depending on the selectors used to define the set of traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Protocol and Port fields), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. The following selector parameters MUST be supported for SA management to facilitate control of SA granularity. Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW
SA(SAは荷物をまとめる)はきめ細かに粒状である、または下品であるかもしれません、SAのためにトラフィックのセットを定義するのに使用されるセレクタによって。 例えば、2人のホストの間のすべてのトラフィックを独身のSAを通して運んで、セキュリティー・サービスのユニフォームセットに提供するかもしれません。 あるいはまた、1組のホストの間のトラフィックは複数のSAsの上に広げられるかもしれません、使用されるアプリケーションによって(NextプロトコルとPort分野によって定義されるように)、異なったセキュリティー・サービスが異なったSAsによって提供されている状態で。 同様に、独身のSAで1組のセキュリティゲートウェイの間のすべてのトラフィックを運ぶことができましたか、またはそれぞれの交信しているホスト組のために1SAを割り当てることができました。 SA経営者側がSA粒状のコントロールを容易にするように、以下のセレクタパラメタをサポートしなければなりません。 例えば、超能力ヘッダーがあるパケットの領収書に関するケース、要約のセキュリティゲートウェイかBITWでそれに注意してください。
Kent & Atkinson Standards Track [Page 17] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[17ページ]。
implementation, the transport layer protocol, source/destination ports, and Name (if present) may be "OPAQUE", i.e., inaccessible because of encryption or fragmentation. Note also that both Source and Destination addresses should either be IPv4 or IPv6.
実装、プロトコル、ソース/仕向港、およびName(存在しているなら)トランスポート層は、暗号化か断片化のために「不透明で」、すなわち、近づきがたいかもしれません。 また、SourceとDestinationアドレスの両方がIPv4かIPv6のどちらかであるべきであることに注意してください。
- Destination IP Address (IPv4 or IPv6): this may be a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), a range of addresses (high and low values (inclusive),
address + mask, or a wildcard address. The last three are used
to support more than one destination system sharing the same SA
(e.g., behind a security gateway). Note that this selector is
conceptually different from the "Destination IP Address" field
in the <Destination IP Address, IPsec Protocol, SPI> tuple used
to uniquely identify an SA. When a tunneled packet arrives at
the tunnel endpoint, its SPI/Destination address/Protocol are
used to look up the SA for this packet in the SAD. This
destination address comes from the encapsulating IP header.
Once the packet has been processed according to the tunnel SA
and has come out of the tunnel, its selectors are "looked up" in
the Inbound SPD. The Inbound SPD has a selector called
destination address. This IP destination address is the one in
the inner (encapsulated) IP header. In the case of a
transport'd packet, there will be only one IP header and this
ambiguity does not exist. [REQUIRED for all implementations]
- 送付先IPアドレス(IPv4かIPv6): これはただ一つのIPアドレスであるかもしれません(ユニキャスト(anycast)は(IPv4専用)、またはマルチキャストグループを放送した)、さまざまなアドレス。+がマスク、またはワイルドカードアドレスであると扱ってください。上下の値(包括的な)、最後の3は、1つ以上の目的地のシステム共有が同じSA(例えば、セキュリティゲートウェイの後ろの)であるとサポートするのに使用されます。(このセレクタが<Destination IP Addressの「送付先IPアドレス」分野と概念的に異なっていることに注意してください、IPsecプロトコル、唯一SAを特定するのに使用されるSPI>tuple; トンネルを堀られたパケットがトンネル終点に到着するとき、SPI/目的地アドレス/プロトコルは、このパケットのためにSADでSAを見上げるのに使用されます。この送付先アドレスは要約のIPヘッダーから来ます; パケットがいったんトンネルSAに従って処理されて、トンネルから出て来ると、セレクタはInbound SPDで「見上げられます」。Inbound SPDは送付先アドレスと呼ばれるセレクタを持っています。この受信者IPアドレスは内側(カプセル化される)のIPヘッダーのものです。中では、輸送に関するケースがそうするだろう、パケット1個のIPヘッダーしかないでしょう、そして、このあいまいさは存在していません。[すべての実装のためのREQUIRED]
- Source IP Address(es) (IPv4 or IPv6): this may be a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), range of addresses (high and low values inclusive),
address + mask, or a wildcard address. The last three are used
to support more than one source system sharing the same SA
(e.g., behind a security gateway or in a multihomed host).
[REQUIRED for all implementations]
- ソースIPアドレス(es)(IPv4かIPv6): これはただ一つのIPアドレスであるかもしれません(ユニキャスト(anycast)は(IPv4専用)、またはマルチキャストグループを放送した)、アドレスの範囲、(上下が評価する、包括的である、)、アドレス+マスク、またはワイルドカードアドレス。 最後の3は、1つ以上のソースのシステム共有が同じSA(例えば、セキュリティゲートウェイの後ろ、または、「マルチ-家へ帰」っているホストの)であるとサポートするのに使用されます。 [すべての実装のためのREQUIRED]
- Name: There are 2 cases (Note that these name forms are
supported in the IPsec DOI.)
1. User ID
a. a fully qualified user name string (DNS), e.g.,
mozart@foo.bar.com
b. X.500 distinguished name, e.g., C = US, SP = MA,
O = GTE Internetworking, CN = Stephen T. Kent.
2. System name (host, security gateway, etc.)
a. a fully qualified DNS name, e.g., foo.bar.com
b. X.500 distinguished name
c. X.500 general name
- 以下を命名してください。 2つのケースがあります(これらの名前フォームがIPsec DOIでサポートされることに注意してください。)。 1. 完全に適切なユーザ名が結ぶユーザID a.(DNS)、例えば、 mozart@foo.bar.com b。 X.500分類名、例えば、Cは米国、SP=MAと等しく、OはGTE Internetworking、スティーブン・T.CN=ケントと等しいです。 2. 完全に適切なDNSが命名するシステム名(ホスト、セキュリティゲートウェイなど)のa.、例えば、foo.bar.com b。 X.500分類名c。 X.500一般名
NOTE: One of the possible values of this selector is "OPAQUE".
以下に注意してください。 このセレクタの可能な値の1つは「不透明です」。
Kent & Atkinson Standards Track [Page 18] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[18ページ]。
[REQUIRED for the following cases. Note that support for name
forms other than addresses is not required for manually keyed
SAs.
o User ID
- native host implementations
- BITW and BITS implementations acting as HOSTS
with only one user
- security gateway implementations for INBOUND
processing.
o System names -- all implementations]
[以下のケースのためのREQUIRED。 アドレス以外の名前形式のサポートはUser ID--ネイティブのホスト導入--手動で合わせられたSAs o BITWに必要でないというメモとHOSTSとして1人のユーザだけ--INBOUND処理o System名のためのセキュリティゲートウェイ実装--すべての実装で機能するBITS実装]
- Data sensitivity level: (IPSO/CIPSO labels)
[REQUIRED for all systems providing information flow security as
per Section 8, OPTIONAL for all other systems.]
- データ感度レベル: (IPSO/CIPSOラベル) [セクション8、OPTIONALに従って情報流れセキュリティを他のすべてのシステムに供給するすべてのシステムのためのREQUIRED。]
- Transport Layer Protocol: Obtained from the IPv4 "Protocol" or
the IPv6 "Next Header" fields. This may be an individual
protocol number. These packet fields may not contain the
Transport Protocol due to the presence of IP extension headers,
e.g., a Routing Header, AH, ESP, Fragmentation Header,
Destination Options, Hop-by-hop options, etc. Note that the
Transport Protocol may not be available in the case of receipt
of a packet with an ESP header, thus a value of "OPAQUE" SHOULD
be supported.
[REQUIRED for all implementations]
- 層のプロトコルを輸送してください: IPv4「プロトコル」かIPv6「次のヘッダー」分野から、得ます。 これは個々のプロトコル番号であるかもしれません。 これらのパケット分野はIP拡張ヘッダー、例えば、ルート設定Header、AH、超能力、Fragmentation Header、Destination Options、ホップによるHopオプションなどの存在のためTransportプロトコルを含まないかもしれません。 Transportプロトコルが超能力ヘッダーがあるパケットの領収書の場合で利用可能でないかもしれないというメモ、その結果、「不透明なもの」の値はサポートされるべきです。 [すべての実装のためのREQUIRED]
NOTE: To locate the transport protocol, a system has to chain
through the packet headers checking the "Protocol" or "Next
Header" field until it encounters either one it recognizes as a
transport protocol, or until it reaches one that isn't on its
list of extension headers, or until it encounters an ESP header
that renders the transport protocol opaque.
以下に注意してください。 トランスポート・プロトコルの場所を見つけるように、システムはトランスポート・プロトコルとして認識するどちらかに遭遇するか、拡張ヘッダーのリストにないものに達する、またはトランスポート・プロトコルを不透明に表す超能力ヘッダーに遭遇するまで「プロトコル」か「次のヘッダー」分野をチェックするパケットのヘッダーを通して鎖を作らなければなりません。
- Source and Destination (e.g., TCP/UDP) Ports: These may be
individual UDP or TCP port values or a wildcard port. (The use
of the Next Protocol field and the Source and/or Destination
Port fields (in conjunction with the Source and/or Destination
Address fields), as an SA selector is sometimes referred to as
"session-oriented keying."). Note that the source and
destination ports may not be available in the case of receipt of
a packet with an ESP header, thus a value of "OPAQUE" SHOULD be
supported.
- ソースと目的地(例えば、TCP/UDP)港: これらは、個々のUDP、TCPポート値またはワイルドカードポートであるかもしれません。 (SAセレクタが時々「セッション指向の合わせる」と呼ばれるようにプロトコルの分野とSource、そして/または、Destination Portがさばく(Source、そして/または、Destination Address分野に関連して)Nextの使用。) ソースと仕向港が超能力ヘッダーがあるパケットの領収書の場合で手があかないかもしれないというメモ、その結果、「不透明なもの」の値はサポートされるべきです。
The following table summarizes the relationship between the
"Next Header" value in the packet and SPD and the derived Port
Selector value for the SPD and SAD.
以下のテーブルはSPDとSADのためにパケットとSPDの「次のヘッダー」値と派生しているPort Selector値との関係をまとめます。
Kent & Atkinson Standards Track [Page 19] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[19ページ]。
Next Hdr Transport Layer Derived Port Selector Field
in Packet Protocol in SPD Value in SPD and SAD
-------- --------------- ---------------------------
ESP ESP or ANY ANY (i.e., don't look at it)
-don't care- ANY ANY (i.e., don't look at it)
specific value specific value NOT ANY (i.e., drop packet)
fragment
specific value specific value actual port selector field
not fragment
次のHdrトランスポート層はSPDで悲しいところのSPD値におけるパケットプロトコルのポートセレクタ分野を引き出しました。-------- --------------- --------------------------- 超能力、超能力かいずれも少しもしない、(すなわち、それを見ません)少しも実際のポートセレクタ分野が断片化しないどんな(すなわち、パケットを下げます)断片詳細の値の特定の価値ではなく、あらゆる(すなわち、それを見ません)特定の価値の特定の値についても気にかけてください。
If the packet has been fragmented, then the port information may
not be available in the current fragment. If so, discard the
fragment. An ICMP PMTU should be sent for the first fragment,
which will have the port information. [MAY be supported]
パケットが断片化されたなら、ポート情報は現在の断片で利用可能でないかもしれません。 そうだとすれば、断片を捨ててください。 最初の断片のためにICMP PMTUを送るべきです。(それは、ポート情報を持つでしょう)。 [サポートされるかもしれません]
The IPsec implementation context determines how selectors are used. For example, a host implementation integrated into the stack may make use of a socket interface. When a new connection is established the SPD can be consulted and an SA (or SA bundle) bound to the socket. Thus traffic sent via that socket need not result in additional lookups to the SPD/SAD. In contrast, a BITS, BITW, or security gateway implementation needs to look at each packet and perform an SPD/SAD lookup based on the selectors. The allowable values for the selector fields differ between the traffic flow, the security association, and the security policy.
IPsec実装文脈は、セレクタがどのように使用されているかを決定します。 例えば、スタックと統合されたホスト導入はソケットインタフェースを利用するかもしれません。 新しい接続が確立されるとき、SPDに相談できました、そして、SA(SAは荷物をまとめる)はソケットに付きました。 したがって、そのソケットを通して送られたトラフィックはSPD/SADへの追加ルックアップをもたらす必要はありません。 対照的に、BITS、BITW、または各パケットを見て、SPD/SADルックアップを実行するセキュリティゲートウェイ実装の必要性がセレクタを基礎づけました。 セレクタ分野への許容量は交通の流れと、セキュリティ協会と、安全保障政策の間で異なります。
The following table summarizes the kinds of entries that one needs to be able to express in the SPD and SAD. It shows how they relate to the fields in data traffic being subjected to IPsec screening. (Note: the "wild" or "wildcard" entry for src and dst addresses includes a mask, range, etc.)
以下のテーブルは人がSPDとSADで言い表すことができる必要があるエントリーの種類をまとめます。 それは、それらがデータ通信量でどう分野に関連するかがIPsec選別にかけられるのを示します。 (注意: srcとdstアドレスのための「荒野」か「ワイルドカード」エントリーはマスク、範囲などを含んでいます)
Field Traffic Value SAD Entry SPD Entry -------- ------------- ---------------- -------------------- src addr single IP addr single,range,wild single,range,wildcard dst addr single IP addr single,range,wild single,range,wildcard xpt protocol* xpt protocol single,wildcard single,wildcard src port* single src port single,wildcard single,wildcard dst port* single dst port single,wildcard single,wildcard user id* single user id single,wildcard single,wildcard sec. labels single value single,wildcard single,wildcard
分野トラフィックは悲しいエントリーSPDエントリーを評価します。-------- ------------- ---------------- -------------------- 単一のIP addrが選抜するsrc addr、範囲、ワイルドなシングル、範囲、ワイルドカードのdst addrのただ一つのIP addrシングル、範囲、ワイルドなシングル、範囲、ワイルドカードxptプロトコル*xptプロトコルシングル、ワイルドカードシングル、ワイルドカードsrcポート*シングルsrcポートシングル、ワイルドカードシングル、ワイルドカードdstポート*シングルdstポートシングル、ワイルドカードシングル、ワイルドカードユーザのイド*シングルユーザーのイドシングル、ワイルドカードシングル、ワイルドカード秒はただ一つの値を単一であるとラベルします、ワイルドカードシングル、ワイルドカード
* The SAD and SPD entries for these fields could be "OPAQUE"
because the traffic value is encrypted.
* トラフィック値が暗号化されているので、これらの分野のためのSADとSPDエントリーは「不透明であることができました」。
NOTE: In principle, one could have selectors and/or selector values in the SPD which cannot be negotiated for an SA or SA bundle. Examples might include selector values used to select traffic for
以下に注意してください。 原則として、1つはSAかSAバンドルのために交渉できないSPDにセレクタ、そして/または、セレクタ値を持っているかもしれません。 例はトラフィックを選択するのにおいて中古のセレクタ値を含むかもしれません。
Kent & Atkinson Standards Track [Page 20] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[20ページ]。
discarding or enumerated lists which cause a separate SA to be created for each item on the list. For now, this is left for future versions of this document and the list of required selectors and selector values is the same for the SPD and the SAD. However, it is acceptable to have an administrative interface that supports use of selector values which cannot be negotiated provided that it does not mislead the user into believing it is creating an SA with these selector values. For example, the interface may allow the user to specify an enumerated list of values but would result in the creation of a separate policy and SA for each item on the list. A vendor might support such an interface to make it easier for its customers to specify clear and concise policy specifications.
各個条のためにリストで別々のSAを作成させる捨てるか列挙されたリスト。 当分、これはこのドキュメントの将来のバージョンに残されます、そして、SPDとSADに、必要なセレクタとセレクタ値のリストは同じです。 しかしながら、これらのセレクタ値でSAを作成していると信じているのにユーザをミスリードしなければ交渉できないセレクタ値の使用をサポートする管理インタフェースを持っているのは許容できます。 例えば、インタフェースは、ユーザが値の列挙されたリストを指定するのを許容するかもしれませんが、リストで各個条のための別々の方針とSAの作成をもたらすでしょう。 ベンダーは、顧客が明確で簡潔な方針仕様を指定するのをより簡単にするようにそのようなインタフェースをサポートするかもしれません。
4.4.3 Security Association Database (SAD)
4.4.3 セキュリティ協会データベース(悲しい)です。
In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, the implementation creates an appropriate SA (or SA Bundle) and links the SPD entry to the SAD entry (see Section 5.1.1). For inbound processing, each entry in the SAD is indexed by a destination IP address, IPsec protocol type, and SPI. The following parameters are associated with each entry in the SAD. This description does not purport to be a MIB, but only a specification of the minimal data items required to support an SA in an IPsec implementation.
それぞれのIPsec実装には、名目上のSecurity Association Databaseがあります。(そこでは、各エントリーが1SAに関連しているパラメタを定義します)。 各SAはSADにエントリーを持っています。 外国行きの処理において、エントリーはSPDにエントリーで示されます。 SPDエントリーが現在パケットに、適切なSAを示さないなら、実装が適切なSA(または、SA Bundle)を作成して、SPDエントリーをSADエントリーにリンクすることに注意してください(セクション5.1.1を見てください)。 本国行きの処理において、SADの各エントリーは送付先IPアドレス、IPsecプロトコルタイプ、およびSPIによって索引をつけられます。 以下のパラメタはSADの各エントリーに関連しています。 この記述は、MIBであることを意味しませんが、最小量のデータ項目の仕様だけがIPsec実装でSAをサポートするのが必要です。
For inbound processing: The following packet fields are used to look up the SA in the SAD:
本国行きの処理のために: 以下のパケット分野はSADでSAを見上げるのに使用されます:
o Outer Header's Destination IP address: the IPv4 or IPv6
Destination address.
[REQUIRED for all implementations]
o IPsec Protocol: AH or ESP, used as an index for SA lookup
in this database. Specifies the IPsec protocol to be
applied to the traffic on this SA.
[REQUIRED for all implementations]
o SPI: the 32-bit value used to distinguish among different
SAs terminating at the same destination and using the same
IPsec protocol.
[REQUIRED for all implementations]
o 外側のHeaderのDestination IPアドレス: IPv4かIPv6 Destinationアドレス。 [すべての実装のためのREQUIRED] o IPsecプロトコル: このデータベースのSAルックアップにインデックスとして使用されるAHか超能力。 このSAの上のトラフィックに適用されるためにIPsecプロトコルを指定します。 [すべての実装のためのREQUIRED] o SPI: 32ビットの値は、以前は異なったSAsの中で同じ目的地で終わって、同じIPsecプロトコルを使用することでよく区別されていました。 [すべての実装のためのREQUIRED]
For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA
セクション4.4.2、SAD MUSTのSAエントリーで定義されたそれぞれのセレクタに関しては、SAが作成されたとき交渉された値か値を含んでください。 送付者に関しては、これらの値は、使用に、与えられたSAが外国行きのパケットで適切であるかどうか決めるのに使用されます。 これは既存のSAがあるかどうか確認するためにチェックする一部です。
Kent & Atkinson Standards Track [Page 21] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[21ページ]。
that can be used. For the receiver, these values are used to check that the selector values in an inbound packet match those for the SA (and thus indirectly those for the matching policy). For the receiver, this is part of verifying that the SA was appropriate for this packet. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, wildcards, or "OPAQUE" as described in section 4.4.2, "Selectors". Note that for an ESP SA, the encryption algorithm or the authentication algorithm could be "NULL". However they MUST not both be "NULL".
それを使用できます。 受信機に関しては、これらの値が本国行きのパケットのセレクタ値がSAのためのそれらに合っているのをチェックするのに使用される、(その結果、間接的である、合っている方針のためのそれら) 受信機に関しては、これはこのパケットに、SAが適切であったことを確かめる一部です。 (規則に関してICMPメッセージに関してセクション6を見てください。) これらの分野は特定の値、範囲、ワイルドカード、またはセクション4.4で説明される「不透明なもの」.2のフォーム、「セレクタ」を持つことができます。 暗号化アルゴリズムか認証アルゴリズムが超能力SAに関して、「ヌルであることができた」と述べてください。 しかしながら、それらはともに「ヌルであってはいけません」。
The following SAD fields are used in doing IPsec processing:
以下のSAD分野はIPsecに処理をする際に使用されます:
o Sequence Number Counter: a 32-bit value used to generate the
Sequence Number field in AH or ESP headers.
[REQUIRED for all implementations, but used only for outbound
traffic.]
o Sequence Counter Overflow: a flag indicating whether overflow
of the Sequence Number Counter should generate an auditable
event and prevent transmission of additional packets on the
SA.
[REQUIRED for all implementations, but used only for outbound
traffic.]
o Anti-Replay Window: a 32-bit counter and a bit-map (or
equivalent) used to determine whether an inbound AH or ESP
packet is a replay.
[REQUIRED for all implementations but used only for inbound
traffic. NOTE: If anti-replay has been disabled by the
receiver, e.g., in the case of a manually keyed SA, then the
Anti-Replay Window is not used.]
o AH Authentication algorithm, keys, etc.
[REQUIRED for AH implementations]
o ESP Encryption algorithm, keys, IV mode, IV, etc.
[REQUIRED for ESP implementations]
o ESP authentication algorithm, keys, etc. If the
authentication service is not selected, this field will be
null.
[REQUIRED for ESP implementations]
o Lifetime of this Security Association: a time interval after
which an SA must be replaced with a new SA (and new SPI) or
terminated, plus an indication of which of these actions
should occur. This may be expressed as a time or byte count,
or a simultaneous use of both, the first lifetime to expire
taking precedence. A compliant implementation MUST support
both types of lifetimes, and must support a simultaneous use
of both. If time is employed, and if IKE employs X.509
certificates for SA establishment, the SA lifetime must be
constrained by the validity intervals of the certificates,
and the NextIssueDate of the CRLs used in the IKE exchange
o 一連番号カウンタ: 32ビットの値は以前はよくAHか超能力ヘッダーのSequence Number分野を生成していました。 [REQUIRED、すべての実装にもかかわらず、アウトバウンドトラフィック] o Sequence Counter Overflowだけに中古: Sequence Number Counterのオーバーフローが監査可能イベントを生成して、SAにおける追加パケットのトランスミッションを防ぐべきであるかどうかを示す旗。 [REQUIRED、すべての実装にもかかわらず、アウトバウンドトラフィック] o Anti-再生Windowだけに中古: 32ビットは、再生に対抗して、本国行きのAHか超能力パケットがそうかどうか決定するのに使用されて、少し写像します(または、同等物)。 [REQUIRED、すべての実装にもかかわらず、インバウンドトラフィックだけにおいて、使用されています。 以下に注意してください。 反再生が例えば、手動で合わせられたSAの場合における受信機によって無効にされたなら、Anti-再生Windowは使用されていません。] o AH Authenticationアルゴリズム、キーなど [AH実装のためのREQUIRED] o超能力Encryptionアルゴリズム、キー、IVモード、IVなど [超能力実装のためのREQUIRED] o超能力認証アルゴリズム、キーなど 認証サービスが選択されないと、この分野はヌルになるでしょう。 [超能力実装のためのREQUIRED] このSecurity Associationのo Lifetime: SAを新しいSA(そして、新しいSPI)に取り替えなければならないか、または終えなければならない時間間隔、およびこれらの動作のどれが起こるべきであるかしるし。 これは時間、バイト・カウント、または両方(優先しながら期限が切れる最初の生涯)の同時の使用として言い表されるかもしれません。 対応する実装は、両方のタイプの生涯をサポートしなければならなくて、両方の同時の使用をサポートしなければなりません。 時間が採用していて、IKEがSA設立のためのX.509証明書を使うなら、証明書の正当性間隔、およびIKE交換に使用されるCRLsのNextIssueDateはSA生涯を抑制しなければなりません。
Kent & Atkinson Standards Track [Page 22] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[22ページ]。
for the SA. Both initiator and responder are responsible for
constraining SA lifetime in this fashion.
[REQUIRED for all implementations]
SAのために。 創始者と応答者の両方がこんなやり方でSA生涯を抑制するのに責任があります。 [すべての実装のためのREQUIRED]
NOTE: The details of how to handle the refreshing of keys
when SAs expire is a local matter. However, one reasonable
approach is:
(a) If byte count is used, then the implementation
SHOULD count the number of bytes to which the IPsec
algorithm is applied. For ESP, this is the encryption
algorithm (including Null encryption) and for AH,
this is the authentication algorithm. This includes
pad bytes, etc. Note that implementations SHOULD be
able to handle having the counters at the ends of an
SA get out of synch, e.g., because of packet loss or
because the implementations at each end of the SA
aren't doing things the same way.
(b) There SHOULD be two kinds of lifetime -- a soft
lifetime which warns the implementation to initiate
action such as setting up a replacement SA and a
hard lifetime when the current SA ends.
(c) If the entire packet does not get delivered during
the SAs lifetime, the packet SHOULD be discarded.
以下に注意してください。 SAsが期限が切れるとき、どうキーのリフレッシュを扱うかに関する詳細は地域にかかわる事柄です。 しかしながら、1つの合理的なアプローチは以下の通りです。 (a) バイト・カウントが使用されているなら、実装SHOULDはIPsecアルゴリズムが適用されているバイト数を数えます。 超能力に関しては、これは暗号化アルゴリズム(Null暗号化を含んでいて)です、そして、AHに関する、認証アルゴリズムです。 これはパッドバイトなどを含んでいます。 実装SHOULDがSAの端のカウンタが同時性から持ち始めるのを扱うことができることに注意してください、例えば、パケット損失のため、またはSAの各端の実装が同じようにことをしないことであるので。 (b) そこ、SHOULD、2種類の生涯になってください--現在のSAが終わるとSAと困難な生涯を交換に決めるのなどように行動を開始するように実装に警告する柔らかい生涯。 (c) 全体のパケットがSAs生涯、パケットSHOULDの間、提供されないなら、捨てられてください。
o IPsec protocol mode: tunnel, transport or wildcard.
Indicates which mode of AH or ESP is applied to traffic on
this SA. Note that if this field is "wildcard" at the
sending end of the SA, then the application has to specify
the mode to the IPsec implementation. This use of wildcard
allows the same SA to be used for either tunnel or transport
mode traffic on a per packet basis, e.g., by different
sockets. The receiver does not need to know the mode in
order to properly process the packet's IPsec headers.
o IPsecはモードを議定書の中で述べます: トンネル、輸送またはワイルドカード。 AHか超能力のどのモードがこのSAでトラフィックに適用されるかを示します。 アプリケーションがこの分野がSAの送信側の「ワイルドカード」であるならIPsec実装にモードを指定しなければならないことに注意してください。 ワイルドカードのこの使用は、同じSAがトンネルか交通機関トラフィックのどちらかにパケット基礎あたりのaで使用されるのを許容します、例えば、異なったソケットで。 受信機は、適切にパケットのIPsecヘッダーを処理するためにモードを知る必要はありません。
[REQUIRED as follows, unless implicitly defined by context:
- host implementations must support all modes
- gateway implementations must support tunnel mode]
[以下のREQUIRED: --実装がすべてのモードをサポートしなければならないホスト--ゲートウェイ実装がトンネルモードをサポートしなければならない文脈によってそれとなく定義されない場合
NOTE: The use of wildcard for the protocol mode of an inbound
SA may add complexity to the situation in the receiver (host
only). Since the packets on such an SA could be delivered in
either tunnel or transport mode, the security of an incoming
packet could depend in part on which mode had been used to
deliver it. If, as a result, an application cared about the
SA mode of a given packet, then the application would need a
mechanism to obtain this mode information.
以下に注意してください。 ワイルドカードの本国行きのSAのプロトコルモードの使用は受信機(ホスト専用)の状況に複雑さを加えるかもしれません。 トンネルか交通機関のどちらかでそのようなSAの上のパケットを提供できるでしょう、したがって、入って来るパケットのセキュリティはどのモードがそれを提供するのに使用されたかに一部依存できました。 その結果、アプリケーションが与えられたパケットのSAモードを心配するなら、アプリケーションは、このモード情報を得るためにメカニズムを必要とするでしょうに。
Kent & Atkinson Standards Track [Page 23] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[23ページ]。
o Path MTU: any observed path MTU and aging variables. See
Section 6.1.2.4
[REQUIRED for all implementations but used only for outbound
traffic]
o 経路MTU: いずれも経路MTUと古い変数を観測しました。 .4は、6.1に.2を区分するのを見ます。[REQUIRED、アウトバウンドトラフィックだけにすべての実装にもかかわらず、中古である、]
4.5 Basic Combinations of Security Associations
4.5 セキュリティ協会の基本的な組み合わせ
This section describes four examples of combinations of security associations that MUST be supported by compliant IPsec hosts or security gateways. Additional combinations of AH and/or ESP in tunnel and/or transport modes MAY be supported at the discretion of the implementor. Compliant implementations MUST be capable of generating these four combinations and on receipt, of processing them, but SHOULD be able to receive and process any combination. The diagrams and text below describe the basic cases. The legend for the diagrams is:
このセクションは言いなりになっているIPsecホストかセキュリティゲートウェイでサポートしなければならないセキュリティ協会の組み合わせに関する4つの例について説明します。 トンネル、そして/または、交通機関におけるAH、そして/または、超能力の追加組み合わせは作成者の裁量でサポートされるかもしれません。 対応する実装は、どんな組み合わせもこれらの4つの組み合わせを生成することができて、受け取って、それら、しかし、SHOULDを処理する領収書で処理できなければなりません。 以下のダイヤグラムとテキストは基本的なケースについて説明します。 ダイヤグラムのための伝説は以下の通りです。
==== = one or more security associations (AH or ESP, transport
or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx = host x
SGx = security gateway x
X* = X supports IPsec
==== = 1つ以上のセキュリティ協会(AH、超能力、輸送またはトンネル)---- = セキュリティゲートウェイxホストx接続性(そのようにラベルされて、管理の境界であるなら)Hx=SGx=X*=XはIPsecをサポートします。
NOTE: The security associations below can be either AH or ESP. The mode (tunnel vs transport) is determined by the nature of the endpoints. For host-to-host SAs, the mode can be either transport or tunnel.
以下に注意してください。 以下のセキュリティ協会は、AHか超能力のどちらかであるかもしれません。 モード(輸送に対してトンネルを堀る)は終点の自然で決定します。 ホストからホストへのSAsに関しては、モードは、輸送かトンネルのどちらかであるかもしれません。
Case 1. The case of providing end-to-end security between 2 hosts
across the Internet (or an Intranet).
1をケースに入れてください。 インターネット(または、イントラネット)中の2人のホストの間に終わりから終わりへのセキュリティを提供するケース。
====================================
| |
H1* ------ (Inter/Intranet) ------ H2*
==================================== | | H1*------ (間の/イントラネット) ------ H2*
Note that either transport or tunnel mode can be selected by the
hosts. So the headers in a packet between H1 and H2 could look
like any of the following:
ホストが輸送かトンネルモードのどちらかを選択できることに注意してください。 それで、H1とH2の間のパケットのヘッダーは以下のどれかに似ることができました:
Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]
輸送トンネル----------------- --------------------- 1. [IP1][ああ][上側]の4。 [IP2][ああ][IP1][上側]の2。 [IP1][超能力][上側]の5。 [IP2][超能力][IP1][上側]の3。 [IP1][ああ][超能力][上側]です。
Kent & Atkinson Standards Track [Page 24] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[24ページ]。
Note that there is no requirement to support general nesting,
but in transport mode, both AH and ESP can be applied to the
packet. In this event, the SA establishment procedure MUST
ensure that first ESP, then AH are applied to the packet.
一般的な巣篭もりをサポートするという要件が全くありませんが、交通機関で、AHと超能力の両方をパケットに適用できることに注意してください。 このイベントでは、SA設立手順はその最初の超能力を確実にしなければならなくて、次に、AHはパケットに当てはまられています。
Case 2. This case illustrates simple virtual private networks
support.
2をケースに入れてください。 本件は簡単な仮想私設網サポートを例証します。
===========================
| |
---------------------|---- ---|-----------------------
| | | | | |
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
=========================== | | ---------------------|---- ---|----------------------- | | | | | | | H1--、(地方の--- SG1*、|、-、--、(インターネット)、-、--、| SG2*、-、--、(地方の--- H2| | イントラネット) | | イントラネット)| -------------------------- --------------------------- アドミン境界アドミン境界
Only tunnel mode is required here. So the headers in a packet
between SG1 and SG2 could look like either of the following:
トンネルモードだけがここで必要です。 それで、SG1とSG2の間のパケットのヘッダーは以下のどちらかに似ることができました:
Tunnel
---------------------
4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]
トンネル--------------------- 4. [IP2][ああ][IP1][上側]の5。 [IP2][超能力][IP1][上側]です。
Case 3. This case combines cases 1 and 2, adding end-to-end security
between the sending and receiving hosts. It imposes no new
requirements on the hosts or security gateways, other than a
requirement for a security gateway to be configurable to pass
IPsec traffic (including ISAKMP traffic) for hosts behind it.
3をケースに入れてください。 発信と受信ホストの間の終わりから終わりへのセキュリティを加えて、本件はケース1と2を結合します。 それはホストかセキュリティゲートウェイにどんな新しい要件も課しません、セキュリティゲートウェイがそれの後ろのホストのために、トラフィック(ISAKMPトラフィックを含んでいる)をIPsecに通過するのにおいて構成可能であるという要件を除いて。
===============================================================
| |
| ========================= |
| | | |
---|-----------------|---- ---|-------------------|---
| | | | | | | |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
=============================================================== | | | ========================= | | | | | ---|-----------------|---- ---|-------------------|--- | | | | | | | | | H1*--、(地方の--- SG1*| | --(インターネット)--SG2*、-、--、(地方の--- H2*| | イントラネット) | | イントラネット)| -------------------------- --------------------------- アドミン境界アドミン境界
Case 4. This covers the situation where a remote host (H1) uses the
Internet to reach an organization's firewall (SG2) and to then
gain access to some server or other machine (H2). The remote
host could be a mobile host (H1) dialing up to a local PPP/ARA
server (not shown) on the Internet and then crossing the
Internet to the home organization's firewall (SG2), etc. The
4をケースに入れてください。 これはリモートホスト(H1)が組織のファイアウォール(SG2)に達して、次に、何らかのサーバか他のマシン(H2)へのアクセスを得るのにインターネットを使用する状況をカバーしています。 リモートホストはインターネットでローカルのPPP/ARAサーバ(目立たない)までダイヤルして、次にホーム組織のファイアウォール(SG2)などとインターネットに交差するモバイルホスト(H1)であるかもしれません。 The
Kent & Atkinson Standards Track [Page 25] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[25ページ]。
details of support for this case, (how H1 locates SG2,
authenticates it, and verifies its authorization to represent
H2) are discussed in Section 4.6.3, "Locating a Security
Gateway".
セクション4.6.3で議論して、「セキュリティゲートウェイの場所を見つけ」て(H1はH2を表すためにどうSG2の場所を見つけて、それを認証して、承認について確かめるか)、このような場合サポートについて詳しく述べます。
======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA server
====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1*----- (インターネット) ------| SG2*---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ ダイアルアップアドミンPPP/ARAサーバへの境界であるかもしれません(任意の)。
Only tunnel mode is required between H1 and SG2. So the choices
for the SA between H1 and SG2 would be one of the ones in case
2. The choices for the SA between H1 and H2 would be one of the
ones in case 1.
トンネルモードだけがH1とSG2の間で必要です。 それで、H1とSG2の間のSAのための選択は場合2におけるものの1つでしょう。 H1とH2の間のSAのための選択は場合1におけるものの1つでしょう。
Note that in this case, the sender MUST apply the transport
header before the tunnel header. Therefore the management
interface to the IPsec implementation MUST support configuration
of the SPD and SAD to ensure this ordering of IPsec header
application.
この場合送付者がトンネルヘッダーの前で輸送ヘッダーを適用しなければならないことに注意してください。 したがって、IPsec実装への管理インタフェースは、IPsecヘッダーアプリケーションのこの注文を確実にするためにSPDとSADの構成をサポートしなければなりません。
As noted above, support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability.
上で述べたように、AHと超能力の追加組み合わせのサポートは任意です。 他の、そして、任意の組み合わせの使用は相互運用性に悪影響を与えるかもしれません。
4.6 SA and Key Management
4.6 SAとKey Management
IPsec mandates support for both manual and automated SA and cryptographic key management. The IPsec protocols, AH and ESP, are largely independent of the associated SA management techniques, although the techniques involved do affect some of the security services offered by the protocols. For example, the optional anti- replay services available for AH and ESP require automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. (See also a discussion of this issue in Section 4.7.) In general, data origin authentication in AH and ESP is limited by the extent to which secrets used with the authentication algorithm (or with a key management protocol that creates such secrets) are shared among multiple possible sources.
IPsec命令は、両方のために手動の、そして、自動化されたSAと暗号化キーが管理であるとサポートします。 IPsecプロトコル(AHと超能力)は、関連SA管理技術から主に独立しています、かかわったテクニックがプロトコルによって提供されたセキュリティー・サービスのいくつかに影響しますが。 例えば、AHと超能力に利用可能な任意の反再生サービスは自動化されたSA管理を必要とします。 そのうえ、IPsecと共に使われた主要な分配の粒状は、認証の粒状が提供されたことを決定します。 (また、セクション4.7における、この問題の議論を見てください。) 一般に、AHと超能力におけるデータ発生源認証は認証アルゴリズム(またはそのような秘密を作成するかぎ管理プロトコルで)で使用される秘密が複数の可能なソースの中で共有される範囲によって制限されます。
Kent & Atkinson Standards Track [Page 26] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[26ページ]。
The following text describes the minimum requirements for both types of SA management.
以下のテキストは両方のタイプのSA管理のために必要最小限について説明します。
4.6.1 Manual Techniques
4.6.1 手動のテクニック
The simplest form of management is manual management, in which a person manually configures each system with keying material and security association management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. For example, a company could create a Virtual Private Network (VPN) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this is likely to be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist.
最も簡単な形式の管理は手動の管理です。(材料を合わせて、セキュリティ協会管理データが関連していた状態で、人は、他のシステムとのコミュニケーションを保証するためにそれで手動で各システムを構成します)。手動のテクニックは小さくて、静的な環境で実用的ですが、それらはよく比例しません。 例えば、会社は、いくつかのサイトでセキュリティゲートウェイでIPsecを使用することでVirtual兵士のNetwork(VPN)を作成できるでしょう。 サイトの数が少なく、すべてのサイトがただ一つの管理ドメインの範囲に該当するので、これは手動の管理技術のための可能な文脈である傾向があります。 この場合、セキュリティゲートウェイは、他の目的地にトラフィックを保護していない間、組織の中にサイトと他のサイトから手動で構成されたキーを使用することでトラフィックを選択的に保護するかもしれません。 また、選択されるだけであるならコミュニケーションが、機密保護される必要があるのも、適切であるかもしれません。 同様の議論は完全に少ない数のホスト、そして/または、ゲートウェイのための組織の中でIPsecの使用に適用されるかもしれません。 また、別の選択肢は存在していますが、手動の管理技術はしばしば静的に構成されて、左右対称のキーを使います。
4.6.2 Automated SA and Key Management
4.6.2 自動化されたSAとKey Management
Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.)
IPsecの広範囲の展開と使用はインターネット標準の、そして、スケーラブルで、自動化されたSA管理プロトコルを必要とします。 そのようなサポートがAHと超能力の反再生機能の使用を容易にして、SAsの要求次第の作成を収容するのに必要です、例えば、ユーザとセッション指向の合わせるために。 (概念SAが"「再-合わせ」る"であるが実際に新しいSPI(一般に、自動化されたSA/かぎ管理プロトコルの使用を含意するプロセス)と共に新しいSAの作成を含意することに注意します)
The default automated key management protocol selected for use with IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of interpretation [Pip98]. Other automated SA management protocols MAY be employed.
自動化された主要な管理プロトコルがIPsecとの使用のために選択したデフォルトは解釈[Pip98]のIPsecドメインの下でイケ[MSST97、Orm97、HC98]です。 他の自動化されたSA管理プロトコルは使われるかもしれません。
When an automated SA/key management protocol is employed, the output from this protocol may be used to generate multiple keys, e.g., for a single ESP SA. This may arise because:
自動化されたSA/かぎ管理プロトコルが採用しているとき、このプロトコルからの出力は複数のキーを生成するのに使用されるかもしれません、例えば、独身のESP SAのために。 これが起こるかもしれない、:
o the encryption algorithm uses multiple keys (e.g., triple DES)
o the authentication algorithm uses multiple keys
o both encryption and authentication algorithms are employed
o 暗号化アルゴリズムが○ 認証アルゴリズム用途倍数が合わせる○の複数のキー(例えば、三重のDES)両方を使用する、暗号化と認証アルゴリズムは採用しています。
Kent & Atkinson Standards Track [Page 27] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[27ページ]。
The Key Management System may provide a separate string of bits for each key or it may generate one string of bits from which all of them are extracted. If a single string of bits is provided, care needs to be taken to ensure that the parts of the system that map the string of bits to the required keys do so in the same fashion at both ends of the SA. To ensure that the IPsec implementations at each end of the SA use the same bits for the same keys, and irrespective of which part of the system divides the string of bits into individual keys, the encryption key(s) MUST be taken from the first (left-most, high- order) bits and the authentication key(s) MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant algorithm specification RFC. In the case of multiple encryption keys or multiple authentication keys, the specification for the algorithm must specify the order in which they are to be selected from a single string of bits provided to the algorithm.
Key Management Systemがビットの別々のストリングを各キーに供給するかもしれませんか、またはそれはそれらのすべてが抽出されるビットの1個のストリングを生成するかもしれません。 ビットの一連を提供するなら、注意は、ビットのストリングを必要なキーに写像するシステムの部分がSAの両端で同じファッションでそうするのを保証するために取られる必要があります。 SAの各端のIPsec実装を同じキーに同じビットを使用して、システムのどの部分がビットのストリングを個々のキー、暗号化キーに分割するかの如何にかかわらず最初(最も左、高いオーダー)のビットと認証から取らなければならないのを保証するために、残っているビットからキーを取らなければなりません。 各キーのためのビットの数は関連アルゴリズム仕様RFCで定義されます。 複数の暗号化キーか複数の認証キーの場合では、アルゴリズムのための仕様はそれらがアルゴリズムに提供されたビットの一連から選択されることになっているオーダーを指定しなければなりません。
4.6.3 Locating a Security Gateway
4.6.3 セキュリティゲートウェイの場所を見つけること。
This section discusses issues relating to how a host learns about the existence of relevant security gateways and once a host has contacted these security gateways, how it knows that these are the correct security gateways. The details of where the required information is stored is a local matter.
このセクションはホストが関連セキュリティゲートウェイの存在に関してどう学ぶかに関連する問題について論じます、そして、一度、ホストはそれが、これらが正しいセキュリティゲートウェイであることをどう知っているかというこれらのセキュリティゲートウェイに連絡したことがあります。 必須情報が保存されるところに関する詳細は地域にかかわる事柄です。
Consider a situation in which a remote host (H1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host (Road Warrior) crossing the Internet to the home organization's firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of Security Associations.) This situation raises several issues:
リモートホスト(H1)がインターネットを使用している状況がサーバか他のマシン(H2)へのアクセスを得ると考えてください。そうすれば、セキュリティゲートウェイ(SG2)があります、例えば、ファイアウォール、どのH1のトラフィックが終わらなければならないかを通して。 この状況に関する例はホーム組織のファイアウォール(SG2)にインターネットを横断するモバイルホスト(道路Warrior)でしょう。 (Security Associationsのセクション4.5Basic CombinationsのCase4を見てください。) この状況はいくつかの問題を提起します:
1. How does H1 know/learn about the existence of the security
gateway SG2?
2. How does it authenticate SG2, and once it has authenticated
SG2, how does it confirm that SG2 has been authorized to
represent H2?
3. How does SG2 authenticate H1 and verify that H1 is authorized
to contact H2?
4. How does H1 know/learn about backup gateways which provide
alternate paths to H2?
1. H1はセキュリティゲートウェイSG2の存在に関してどのように知っていますか、学びますか? 2. どのようにSG2を認証するか、そして、いったんSG2を認証すると、SG2がH2を表すのがどのように認可されたと確認しますか? 3. SG2は、H1を認証して、H1がH2に連絡するのがどのように認可されることを確かめますか? 4. H1は代替パスをH2に供給するバックアップゲートウェイに関して、どのように知っていますか、学びますか?
To address these problems, a host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of a security gateway for any sets of destination addresses that require its use. This includes the ability to configure:
これらの問題、ホストまたはセキュリティゲートウェイに演説するのにおいて、ユーザ/管理者が使用を必要とするどんなセットの送付先アドレスのためにもセキュリティゲートウェイのアドレスを構成できる管理インタフェースがなければなりません。 これは構成する能力を含んでいます:
Kent & Atkinson Standards Track [Page 28] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[28ページ]。
o the requisite information for locating and authenticating the
security gateway and verifying its authorization to represent
the destination host.
o the requisite information for locating and authenticating any
backup gateways and verifying their authorization to represent
the destination host.
o 場所を見つける、セキュリティゲートウェイを認証して、あて先ホストの代理をするために承認について確かめるために. ○ いずれも場所を見つけて、認証するための必要な情報がゲートウェイのバックアップをとるという必要な情報とあて先ホストの代理をするためにそれらの承認について確かめること。
It is assumed that the SPD is also configured with policy information that covers any other IPsec requirements for the path to the security gateway and the destination host.
また、SPDが経路のためのいかなる他のIPsec要件もセキュリティゲートウェイとあて先ホストにカバーする方針情報によって構成されると思われます。
This document does not address the issue of how to automate the discovery/verification of security gateways.
このドキュメントはどうセキュリティゲートウェイの発見/検証を自動化するかに関する問題を扱いません。
4.7 Security Associations and Multicast
4.7 セキュリティ協会とマルチキャスト
The receiver-orientation of the Security Association implies that, in the case of unicast traffic, the destination system will normally select the SPI value. By having the destination select the SPI value, there is no potential for manually configured Security Associations to conflict with automatically configured (e.g., via a key management protocol) Security Associations or for Security Associations from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems per multicast group. So some system or person will need to coordinate among all multicast groups to select an SPI or SPIs on behalf of each multicast group and then communicate the group's IPsec information to all of the legitimate members of that multicast group via mechanisms not defined here.
Security Associationの受信機オリエンテーションは、通常、目的地システムがユニキャストトラフィックの場合でSPI値を選択するのを含意します。 目的地にSPI値を選択させることによって、手動で構成されたSecurity Associationsが自動的に構成された(例えば、かぎ管理プロトコルで)セキュリティAssociationsと衝突するか、または複数のソースからのSecurity Associationsが互いと衝突する可能性が全くありません。 マルチキャストトラフィックのために、複数のマルチキャストグループあたりの目的地システムがあります。 それで、システムか人が、ここで定義されなかったメカニズムでそれぞれのマルチキャストグループを代表してSPIかSPIsを選択して、次に、そのマルチキャストグループの正統のメンバーのすべてにグループのIPsec情報を伝えるためにすべてのマルチキャストグループで調整する必要があるでしょう。
Multiple senders to a multicast group SHOULD use a single Security Association (and hence Security Parameter Index) for all traffic to that group when a symmetric key encryption or authentication algorithm is employed. In such circumstances, the receiver knows only that the message came from a system possessing the key for that multicast group. In such circumstances, a receiver generally will not be able to authenticate which system sent the multicast traffic. Specifications for other, more general multicast cases are deferred to later IPsec documents.
対称鍵暗号化か認証アルゴリズムが採用しているとき、マルチキャストグループSHOULDへの複数の送付者がすべてのトラフィックに、独身のSecurity Association(そして、したがって、Security Parameter Index)をそのグループに使用します。 そのような事情では、受信機は、メッセージがそのマルチキャストグループにキーを所有しているシステムから来ただけであるのを知っています。 一般に、事情、受信機が認証できないそれのシステムがマルチキャストトラフィックを送ったそのようなもので。 他の、そして、より一般的なマルチキャストケースのための仕様は後のIPsecドキュメントに延期されます。
At the time this specification was published, automated protocols for multicast key distribution were not considered adequately mature for standardization. For multicast groups having relatively few members, manual key distribution or multiple use of existing unicast key distribution algorithms such as modified Diffie-Hellman appears feasible. For very large groups, new scalable techniques will be needed. An example of current work in this area is the Group Key Management Protocol (GKMP) [HM97].
この仕様が発表されたとき、マルチキャストの主要な分配のための自動化されたプロトコルは標準化において熟すと適切に考えられませんでした。 比較的わずかなメンバーがいるマルチキャストグループに関しては、変更されたディフィー-ヘルマンなどの既存のユニキャスト主要な分配アルゴリズムの手動の主要な分配か複数の使用が可能に見えます。 非常に大きいグループにおいて、新しいスケーラブルなテクニックが必要でしょう。 この領域での執筆中の作品に関する例はGroup Key Managementプロトコル(GKMP)[HM97]です。
Kent & Atkinson Standards Track [Page 29] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[29ページ]。
5. IP Traffic Processing
5. IPトラフィック処理
As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", the SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded.
セクション4.4.1で「安全保障政策データベース(SPD)」について言及するとき、すべてのトラフィック(INBOUNDとOUTBOUND)の処理の間、SPDに相談しなければなりません、非IPsecトラフィックを含んでいて。 または、方針が全くパケットに合っているSPDで見つけられない、(どちらかにおける本国行き、アウトバウンドトラフィック)、パケットを捨てなければなりません。
NOTE: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order.
以下に注意してください。 IPsecで使用される暗号アルゴリズムのすべてが、正準なネットワークバイトオーダー(RFC791のAppendixを見る)で彼らの入力を予想して、正準なネットワークバイトオーダーで彼らの出力を生成します。 また、IPパケットはネットワークバイトオーダーで伝えられます。
5.1 Outbound IP Traffic Processing
5.1 外国行きのIPトラフィック処理
5.1.1 Selecting and Using an SA or SA Bundle
5.1.1 SAかSAバンドルを選択して、使用すること。
In a security gateway or BITW implementation (and in many BITS implementations), each outbound packet is compared against the SPD to determine what processing is required for the packet. If the packet is to be discarded, this is an auditable event. If the traffic is allowed to bypass IPsec processing, the packet continues through "normal" processing for the environment in which the IPsec processing is taking place. If IPsec processing is required, the packet is either mapped to an existing SA (or SA bundle), or a new SA (or SA bundle) is created for the packet. Since a packet's selectors might match multiple policies or multiple extant SAs and since the SPD is ordered, but the SAD is not, IPsec MUST:
セキュリティゲートウェイかBITW実装(そして多くのBITS実装で)では、SPDに対してそれぞれの外国行きのパケットは、どんな処理がパケットに必要であるかを決定するために比較されます。 パケットが捨てられるつもりであるなら、これは監査可能イベントです。 トラフィックがIPsec処理を迂回させることができるなら、パケットはIPsec処理が行われている環境のための「正常な」処理で続きます。 IPsec処理が必要であるなら、パケットが既存のSAに写像されるか(SAは荷物をまとめます)、または新しいSA(SAは荷物をまとめる)はパケットのために作成されます。 パケットのセレクタが複数の方針か複数の実在のSAsに合うかもしれなくて、SPDを注文しますが、SADが注文するというわけではないので、IPsecは注文しなければなりません:
1. Match the packet's selector fields against the outbound
policies in the SPD to locate the first appropriate
policy, which will point to zero or more SA bundles in the
SAD.
1. SPDの外国行きの方針に対してパケットのセレクタ分野を合わせて、ゼロを示す最初の適切な方針の場所を見つけてください。さもないと、より多くのSAがSADに荷物をまとめます。
2. Match the packet's selector fields against those in the SA
bundles found in (1) to locate the first SA bundle that
matches. If no SAs were found or none match, create an
appropriate SA bundle and link the SPD entry to the SAD
entry. If no key management entity is found, drop the
packet.
2. それらに対して合っている最初のSAバンドルの場所を見つけるように(1)で見つけられたSAバンドルでパケットのセレクタ分野を合わせてください。 SAsが全く見つけられなかったか、またはなにも合っていないなら、適切なSAバンドルを作成してください、そして、SPDエントリーをSADエントリーにリンクしてください。 かぎ管理実体が全く見つけられないなら、パケットを下げてください。
3. Use the SA bundle found/created in (2) to do the required
IPsec processing, e.g., authenticate and encrypt.
3. 例えば処理するのが認証して、暗号化する必要なIPsecをするために(2)で見つけられたか、または作成されたSAバンドルを使用してください。
In a host IPsec implementation based on sockets, the SPD will be consulted whenever a new socket is created, to determine what, if any, IPsec processing will be applied to the traffic that will flow on that socket.
ソケットに基づくホストIPsec実装では、新しいソケットがIPsec処理がどんなであるも何になるかをそのソケットの上に流れるトラフィックに適用されていた状態で決定するために作成されるときはいつも、SPDに相談するでしょう。
Kent & Atkinson Standards Track [Page 30] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[30ページ]。
NOTE: A compliant implementation MUST not allow instantiation of an ESP SA that employs both a NULL encryption and a NULL authentication algorithm. An attempt to negotiate such an SA is an auditable event.
以下に注意してください。 対応する実装はNULL暗号化とNULL認証アルゴリズムの両方を使うESP SAの具体化を許容してはいけません。 そのようなSAを交渉する試みは監査可能イベントです。
5.1.2 Header Construction for Tunnel Mode
5.1.2 トンネル・モードのためのヘッダー工事
This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels. This includes how to construct the encapsulating (outer) IP header, how to handle fields in the inner IP header, and what other actions should be taken. The general idea is modeled after the one used in RFC 2003, "IP Encapsulation with IP":
このセクションはAHと超能力トンネルのための内側の、そして、外側のIPヘッダー、拡張ヘッダー、およびオプションの取り扱いについて説明します。 これは、どのように要約(外側の)のIPヘッダーを組み立てるか、そして、どのように内側のIPヘッダーの分野を扱うか、そして、どんな他の行動が取られるべきであるかを含んでいます。 概念はRFC2003で使用されるもの、「IPがあるIPカプセル化」に倣われます:
o The outer IP header Source Address and Destination Address
identify the "endpoints" of the tunnel (the encapsulator and
decapsulator). The inner IP header Source Address and
Destination Addresses identify the original sender and
recipient of the datagram, (from the perspective of this
tunnel), respectively. (see footnote 3 after the table in
5.1.2.1 for more details on the encapsulating source IP
address.)
o The inner IP header is not changed except to decrement the TTL
as noted below, and remains unchanged during its delivery to
the tunnel exit point.
o No change to IP options or extension headers in the inner
header occurs during delivery of the encapsulated datagram
through the tunnel.
o If need be, other protocol headers such as the IP
Authentication header may be inserted between the outer IP
header and the inner IP header.
o 外側のIPのヘッダーSource AddressとDestination Addressはトンネル(encapsulatorとdecapsulator)の「終点」を特定します。 内側のIPのヘッダーSource AddressとDestination Addressesがデータグラムの元の送り主と受取人を特定する、(このトンネルの見解からの)、それぞれ。 (テーブルの後に中で脚注3を見てください、5.1、.2、.1、要約のソースIPアドレスに関するその他の詳細)。 o 内側のIPヘッダーは、以下に述べられるようにTTLを減少させる以外に、変えられないで、また配送の間、トンネルエキジットポイントに変わりがありません。○ 内側のヘッダーのIPオプションか拡張ヘッダーへの変化は全くトンネルを通るカプセル化されたデータグラムの配送の間、起こりません。o Ifがなければならなくて、IP Authenticationヘッダーなどの他のプロトコルヘッダーは外側のIPヘッダーと内側のIPヘッダーの間に挿入されるかもしれません。
The tables in the following sub-sections show the handling for the different header/option fields (constructed = the value in the outer field is constructed independently of the value in the inner).
以下の小区分におけるテーブルは異なったヘッダー/オプション・フィールドのための取り扱いを示しています(= 組み立てられて、外側の分野の値は内側の値の如何にかかわらず構成されます)。
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode
5.1.2.1 IPv4--トンネル・モードのためのヘッダー工事
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 4 (1) no change
header length constructed no change
TOS copied from inner hdr (5) no change
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragmt offset constructed no change
<--Inner HdrへのどのようにOuter Hdr Relates--IPv4 Encapsulator Decapsulator Header分野のInner Hdrの>Outer Hdr: -------------------- ------------ バージョン4 (1) 変化の変化の内側のhdr(5)ノー全長の組み立てられたノーIDからコピーされた変化ヘッダ長がない変化の組み立てられたノーTOSは旗(DF、MF)が組み立てなかった変化を全く組み立てて、どんな変化fragmtも相殺しなかったDF(4)は変化を全く組み立てませんでした。
Kent & Atkinson Standards Track [Page 31] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[31ページ]。
TTL constructed (2) decrement (2)
protocol AH, ESP, routing hdr no change
checksum constructed constructed (2)
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change
TTLは(2) 減少(2)プロトコルAH、超能力を組み立てて、どんな変化チェックサムも組み立てなかったhdrを発送して、組み立てられた(2)srcアドレス変化destアドレスの変化の組み立てられた(3)ノー組み立てられた(3)ノーOptionsは変化を全く決してコピーしませんでした。
1. The IP version in the encapsulating header can be different
from the value in the inner header.
1. 要約のヘッダーのIPバージョンは内側のヘッダーで値と異なっている場合があります。
2. The TTL in the inner header is decremented by the
encapsulator prior to forwarding and by the decapsulator if
it forwards the packet. (The checksum changes when the TTL
changes.)
2. パケットを進めるなら、内側のヘッダーのTTLは推進の前のencapsulatorとdecapsulatorによって減少します。 (チェックサムは、TTLがいつ変化するかを変えます。)
Note: The decrementing of the TTL is one of the usual actions
that takes place when forwarding a packet. Packets
originating from the same node as the encapsulator do not
have their TTL's decremented, as the sending node is
originating the packet rather than forwarding it.
以下に注意してください。 TTLの減少はパケットを進めるとき行われる普通の動作の1つです。 それらのTTLのものはencapsulatorと同じノードから発するパケットで減少しません、むしろ送付ノードがそれを進めるよりパケットを溯源しているとき。
3. src and dest addresses depend on the SA, which is used to
determine the dest address which in turn determines which src
address (net interface) is used to forward the packet.
3. srcとdestアドレスはSAによります。(SAは、どのsrcアドレス(ネットのインタフェース)がパケットを進めるのに使用されるかを順番に決定するdestアドレスを決定するのに使用されます)。
NOTE: In principle, the encapsulating IP source address can
be any of the encapsulator's interface addresses or even an
address different from any of the encapsulator's IP
addresses, (e.g., if it's acting as a NAT box) so long as the
address is reachable through the encapsulator from the
environment into which the packet is sent. This does not
cause a problem because IPsec does not currently have any
INBOUND processing requirement that involves the Source
Address of the encapsulating IP header. So while the
receiving tunnel endpoint looks at the Destination Address in
the encapsulating IP header, it only looks at the Source
Address in the inner (encapsulated) IP header.
以下に注意してください。 原則として、要約のIPソースアドレスはencapsulatorのインターフェース・アドレスのいずれであることができますかencapsulatorのIPアドレスのいずれとも異なったアドレスさえアドレスと同じくらい長い間、パケットが送られる環境からのencapsulatorを通して届いています(例えば、NAT箱として機能しているなら)。 現在、IPsecには要約のIPヘッダーのSource Addressにかかわる少しのINBOUND処理所要もないので、これは問題を引き起こしません。 それで、受信トンネル終点は要約のIPヘッダーでDestination Addressを見ますが、それは内側(カプセル化される)のIPヘッダーでSource Addressを見るだけです。
4. configuration determines whether to copy from the inner
header (IPv4 only), clear or set the DF.
4. 構成は、内側のヘッダー(IPv4専用)からコピーするか、クリアするか、またはDFを設定するかを決定します。
5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS. If Inner
Hdr is IPv6 (Protocol = 41), map the Class to TOS.
5. Inner HdrがIPv4(プロトコル=4)であるなら、TOSをコピーしてください。 Inner HdrがIPv6(プロトコル=41)であるなら、ClassをTOSに写像してください。
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode
5.1.2.2 IPv6--トンネル・モードのためのヘッダー工事
See previous section 5.1.2 for notes 1-5 indicated by (footnote number).
注意1-5のための前項5.1.2が(脚注番号)によって示されるのを見てください。
Kent & Atkinson Standards Track [Page 32] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[32ページ]。
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
class copied or configured (6) no change
flow id copied or configured no change
len constructed no change
next header AH,ESP,routing hdr no change
hop limit constructed (2) decrement (2)
src address constructed (3) no change
dest address constructed (3) no change
Extension headers never copied no change
<--外側のHdrはどう内側のHdrを関係づけるか。---IPv6 Encapsulator Decapsulator Header分野のInner Hdrの>の外側のHdr: -------------------- ------------ バージョン6 (1) 変化のクラスが全くコピーされなかったか、または(6) 変化流れイドが全くコピーされなかったのを構成するか、または次の変化のヘッダーの変化のlen組み立てられたノーがないAH、超能力を構成して、組み立てられた(2)減少(2)srcアドレスの変化destアドレスの変化のhdrノー変化ホップ限界組み立てられた(3)ノー組み立てられた(3)ノーExtensionを発送して、ヘッダーは変化を全く決してコピーしませんでした。
6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If
Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class.
6. Inner HdrがIPv6(次のHeader=41)であるなら、Classをコピーしてください。 Inner HdrがIPv4(次のHeader=4)であるなら、TOSをClassに写像してください。
5.2 Processing Inbound IP Traffic
5.2 処理の本国行きのIPトラフィック
Prior to performing AH or ESP processing, any IP fragments are reassembled. Each inbound IP datagram to which IPsec processing will be applied is identified by the appearance of the AH or ESP values in the IP Next Protocol field (or of AH or ESP as an extension header in the IPv6 context).
AHか超能力処理を実行する前に、どんなIP断片も組み立て直されます。 IPsec処理が適用されるそれぞれの本国行きのIPデータグラムはIP Nextプロトコル分野(またはIPv6文脈の拡張ヘッダーとしてのAHか超能力について)のAHか超能力値の外観で特定されます。
Note: Appendix C contains sample code for a bitmask check for a 32 packet window that can be used for implementing anti-replay service.
以下に注意してください。 付録Cは反再生サービスを実装するのに使用できる32パケット・ウィンドウのためのビットマスクチェックのためのサンプルコードを含んでいます。
5.2.1 Selecting and Using an SA or SA Bundle
5.2.1 SAかSAバンドルを選択して、使用すること。
Mapping the IP datagram to the appropriate SA is simplified because of the presence of the SPI in the AH or ESP header. Note that the selector checks are made on the inner headers not the outer (tunnel) headers. The steps followed are:
IPデータグラムを適切なSAに写像するのはAHか超能力ヘッダーでのSPIの存在のために簡素化されます。 外側の(トンネル)ヘッダーではなく、内側のヘッダーの上にセレクタチェックをすることに注意してください。 従われた方法は以下の通りです。
1. Use the packet's destination address (outer IP header),
IPsec protocol, and SPI to look up the SA in the SAD. If
the SA lookup fails, drop the packet and log/report the
error.
1. パケットの送付先アドレス(外側のIPヘッダー)、IPsecプロトコル、およびSPIを使用して、SADでSAを見上げてください。 誤りをSAルックアップが失敗するなら、パケットを下げてください、そして、登録するか、または報告してください。
2. Use the SA found in (1) to do the IPsec processing, e.g.,
authenticate and decrypt. This step includes matching the
packet's (Inner Header if tunneled) selectors to the
selectors in the SA. Local policy determines the
specificity of the SA selectors (single value, list,
range, wildcard). In general, a packet's source address
MUST match the SA selector value. However, an ICMP packet
received on a tunnel mode SA may have a source address
2. 例えば処理するのが認証して、解読するIPsecをするために(1)で見つけられたSAを使用してください。 このステップが、パケットのものを合わせるのを含んでいる、(内側のHeader、トンネルを堀られる、)、SAのセレクタへのセレクタ。 ローカルの方針はSAセレクタ(ただ一つの値、リスト、範囲、ワイルドカード)の特異性を決定します。 一般に、パケットのソースアドレスはSAセレクタ価値に合わなければなりません。 しかしながら、ICMPパケットはSAがソースに扱わせるかもしれないトンネルモードで受信されました。
Kent & Atkinson Standards Track [Page 33] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[33ページ]。
other than that bound to the SA and thus such packets
should be permitted as exceptions to this check. For an
ICMP packet, the selectors from the enclosed problem
packet (the source and destination addresses and ports
should be swapped) should be checked against the selectors
for the SA. Note that some or all of these selectors may
be inaccessible because of limitations on how many bits of
the problem packet the ICMP packet is allowed to carry or
due to encryption. See Section 6.
SAとその結果、そのようなものに縛られるのを除いて、これへの例外がチェックするようにパケットは受入れられるべきです。 ICMPパケットに関しては、同封の問題パケット(ソース、送付先アドレス、およびポートは交換されるべきである)からのセレクタはSAがないかどうかセレクタに対してチェックされるべきです。 これらのセレクタのいくつかかすべてがICMPパケットが問題パケットのいくつのビットまで運ぶことができるかにおける制限のため暗号化のため近づきがたいかもしれないことに注意してください。 セクション6を見てください。
Do (1) and (2) for every IPsec header until a Transport
Protocol Header or an IP header that is NOT for this
system is encountered. Keep track of what SAs have been
used and their order of application.
どんなこのシステムにも賛成しないTransportプロトコルHeaderかIPヘッダーが遭遇するまで、すべてのIPsecヘッダーのための(1)と(2)をしてください。 SAsが何に使用されるか、そして、彼らの適用の順序の動向をおさえてください。
3. Find an incoming policy in the SPD that matches the
packet. This could be done, for example, by use of
backpointers from the SAs to the SPD or by matching the
packet's selectors (Inner Header if tunneled) against
those of the policy entries in the SPD.
3. パケットに合っているSPDで入って来る方針を見つけてください。 例えば、backpointersのSAsからSPDまでの使用かパケットのセレクタを合わせることによってこれができるだろう、(内側のHeader、トンネルを堀られる、)、SPDの方針エントリーのものに対して。
4. Check whether the required IPsec processing has been
applied, i.e., verify that the SA's found in (1) and (2)
match the kind and order of SAs required by the policy
found in (3).
4. 必要なIPsec処理が適用されたかどうかチェックしてください、そして、すなわち、SAが、(1)と(2)で種類を合わせてください。そうすれば、SAsの注文が(3)で見つけられた方針が必要であることがわかったことを確かめてください。
NOTE: The correct "matching" policy will not necessarily
be the first inbound policy found. If the check in (4)
fails, steps (3) and (4) are repeated until all policy
entries have been checked or until the check succeeds.
以下に注意してください。 正しい「合わせている」方針は必ず見つけられた最初の本国行きの方針になるというわけではないでしょう。 (4)でのチェックが失敗するなら、すべての方針エントリーをチェックしてあるか、またはチェックが成功するまで、ステップ(3)と(4)は繰り返されます。
At the end of these steps, pass the resulting packet to the Transport Layer or forward the packet. Note that any IPsec headers processed in these steps may have been removed, but that this information, i.e., what SAs were used and the order of their application, may be needed for subsequent IPsec or firewall processing.
これらのステップの端ときに、結果として起こるパケットをTransport Layerに通過するか、またはパケットを送ってください。 これらのステップで処理されたどんなIPsecヘッダーも取り除きましたが、この情報(すなわち、どんなSAsが使用されましたか、そして、彼らのアプリケーションの注文)をその後のIPsecかファイアウォール処理に必要とするかもしれないことに注意してください。
Note that in the case of a security gateway, if forwarding causes a packet to exit via an IPsec-enabled interface, then additional IPsec processing may be applied.
IPsecによって可能にされたインタフェースを通して出るためにパケットを原因に送るならセキュリティゲートウェイの場合では、追加IPsec処理が適用されるかもしれないことに注意してください。
5.2.2 Handling of AH and ESP tunnels
5.2.2 AHと超能力トンネルの取り扱い
The handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels should be performed as described in the tables in Section 5.1.
AHと超能力トンネルのための内側の、そして、外側のIPヘッダー、拡張ヘッダー、およびオプションの取り扱いはセクション5.1でテーブルで説明されるように実行されるべきです。
Kent & Atkinson Standards Track [Page 34] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[34ページ]。
6. ICMP Processing (relevant to IPsec)
6. ICMP処理(IPsecに関連する)です。
The focus of this section is on the handling of ICMP error messages. Other ICMP traffic, e.g., Echo/Reply, should be treated like other traffic and can be protected on an end-to-end basis using SAs in the usual fashion.
ICMPエラーメッセージの取り扱いにはこのセクションの焦点があります。 普通のファッションでSAsを使用することで他のICMPトラフィック(例えば、Echo/回答)を他のトラフィックのように扱うべきであり、終わりから終わりへのベースに保護できます。
An ICMP error message protected by AH or ESP and generated by a router SHOULD be processed and forwarded in a tunnel mode SA. Local policy determines whether or not it is subjected to source address checks by the router at the destination end of the tunnel. Note that if the router at the originating end of the tunnel is forwarding an ICMP error message from another router, the source address check would fail. An ICMP message protected by AH or ESP and generated by a router MUST NOT be forwarded on a transport mode SA (unless the SA has been established to the router acting as a host, e.g., a Telnet connection used to manage a router). An ICMP message generated by a host SHOULD be checked against the source IP address selectors bound to the SA in which the message arrives. Note that even if the source of an ICMP error message is authenticated, the returned IP header could be invalid. Accordingly, the selector values in the IP header SHOULD also be checked to be sure that they are consistent with the selectors for the SA over which the ICMP message was received.
ICMPエラーメッセージがAHか超能力によって保護されて、ルータによって生成されて、SHOULDは処理されて、トンネルモードでSAを進めました。 ローカルの方針は、それがトンネルの目的地の端のルータによってソースアドレス検査にかけられるかどうか決定します。 トンネルの起因する端のルータが別のルータからICMPエラーメッセージを転送しているなら、ソースアドレス検査が失敗することに注意してください。 交通機関SAでAHか超能力によって保護されて、ルータによって生成されたICMPメッセージを転送してはいけません(SAがホストとして務めるルータに設立されていない場合、例えば、Telnet接続は以前はよくルータを管理していました)。 ICMPメッセージはホストでSHOULDを生成しました。メッセージが到着するSAに制限されたソースIPアドレスセレクタに対してチェックされてください。 ICMPエラーメッセージの源が認証されても、返されたIPヘッダーが無効であるかもしれないことに注意してください。 それに従って、セレクタはIPヘッダーでSHOULDを評価します、また、ICMPメッセージが受け取られたSAにおいて、それらがセレクタと一致しているのを確信しているには、チェックされてください。
The table in Appendix D characterize ICMP messages as being either host generated, router generated, both, unknown/unassigned. ICMP messages falling into the last two categories should be handled as determined by the receiver's policy.
Appendix Dのテーブルはどちらかのホストであるとしてのメッセージが生成したICMP、ともに未知か割り当てられなく生成されたルータを特徴付けます。 最後の2つのカテゴリになるICMPメッセージは受信機の方針で決定するように扱われるべきです。
An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial of service. This suggests that, in general, it would be desirable to ignore such messages. However, it is expected that many routers (vs. security gateways) will not implement IPsec for transit traffic and thus strict adherence to this rule would cause many ICMP messages to be discarded. The result is that some critical IP functions would be lost, e.g., redirection and PMTU processing. Thus it MUST be possible to configure an IPsec implementation to accept or reject (router) ICMP traffic as per local security policy.
AHか超能力によって保護されなかったICMPメッセージは非認証されます、そして、処理、そして/または、推進はサービスの否定をもたらすかもしれません。 これは、一般に、そのようなメッセージを無視するのが望ましいと示唆します。 しかしながら、多くのルータ(セキュリティゲートウェイに対する)がトランジットトラフィックのためにIPsecを実装しないと予想されて、その結果、この規則への厳しい固守は多くの捨てられるべきICMPメッセージを引き起こすでしょう。 結果はいくつかのきわどいIP機能が例えば失われているだろうということです。リダイレクションとPMTU処理。 したがって、ローカルの安全保障政策に従って(ルータ)ICMPトラフィックを受け入れるか、または拒絶するためにIPsec実装を構成するのは可能であるに違いありません。
The remainder of this section addresses how PMTU processing MUST be performed at hosts and security gateways. It addresses processing of both authenticated and unauthenticated ICMP PMTU messages. However, as noted above, unauthenticated ICMP messages MAY be discarded based on local policy.
このセクションの残りはホストとセキュリティゲートウェイでどうPMTU処理を実行しなければならないかを扱います。 それは認証された両方とunauthenticated ICMP PMTUメッセージの処理を扱います。 しかしながら、上で述べたように、unauthenticated ICMPメッセージはローカルの方針に基づいて捨てられるかもしれません。
Kent & Atkinson Standards Track [Page 35] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[35ページ]。
6.1 PMTU/DF Processing
6.1 PMTU/DF処理
6.1.1 DF Bit
6.1.1 DFは噛み付きました。
In cases where a system (host or gateway) adds an encapsulating header (ESP tunnel or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). This means that it MUST be possible to configure the system's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix B for rationale.)
システム(ホストかゲートウェイ)が要約のヘッダーを加える(超能力トンネルかAHがトンネルを堀ります)場合では、それはオリジナルのパケットから要約のヘッダーまでDFビットをコピーするオプションをサポートしなければなりません(ICMP PMTUメッセージを処理して)。 これは、システムのDFビット(はっきりと、カプセル化されたヘッダーからコピーを設定する)の処理を各インタフェースに構成するのが可能であるに違いないことを意味します。 (原理に関してAppendix Bを見てください。)
6.1.2 Path MTU Discovery (PMTU)
6.1.2 経路MTU発見(PMTU)
This section discusses IPsec handling for Path MTU Discovery messages. ICMP PMTU is used here to refer to an ICMP message for:
このセクションはPath MTUディスカバリーメッセージのためにIPsec取り扱いについて論じます。 ICMP PMTUは、以下についてICMPメッセージを示すのにここで使用されます。
IPv4 (RFC 792):
- Type = 3 (Destination Unreachable)
- Code = 4 (Fragmentation needed and DF set)
- Next-Hop MTU in the low-order 16 bits of the second
word of the ICMP header (labelled "unused" in RFC
792), with high-order 16 bits set to zero
IPv4(RFC792): - ICMPヘッダー(RFC792で「未使用である」とラベルされる)の2番目の単語の下位の16ビットで16ビットがゼロに設定する高位で=3(目的地Unreachable)--コード=4(必要である断片化とDFはセットしました)--次のホップMTUをタイプしてください。
IPv6 (RFC 1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed)
- Next-Hop MTU in the 32 bit MTU field of the ICMP6
message
IPv6(RFC1885): - =2(パケットToo Big)--コード=0(必要である断片化)--次のホップMTUをICMP6メッセージの32ビットのMTU分野にタイプしてください。
6.1.2.1 Propagation of PMTU
6.1.2.1 PMTUの伝播
The amount of information returned with the ICMP PMTU message (IPv4 or IPv6) is limited and this affects what selectors are available for use in further propagating the PMTU information. (See Appendix B for more detailed discussion of this topic.)
ICMP PMTUメッセージ(IPv4かIPv6)と共に返された情報量は限られています、そして、これはどんなセレクタがさらにPMTU情報を伝播することにおける使用に利用可能であるかに影響します。 (この話題の、より詳細な議論に関してAppendix Bを見てください。)
o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU
message contains only 64 bits of the IPsec header (minimum for
IPv4), then a security gateway MUST support the following options
on a per SPI/SA basis:
o PMTUはIPsecヘッダーの64ビットで通信します--ICMP PMTUメッセージがIPsecヘッダー(IPv4に、最小の)の64ビットだけを含んでいるなら、セキュリティゲートウェイはSPI/SA基礎あたりのaで以下のオプションをサポートしなければなりません:
a. if the originating host can be determined (or the possible
sources narrowed down to a manageable number), send the PM
information to all the possible originating hosts.
b. if the originating host cannot be determined, store the PMTU
with the SA and wait until the next packet(s) arrive from the
originating host for the relevant security association. If
送信元ホストが決定できるなら(可能なソースは処理しやすい数まで狭くしました)、すべての可能な送信元ホストにPM情報を送ってください。a. b.は送信元ホストであるなら関連セキュリティ協会を断固として、SAと共にPMTUを保存して、次のパケットが送信元ホストから到着するまで、待つことができません。 if
Kent & Atkinson Standards Track [Page 36] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[36ページ]。
the packet(s) are bigger than the PMTU, drop the packet(s),
and compose ICMP PMTU message(s) with the new packet(s) and
the updated PMTU, and send the ICMP message(s) about the
problem to the originating host. Retain the PMTU information
for any message that might arrive subsequently (see Section
6.1.2.4, "PMTU Aging").
パケットは、PMTUより大きく、新しいパケットとアップデートされたPMTUと共にパケットを下げて、ICMP PMTUメッセージを構成して、問題に関するICMPメッセージを送信元ホストに送ります。 次に到着するどんなメッセージのためのPMTU情報も保有してください、(見る、セクション6.1 .2 「PMTUは年をとる」.4
o PMTU message with >64 bits of IPsec header -- If the ICMP message
contains more information from the original packet then there may
be enough non-opaque information to immediately determine to which
host to propagate the ICMP/PMTU message and to provide that system
with the 5 fields (source address, destination address, source
port, destination port, transport protocol) needed to determine
where to store/update the PMTU. Under such circumstances, a
security gateway MUST generate an ICMP PMTU message immediately
upon receipt of an ICMP PMTU from further down the path.
o IPsecヘッダーの>64ビットがあるPMTUメッセージ--ICMPメッセージがオリジナルのパケットからの詳しい情報を含んでいるなら、すぐにICMP/PMTUメッセージを伝播して、どこでPMTUを保存するか、またはアップデートするかを決定するのに必要である5つの野原(ソースアドレス、送付先アドレス、ソースポート、仕向港はプロトコルを輸送する)をそのシステムに提供することをどのホストに決定する非不明瞭な情報は、十分あるかもしれません。 これでは、セキュリティゲートウェイは、すぐより遠い下であるのからのICMP PMTUを受け取り次第ICMP PMTUメッセージが経路であると生成しなければなりません。
o Distributing the PMTU to the Transport Layer -- The host mechanism
for getting the updated PMTU to the transport layer is unchanged,
as specified in RFC 1191 (Path MTU Discovery).
o Transport LayerにPMTUを分配します--アップデートされたPMTUをトランスポート層に手に入れるためのホストメカニズムは変わりがありません、RFC1191(経路MTUディスカバリー)で指定されるように。
6.1.2.2 Calculation of PMTU
6.1.2.2 PMTUの計算
The calculation of PMTU from an ICMP PMTU MUST take into account the addition of any IPsec header -- AH transport, ESP transport, AH/ESP transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of implementation issues.)
ICMP PMTU MUSTからのPMTUの計算はどんなIPsecヘッダーの追加も考慮に入れます--AH輸送、超能力輸送、AH/超能力輸送、超能力トンネル、AHはトンネルを堀ります。 (導入問題の議論に関してAppendix Bを見てください。)
Note: In some situations the addition of IPsec headers could result in an effective PMTU (as seen by the host or application) that is unacceptably small. To avoid this problem, the implementation may establish a threshold below which it will not report a reduced PMTU. In such cases, the implementation would apply IPsec and then fragment the resulting packet according to the PMTU. This would result in a more efficient use of the available bandwidth.
以下に注意してください。 いくつかの状況で、IPsecヘッダーの追加は容認できないほど小さい有効なPMTU(ホストかアプリケーションで見られるように)をもたらすかもしれません。 この問題を避けるために、実装はそれが減少しているPMTUを報告しない敷居を確立するかもしれません。 そのような場合、PMTUによると、実装は、IPsecを適用して、次に、結果として起こるパケットを断片化するでしょう。 これは利用可能な帯域幅の、より効率的な使用をもたらすでしょう。
6.1.2.3 Granularity of PMTU Processing
6.1.2.3 PMTU処理の粒状
In hosts, the granularity with which ICMP PMTU processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues (See Appendix B for additional details on this topic.):
ホストでは、実装状況によって、ICMP PMTU処理をできる粒状は異なります。 ホストを見て、PMTU問題に関して興味がある3つの状況があります(この話題に関する追加詳細に関してAppendix Bを見てください。):
a. Integration of IPsec into the native IP implementation
b. Bump-in-the-stack implementations, where IPsec is implemented
"underneath" an existing implementation of a TCP/IP protocol
stack, between the native IP and the local network drivers
a。 ネイティブのIP実装bへのIPsecの統合。 スタックでの隆起実装、IPsecが“underneath"であると実装されるところでTCP/IPプロトコルの既存の実装は積み重ねられます、ネイティブのIPと企業内情報通信網のドライバーの間で
Kent & Atkinson Standards Track [Page 37] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[37ページ]。
c. No IPsec implementation -- This case is included because it
is relevant in cases where a security gateway is sending PMTU
information back to a host.
c。 IPsec実装がありません--それがセキュリティゲートウェイがPMTU情報をホストに送り返している場合で関連しているので、本件は含まれています。
Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In (b) and (c), the IP layer will only be able to maintain PMTU data at the granularity of source and destination IP addresses (and optionally TOS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms).
場合(a)だけでは、コミュニケーション協会と同じ粒状でPMTUデータを保守できます。 IP層が(b)と(c)でソースと送付先IPアドレスの粒状でPMTUデータを保守できるだけである、(任意に、TOS)、RFC1191では、説明されます。 これは重要な違いです、1つ以上のコミュニケーション協会が同じソースと目的地IPにアドレスを写像するかもしれなくて、それぞれのコミュニケーション協会には異なった量のIPsecヘッダーオーバーヘッド(例えば、異なった変換か異なったアルゴリズムの使用による)があるかもしれないので。
Implementation of the calculation of PMTU and support for PMTUs at the granularity of individual communication associations is a local matter. However, a socket-based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The calculation of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message.
個別の通報協会の粒状におけるPMTUsのPMTUとサポートの計算の実装は地域にかかわる事柄です。 しかしながら、ホストSHOULDのIPsecのソケットベースの実装はソケット基礎あたりのaの情報を保守します。 スタックシステムにおける隆起はホストIP実装にICMP PMTUを渡さなければなりません、どんなIPsecヘッダーオーバーヘッドでもそれを調整するのが、これらのシステムで. 頭上のSHOULDの計算が返されたICMP PMTUメッセージの現在のSPIといかなる他のセレクタ情報の分析でも決定すると言い足した後に。
6.1.2.4 PMTU Aging
6.1.2.4 PMTUの年をとること
In all systems (host or gateway) implementing IPsec and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) MUST be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Note that if there are nested tunnels, multiple packets and round trip times might be required to get an ICMP message back to an encapsulator or originating host.
IPsecを実装して、PMTU情報を保守するすべてのシステム(ホストかゲートウェイ)では、セキュリティ関係(輸送するか、またはトンネルを堀る)に関連しているPMTUは直ちにPMTUをアップデートするために適所に置かれた、「高年層」と何らかのメカニズムであるに違いありません、特にPMTUがそれが、必要がある小さいかどうか発見するために。 現在のPMTUが大き過ぎるなら、与えられたPMTUはパケットがセキュリティ協会のソース終わりから得ることができるくらいの長い間セキュリティ協会のもう一方の端に適所にシステムに留まっていて、ICMPエラーメッセージを伝播して戻さなければなりません。 入れ子にされたトンネルがあれば、複数のパケットと周遊旅行時間がICMPメッセージをencapsulatorか送信元ホストに取り戻すのに必要であるかもしれないことに注意してください。
Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable.
システムSHOULDはPath MTUディスカバリードキュメント(RFC1191、セクション6.3)で説明されたアプローチを使用します。ドキュメントは、定期的に最初に、ホップデータ・リンクMTUにPMTUをリセットして、次に、正常なPMTUディスカバリープロセスに必要に応じてPMTUをアップデートさせるのを示します。 以上、SHOULD。構成可能であってください。
Kent & Atkinson Standards Track [Page 38] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[38ページ]。
7. Auditing
7. 監査
Not all systems that implement IPsec will implement auditing. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in the AH and ESP specifications and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
IPsecを実装するというわけではないすべてのシステムが監査を実装するでしょう。 監査の粒状はだいたい、地域にかかわる事柄です。 しかしながら、いくつかの監査可能イベントがAHと超能力仕様で特定されます、そして、それぞれのこれらのイベントにおいて、SHOULDが監査ログに含まれているという最小の情報は定義されます。 追加情報もこの仕様で明らかに大声で叫んで、また、監査航空日誌記入事項をもたらすかもしれないのではなく、それぞれのこれらのイベント、および追加イベントのための監査ログに含まれるかもしれません。 受信機が監査可能イベントの検出に対応してどんなメッセージも主張された送信機に送るという要件が全くありません、そのような動作でサービスの否定を引き起こす可能性のために。
8. Use in Systems Supporting Information Flow Security
8. 情報流動がセキュリティであるとサポートするシステムにおける使用
Information of various sensitivity levels may be carried over a single network. Information labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish such information. The use of labels facilitates segregation of information, in support of information flow security models, e.g., the Bell-LaPadula model [BL73]. Such models, and corresponding supporting technology, are designed to prevent the unauthorized flow of sensitive information, even in the face of Trojan Horse attacks. Conventional, discretionary access control (DAC) mechanisms, e.g., based on access control lists, generally are not sufficient to support such policies, and thus facilities such as the SPD do not suffice in such environments.
様々な感度レベルに関する情報はただ一つのネットワークの上まで運ばれるかもしれません。 情報ラベル(例えば、Unclassified、Proprietary社、Secret)[DoD85、DoD87]は、そのような情報を区別するのにしばしば使われます。 ラベルの使用は情報流れ機密保護モデル、例えば、ベル-LaPadulaモデル[BL73]を支持して情報の隔離を容易にします。 そのようなモデルと、技術をサポートしながら対応するのは機密情報の権限のない流れを防ぐように設計されています、トロイの木馬攻撃に直面してさえ。 その結果、SPDなどの施設はそのような環境で一般に、従来の、そして、任意のアクセス制御(DAC)メカニズムが例えば、アクセスコントロールリストに基づいてそのような方針をサポートすることができないくらいには十分ではありません。
In the military context, technology that supports such models is often referred to as multi-level security (MLS). Computers and networks often are designated "multi-level secure" if they support the separation of labelled data in conjunction with information flow security policies. Although such technology is more broadly applicable than just military applications, this document uses the acronym "MLS" to designate the technology, consistent with much extant literature.
軍事の文脈では、そのようなモデルをサポートする技術がしばしばマルチレベルセキュリティ(MLS)と呼ばれます。 情報流れ安全保障政策に関連してラベルされたデータの分離をサポートするなら、コンピュータとネットワークはしばしば「マルチレベル安全な」状態で指定されます。 技術はまさしく軍事利用より広く同じくらい適切ですが、このドキュメントは技術を指定するのに頭文字語「MLS」を使用します、多くの実在の文学と一致しています。
IPsec mechanisms can easily support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC), which unprivileged users or unprivileged processes are incapable of controlling or violating. This section pertains only to the use of these IP security mechanisms in MLS (information flow security policy) environments. Nothing in this section applies to systems not claiming to provide MLS.
IPsecメカニズムは、MLSがネットワークであると容易にサポートすることができます。 MLSネットワークは制御できないか、(MAC)(ユーザに「非-特権を与え」させたか、またはプロセスに「非-特権を与え」させた)が違反できない強いMandatory Access Controlsの使用を必要とします。 このセクションはMLS(情報流れ安全保障政策)環境におけるこれらのIPセキュリティー対策の使用だけに関係します。 このセクションの何もMLSを提供すると主張しないシステムに適用されません。
Kent & Atkinson Standards Track [Page 39] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[39ページ]。
As used in this section, "sensitivity information" might include implementation-defined hierarchic levels, categories, and/or releasability information.
このセクションで使用されるように、「感度情報」は実装で定義された階層的なレベル、カテゴリ、そして/または、releasability情報を含むかもしれません。
AH can be used to provide strong authentication in support of mandatory access control decisions in MLS environments. If explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and confidentiality is not considered necessary within the particular operational environment, AH can be used to authenticate the binding between sensitivity labels in the IP header and the IP payload (including user data). This is a significant improvement over labeled IPv4 networks where the sensitivity information is trusted even though there is no authentication or cryptographic binding of the information to the IP header and user data. IPv4 networks might or might not use explicit labelling. IPv6 will normally use implicit sensitivity information that is part of the IPsec Security Association but not transmitted with each packet instead of using explicit sensitivity information. All explicit IP sensitivity information MUST be authenticated using either ESP, AH, or both.
MLS環境における義務的なアクセス制御決定を支持して強い認証を提供するのにAHを使用できます。 明白なIP感度情報(例えば、IPSO[Ken91])が使用されていて、秘密性が特定の運用環境の中で必要であることは考えられないなら、IPヘッダーとIPペイロードの感度ラベルの間の結合を認証するのにAHを使用できます(利用者データを含んでいて)。 これはIPヘッダーと利用者データへの情報のどんな認証も暗号の結合もありませんが、感度情報が信じられるラベルされたIPv4ネットワークの上のかなりの改善です。 IPv4ネットワークは、使用するか、または明白なラベルを使用しないかもしれません。 通常、IPv6は各パケットが明白な感度情報を使用することの代わりにあるIPsec Security Associationにもかかわらず、伝えられないことの一部である暗黙の感度情報を使用するでしょう。 超能力、AHか両方のどちらかを使用して、すべての明白なIP感度情報を認証しなければなりません。
Encryption is useful and can be desirable even when all of the hosts are within a protected environment, for example, behind a firewall or disjoint from any external connectivity. ESP can be used, in conjunction with appropriate key management and encryption algorithms, in support of both DAC and MAC. (The choice of encryption and authentication algorithms, and the assurance level of an IPsec implementation will determine the environments in which an implementation may be deemed sufficient to satisfy MLS requirements.) Key management can make use of sensitivity information to provide MAC. IPsec implementations on systems claiming to provide MLS SHOULD be capable of using IPsec to provide MAC for IP-based communications.
暗号化は、役に立って、ホストが皆、例えばファイアウォールの後ろに保護された環境の中にいるときさえ、望ましいか、またはどんな外部の接続性からもばらばらになることができます。 適切なかぎ管理と暗号化アルゴリズムに関連してDACとMACの両方を支持して超能力を使用できます。 (アルゴリズム、およびIPsec実装の保証レベルがそうする暗号化と認証の選択は実装がMLS要件を満たすために十分であると考えられるかもしれない環境を決定します。) かぎ管理は、MACを提供するのに感度情報を利用できます。 MLS SHOULDを提供するのに、IPベースのコミュニケーションにMACを提供するのにIPsecを使用できるように主張するシステムの上のIPsec実装。
8.1 Relationship Between Security Associations and Data Sensitivity
8.1 セキュリティ協会とデータ感度との関係
Both the Encapsulating Security Payload and the Authentication Header can be combined with appropriate Security Association policies to provide multi-level secure networking. In this case each SA (or SA bundle) is normally used for only a single instance of sensitivity information. For example, "PROPRIETARY - Internet Engineering" must be associated with a different SA (or SA bundle) from "PROPRIETARY - Finance".
マルチレベルの安全なネットワークを提供するためにEncapsulating Security有効搭載量とAuthentication Headerの両方を適切なSecurity Association方針に結合できます。 この場合、通常、各SA(SAは荷物をまとめる)は感度情報のただ一つのインスタンスだけに使用されます。 例えば、「独占--、インターネット、」 必須を設計して、異なったSAに関連してください、(SAは荷物をまとめます)「独占--、財政、」
8.2 Sensitivity Consistency Checking
8.2 感度一貫性の照合
An MLS implementation (both host and router) MAY associate sensitivity information, or a range of sensitivity information with an interface, or a configured IP address with its associated prefix (the latter is sometimes referred to as a logical interface, or an
MLS実装(ホストとルータの両方)は関連接頭語で感度情報、またはさまざまな感度情報をインタフェース、または構成されたIPアドレスに関連づけるかもしれません。または(後者が時々論理的なインタフェースと呼ばれる。
Kent & Atkinson Standards Track [Page 40] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[40ページ]。
interface alias). If such properties exist, an implementation SHOULD compare the sensitivity information associated with the packet against the sensitivity information associated with the interface or address/prefix from which the packet arrived, or through which the packet will depart. This check will either verify that the sensitivities match, or that the packet's sensitivity falls within the range of the interface or address/prefix.
インタフェース別名) そのような特性が存在しているなら、SHOULDが情報が関連づけた感度を比べる感度情報に対するパケットがパケットが到着したインタフェースかアドレス/接頭語に関連づけたか、またはパケットが出発する実装です。 このチェックは、敏感さが合っているか、またはパケットの感度がインタフェースかアドレス/接頭語の範囲の中に下がることを確かめるでしょう。
The checking SHOULD be done on both inbound and outbound processing.
SHOULDをチェックして、本国行きの、そして、外国行きの両方の処理のときにしてください。
8.3 Additional MLS Attributes for Security Association Databases
8.3 セキュリティ協会データベースのための追加MLS属性
Section 4.4 discussed two Security Association databases (the Security Policy Database (SPD) and the Security Association Database (SAD)) and the associated policy selectors and SA attributes. MLS networking introduces an additional selector/attribute:
セクション4.4は2つのSecurity Associationデータベース(Security Policy Database(SPD)とSecurity Association Database(SAD))、関連方針セレクタ、およびSA属性について論じました。 MLSネットワークは追加セレクタ/属性を導入します:
- Sensitivity information.
- 感度情報。
The Sensitivity information aids in selecting the appropriate algorithms and key strength, so that the traffic gets a level of protection appropriate to its importance or sensitivity as described in section 8.1. The exact syntax of the sensitivity information is implementation defined.
保護のレベルがセクション8.1で説明されるようにトラフィックでその重要性か感度に適切になるための適切なアルゴリズムと主要な強さを選択することにおけるSensitivity情報援助。 感度情報の正確な構文は定義された実装です。
8.4 Additional Inbound Processing Steps for MLS Networking
8.4 MLSネットワークのための追加本国行きの処理ステップ
After an inbound packet has passed through IPsec processing, an MLS implementation SHOULD first check the packet's sensitivity (as defined by the SA (or SA bundle) used for the packet) with the interface or address/prefix as described in section 8.2 before delivering the datagram to an upper-layer protocol or forwarding it.
本国行きのパケットがIPsecに処理、MLSを通した後に、実装SHOULDは最初に、上側の層のプロトコルにデータグラムを提供する前のセクション8.2で説明されるか、またはそれを進めるとしてパケットの感度(パケットに使用されるSA(SAは荷物をまとめる)によって定義されるように)についてインタフェースかアドレス/接頭語に問い合わせます。
The MLS system MUST retain the binding between the data received in an IPsec protected packet and the sensitivity information in the SA or SAs used for processing, so appropriate policy decisions can be made when delivering the datagram to an application or forwarding engine. The means for maintaining this binding are implementation specific.
データグラムをアプリケーションに提供するとき、政策決定をすることができるように処理に中古の、そして、とても適切なSAかSAsのIPsecの保護されたパケットと感度情報を受け取るか、またはエンジンを進めて、MLSシステムはデータの間で結合を保有しなければなりません。 この結合を維持するための手段は実装特有です。
8.5 Additional Outbound Processing Steps for MLS Networking
8.5 MLSネットワークのための追加外国行きの処理ステップ
An MLS implementation of IPsec MUST perform two additional checks besides the normal steps detailed in section 5.1.1. When consulting the SPD or the SAD to find an outbound security association, the MLS implementation MUST use the sensitivity of the data to select an
IPsecのMLS実装はセクション5.1.1で詳細な通常のステップ以外に2つの追加チェックを実行しなければなりません。 外国行きのセキュリティ協会を見つけるためにSPDかSADに相談するとき、MLS実装は選択するデータの感度を使用しなければなりません。
Kent & Atkinson Standards Track [Page 41] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[41ページ]。
appropriate outbound SA or SA bundle. The second check comes before forwarding the packet out to its destination, and is the sensitivity consistency checking described in section 8.2.
適切な外国行きのSAかSAが荷物をまとめます。 2番目のチェックは、目的地への外にパケットを送りながら前に来て、セクション8.2で説明された感度一貫性の照合です。
8.6 Additional MLS Processing for Security Gateways
8.6 セキュリティゲートウェイのための追加MLS処理
An MLS security gateway MUST follow the previously mentioned inbound and outbound processing rules as well as perform some additional processing specific to the intermediate protection of packets in an MLS environment.
MLSセキュリティゲートウェイは、以前に言及された本国行きの、そして、外国行きの処理規則に従って、MLS環境における、パケットの中間的保護に特定の何らかの追加処理を実行しなければなりません。
A security gateway MAY act as an outbound proxy, creating SAs for MLS systems that originate packets forwarded by the gateway. These MLS systems may explicitly label the packets to be forwarded, or the whole originating network may have sensitivity characteristics associated with it. The security gateway MUST create and use appropriate SAs for AH, ESP, or both, to protect such traffic it forwards.
セキュリティゲートウェイは外国行きのプロキシとして務めるかもしれません、ゲートウェイによって進められたパケットを溯源するMLSシステムのためのSAsを作成して。 これらのMLSシステムが明らかに進められるパケットをラベルするかもしれませんか、または全体の起因するネットワークにはそれに関連している感度の特性があるかもしれません。 セキュリティゲートウェイは、それが進めるそのようなトラフィックを保護するのにAH、超能力、または両方のための適切なSAsを作成して、使用しなければなりません。
Similarly such a gateway SHOULD accept and process inbound AH and/or ESP packets and forward appropriately, using explicit packet labeling, or relying on the sensitivity characteristics of the destination network.
同様に、そのようなゲートウェイSHOULDは適切に本国行きのAH、そして/または、超能力パケットとフォワードを受け入れて、処理します、送信先ネットワークの感度の特性をラベルするか、または当てにしながら明白なパケットを使用して。
9. Performance Issues
9. パフォーマンス問題
The use of IPsec imposes computational performance costs on the hosts or security gateways that implement these protocols. These costs are associated with the memory needed for IPsec code and data structures, and the computation of integrity check values, encryption and decryption, and added per-packet handling. The per-packet computational costs will be manifested by increased latency and, possibly, reduced throughout. Use of SA/key management protocols, especially ones that employ public key cryptography, also adds computational performance costs to use of IPsec. These per- association computational costs will be manifested in terms of increased latency in association establishment. For many hosts, it is anticipated that software-based cryptography will not appreciably reduce throughput, but hardware may be required for security gateways (since they represent aggregation points), and for some hosts.
IPsecの使用はこれらのプロトコルを実装するホストかセキュリティゲートウェイに計算性能コストを課します。 これらのコストはIPsecコードとデータ構造に必要であるメモリ、保全チェック値、暗号化、および復号化の計算、および1パケットあたりの加えられた取り扱いに関連しています。 1パケットあたりのコンピュータのコストでは、増強された潜在で表されて、ことによると減少するでしょう。 また、SA/かぎ管理プロトコルの使用(特に公開鍵暗号を使うもの)はIPsecの使用に計算性能コストを加えます。 これら、-、協会のコンピュータのコストは協会設立で増強された潜在で表されるでしょう。 多くのホストに関しては、ソフトウェアベースの暗号がかなりスループットを減らさないと予期されますが、ハードウェアがセキュリティゲートウェイ(彼らが集合ポイントを表すので)、および何人かのホストに必要であるかもしれません。
The use of IPsec also imposes bandwidth utilization costs on transmission, switching, and routing components of the Internet infrastructure, components not implementing IPsec. This is due to the increase in the packet size resulting from the addition of AH and/or ESP headers, AH and ESP tunneling (which adds a second IP header), and the increased packet traffic associated with key management protocols. It is anticipated that, in most instances,
また、IPsecの使用はインターネット基盤(IPsecを実装しないコンポーネント)のトランスミッション、切り換え、およびルーティング成分に帯域幅利用コストを課します。 これはAH、そして/または、超能力ヘッダーと、AHと超能力トンネリングの追加(2番目のIPヘッダーを加える)から生じるパケットサイズ、およびかぎ管理プロトコルに関連している増強されたパケットトラフィックの増加のためです。 それが予期される、ほとんどのインスタンスにおけるそれ
Kent & Atkinson Standards Track [Page 42] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[42ページ]。
this increased bandwidth demand will not noticeably affect the Internet infrastructure. However, in some instances, the effects may be significant, e.g., transmission of ESP encrypted traffic over a dialup link that otherwise would have compressed the traffic.
この増強された帯域幅需要はインターネット基盤に顕著に影響しないでしょう。 しかしながら、ある場合に、効果は重要であるかもしれません、例えば、そうでなければトラフィックを圧縮したダイアルアップリンクの上の超能力の暗号化されたトラフィックの送信。
Note: The initial SA establishment overhead will be felt in the first packet. This delay could impact the transport layer and application. For example, it could cause TCP to retransmit the SYN before the ISAKMP exchange is done. The effect of the delay would be different on UDP than TCP because TCP shouldn't transmit anything other than the SYN until the connection is set up whereas UDP will go ahead and transmit data beyond the first packet.
以下に注意してください。 初期のSA設立オーバーヘッドは最初のパケットで感じられるでしょう。 この遅れはトランスポート層とアプリケーションに影響を与えるかもしれません。 例えば、それで、ISAKMP交換が完了している前にTCPはSYNを再送できました。 遅れの効果はTCPがTCPは接続がセットアップされるまでSYN以外の何でも伝えるべきであるのではなく、UDPを伝えるので最初のパケットを超えて前に進んで、データを送るよりUDPで異なっているでしょう。
Note: As discussed earlier, compression can still be employed at layers above IP. There is an IETF working group (IP Payload Compression Protocol (ippcp)) working on "protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by IPsec protocols."
以下に注意してください。 以前に検討したことであるが、IPの上の層でまだ圧縮を使うことができます。 「ペイロードがそれを暗号化するプロトコルによって処理される前に個々のペイロードに可逆圧縮を実行するのを可能にするプロトコル仕様」に働いているIETFワーキンググループ(IP有効搭載量Compressionプロトコル(ippcp))があります。 「これらの仕様は、圧縮操作がペイロードの暗号化の前にIPsecプロトコルによって実行されるのを許容するでしょう。」
10. Conformance Requirements
10. 順応要件
All IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. All IPv6 systems MUST comply with all requirements of the Security Architecture document.
IPsecを実装すると主張するすべてのIPv4システムがSecurity Architectureドキュメントのすべての要件に従わなければなりません。 すべてのIPv6システムがSecurity Architectureドキュメントのすべての要件に従わなければなりません。
11. Security Considerations
11. セキュリティ問題
The focus of this document is security; hence security considerations permeate this specification.
このドキュメントの焦点はセキュリティです。 したがって、セキュリティ問題はこの仕様を普及させます。
12. Differences from RFC 1825
12. RFC1825からの違い
This architecture document differs substantially from RFC 1825 in detail and in organization, but the fundamental notions are unchanged. This document provides considerable additional detail in terms of compliance specifications. It introduces the SPD and SAD, and the notion of SA selectors. It is aligned with the new versions of AH and ESP, which also differ from their predecessors. Specific requirements for supported combinations of AH and ESP are newly added, as are details of PMTU management.
このアーキテクチャドキュメントは詳細と組織において実質的にRFC1825と異なっていますが、根本的な観念は変わりがありません。 このドキュメントは承諾仕様でかなりの追加詳細を明らかにします。 それはSPD、SAD、およびSAセレクタの概念を紹介します。 それはAHと超能力の新しいバージョンに並べられます。(また、超能力は彼らの前任者と異なっています)。 AHと超能力のサポートしている組み合わせのための決められた一定の要求はPMTU管理の細部のように新たに加えられます。
Kent & Atkinson Standards Track [Page 43] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[43ページ]。
Acknowledgements
承認
Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], and the work done for SNMP Security and SNMPv2 Security.
この仕様に表現された概念の多くはセキュリティプロトコル、ISO/IECのNLSP、提案されたswIPeセキュリティプロトコル[SDNS、ISO、IB93、IBK93]、およびSNMP SecurityとSNMPv2 Securityのために行われた仕事に、引き出されたか、または米国政府のSP3によって影響を及ぼされました。
For over 3 years (although it sometimes seems *much* longer), this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, Harry Varnis, and Nina Yuan.
3年間(*はるかに長い間時々*に見えますが)以上、このドキュメントは複数のバージョンと繰り返しで発展しています。 この間に、多くの人々が重要な考えとエネルギーをプロセスとドキュメント自体に寄付しました。 作者は、仕様のこのバージョンのためのレビュー、編集、バックグラウンド研究、およびコーディネートにおける大規模な助けを提供して頂いて、カレンSeoに感謝したがっています。 また、作者は(アルファベット順に)IPsecのメンバーと取り組みの特記があるIPngワーキンググループに感謝したがっています: スティーブBellovin、スティーブ・デアリング、ジェームス・ヒューズ、フィルKarn、フランクKastenholz、Perryメッツガー、デヴィッドMihelcic、Hilarie Orman、ノーマン・シュルマン、ウィリアム・シンプソン、ハリーVarnis、およびニーナYuan。
Kent & Atkinson Standards Track [Page 44] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[44ページ]。
Appendix A -- Glossary
付録A--用語集
This section provides definitions for several key terms that are employed in this document. Other documents provide additional definitions and background information relevant to this technology, e.g., [VK83, HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms.
このセクションは本書では使われるいくつかの主要な期間、定義を提供します。 他のドキュメントはこの技術、例えば、[VK83、HA94]に関連している追加定義と基礎的な情報を提供します。 この用語集に含まれているのは、ジェネリックセキュリティー・サービスと、セキュリティー対策用語と、IPsec-種の用語です。
Access Control
Access control is a security service that prevents unauthorized
use of a resource, including the prevention of use of a resource
in an unauthorized manner. In the IPsec context, the resource
to which access is being controlled is often:
o for a host, computing cycles or data
o for a security gateway, a network behind the gateway
or
bandwidth on that network.
アクセスControl Accessコントロールはリソースの無断使用を防ぐセキュリティー・サービスです、権限のない方法によるリソースで役に立つ防止を含んでいて。 IPsec文脈では、しばしばアクセスが制御されているリソースは以下の通りです。 o セキュリティゲートウェイへのo、ゲートウェイの後ろのネットワークまたはそれにおける帯域幅がネットワークでつなぐホスト、コンピューティングサイクルまたはデータのために。
Anti-replay
[See "Integrity" below]
反再生[以下の「保全」を見ます]
Authentication
This term is used informally to refer to the combination of two
nominally distinct security services, data origin authentication
and connectionless integrity. See the definitions below for
each of these services.
認証This用語は、2つの名目上は異なったセキュリティー・サービス、データ発生源認証、およびコネクションレスな保全の組み合わせについて言及するのに非公式に使用されます。 それぞれのこれらのサービスに関して以下での定義を見てください。
Availability
Availability, when viewed as a security service, addresses the
security concerns engendered by attacks against networks that
deny or degrade service. For example, in the IPsec context, the
use of anti-replay mechanisms in AH and ESP support
availability.
セキュリティー・サービスとして見なされると、有用性Availabilityは、セキュリティがサービスを否定するか、または下がらせるネットワークに対する攻撃で生み出された関心であると扱います。 例えば、IPsec文脈では、AHと超能力における反再生メカニズムの使用は有用性をサポートします。
Confidentiality
Confidentiality is the security service that protects data from
unauthorized disclosure. The primary confidentiality concern in
most instances is unauthorized disclosure of application level
data, but disclosure of the external characteristics of
communication also can be a concern in some circumstances.
Traffic flow confidentiality is the service that addresses this
latter concern by concealing source and destination addresses,
message length, or frequency of communication. In the IPsec
context, using ESP in tunnel mode, especially at a security
gateway, can provide some level of traffic flow confidentiality.
(See also traffic analysis, below.)
秘密性Confidentialityは不当開示からデータを保護するセキュリティー・サービスです。 プライマリ機密保持の懸念はたいていの場合アプリケーションレベルデータの不当開示ですが、コミュニケーションの外部の特性の公開もいくつかの事情において関心であるかもしれません。 交通の流れ秘密性はコミュニケーションのソースと送付先アドレスか、メッセージ長か、頻度を隠すことによってこの後者の関心を扱うサービスです。 IPsec文脈に、特にセキュリティゲートウェイでトンネルモードで超能力を使用すると、何らかのレベルの交通の流れ秘密性を提供できます。 (また、以下でのトラヒック分析を見ます)
Kent & Atkinson Standards Track [Page 45] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[45ページ]。
Encryption
Encryption is a security mechanism used to transform data from
an intelligible form (plaintext) into an unintelligible form
(ciphertext), to provide confidentiality. The inverse
transformation process is designated "decryption". Oftimes the
term "encryption" is used to generically refer to both
processes.
暗号化Encryptionは、秘密性を提供するためには明瞭なフォーム(平文)からのデータを難解なフォーム(暗号文)に変えるのに使用されるセキュリティー対策です。 逆さの変換プロセスは「復号化」に指定されます。 「暗号化」という期間が一般的に使用されているOftimesは両方のプロセスについて言及します。
Data Origin Authentication
Data origin authentication is a security service that verifies
the identity of the claimed source of data. This service is
usually bundled with connectionless integrity service.
データOrigin Authentication Data発生源認証はデータの要求された源のアイデンティティについて確かめるセキュリティー・サービスです。 通常、このサービスはコネクションレスな保全サービスで添付されます。
Integrity
Integrity is a security service that ensures that modifications
to data are detectable. Integrity comes in various flavors to
match application requirements. IPsec supports two forms of
integrity: connectionless and a form of partial sequence
integrity. Connectionless integrity is a service that detects
modification of an individual IP datagram, without regard to the
ordering of the datagram in a stream of traffic. The form of
partial sequence integrity offered in IPsec is referred to as
anti-replay integrity, and it detects arrival of duplicate IP
datagrams (within a constrained window). This is in contrast to
connection-oriented integrity, which imposes more stringent
sequencing requirements on traffic, e.g., to be able to detect
lost or re-ordered messages. Although authentication and
integrity services often are cited separately, in practice they
are intimately connected and almost always offered in tandem.
保全Integrityはデータへの変更が確実に検出可能になるようにするセキュリティー・サービスです。 保全は、アプリケーション要件を合わせるために様々な風味で登場します。 IPsecは2つのフォームの保全をサポートします: 部分的な系列保全のコネクションレス、そして、aフォーム。 コネクションレスな保全は個々のIPデータグラムの変更を検出するサービスです、トラフィックのストリームにおける、データグラムの注文への尊敬なしで。 IPsecで提供された部分的な系列保全の書式は反再生保全と呼ばれます、そして、それは写しIPデータグラム(強制的な窓の中の)の到着を検出します。 これは接続指向の保全と対照的になっています。保全は、例えば無くなっているか再規則正しいメッセージを検出できるように、より厳しい配列要件をトラフィックに課します。 認証と保全サービスは別々にしばしば引用されますが、それらは、実際には、親密に接続されていて2人乗り自転車でほとんどいつも提供されています。
Security Association (SA)
A simplex (uni-directional) logical connection, created for
security purposes. All traffic traversing an SA is provided the
same security processing. In IPsec, an SA is an internet layer
abstraction implemented through the use of AH or ESP.
シンプレクスの(uni方向)の論理的な接続であって、セキュリティ目的のために作成されたセキュリティAssociation(SA)。 SAを横断するすべてのトラフィックに同じセキュリティ処理を提供します。 IPsecでは、SAはAHか超能力の使用で実装されたインターネット層の抽象化です。
Security Gateway
A security gateway is an intermediate system that acts as the
communications interface between two networks. The set of hosts
(and networks) on the external side of the security gateway is
viewed as untrusted (or less trusted), while the networks and
hosts and on the internal side are viewed as trusted (or more
trusted). The internal subnets and hosts served by a security
gateway are presumed to be trusted by virtue of sharing a
common, local, security administration. (See "Trusted
Subnetwork" below.) In the IPsec context, a security gateway is
a point at which AH and/or ESP is implemented in order to serve
セキュリティゲートウェイAセキュリティゲートウェイはコミュニケーションが2つのネットワークの間で連結するとき作動する中間システムです。 セキュリティゲートウェイの外部の側面の上のホスト(そして、ネットワーク)のセットはネットワークとホストである間、信頼されていない、そして、(それほど信じられません)として見なされます、そして、内部では、側は信じられるように(または、さらに信じられます)見なされます。 一般的で、地方のセキュリティ管理を共有することによってセキュリティゲートウェイによって役立たれる内部サブネットとホストはあえて信じられます。 (以下の「信じられたサブネットワーク」を見てください。) IPsec文脈では、セキュリティゲートウェイはAH、そして/または、超能力が役立つように実装されるポイントです。
Kent & Atkinson Standards Track [Page 46] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[46ページ]。
a set of internal hosts, providing security services for these
hosts when they communicate with external hosts also employing
IPsec (either directly or via another security gateway).
彼らがまた、IPsec(直接かもう1セキュリティ門を通した)を使う外部のホストとコミュニケートするときこれらのホストのためのセキュリティー・サービスを提供する1セットの内部のホスト。
SPI
Acronym for "Security Parameters Index". The combination of a
destination address, a security protocol, and an SPI uniquely
identifies a security association (SA, see above). The SPI is
carried in AH and ESP protocols to enable the receiving system
to select the SA under which a received packet will be
processed. An SPI has only local significance, as defined by
the creator of the SA (usually the receiver of the packet
carrying the SPI); thus an SPI is generally viewed as an opaque
bit string. However, the creator of an SA may choose to
interpret the bits in an SPI to facilitate local processing.
「セキュリティパラメタは索引をつける」SPI頭文字語。 送付先アドレス、セキュリティプロトコル、およびSPIの組み合わせは唯一セキュリティ協会を特定します(SA、上を見てください)。 SPIは、受電方式が容認されたパケットが処理されるSAを選択するのを可能にするためにAHと超能力プロトコルで運ばれます。 SPIには、ローカルの意味しかありません、SA(通常SPIを運ぶパケットの受信機)のクリエイターによって定義されるように。 したがって、一般に、SPIは不明瞭なビット列として見なされます。 しかしながら、SAのクリエイターは、ローカル処理を容易にするためにSPIでビットを解釈するのを選ぶかもしれません。
Traffic Analysis
The analysis of network traffic flow for the purpose of deducing
information that is useful to an adversary. Examples of such
information are frequency of transmission, the identities of the
conversing parties, sizes of packets, flow identifiers, etc.
[Sch94]
ネットワークトラフィックの分析が目的のために敵の役に立つ情報を推論しながら流れるトラフィックAnalysis。 そのような情報に関する例はトランスミッションの頻度、話しパーティーのアイデンティティ、パケットのサイズ、流れ識別子ですなど。 [Sch94]
Trusted Subnetwork
A subnetwork containing hosts and routers that trust each other
not to engage in active or passive attacks. There also is an
assumption that the underlying communications channel (e.g., a
LAN or CAN) isn't being attacked by other means.
ホストを含む信じられたSubnetwork Aサブネットワークと互いがアクティブであるか受け身の攻撃に従事していないと信じるルータ。 また、基本的なコミュニケーションチャンネル(例えば、LANかCAN)が他の手段で攻撃されていないという仮定があります。
Kent & Atkinson Standards Track [Page 47] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[47ページ]。
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues
付録B--PMTU/DF/断片化問題の分析/議論
B.1 DF bit
B.1 DFビット
In cases where a system (host or gateway) adds an encapsulating header (e.g., ESP tunnel), should/must the DF bit in the original packet be copied to the encapsulating header?
システム(ホストかゲートウェイ)が要約のヘッダー(例えば、超能力トンネル)を加える場合では、DFがオリジナルのパケットで噛み付いた/必須は要約のヘッダーにコピーされるべきですか?
Fragmenting seems correct for some situations, e.g., it might be appropriate to fragment packets over a network with a very small MTU, e.g., a packet radio network, or a cellular phone hop to mobile node, rather than propagate back a very small PMTU for use over the rest of the path. In other situations, it might be appropriate to set the DF bit in order to get feedback from later routers about PMTU constraints which require fragmentation. The existence of both of these situations argues for enabling a system to decide whether or not to fragment over a particular network "link", i.e., for requiring an implementation to be able to copy the DF bit (and to process ICMP PMTU messages), but making it an option to be selected on a per interface basis. In other words, an administrator should be able to configure the router's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface.
断片化はいくつかの状況に正しく見えて、例えば、使用のために経路の残りの上で非常に小さいPMTUを伝播して戻すよりむしろ非常に小さいMTU、例えば、パケット無線ネットワークとのネットワークの上でパケットを断片化するか、または携帯電話ホップをモバイルノードに断片化するのが適切であるかもしれません。 他の状況で、DFビットを設定するのは、断片化を必要とするPMTU規制に関して後のルータから反応を得るために適切であるかもしれません。 「リンクしてください」と、これらの状況の両方の存在はシステムが、特定のネットワークの上で断片化するかどうか決めるのを可能にするために主張します、すなわち、実装がDFビットをコピーできるのが(ICMP PMTUメッセージを処理するために)必要ですが、インタフェース基礎あたりのaで選択されるためにそれをオプションにするように。 言い換えれば、管理者はルータのDFビット(はっきりと、カプセル化されたヘッダーからコピーを設定する)の処理を各インタフェースに構成できるべきです。
Note: If a bump-in-the-stack implementation of IPsec attempts to apply different IPsec algorithms based on source/destination ports, it will be difficult to apply Path MTU adjustments.
以下に注意してください。 IPsecのスタックでの隆起実装が、ソース/仕向港に基づく異なったIPsecアルゴリズムを適用するのを試みると、Path MTU調整を適用するのは難しいでしょう。
B.2 Fragmentation
B.2断片化
If required, IP fragmentation occurs after IPsec processing within an IPsec implementation. Thus, transport mode AH or ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied may itself be fragmented by routers en route, and such fragments MUST be reassembled prior to IPsec processing at a receiver. In tunnel mode, AH or ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway, "bump-in-the-stack" (BITS), or "bump- in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to such fragments. Note that BITS or BITW implementations are examples of where a host IPsec implementation might receive fragments to which tunnel mode is to be applied. However, if transport mode is to be applied, then these implementations MUST reassemble the fragments prior to applying IPsec.
必要なら、IP断片化はIPsec処理の後にIPsec実装の中に起こります。 したがって、交通機関AHか超能力が全体のIPデータグラム(IPに断片化しない)だけに適用されます。 AHか超能力が適用されたIPパケットがそうするかもしれない、それ自体、トンネルモードで、AHか超能力がIPパケットに適用されるということになってください。断片化されて、途中ルータ、および断片がそうしなければならないそのようなものによってIPsec処理の前に受信機で組み立て直されてください。そのペイロードは断片化しているIPパケットであるかもしれません。 例えば、セキュリティゲートウェイ、「スタックで突き当たる」(BITS)か「ワイヤで突き当たってください」という(BITW)IPsec実装はトンネルモードAHをそのような断片に適用するかもしれません。 BITSかBITW実装がホストIPsec実装が適用されているトンネルモードがことである断片を受けるかもしれないところに関する例であることに注意してください。 しかしながら、交通機関が適用されていることであるなら、IPsecを適用する前に、これらの実装は断片を組み立て直さなければなりません。
Kent & Atkinson Standards Track [Page 48] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[48ページ]。
NOTE: IPsec always has to figure out what the encapsulating IP header fields are. This is independent of where you insert IPsec and is intrinsic to the definition of IPsec. Therefore any IPsec implementation that is not integrated into an IP implementation must include code to construct the necessary IP headers (e.g., IP2):
以下に注意してください。 IPsecは、いつも要約のIPヘッダーフィールドが何であるかを理解しなければなりません。 これは、あなたがIPsecを挿入するところから独立していて、IPsecの定義に本質的です。 したがって、IP実装と統合されないどんなIPsec実装も必要なIPヘッダー(例えば、IP2)を組み立てるためにコードを含まなければなりません:
o AH-tunnel --> IP2-AH-IP1-Transport-Data
o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer
o AH-トンネル-->IP2-AH-IP1輸送データo超能力トンネル-->IP2超能力_hdr-IP1-輸送データ超能力_トレーラ
*********************************************************************
*********************************************************************
Overall, the fragmentation/reassembly approach described above works for all cases examined.
全体的に見て、ケースが調べた限り、上で説明された断片化/再アセンブリアプローチは働いています。
AH Xport AH Tunnel ESP Xport ESP Tunnel
Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
----------------------- ---- ---- ---- ---- ---- ---- ---- ----
Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y
Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y
S. Gwy (integr w/ IP stack) Y Y Y Y
Outboard crypto processor *
AH Xport AH Tunnel超能力Xport超能力Tunnel ImplementationアプローチIPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6----------------------- ---- ---- ---- ---- ---- ---- ---- ---- (IPスタックがあるintegr)Y Y Y Y Y Y Y Y Hosts(betw/IPとドライバー)Y Y Y Y Y Y Y Y S.Gwy(IPスタックがあるintegr)Y Y Y Y Outboard暗号プロセッサ*を接待します。
* If the crypto processor system has its own IP address, then it
is covered by the security gateway case. This box receives
the packet from the host and performs IPsec processing. It
has to be able to handle the same AH, ESP, and related
IPv4/IPv6 tunnel processing that a security gateway would have
to handle. If it doesn't have it's own address, then it is
similar to the bump-in-the stack implementation between IP and
the network drivers.
* 暗号プロセッサシステムがそれ自身のIP住所を知っているなら、それはセキュリティゲートウェイケースでカバーされています。 この箱は、ホストからパケットを受けて、IPsec処理を実行します。 それは同じAH、超能力、およびセキュリティゲートウェイが扱わなければならない関連するIPv4/IPv6トンネル処理を扱うことができなければなりません。 それにそれのものがないなら、アドレスを所有してください、それが同様であるその時、突き当たる、IPとネットワークドライバーの間の実装を積み重ねてください。
The following analysis assumes that:
以下の分析は、以下のことと仮定します。
1. There is only one IPsec module in a given system's stack.
There isn't an IPsec module A (adding ESP/encryption and
thus) hiding the transport protocol, SRC port, and DEST port
from IPsec module B.
2. There are several places where IPsec could be implemented (as
shown in the table above).
a. Hosts with integration of IPsec into the native IP
implementation. Implementer has access to the source
for the stack.
b. Hosts with bump-in-the-stack implementations, where
IPsec is implemented between IP and the local network
drivers. Source access for stack is not available;
but there are well-defined interfaces that allows the
IPsec code to be incorporated into the system.
1. 1つのIPsecモジュールしか与えられたシステムのスタックにありません。 トランスポート・プロトコルを隠すIPsecモジュールA(その結果、超能力/暗号化を加えます)がありません、SRCポート、そして、DESTはIPsecモジュールからB.2を移植します。 処々方々が. (上の表に示されているように)aであるとIPsecを実装することができたところにあります。 ネイティブのIP実装へのIPsecの統合のホスト。 Implementerはスタックのために. bをソースにアクセスさせます。 スタックでの隆起実装で、IPsecがIPと企業内情報通信網のドライバーの間で実装されるところで接待します。 スタックのためのソースアクセスは利用可能ではありません。 しかし、システムにはそれが法人組織であることをIPsecコードを許容する明確なインタフェースがあります。
Kent & Atkinson Standards Track [Page 49] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[49ページ]。
c. Security gateways and outboard crypto processors with
integration of IPsec into the stack.
3. Not all of the above approaches are feasible in all hosts.
But it was assumed that for each approach, there are some
hosts for whom the approach is feasible.
c。 スタックへのIPsecの統合があるセキュリティゲートウェイと船外の暗号プロセッサ。 3. 上のアプローチのすべてがすべてのホストで可能であるというわけではありません。 しかし、各アプローチを支持して、アプローチが可能である何人かのホストがいると思われました。
For each of the above 3 categories, there are IPv4 and IPv6, AH transport and tunnel modes, and ESP transport and tunnel modes -- for a total of 24 cases (3 x 2 x 4).
それぞれの上の3つのカテゴリのために、合計24のケース(3x2x4)のためのIPv4、IPv6、AH輸送、トンネルモード、超能力輸送、およびトンネルモードがあります。
Some header fields and interface fields are listed here for ease of reference -- they're not in the header order, but instead listed to allow comparison between the columns. (* = not covered by AH authentication. ESP authentication doesn't cover any headers that precede it.)
いくつかのヘッダーフィールドとインタフェース分野がここに参照する場合に便利なように記載されています--それらは、ヘッダー注文に記載されているのではなく、コラムでの比較を許すために代わりに記載されています。 (* = AH認証で、カバーされません。 超能力認証はそれに先行するどんなヘッダーもカバーしていません。)
IP/Transport Interface
IPv4 IPv6 (RFC 1122 -- Sec 3.4)
---- ---- ----------------------
Version = 4 Version = 6
Header Len
*TOS Class,Flow Lbl TOS
Packet Len Payload Len Len
ID ID (optional)
*Flags DF
*Offset
*TTL *Hop Limit TTL
Protocol Next Header
*Checksum
Src Address Src Address Src Address
Dst Address Dst Address Dst Address
Options? Options? Opt
IP/輸送インタフェースIPv4 IPv6(RFC1122--秒3.4)---- ---- ---------------------- 4バージョン=バージョンは6ヘッダーレン*TOSのクラスと等しいです、DF*オフセット*TTL*ホップ限界TTLプロトコル次のヘッダー*チェックサムSrcアドレスSrcアドレスSrcがDstアドレスDstアドレスDstアドレスオプションであると扱うFlow Lbl TOS Packetレン有効搭載量レンレンID ID(任意の)*旗? オプション? 選んでください。
? = AH covers Option-Type and Option-Length, but
might not cover Option-Data.
AHはOption-タイプとOption-長さを含んでいますが、= Option-データをカバーしないかもしれません。
The results for each of the 20 cases is shown below ("works" = will
work if system fragments after outbound IPsec processing, reassembles
before inbound IPsec processing). Notes indicate implementation
issues.
20のケースのそれぞれのための結果は以下に示されます(システムが外国行きのIPsec処理の後に断片化するなら=が扱う「作品」は本国行きのIPsec処理の前に組み立て直されます)。 注意は導入問題を示します。
a. Hosts (integrated into IP stack)
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
a。 (IP1-AH輸送データ)(IPv4)が扱う>(IPv6)がo AH-トンネル-->(IP2-AH-IP1輸送データ)--IPv4を扱うというo AH-輸送が働かせるホスト(IPスタックと統合されます)(IPv6)は働いています。
Kent & Atkinson Standards Track [Page 50] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[50ページ]。
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o (IP1超能力_hdr-輸送データ超能力_トレーラ)(IPv4)が扱う>(IPv6)がo超能力トンネルを扱うという>(IP2超能力_hdr-IP1-輸送データ超能力_トレーラ)(IPv4)が扱う超能力輸送(IPv6)は働いています。
b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and
network drivers. In this case, the IPsec module would have to do
something like one of the following for fragmentation and
reassembly.
- do the fragmentation/reassembly work itself and
send/receive the packet directly to/from the network
layer. In AH or ESP transport mode, this is fine. In AH
or ESP tunnel mode where the tunnel end is at the ultimate
destination, this is fine. But in AH or ESP tunnel modes
where the tunnel end is different from the ultimate
destination and where the source host is multi-homed, this
approach could result in sub-optimal routing because the
IPsec module may be unable to obtain the information
needed (LAN interface and next-hop gateway) to direct the
packet to the appropriate network interface. This is not
a problem if the interface and next-hop gateway are the
same for the ultimate destination and for the tunnel end.
But if they are different, then IPsec would need to know
the LAN interface and the next-hop gateway for the tunnel
end. (Note: The tunnel end (security gateway) is highly
likely to be on the regular path to the ultimate
destination. But there could also be more than one path
to the destination, e.g., the host could be at an
organization with 2 firewalls. And the path being used
could involve the less commonly chosen firewall.) OR
- pass the IPsec'd packet back to the IP layer where an
extra IP header would end up being pre-pended and the
IPsec module would have to check and let IPsec'd fragments
go by.
OR
- pass the packet contents to the IP layer in a form such
that the IP layer recreates an appropriate IP header
b。 ホスト(スタックでは、突き当たります)--IP層とネットワークドライバーの間にIPsecを置いてください。 この場合、IPsecモジュールは断片化のための以下と再アセンブリの1つのようにしなければならないでしょう。 - 直接ネットワーク層からの/にパケットを断片化/再アセンブリ仕事自体をしてください、そして、送るか、または受けてください。 AHか超能力交通機関では、これはすばらしいです。 AHかトンネルエンドが最終仕向地にある超能力トンネルモードで、これはすばらしいです。 AHかトンネルエンドが最終仕向地と異なっていて、送信元ホストがそうである超能力トンネルモード、マルチ、家へ帰り、IPsecモジュールがパケットを指示するのに必要である(LANインタフェースと次のホップゲートウェイ)情報を適切なネットワーク・インターフェースに得ることができないかもしれないので、このアプローチはサブ最適ルーティングをもたらすかもしれません。 インタフェースと次のホップゲートウェイが最終仕向地とトンネルエンドのときに同じであるなら、これは問題ではありません。 しかし、それらが異なるなら、IPsecは、LANインタフェースと次のホップゲートウェイをトンネルエンドに知る必要があるでしょう。 (以下に注意してください。 最終仕向地にはトンネルエンド(セキュリティゲートウェイ)が通常の経路に非常にありそうです。 しかし、また、目的地への1つ以上の経路があるかもしれません、例えば、ホストは2個のファイアウォールによる組織にいるかもしれません。 そして、使用される経路は、より少ない一般的に選ばれたファイアウォールにかかわるかもしれません。) OR--付加的なIPヘッダーが存在に終わるIP層へのパケット後部があらかじめpendedしたならIPsecを渡して、IPsecモジュールはチェックしなければならないでしょう、そして、貸されて、IPsecはチェックしなければならないでしょう。断片は過ぎます。 OR--IP層が適切なIPヘッダーを再作成するように、フォームでのIP層にパケットコンテンツを通過してください。
At the network layer, the IPsec module will have access to the
following selectors from the packet -- SRC address, DST address,
Next Protocol, and if there's a transport layer header --> SRC
port and DST port. One cannot assume IPsec has access to the
Name. It is assumed that the available selector information is
sufficient to figure out the relevant Security Policy entry and
Security Association(s).
ネットワーク層では、IPsecモジュールはパケットから以下のセレクタに近づく手段を持つでしょう。--SRCが扱う、DSTアドレス、Nextプロトコル、あれば、aは層のヘッダーを輸送します-->SRCポートとDSTポート 人は、IPsecがNameに近づく手段を持っていると仮定できません。 利用可能なセレクタ情報が関連Security PolicyエントリーとSecurity Association(s)を見積もるために十分であると思われます。
Kent & Atkinson Standards Track [Page 51] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[51ページ]。
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o (IP1-AH輸送データ)(IPv4)が扱う>(IPv6)がo AH-トンネルを扱うという>(IP2-AH-IP1輸送データ)(IPv4)が扱うAH-輸送(IPv6)は(IP1超能力_hdr-輸送データ超能力_トレーラ)(IPv4)が扱う>(IPv6)がo超能力トンネルを扱うという(IP2超能力_hdr-IP1-輸送データ超能力_トレーラ)(IPv4)が扱う>(IPv6)が扱うo超能力輸送を扱います。
c. Security gateways -- integrate IPsec into the IP stack
c。 セキュリティゲートウェイ--IPスタックとIPsecを統合してください。
NOTE: The IPsec module will have access to the following
selectors from the packet -- SRC address, DST address, Next
Protocol, and if there's a transport layer header --> SRC port
and DST port. It won't have access to the User ID (only Hosts
have access to User ID information.) Unlike some Bump-in-the-
stack implementations, security gateways may be able to look up
the Source Address in the DNS to provide a System Name, e.g., in
situations involving use of dynamically assigned IP addresses in
conjunction with dynamically updated DNS entries. It also won't
have access to the transport layer information if there is an ESP
header, or if it's not the first fragment of a fragmented
message. It is assumed that the available selector information
is sufficient to figure out the relevant Security Policy entry
and Security Association(s).
以下に注意してください。 IPsecモジュールはパケットから以下のセレクタに近づく手段を持つでしょう。--SRCが扱う、DSTアドレス、Nextプロトコル、あれば、aは層のヘッダーを輸送します-->SRCポートとDSTポート それはUser IDに近づく手段を持たないでしょう(HostsだけがUser ID情報に近づく手段を持っています。)。 中のいくらかのBump、-、-スタック実装、セキュリティゲートウェイはSystem Nameを提供するためにDNSでSource Addressを見上げることができるかもしれません、例えば、ダイナミックにアップデートされたDNSエントリーに関連してダイナミックに割り当てられたIPアドレスの使用にかかわる状況で。 また、それは超能力ヘッダーがあるか、または断片化しているメッセージの最初の断片でないならトランスポート層情報に近づく手段を持たないでしょう。 利用可能なセレクタ情報が関連Security PolicyエントリーとSecurity Association(s)を見積もるために十分であると思われます。
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o (IP2-AH-IP1輸送データ)(IPv4)が扱う>(IPv6)がo超能力トンネルを扱うという>(IP2超能力_hdr-IP1-輸送データ超能力_トレーラ)(IPv4)が扱うAH-トンネル(IPv6)は働いています。
**********************************************************************
**********************************************************************
B.3 Path MTU Discovery
B.3経路MTU発見
As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for Path MTU Discovery.
先に述べたように、"ICMP PMTU"は経路MTU発見に使用されるICMPメッセージを示します。
The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2) is:
B.3.1とB.3.3(しかし、B.3.2でない)の以下のダイヤグラムのための伝説は以下の通りです。
==== = security association (AH or ESP, transport or tunnel)
==== = セキュリティ協会(AH、超能力、輸送またはトンネル)
Kent & Atkinson Standards Track [Page 52] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[52ページ]。
---- = connectivity (or if so labelled, administrative boundary)
.... = ICMP message (hereafter referred to as ICMP PMTU) for
---- = 接続性(そのようにラベルされて、管理の境界であるなら)… = ICMPは通信します(今後ICMP PMTUと呼ばれます)。
IPv4:
- Type = 3 (Destination Unreachable)
- Code = 4 (Fragmentation needed and DF set)
- Next-Hop MTU in the low-order 16 bits of the second
word of the ICMP header (labelled unused in RFC 792),
with high-order 16 bits set to zero
IPv4: - ICMPヘッダー(RFC792で未使用であるとラベルされる)の2番目の単語の下位の16ビットで16ビットがゼロに設定する高位で=3(目的地Unreachable)--コード=4(必要である断片化とDFはセットしました)--次のホップMTUをタイプしてください。
IPv6 (RFC 1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed and DF set)
- Next-Hop MTU in the 32 bit MTU field of the ICMP6
IPv6(RFC1885): - =2(パケットToo Big)--コード=0(必要である断片化とDFはセットしました)--次のホップMTUをICMP6の32ビットのMTU分野にタイプしてください。
Hx = host x
Rx = router x
SGx = security gateway x
X* = X supports IPsec
ルータx SGx=セキュリティゲートウェイx X*ホストx Hx=Rx==XはIPsecをサポートします。
B.3.1 Identifying the Originating Host(s)
送信元ホストを特定するB.3.1(s)
The amount of information returned with the ICMP message is limited and this affects what selectors are available to identify security associations, originating hosts, etc. for use in further propagating the PMTU information.
ICMPメッセージと共に返された情報量は限られています、そして、これはどんなセレクタがセキュリティ協会を特定するために利用可能であるかに影響します、さらにPMTU情報を伝播することにおける使用のためにホストなどを溯源して。
In brief... An ICMP message must contain the following information
from the "offending" packet:
- IPv4 (RFC 792) -- IP header plus a minimum of 64 bits
要するに… ICMPメッセージは「怒っている」パケットからの以下の情報を含まなければなりません: - IPv4(RFC792)--IPヘッダーと最低64ビット
Accordingly, in the IPv4 context, an ICMP PMTU may identify only the first (outermost) security association. This is because the ICMP PMTU may contain only 64 bits of the "offending" packet beyond the IP header, which would capture only the first SPI from AH or ESP. In the IPv6 context, an ICMP PMTU will probably provide all the SPIs and the selectors in the IP header, but maybe not the SRC/DST ports (in the transport header) or the encapsulated (TCP, UDP, etc.) protocol. Moreover, if ESP is used, the transport ports and protocol selectors may be encrypted.
それに従って、IPv4文脈では、ICMP PMTUは最初の(一番はずれ)のセキュリティ協会だけを特定するかもしれません。 これはICMP PMTUがIPヘッダーを超えて「怒っている」パケットの64ビットだけを含むかもしれないからです。ヘッダーはAHか超能力から最初のSPIだけをキャプチャするでしょう。 IPv6文脈では、IPヘッダーのSPIsとセレクタをすべてに供給しますが、ICMP PMTUはたぶんポート(輸送ヘッダーの)かカプセル化された(TCP、UDPなど)プロトコルをそうでないかもしれない、SRC/DSTに供給するでしょう。 そのうえ、超能力が使用されているなら、輸送ポートとプロトコルセレクタは暗号化されるかもしれません。
Looking at the diagram below of a security gateway tunnel (as mentioned elsewhere, security gateways do not use transport mode)...
セキュリティゲートウェイについて以下のダイヤグラムを見て、トンネルを堀ってください(別記であるとして、セキュリティゲートウェイは交通機関を使用しません)…
Kent & Atkinson Standards Track [Page 53] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[53ページ]。
H1 =================== H3
\ | | /
H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
/ ^ | \
H2 |........| H4
H1=================== H3\| | /H0--SG1*---- R1---- SG2*---- R2--H5/^| \H2|........| H4
Suppose that the security policy for SG1 is to use a single SA to SG2 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, and H5. And suppose H0 sends a data packet to H5 which causes R1 to send an ICMP PMTU message to SG1. If the PMTU message has only the SPI, SG1 will be able to look up the SA and find the list of possible hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out that H0 sent the traffic that triggered the ICMP PMTU message.
SG1のための安全保障政策がホストのすべてのトラフィックのためのホストのH0と、H1と、H2の間のSG2、H3、H4、およびH5に独身のSAを使用することであると仮定してください。 そして、H0がR1にICMP PMTUメッセージをSG1に送らせるH5にデータ・パケットを送ると仮定してください。 PMTUメッセージにSPIしかないと、SG1はSAを見上げて、可能なホスト(H0、H1、H2、ワイルドカード)のリストを見つけることができるでしょう。 しかし、SG1には、H0がICMP PMTUメッセージの引き金となったトラフィックを送ったのを理解する方法が全くないでしょう。
original after IPsec ICMP
packet processing packet
-------- ----------- ------
IP-3 header (S = R1, D = SG1)
ICMP header (includes PMTU)
IP-2 header IP-2 header (S = SG1, D = SG2)
ESP header minimum of 64 bits of ESP hdr (*)
IP-1 header IP-1 header
TCP header TCP header
TCP data TCP data
ESP trailer
IPsec ICMPパケット処理パケットの後にオリジナルです。-------- ----------- ------ 超能力hdr(*)IP-1ヘッダーIP-1ヘッダーTCPヘッダーTCPヘッダーTCPデータTCPデータ超能力トレーラの64ビットのIP-3ヘッダー(SはR1と等しいです、D=SG1)ICMPヘッダー(PMTUを含んでいる)IP-2ヘッダーIP-2ヘッダー(SはSG1と等しいです、D=SG2)超能力ヘッダー最小限
(*) The 64 bits will include enough of the ESP (or AH) header to
include the SPI.
- ESP -- SPI (32 bits), Seq number (32 bits)
- AH -- Next header (8 bits), Payload Len (8 bits),
Reserved (16 bits), SPI (32 bits)
(*) 64ビットは超能力(または、AH)ヘッダーがSPIを含む十分を含むでしょう。 - 超能力--SPI(32ビット)、Seq番号(32ビット)--AH--次のヘッダー(8ビット)、Payloadレン(8ビット)、Reserved(16ビット)、SPI(32ビット)
This limitation on the amount of information returned with an ICMP message creates a problem in identifying the originating hosts for the packet (so as to know where to further propagate the ICMP PMTU information). If the ICMP message contains only 64 bits of the IPsec header (minimum for IPv4), then the IPsec selectors (e.g., Source and Destination addresses, Next Protocol, Source and Destination ports, etc.) will have been lost. But the ICMP error message will still provide SG1 with the SPI, the PMTU information and the source and destination gateways for the relevant security association.
ICMPメッセージと共に返された情報量におけるこの制限はパケットのために送信元ホストを特定する際に問題を生じさせます(さらにICMP PMTU情報をどこに伝播するかを知るために)。 ICMPメッセージがIPsecヘッダー(IPv4に、最小の)の64ビットだけを含んでいるなら、IPsecセレクタ(例えば、SourceとDestinationアドレスとNextプロトコルとSourceとDestinationポートなど)はなくされてしまうでしょう。 しかし、それでも、ICMPエラーメッセージは関連セキュリティ協会のためにSPI、PMTU情報、ソース、および目的地ゲートウェイをSG1に提供するでしょう。
The destination security gateway and SPI uniquely define a security association which in turn defines a set of possible originating hosts. At this point, SG1 could:
目的地セキュリティゲートウェイとSPIは唯一順番に1セットの可能な送信元ホストを定義するセキュリティ協会を定義します。 ここに、SG1はそうすることができました:
Kent & Atkinson Standards Track [Page 54] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[54ページ]。
a. send the PMTU information to all the possible originating hosts.
This would not work well if the host list is a wild card or if
many/most of the hosts weren't sending to SG1; but it might work
if the SPI/destination/etc mapped to just one or a small number of
hosts.
b. store the PMTU with the SPI/etc and wait until the next packet(s)
arrive from the originating host(s) for the relevant security
association. If it/they are bigger than the PMTU, drop the
packet(s), and compose ICMP PMTU message(s) with the new packet(s)
and the updated PMTU, and send the originating host(s) the ICMP
message(s) about the problem. This involves a delay in notifying
the originating host(s), but avoids the problems of (a).
a. すべての可能な送信元ホストにPMTU情報を送ってください。 これがホストリストがワイルドカードであるならうまくいかなかっただろうか、またはホストの大部分は多くの/であるならSG1に発信していませんでした。 しかし、ホストちょうど1つに写像されたSPI/目的地/などか少ない数のb.が関連セキュリティ協会をSPI/などでPMTUを保存して、次のパケットが送信元ホストから到着するまで待つなら、それは働くかもしれません。 それである、/、彼らは、PMTUより大きく、新しいパケットとアップデートされたPMTUと共にパケットを下げて、ICMP PMTUメッセージを構成して、問題に関してICMPメッセージを送信元ホストに送ります。 これは、送信元ホストに通知する遅れにかかわりますが、(a)の問題を避けます。
Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, then there may be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, and transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field may not be contained in the ICMP message and the use of ESP encryption may hide the selector fields that have been encrypted.
後者のアプローチだけがすべての場合に可能であるので、セキュリティゲートウェイはオプションとしてそのようなサポートを提供しなければなりません。 しかしながら、ICMPメッセージがオリジナルのパケットからの詳しい情報を含んでいるなら、5つの分野(ソースアドレス、送付先アドレス、ソースポート、仕向港、およびトランスポート・プロトコル)がどこでPMTUを保存するか、またはアップデートするかを決定するのに必要である状態ですぐにICMP/PMTUメッセージを伝播して、そのシステムを提供することをどのホストに決定する情報は、十分あるかもしれません。 これでは、セキュリティゲートウェイは、すぐより遠い下であるのからのICMP PMTUを受け取り次第ICMP PMTUメッセージが経路であると生成しなければなりません。 以下に注意してください。 Nextプロトコル分野はICMPメッセージに含まれないかもしれません、そして、超能力暗号化の使用は暗号化されたセレクタ野原を隠すかもしれません。
B.3.2 Calculation of PMTU
PMTUのB.3.2計算
The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPsec header by H1 -- AH and/or ESP transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. (See Section 4.5 Basic Combinations of Security Associations for description of the combinations that MUST be supported). The diagram below illustrates an example of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPx or AHx = transport mode)
ICMP PMTUからのPMTUの計算はH1でどんなIPsecヘッダーの追加も考慮に入れなければなりません--AH、そして/または、超能力輸送、超能力またはAHトンネル。 独身のホストの中では、複数のアプリケーションがSPIを共有するかもしれません、そして、セキュリティ協会の巣篭もりは起こるかもしれません。 (サポートしなければならない組み合わせの記述に関してセクション4.5 Security AssociationsのBasic Combinationsを見ます。) 以下のダイヤグラムは1組のホストの間のセキュリティ協会に関する例を例証します(ホストのひとりの見解から見られるように)。 (ESPxかAHx=交通機関)
Socket 1 -------------------------|
|
Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet
ソケット1-------------------------| | ソケット2、(ESPx/SPI-a)---------- AHx(SPI-B)--インターネット
In order to figure out the PMTU for each socket that maps to SPI-B, it will be necessary to have backpointers from SPI-B to each of the 2 paths that lead to it -- Socket 1 and Socket 2/SPI-A.
それがSPI-Bに写像する各ソケットのためにPMTUを見積もるために、それに通じるそれぞれの2つの経路にSPI-Bからのbackpointersを持つのが必要でしょう--ソケット1とSocket2/SPI-A。
Kent & Atkinson Standards Track [Page 55] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[55ページ]。
B.3.3 Granularity of Maintaining PMTU Data
PMTUデータを保守するB.3.3粒状
In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are three situations that are of interest with respect to PMTU issues:
ホストでは、実装状況によって、PMTU ICMP処理をできる粒状は異なります。 ホストを見て、PMTU問題に関して興味がある3つの状況があります:
a. Integration of IPsec into the native IP implementation
b. Bump-in-the-stack implementations, where IPsec is implemented
"underneath" an existing implementation of a TCP/IP protocol
stack, between the native IP and the local network drivers
c. No IPsec implementation -- This case is included because it is
relevant in cases where a security gateway is sending PMTU
information back to a host.
a。 ネイティブのIP実装bへのIPsecの統合。 スタックでの隆起実装、IPsecが“underneath"であると実装されるところでTCP/IPプロトコルの既存の実装は積み重ねられます、ネイティブのIPと企業内情報通信網のドライバーcの間で。 IPsec実装がありません--それがセキュリティゲートウェイがPMTU情報をホストに送り返している場合で関連しているので、本件は含まれています。
Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In the other cases, the IP layer will maintain PMTU data at the granularity of Source and Destination IP addresses (and optionally TOS/Class), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms). The examples below illustrate this.
場合(a)だけでは、コミュニケーション協会と同じ粒状でPMTUデータを保守できます。 他の場合では、IP層はSourceとDestination IPアドレスの粒状でPMTUデータを保守するでしょう(任意に、TOS/は属します)、RFC1191で説明されるように。 これは重要な違いです、1つ以上のコミュニケーション協会が同じソースと目的地IPにアドレスを写像するかもしれなくて、それぞれのコミュニケーション協会には異なった量のIPsecヘッダーオーバーヘッド(例えば、異なった変換か異なったアルゴリズムの使用による)があるかもしれないので。 以下の例はこれを例証します。
In cases (a) and (b)... Suppose you have the following situation. H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds the PMTU of the network hop between them.
場合(a)と(b)で… 以下の状況があると仮定してください。 H1はH2に発信します、そして、R1からR2に送られるパケットはそれらの間のネットワークホップのPMTUを超えています。
==================================
| |
H1* --- R1 ----- R2 ---- R3 ---- H2*
^ |
|.......|
================================== | | H1*--- R1----- R2---- R3---- H2* ^ | |.......|
If R1 is configured to not fragment subscriber traffic, then R1 sends an ICMP PMTU message with the appropriate PMTU to H1. H1's processing would vary with the nature of the implementation. In case (a) (native IP), the security services are bound to sockets or the equivalent. Here the IP/IPsec implementation in H1 can store/update the PMTU for the associated socket. In case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses and possibly TOS/Class, as noted above. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination.
R1が加入者トラフィックを断片化しないように構成されるなら、R1は適切なPMTUがあるICMP PMTUメッセージをH1に送ります。 H1の処理は実装の本質で異なるでしょう。 場合(a)(ネイティブのIP)では、セキュリティー・サービスはソケットか同等物に向かっています。 ここで、H1のIP/IPsec実装は、関連ソケットのためにPMTUを保存するか、またはアップデートできます。 場合(b)では、PMTUを保存するか、またはアップデートしますが、H1のIP層は単にSource、Destinationアドレス、およびことによるとTOS/クラスの粒状でそうすることができます、上で述べたように。 それで、結果はサブ最適であるかもしれません、与えられたSRC/DST/TOS/クラスのためのPMTUが与えられたソースと目的地とのどんなコミュニケーション仲間にも使用される最も多量のIPsecヘッダーの引き算になるので。
Kent & Atkinson Standards Track [Page 56] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[56ページ]。
In case (c), there has to be a security gateway to have any IPsec processing. So suppose you have the following situation. H1 is sending to H2 and the packet to be sent from SG1 to R exceeds the PMTU of the network hop between them.
場合(c)には、どんなIPsec処理も持つセキュリティゲートウェイがなければなりません。 それで、以下の状況があると仮定してください。 H1はH2に発信します、そして、SG1からRに送られるパケットはそれらの間のネットワークホップのPMTUを超えています。
================
| |
H1 ---- SG1* --- R --- SG2* ---- H2
^ |
|.......|
================ | | H1---- SG1*--- R--- SG2*---- H2^| |.......|
As described above for case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses, and possibly TOS/Class. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination.
ケース(b)のために上で説明されるように、PMTUを保存するか、またはアップデートしますが、H1のIP層はSourceの粒状、Destinationアドレス、およびことによるとTOS/クラスだけで説明できます。 それで、結果はサブ最適であるかもしれません、与えられたSRC/DST/TOS/クラスのためのPMTUが与えられたソースと目的地とのどんなコミュニケーション仲間にも使用される最も多量のIPsecヘッダーの引き算になるので。
B.3.4 Per Socket Maintenance of PMTU Data
PMTUデータのソケットメインテナンスあたりのB.3.4
Implementation of the calculation of PMTU (Section B.3.2) and support for PMTUs at the granularity of individual "communication associations" (Section B.3.3) is a local matter. However, a socket- based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The determination of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message.
個々の「コミュニケーション協会」(セクションB.3.3)の粒状におけるPMTUsのPMTU(セクションB.3.2)とサポートの計算の実装は地域にかかわる事柄です。 しかしながら、ソケットはSHOULDがソケット基礎あたりのaの情報であることを支持するホストでIPsecの実装を基礎づけました。 スタックシステムにおける隆起はホストIP実装にICMP PMTUを渡さなければなりません、どんなIPsecヘッダーオーバーヘッドでもそれを調整するのが、これらのシステムで. 頭上のSHOULDの決断が返されたICMP PMTUメッセージの現在のSPIといかなる他のセレクタ情報の分析でも決定すると言い足した後に。
B.3.5 Delivery of PMTU Data to the Transport Layer
トランスポート層へのPMTUデータのB.3.5配送
The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).
アップデートされたPMTUをトランスポート層に手に入れるためのホストメカニズムは変わりがありません、RFC1191(経路MTUディスカバリー)で指定されるように。
B.3.6 Aging of PMTU Data
PMTUデータで老朽化しているB.3.6
This topic is covered in Section 6.1.2.4.
この話題はセクション6.1.2で.4にカバーされています。
Kent & Atkinson Standards Track [Page 57] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[57ページ]。
Appendix C -- Sequence Space Window Code Example
付録C--系列スペース窓のコードの例
This appendix contains a routine that implements a bitmask check for a 32 packet window. It was provided by James Hughes (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com) and is intended as an implementation example. Note that this code both checks for a replay and updates the window. Thus the algorithm, as shown, should only be called AFTER the packet has been authenticated. Implementers might wish to consider splitting the code to do the check for replays before computing the ICV. If the packet is not a replay, the code would then compute the ICV, (discard any bad packets), and if the packet is OK, update the window.
この付録は32パケット・ウィンドウのためのビットマスクチェックを実装するルーチンを含んでいます。 それは、ジェームス・ヒューズ( jim_hughes@stortek.com )とハリーVarnis( hgv@anubis.network.com )によって提供されて、実装の例として意図します。 このコードが再生がないかどうかチェックして、窓をアップデートすることに注意してください。 したがって、示されるアルゴリズムは呼び止められて、パケットが認証されたということであるにすぎないべきです。 Implementersは、ICVを計算する前に再生のためにチェックするためにコードを分けると考えたがっているかもしれません。 次に、コードがパケットが再生でないなら、ICVを計算するだろう、(どんな悪いパケットも捨てます)、パケットがOKであるなら、窓をアップデートしてください。
#include <stdio.h> #include <stdlib.h> typedef unsigned long u_long;
#長い間、<stdio.h>#インクルードの>のtypedefの未署名の長いu<stdlib.h_を含めてください。
enum {
ReplayWindowSize = 32
};
enum ReplayWindowSize=32。
u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */
u_の長いビットマップ=0。 /*セッション状態--32ビット*/u_の長いlastSeq=0でなければならない。 /*セッション状態*/
/* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq);
*が禁じられたパケット、1であるならパケットであるなら0を返す/は*/int ChkReplayWindow(_u長いseq)を可能にしました。
int ChkReplayWindow(u_long seq) {
u_long diff;
int ChkReplayWindow(_u長いseq)、u_の長いデフ。
if (seq == 0) return 0; /* first == 0 or wrapped */
if (seq > lastSeq) { /* new larger sequence number */
diff = seq - lastSeq;
if (diff < ReplayWindowSize) { /* In window */
bitmap <<= diff;
bitmap |= 1; /* set bit for this packet */
} else bitmap = 1; /* This packet has a "way larger" */
lastSeq = seq;
return 1; /* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
bitmap |= ((u_long)1 << diff); /* mark as seen */
return 1; /* out of order but good */
}
(seq=0)が0を返すなら。 /*新しいより大きい一連番号*/デフはseqと等しいです--lastSeq、このパケット*/のための*窓の*/ビットマップ<<=デフ; ビットマップ| =1;/設定しているビットの(デフ<ReplayWindowSize)/*であるなら、ビットマップはほかの1と等しいです; 「ずっと大きい」*/lastSeq=がこのパケットでseqする/*; 1;/に*をより大きい状態で返すのは、良い*/です。/*最初の=0、(seq>lastSeq)であるなら*/を包装する、デフはlastSeqと等しいです--seq (デフ>=ReplayWindowSize)が0を返すなら。 /*古過ぎるか包装された*/は(ビットマップと(u_長さ)1<<デフ)であるなら0を返します。 /*既に目にふれている*/ビットマップ|= ((u_長さ)1<<デフ)。 見られた*/リターン1としての/*マーク。 /*故障していますが、良い*/
char string_buffer[512];
ストリング_バッファ[512]を炭にしてください。
Kent & Atkinson Standards Track [Page 58] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[58ページ]。
#define STRING_BUFFER_SIZE sizeof(string_buffer)
#STRING_BUFFER_SIZE sizeofを定義してください。(ストリング_バッファ)
int main() {
int result;
u_long last, current, bits;
intメイン()、int結果(u_長い最後の、そして、現在のビット)
printf("Input initial state (bits in hex, last msgnum):\n");
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last);
if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
printf("Input value to test (current):\n");
printf(「初期状態(十六進法におけるビット、最後のmsgnum): \nを入力します」)。 (fgets(ストリング_バッファ、STRING_BUFFER_SIZE、stdin))が(0)を出るなら。 「sscanf、(ストリング_バッファ、」、%lx、%Lu、」 ビット、および最終である、)、。 (最終!=0)ビットです。|= 1; ビットマップ=ビット。 lastSeq=は持続します。 printf、(「ビット: 08lxが持続する%:、%、Lu\n」、ビットマップ、lastSeq)、。 printf(「テストする(現在の)入力値: \n」)。
while (1) {
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", ¤t);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
}
return 0;
}
「(1)である、(fgets(_バッファを結んでください、STRING_BUFFER_SIZE、stdin))中断; sscanfする、(ストリング_バッファ、」、%Lu、」、¤t); なる=ChkReplayWindow(現在の); printf(結果--「%-3s」、「悪い」状態で以下を「承認する」); printf、(「ビット: 08lxが持続する%:、%、Lu\n」、ビットマップ、lastSeq)、;、リターン0。 }
Kent & Atkinson Standards Track [Page 59] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[59ページ]。
Appendix D -- Categorization of ICMP messages
付録D--ICMPメッセージの分類
The tables below characterize ICMP messages as being either host generated, router generated, both, unassigned/unknown. The first set are IPv4. The second set are IPv6.
以下のテーブルはどちらかのホストであるとしてのメッセージが生成したICMP、ともに割り当てられないか、または未知で生成されたルータを特徴付けます。 第一セットはIPv4です。 2番目のセットはIPv6です。
IPv4
IPv4
Type Name/Codes Reference
========================================================================
HOST GENERATED:
3 Destination Unreachable
2 Protocol Unreachable [RFC792]
3 Port Unreachable [RFC792]
8 Source Host Isolated [RFC792]
14 Host Precedence Violation [RFC1812]
10 Router Selection [RFC1256]
型名/コード参照======================================================================== ホストは生成しました: 3 目的地手の届かない2のプロトコルの手の届かない[RFC792]3ポートの手の届かない[RFC792]8送信元ホストの孤立している[RFC792]14ホスト先行違反[RFC1812]10ルータ選択[RFC1256]
Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
3 Destination Unreachable
0 Net Unreachable [RFC792]
4 Fragmentation Needed, Don't Fragment was Set [RFC792]
5 Source Route Failed [RFC792]
6 Destination Network Unknown [RFC792]
7 Destination Host Unknown [RFC792]
9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792]
11 Destination Network Unreachable for Type of Service[RFC792]
5 Redirect
0 Redirect Datagram for the Network (or subnet) [RFC792]
2 Redirect Datagram for the Type of Service & Network[RFC792]
9 Router Advertisement [RFC1256]
18 Address Mask Reply [RFC950]
型名/コード参照======================================================================== ルータは生成しました: Unreachable[RFC792]4Fragmentationが必要とした3目的地Unreachable0ネット、Fragmentではなく、ドンがSet[RFC792]5Source Route Failed[RFC792]6Destination Network Unknown[RFC792]でした。7Destination Host Unknown[RFC792]9Comm Destと共に。 網状になってください。Administratively Prohibited[RFC792]はService&Network[RFC792]9Router Advertisement[RFC1256]18Address Mask ReplyのTypeのためのNetwork(または、サブネット)[RFC792]2RedirectデータグラムのためのService[RFC792]5Redirect0RedirectデータグラムのTypeのための11Destination Network Unreachableですか?[RFC950]
Kent & Atkinson Standards Track [Page 60] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[60ページ]。
IPv4
Type Name/Codes Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
0 Echo Reply [RFC792]
3 Destination Unreachable
1 Host Unreachable [RFC792]
10 Comm. w/Dest. Host is Administratively Prohibited [RFC792]
12 Destination Host Unreachable for Type of Service [RFC792]
13 Communication Administratively Prohibited [RFC1812]
15 Precedence cutoff in effect [RFC1812]
4 Source Quench [RFC792]
5 Redirect
1 Redirect Datagram for the Host [RFC792]
3 Redirect Datagram for the Type of Service and Host [RFC792]
6 Alternate Host Address [JBP]
8 Echo [RFC792]
11 Time Exceeded [RFC792]
12 Parameter Problem [RFC792,RFC1108]
13 Timestamp [RFC792]
14 Timestamp Reply [RFC792]
15 Information Request [RFC792]
16 Information Reply [RFC792]
17 Address Mask Request [RFC950]
30 Traceroute [RFC1393]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [Johnson]
39 SKIP [Markson]
40 Photuris [Simpson]
IPv4型名/コード参照======================================================================== ルータとホストの両方が生成しました: 0 目的地1人のエコー・リプライ[RFC792]3手の届かないホストの手の届かない[RFC792]10Comm Destと共に。 ホスト、事実上、Service RFC792 13Communication Administratively Prohibited RFC1812 15 Precedence締切りのTypeのためのAdministratively Prohibited RFC792 12Destination Host UnreachableはServiceとHost RFC792 6Alternate Host Address JBP8Echo RFC792 11Time Exceeded RFC792 12Parameter Problem RFC792のTypeのためのHost RFC792 3RedirectデータグラムのためのRFC1812 4Source Quench RFC792 5Redirect1Redirectデータグラムです; RFC1108 13タイムスタンプRFC792 14タイムスタンプ回答RFC792 15情報要求RFC792 16情報回答RFC792 17アドレスマスク要求RFC950 30の変換の誤りのRFC1475 32のモバイルホストの再直接のトレースルートRFC1393 31データグラムペニス39はMarkson40Photurisをスキップします。[シンプソン]
Type Name/Codes Reference ======================================================================== UNASSIGNED TYPE OR UNKNOWN GENERATOR: 1 Unassigned [JBP] 2 Unassigned [JBP] 7 Unassigned [JBP] 19 Reserved (for Security) [Solo] 20-29 Reserved (for Robustness Experiment) [ZSu] 33 IPv6 Where-Are-You [Simpson] 34 IPv6 I-Am-Here [Simpson] 35 Mobile Registration Request [Simpson] 36 Mobile Registration Reply [Simpson] 37 Domain Name Request [Simpson] 38 Domain Name Reply [Simpson] 41-255 Reserved [JBP]
型名/コード参照======================================================================== 割り当てられなかったタイプか未知のジェネレータ: 1 割り当てられなかった20-29に予約された(セキュリティのために)[独奏][JBP]19が割り当てられなかった[JBP]7が割り当てられなかった[JBP]2は[シンプソン]41-255が控えたあなたがどこにいるか[ZSu]33IPv6[シンプソン]34IPv6 Iがここにある[シンプソン]35のモバイル登録要求[シンプソン]の36のモバイル登録回答[シンプソン]37ドメイン名要求[シンプソン]38ドメイン名回答を控えました(丈夫さ実験のために)。[JBP]
Kent & Atkinson Standards Track [Page 61] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[61ページ]。
IPv6
IPv6
Type Name/Codes Reference
========================================================================
HOST GENERATED:
1 Destination Unreachable [RFC 1885]
4 Port Unreachable
型名/コード参照======================================================================== ホストは生成しました: 1つの目的地の手の届かない[RFC1885]4ポート手が届きません。
Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
1 Destination Unreachable [RFC1885]
0 No Route to Destination
1 Comm. w/Destination is Administratively Prohibited
2 Not a Neighbor
3 Address Unreachable
2 Packet Too Big [RFC1885]
0
型名/コード参照======================================================================== ルータは生成しました: Destinationへの1つの目的地Unreachable[RFC1885]0ノーRoute、1Comm、Destinationと共に、Administratively Prohibited2Not a Neighbor3Address Unreachable2Packet Too Big[RFC1885]0があります。
3 Time Exceeded [RFC1885]
0 Hop Limit Exceeded in Transit
1 Fragment reassembly time exceeded
3Transitの1Fragment reassemblyの回の間のExceeded[RFC1885]0Hop Limit Exceededが超えていた時間
Type Name/Codes Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
4 Parameter Problem [RFC1885]
0 Erroneous Header Field Encountered
1 Unrecognized Next Header Type Encountered
2 Unrecognized IPv6 Option Encountered
型名/コード参照======================================================================== ルータとホストの両方が生成しました: 4 パラメタ問題[RFC1885]0誤ったヘッダーフィールドは遭遇している2認識されていないIPv6オプションが遭遇した次の1つの認識されていないヘッダータイプに遭遇しました。
Kent & Atkinson Standards Track [Page 62] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[62ページ]。
References
参照
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
Mathematical Foundations and Model", Technical Report M74-
244, The MITRE Corporation, Bedford, MA, May 1973.
[BL73]ベルとD.E.とLaPadula、L.J.、「コンピュータシステムズを機密保護してください」 「数学の財団とモデル」、技術報告書M74 244、斜め継ぎ社、ベッドフォード、MAは1973がそうするかもしれません。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97] ブラドナー、S.、「Indicate Requirement LevelへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[DoD85] US National Computer Security Center, "Department of
Defense Trusted Computer System Evaluation Criteria", DoD
5200.28-STD, US Department of Defense, Ft. Meade, MD.,
December 1985.
[DoD85]米国の国家のコンピュータセキュリティセンター、「国防総省はコンピュータシステム評価を信じました」、DoD 5200.28-STD、米国国防総省フィート ミード(MD)、12月1985日
[DoD87] US National Computer Security Center, "Trusted Network
Interpretation of the Trusted Computer System Evaluation
Criteria", NCSC-TG-005, Version 1, US Department of
Defense, Ft. Meade, MD., 31 July 1987.
[DoD87]米国の国家のコンピュータセキュリティセンター、「信じられたコンピュータシステム評価の信じられたネットワーク解釈」、NCSC-TG-005、バージョン1、米国国防総省、フィート ミード(MD)、1987年7月31日。
[HA94] Haller, N., and R. Atkinson, "On Internet Authentication",
RFC 1704, October 1994.
[HA94] ハラー、N.とR.アトキンソン、「インターネット認証」、RFC1704、1994年10月。
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[HC98]ハーキン、D.、およびD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[HM97] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, July 1997.
[HM97] ハーニー、H.、およびC.Muckenhirn、「グループKey Managementプロトコル(GKMP)アーキテクチャ」、RFC2094、1997年7月。
[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[ISO] ISO/IEC JTC1/SC6、ネットワーク層セキュリティプロトコル、ISO-IEC不-11577、世界規格機構、ジュネーブ(スイス)1992年11月29日。
[IB93] John Ioannidis and Matt Blaze, "Architecture and
Implementation of Network-layer Security Under Unix",
Proceedings of USENIX Security Symposium, Santa Clara, CA,
October 1993.
[IB93]のジョンIoannidisとマットBlazeと、「ネットワーク層セキュリティ下のunixのアーキテクチャと実装」、USENIXセキュリティシンポジウム(サンタクララ(カリフォルニア)1993年10月)の議事
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-
Layer Security for IP", presentation at the Spring 1993
IETF Meeting, Columbus, Ohio
[IBK93]ジョンIoannidis(マット炎、およびフィルKarn)は「以下を強打します」。 「IPのためのネットワーク層のSecurity」、Spring1993IETF Meeting、コロンブス、オハイオでのプレゼンテーション
[KA98a] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[KA98a] ケント、S.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[KA98b]ケント、S.、およびR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
Kent & Atkinson Standards Track [Page 63] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[63ページ]。
[Ken91] Kent, S., "US DoD Security Options for the Internet
Protocol", RFC 1108, November 1991.
[Ken91] ケント、S.、「インターネットプロトコルのための米国のDoDセキュリティオプション」、RFC1108、1991年11月。
[MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[MSST97] Maughan、D.、Schertler、M.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
[Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[Orm97] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、1998年11月。
[Pip98] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[Pip98]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John
Wiley & Sons, New York, NY, 1994.
[Sch94]ブルース・シュナイアー、適用された暗号、セクション8.6、ジョン・ワイリー、および息子、ニューヨーク(ニューヨーク)1994。
[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, published in
NIST Publication NIST-IR-90-4250, February 1990.
[SDNS]SDNS Secure Data Network System、Securityプロトコル3、SP3、Document SDN.301、Revision1.5(1989年5月15日)はNIST Publication NIST IR90-4250(1990年2月)で発行しました。
[SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, August
1998.
[SMPT98]Shacham、A.、Monsour、R.、ペレイラ、R.、およびM.トーマス、「IP有効搭載量圧縮プロトコル(IPComp)」、RFC2393 1998年8月。
[TDG97] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[TDG97] セイヤーとR.とDoraswamy、N.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-
level Networks", ACM Computing Surveys, Vol. 15, No. 2,
June 1983.
[VK83]V.L.VoydockとS.T.ケント、「HighのセキュリティMechanismsはNetworksを平らにします」、ACM Computing Surveys、Vol.15、No.2、1983年6月。
Disclaimer
注意書き
The views and specification expressed in this document are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this design.
本書では言い表された視点と仕様は、作者のものであり、必ず彼らの雇い主のものであるというわけではありません。 作者と彼らの雇い主はこのデザインの正しいか不正確な実装か使用から起こることにおけるどんな問題によっても明確に責任を拒否します。
Kent & Atkinson Standards Track [Page 64] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[64ページ]。
Author Information
作者情報
Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA
スティーブンケントBBN社70のフォーセット・通りMA02140ケンブリッジ(米国)
Phone: +1 (617) 873-3988 EMail: kent@bbn.com
以下に電話をしてください。 +1 (617) 873-3988 メールしてください: kent@bbn.com
Randall Atkinson @Home Network 425 Broadway Redwood City, CA 94063 USA
ランドルアトキンソン@Home Network425ブロードウェイカリフォルニア94063レッドウッドシティー(米国)
Phone: +1 (415) 569-5000 EMail: rja@corp.home.net
以下に電話をしてください。 +1 (415) 569-5000 メールしてください: rja@corp.home.net
Kent & Atkinson Standards Track [Page 65] RFC 2401 Security Architecture for IP November 1998
ケントとアトキンソンStandardsは1998年11月にIPのためにRFC2401セキュリティー体系を追跡します[65ページ]。
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Kent & Atkinson Standards Track [Page 66]
ケントとアトキンソン標準化過程[66ページ]
一覧
スポンサーリンク
