RFC4301 日本語訳
4301 Security Architecture for the Internet Protocol. S. Kent, K. Seo. December 2005. (Format: TXT=262123 bytes) (Obsoletes RFC2401) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Kent Request for Comments: 4301 K. Seo Obsoletes: 2401 BBN Technologies Category: Standards Track December 2005
コメントを求めるワーキンググループS.ケント要求をネットワークでつないでください: 4301K.Seoは以下を時代遅れにします。 2401年のBBN技術カテゴリ: 標準化過程2005年12月
Security Architecture for the Internet Protocol
インターネットプロトコルのためのセキュリティー体系
Status of This 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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998).
このドキュメントはIP層のトラフィックのためのセキュリティー・サービスを提供するように設計されている「IPのためのセキュリティー体系」のアップデートされたバージョンについて説明します。 このドキュメントはRFC2401(1998年11月)を時代遅れにします。
Dedication
奉納
This document is dedicated to the memory of Charlie Lynn, a long-time senior colleague at BBN, who made very significant contributions to the IPsec documents.
このドキュメントはチャーリーリンのメモリ、BBNのIPsecドキュメントへの非常に重要な貢献をした長年の先任の同僚に捧げられます。
Kent & Seo Standards Track [Page 1] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Summary of Contents of Document ............................4
1.2. Audience ...................................................4
1.3. Related Documents ..........................................5
2. Design Objectives ...............................................5
2.1. Goals/Objectives/Requirements/Problem Description ..........5
2.2. Caveats and Assumptions ....................................6
3. System Overview .................................................7
3.1. What IPsec Does ............................................7
3.2. How IPsec Works ............................................9
3.3. Where IPsec Can Be Implemented ............................10
4. Security Associations ..........................................11
4.1. Definition and Scope ......................................12
4.2. SA Functionality ..........................................16
4.3. Combining SAs .............................................17
4.4. Major IPsec Databases .....................................18
4.4.1. The Security Policy Database (SPD) .................19
4.4.1.1. Selectors .................................26
4.4.1.2. Structure of an SPD Entry .................30
4.4.1.3. More Regarding Fields Associated
with Next Layer Protocols .................32
4.4.2. Security Association Database (SAD) ................34
4.4.2.1. Data Items in the SAD .....................36
4.4.2.2. Relationship between SPD, PFP
flag, packet, and SAD .....................38
4.4.3. Peer Authorization Database (PAD) ..................43
4.4.3.1. PAD Entry IDs and Matching Rules ..........44
4.4.3.2. IKE Peer Authentication Data ..............45
4.4.3.3. Child SA Authorization Data ...............46
4.4.3.4. How the PAD Is Used .......................46
4.5. SA and Key Management .....................................47
4.5.1. Manual Techniques ..................................48
4.5.2. Automated SA and Key Management ....................48
4.5.3. Locating a Security Gateway ........................49
4.6. SAs and Multicast .........................................50
5. IP Traffic Processing ..........................................50
5.1. Outbound IP Traffic Processing
(protected-to-unprotected) ................................52
5.1.1. Handling an Outbound Packet That Must Be
Discarded ..........................................54
5.1.2. Header Construction for Tunnel Mode ................55
5.1.2.1. IPv4: Header Construction for
Tunnel Mode ...............................57
5.1.2.2. IPv6: Header Construction for
Tunnel Mode ...............................59
5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59
1. 序論…4 1.1. ドキュメントのコンテンツの概要…4 1.2. 聴衆…4 1.3. ドキュメントについて話します…5 2. 目的を設計してください…5 2.1. Goals/Objectives/Requirements/問題記述…5 2.2. 警告と仮定…6 3. システム概要…7 3.1. IPsecがすること…7 3.2. どのようにIPsecは働いているか…9 3.3. IPsecを実装することができるところ…10 4. セキュリティ協会…11 4.1. 定義と範囲…12 4.2. SAの機能性…16 4.3. SAsを結合します…17 4.4. 主要なIPsecデータベース…18 4.4.1. 安全保障政策データベース(SPD)…19 4.4.1.1. セレクタ…26 4.4.1.2. SPDエントリーの構造…30 4.4.1.3. 分野に関する以上は次の層のプロトコルと交際しました…32 4.4.2. セキュリティ協会データベース(悲しい)…34 4.4.2.1. 悲しさのデータ項目…36 4.4.2.2. SPDと、PFP旗と、パケットと、SADとの関係…38 4.4.3. 同輩承認データベース(パッド)…43 4.4.3.1. エントリーIDと合っている規則を水増ししてください…44 4.4.3.2. IKE同輩認証データ…45 4.4.3.3. 子供SA承認データ…46 4.4.3.4. パッドはどう使用されているか…46 4.5. SAと主要な管理…47 4.5.1. 手動のテクニック…48 4.5.2. 自動化されたSAとKey Management…48 4.5.3. セキュリティゲートウェイの場所を見つけます…49 4.6. SAsとマルチキャスト…50 5. IPトラフィック処理…50 5.1. 外国行きのIPトラフィック処理(保護のなく保護されます)…52 5.1.1. 外国行きのパケットを扱って、それを捨てなければなりません…54 5.1.2. トンネル・モードのためのヘッダー工事…55 5.1.2.1. IPv4: トンネル・モードのためのヘッダー工事…57 5.1.2.2. IPv6: トンネル・モードのためのヘッダー工事…59 5.2. 本国行きのIPトラフィック(保護されるのに保護のない)を処理します。59
Kent & Seo Standards Track [Page 2] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[2ページ]。
6. ICMP Processing ................................................63
6.1. Processing ICMP Error Messages Directed to an
IPsec Implementation ......................................63
6.1.1. ICMP Error Messages Received on the
Unprotected Side of the Boundary ...................63
6.1.2. ICMP Error Messages Received on the
Protected Side of the Boundary .....................64
6.2. Processing Protected, Transit ICMP Error Messages .........64
7. Handling Fragments (on the protected side of the IPsec
boundary) ......................................................66
7.1. Tunnel Mode SAs that Carry Initial and Non-Initial
Fragments .................................................67
7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67
7.3. Stateful Fragment Checking ................................68
7.4. BYPASS/DISCARD Traffic ....................................69
8. Path MTU/DF Processing .........................................69
8.1. DF Bit ....................................................69
8.2. Path MTU (PMTU) Discovery .................................70
8.2.1. Propagation of PMTU ................................70
8.2.2. PMTU Aging .........................................71
9. Auditing .......................................................71
10. Conformance Requirements ......................................71
11. Security Considerations .......................................72
12. IANA Considerations ...........................................72
13. Differences from RFC 2401 .....................................72
14. Acknowledgements ..............................................75
Appendix A: Glossary ..............................................76
Appendix B: Decorrelation .........................................79
B.1. Decorrelation Algorithm ...................................79
Appendix C: ASN.1 for an SPD Entry ................................82
Appendix D: Fragment Handling Rationale ...........................88
D.1. Transport Mode and Fragments ..............................88
D.2. Tunnel Mode and Fragments .................................89
D.3. The Problem of Non-Initial Fragments ......................90
D.4. BYPASS/DISCARD Traffic ....................................93
D.5. Just say no to ports? .....................................94
D.6. Other Suggested Solutions..................................94
D.7. Consistency................................................95
D.8. Conclusions................................................95
Appendix E: Example of Supporting Nested SAs via SPD and
Forwarding Table Entries...............................96
References.........................................................98
Normative References............................................98
Informative References..........................................99
6. ICMP処理…63 6.1. IPsec実装に向けられた処理ICMPエラーメッセージ…63 6.1.1. ICMPエラーメッセージは境界保護のない側で受信されました…63 6.1.2. ICMPエラーメッセージは境界保護側で受信されました…64 6.2. 処理は保護されて、トランジットICMPはエラーメッセージです…64 7. 取り扱いFragments(IPsec境界保護側の)…66 7.1. ModeのSAsのそのCarry Initialの、そして、Non初期のFragmentsにトンネルを堀ってください…67 7.2. 非初期の断片のためにトンネル・モードSAsを切り離してください…67 7.3. Statefulは照合を断片化します…68 7.4. トラフィックを迂回するか、または捨ててください…69 8. 経路MTU/DF処理…69 8.1. DFは噛み付きました…69 8.2. 経路MTU(PMTU)発見…70 8.2.1. PMTUの伝播…70 8.2.2. PMTUの年をとること…71 9. 監査します。71 10. 順応要件…71 11. セキュリティ問題…72 12. IANA問題…72 13. RFC2401からの違い…72 14. 承認…75 付録A: 用語集…76 付録B: Decorrelation…79 B.1。 Decorrelationアルゴリズム…79 付録C: SPDエントリーへのASN.1…82 付録D: 取り扱い原理を断片化してください…88 D.1。 モードと断片を輸送してください…88 D.2。 モードと断片にトンネルを堀ってください…89 D.3。 非初期の断片の問題…90 D.4。 トラフィックを迂回するか、または捨ててください…93 D.5。 ただ、ポートを断りますか? .....................................94 D.6。 他の提案されたソリューション…94 D.7。 一貫性…95 D.8。 結論…95 付録E: SPDとForwarding Table Entriesを通したSupporting Nested SAsに関する例…96の参照箇所…98 標準の参照…98 有益な参照…99
Kent & Seo Standards Track [Page 3] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[3ページ]。
1. Introduction
1. 序論
1.1. Summary of Contents of Document
1.1. ドキュメントのコンテンツの概要
This document specifies the base architecture for IPsec-compliant systems. It describes how to provide a set of security services for traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98] environments. This document describes the requirements for systems that implement IPsec, the fundamental elements of such systems, and how the elements fit together and fit 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 the IPsec architecture. Other documents address additional architectural details in specialized environments, e.g., use of IPsec in Network Address Translation (NAT) environments and more comprehensive support for IP multicast. The 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層のトラフィックのための1セットのセキュリティー・サービスを提供する方法を説明します、両方のIPv4[Pos81a]とIPv6[DH98]環境で。 このドキュメントは要素がどうIP環境をIPsecを実装するシステムと、そのようなシステムの基本的な原理と、合わせて、収まるか要件について説明します。 また、それはIPsecプロトコルによって提供されたセキュリティー・サービスと、IP環境でどうこれらのサービスを使うことができるかを説明します。 このドキュメントはIPsecアーキテクチャの全面を扱いません。 他のドキュメントはIPマルチキャストのNetwork Address Translation(NAT)環境と、より包括的なサポートで専門化している環境における追加建築詳細、例えばIPsecの使用を扱います。 それらの基本的で、必要な機能性で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 automated (The Internet Key
Exchange (IKE))
d. Cryptographic algorithms for authentication and encryption
a。 セキュリティプロトコル--認証Header(AH)とEncapsulating Security有効搭載量(超能力)b。 彼らはそうであり、どのようにが彼らであるか。セキュリティAssociations--、こと、仕事、彼らはどう管理されて、関連している処理cであるか。 Key Management--手動の、そして、自動化された(インターネット・キー・エクスチェンジ(IKE))d。 認証と暗号化のための暗号アルゴリズム
This document is not a 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 spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec (e.g., IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of the sequence of letters "IPsec" should be understood to refer to the IPsec protocols.
スペル"IPsec"は、これとすべての関連するIPsec規格中で好まれて、使用されます。 IPsec(例えば、IPSEC、IPSec、ipsec)の他のすべての資源化が推奨しないです。 しかしながら、"IPsec"という手紙の系列のどんな資源化もIPsecプロトコルを示すのが理解されるべきです。
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 is primarily individuals who implement this IP security technology or who architect systems that will use this technology. Technically adept users of this technology
または、このドキュメントのための対象者が主としてこのIPセキュリティが技術であると実装する個人である、だれ、この技術を使用する建築家システム。 この技術の技術的に手際のユーザ
Kent & Seo Standards Track [Page 4] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[4ページ]。
(end users or system administrators) also are part of the target audience. A glossary is provided in Appendix A to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol (IP), related networking technology, and general information system security terms and concepts.
(エンドユーザかシステム管理者)も対象者の一部です。 バックグラウンド/ボキャブラリーの不足に記入するのを助けるためにAppendix Aに用語集を提供します。 このドキュメントは、読者がインターネットプロトコル(IP)、関連するネットワーク・テクノロジー、一般情報システムセキュリティ用語、および概念に詳しいと仮定します。
1.3. Related Documents
1.3. 関連ドキュメント
As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their interrelationship. They include RFCs on the following topics:
以上のように、他のドキュメントはIPsecのいくつかの部品とそれらの相互関係での詳細な定義を提供します。 彼らは以下の話題のRFCsを含んでいます:
a. security protocols -- RFCs describing the Authentication
Header (AH) [Ken05b] and Encapsulating Security Payload
(ESP) [Ken05a] protocols.
b. cryptographic algorithms for integrity and encryption -- one
RFC that defines the mandatory, default algorithms for use
with AH and ESP [Eas05], a similar RFC that defines the
mandatory algorithms for use with IKEv2 [Sch05] plus a
separate RFC for each cryptographic algorithm.
c. automatic key management -- RFCs on "The Internet Key
Exchange (IKEv2) Protocol" [Kau05] and "Cryptographic
Algorithms for Use in the Internet Key Exchange Version 2
(IKEv2)" [Sch05].
a. セキュリティプロトコル--Encapsulating Security有効搭載量(超能力)Ken05aプロトコル保全と暗号化のためのAuthentication Header(AH)Ken05bについて説明するRFCsとb.暗号アルゴリズム; AHと超能力Eas05、同様のRFCとのそれが義務的なアルゴリズムを定義する使用のための義務的なデフォルトアルゴリズムを定義する1RFCがそれぞれにIKEv2 Sch05と別々のRFCと共に暗号アルゴリズムc.の自動かぎ管理を使用します--「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」Kau05と「インターネットキーにおける使用のための暗号アルゴリズムはバージョン2(IKEv2)を交換する」Sch05の上のRFCs。
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, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection in a standard fashion for all protocols that may be carried over IP (including IP itself).
IPsecが共同利用できて、高い品質を提供するように設計されている、暗号で、ベース、IPv4とIPv6のためのセキュリティ。 サービスが提供したセキュリティのセットは再生(部分的な系列保全のフォーム)、秘密性(暗号化を通した)、および限られた交通の流れ秘密性のアクセスコントロール、コネクションレスな保全、データ発生源認証、検出、および拒絶を含んでいます。 IP層でこれらのサービスを提供します、IPの上まで運ばれるかもしれないすべてのプロトコルのために一般的なファッションで保護を提供して(IP自身を含んでいて)。
IPsec includes a specification for minimal firewall functionality, since that is an essential aspect of access control at the IP layer. Implementations are free to provide more sophisticated firewall mechanisms, and to implement the IPsec-mandated functionality using those more sophisticated mechanisms. (Note that interoperability may suffer if additional firewall constraints on traffic flows are imposed by an IPsec implementation but cannot be negotiated based on the traffic selector features defined in this document and negotiated
IPsecは最小量のファイアウォールの機能性のための仕様を含んでいます、それがIP層でのアクセスコントロールの不可欠の局面であるので。 実装が、より精巧なファイアウォールメカニズムを提供して、それらのより精巧なメカニズムを使用するのにおいて自由にIPsecによって強制された機能性を実装することができる、(交通の流れにおける追加ファイアウォール規制はIPsec実装によって課されますが、本書では定義されたトラフィックセレクタ機能に基づいて交渉して、交渉できないならその相互運用性が受けるかもしれないことに注意してください。
Kent & Seo Standards Track [Page 5] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[5ページ]。
via IKEv2.) The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection.
IKEv2を通して。) IPsecファイアウォール機能は暗号で実施された認証、すべてのIPsecトラフィックがファイアウォールの使用で得ることができるだろうより良いアクセスコントロールを提供するように提供された保全(当事者ではなく、IPsecの内部のパラメタへの1)、および別々の暗号の保護を利用します。
Most of the security services are provided through 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 a context, and the ways in which they are employed, will be determined by the users/administrators in that context. It is the goal of the IPsec architecture to ensure that compliant implementations include the services and management interfaces needed to meet the security requirements of a broad user population.
2つのトラヒック保全プロトコル、Authentication Header(AH)、およびEncapsulating Security有効搭載量(超能力)の使用を通して暗号化キー管理手順とプロトコルの使用を通してセキュリティー・サービスの大部分を提供します。 文脈で使われたIPsecプロトコルのセット、およびそれらが採用している方法はその文脈でユーザ/管理者によって決定されるでしょう。 それは対応する実装がそのサービスを含んで、管理インタフェースが、広いユーザ人口に関するセキュリティ必要条件を満たす必要だったのを保証するIPsecアーキテクチャの目標です。
When IPsec is correctly implemented and deployed, it ought not adversely affect users, hosts, and other Internet components that do not employ IPsec for traffic protection. IPsec security protocols (AH and ESP, and to a lesser extent, IKE) are designed to be cryptographic algorithm independent. This modularity permits selection of different sets of cryptographic algorithms as appropriate, without affecting the other parts of the implementation. For example, different user communities may select different sets of cryptographic algorithms (creating cryptographically-enforced cliques) if required.
IPsecが正しく実装されて、配布されるとき、それはユーザ、ホスト、およびトラフィック保護にIPsecを使わない他のインターネットコンポーネントに悪影響を与えません。 IPsecセキュリティプロトコル(AH、超能力、およびある程度IKE)は、暗号アルゴリズム独立者になるように設計されています。 実装の他の部品に影響しないで、このモジュール方式は適宜異なった暗号アルゴリズムの品揃えを可能にします。 例えば、必要なら、異なったユーザーコミュニティは異なった暗号アルゴリズム(作成は暗号で徒党を実施した)を選択するかもしれません。
To facilitate interoperability in the global Internet, a set of default cryptographic algorithms for use with AH and ESP is specified in [Eas05] and a set of mandatory-to-implement algorithms for IKEv2 is specified in [Sch05]. [Eas05] and [Sch05] will be periodically updated to keep pace with computational and cryptologic advances. By specifying these algorithms in documents that are separate from the AH, ESP, and IKEv2 specifications, these algorithms can be updated or replaced without affecting the standardization progress of the rest of the IPsec document suite. The use of these cryptographic 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.
世界的なインターネットで相互運用性を容易にするために、AHと超能力との使用のための1セットのデフォルト暗号アルゴリズムは[Eas05]で指定されます、そして、1セットのIKEv2に、実装するために義務的なアルゴリズムは[Sch05]で指定されます。 コンピュータの、そして、cryptologicな進歩と足並をそろえるために定期的に[Eas05]と[Sch05]をアップデートするでしょう。 AHから別々のドキュメント、超能力、およびIKEv2仕様でこれらのアルゴリズムを指定すると、IPsecドキュメントスイートの残りの標準化進歩に影響しないで、これらのアルゴリズムをアップデートするか、または取り替えることができます。 IPsecトラフィック保護とかぎ管理プロトコルに関連して、これらの暗号アルゴリズムの使用が、システムとアプリケーション開発者が高い品質を配布することを許可することを意図します、インターネット層、暗号のセキュリティー技術。
2.2. Caveats and Assumptions
2.2. 警告と仮定
The suite of IPsec protocols and associated default cryptographic 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 their implementation, which is
IPsecプロトコルと関連デフォルト暗号アルゴリズムのスイートは、高品質のセキュリティをインターネットトラフィックに提供するように設計されています。 しかしながら、結局これらのプロトコルの使用で提供されたセキュリティをそれらの実装の品質に依存して、どれがありますか?
Kent & Seo Standards Track [Page 6] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[6ページ]。
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は総合体系セキュリティー体系の一部にすぎません。
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, as a security gateway
(SG), or as an independent device, affording protection to IP
traffic. (A security gateway is an intermediate system implementing
IPsec, e.g., a firewall or router that has been IPsec-enabled.) More
detail on these classes of implementations is provided later, in
Section 3.3. The protection offered by IPsec 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 established by either of the above. In
general, packets are selected for one of three processing actions
based on IP and next layer header information ("Selectors", Section
4.4.1.1) matched against entries in the SPD. Each packet is either
PROTECTed using IPsec security services, DISCARDed, or allowed to
BYPASS IPsec protection, based on the applicable SPD policies
identified by the Selectors.
IPsec実装はセキュリティゲートウェイ(SG)として、または、ホストか、独立しているデバイスとして作動します、IPトラフィックに保護して。 (セキュリティゲートウェイは、IPsec、例えばファイアウォールを実装する中間システムかIPsecによって可能にされたルータです。) 後でこれらのクラスの実装に関するその他の詳細をセクション3.3に提供します。 IPsecによって提供された保護はユーザかシステム管理者によって設立されて、維持されたSecurity Policy Database(SPD)、または上記のどちらかによって確立された規制の中で作動するアプリケーションで定義された要件に基づいています。 一般に、パケットはIPに基づく3つの処理動作と次の層のヘッダー情報の1つのために選択されます。(「セレクタ」、.1が)SPDでエントリーに対して合っていたセクション4.4.1。 各パケットはSelectorsによって特定された適切なSPD方針に基づいてIPsecセキュリティー・サービス、DISCARDedを使用するか、またはBYPASS IPsec保護に許容されたPROTECTedです。
3.1. What IPsec Does
3.1. IPsecがすること
IPsec creates a boundary between unprotected and protected interfaces, for a host or a network (see Figure 1 below). Traffic traversing the boundary is subject to the access controls specified by the user or administrator responsible for the IPsec configuration. These controls indicate whether packets cross the boundary unimpeded, are afforded security services via AH or ESP, or are discarded.
IPsecはホストかネットワークのために保護のなくて保護されたインタフェースの間の境界を作成します(以下の図1を見てください)。 境界を横断するトラフィックはIPsec構成に責任があるユーザか管理者によって指定されたアクセス制御を受けることがあります。 または、これらのコントロールが示す、妨害がなくて、パケットが境界を越えるか否かに関係なく、AHか超能力を通して都合されたセキュリティー・サービスがある、捨てられます。
Kent & Seo Standards Track [Page 7] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[7ページ]。
IPsec security services are offered at the IP layer through selection of appropriate security protocols, cryptographic algorithms, and cryptographic keys. IPsec can be used to protect one or more "paths" (a) between a pair of hosts, (b) between a pair of security gateways, or (c) between a security gateway and a host. A compliant host implementation MUST support (a) and (c) and a compliant security gateway must support all three of these forms of connectivity, since under certain circumstances a security gateway acts as a host.
IP層で適切なセキュリティプロトコル、暗号アルゴリズム、および暗号化キーの品揃えでIPsecセキュリティー・サービスを提供します。 1組のホスト、1組のセキュリティゲートウェイの間の(b)、またはセキュリティゲートウェイとホストの間の(c)の間に1「経路」(a)を保護するのにIPsecを使用できます。 対応するホスト導入は(a)と(c)をサポートしなければなりません、そして、言いなりになっているセキュリティゲートウェイは接続性のこれらのすべての3つのフォームをサポートしなければなりません、セキュリティゲートウェイがホストとしてある状況で務めるので。
Unprotected
^ ^
| |
+-------------|-------|-------+
| +-------+ | | |
| |Discard|<--| V |
| +-------+ |B +--------+ |
................|y..| AH/ESP |..... IPsec Boundary
| +---+ |p +--------+ |
| |IKE|<----|a ^ |
| +---+ |s | |
| +-------+ |s | |
| |Discard|<--| | |
| +-------+ | | |
+-------------|-------|-------+
| |
V V
Protected
保護のない^ ^| | +-------------|-------|-------+ | +-------+ | | | | |破棄| <--、| V| | +-------+ |B+--------+ | ................|y.。| ああ、/、超能力|..... IPsec境界| +---+ |p+--------+ | | |イケ| <、-、-、--、|^| | +---+ |s| | | +-------+ |s| | | |破棄| <--、|、|、|、| +-------+ | | | +-------------|-------|-------+ | | V Vは保護されました。
Figure 1. Top Level IPsec Processing Model
図1。 トップ平らなIPsec処理モデル
In this diagram, "unprotected" refers to an interface that might also be described as "black" or "ciphertext". Here, "protected" refers to an interface that might also be described as "red" or "plaintext". The protected interface noted above may be internal, e.g., in a host implementation of IPsec, the protected interface may link to a socket layer interface presented by the OS. In this document, the term "inbound" refers to traffic entering an IPsec implementation via the unprotected interface or emitted by the implementation on the unprotected side of the boundary and directed towards the protected interface. The term "outbound" refers to traffic entering the implementation via the protected interface, or emitted by the implementation on the protected side of the boundary and directed toward the unprotected interface. An IPsec implementation may support more than one interface on either or both sides of the boundary.
このダイヤグラムで、「保護のないこと」はまた、「黒い」と記述されているかもしれないインタフェースか「暗号文」を示します。 ここに、「保護」はまた、「赤い」と記述されているかもしれないインタフェースか「平文」を示します。 上に述べられた保護されたインタフェースが内部であるかもしれない、例えば、IPsecのホスト導入では、保護されたインタフェースはOSで提示されたソケットレイヤーインタフェースにリンクされるかもしれません。 本書では、「本国行き」という用語は保護されたインタフェースに保護のないインタフェースを通してIPsec実装を入れるか、境界保護のない側で実装によって放たれていて、または向けられたトラフィックについて言及します。 「外国行き」という用語は保護のないインタフェースに保護されたインタフェースを通して実装を入れるか、境界保護側で実装によって放たれていて、または向けられたトラフィックについて言及します。 IPsec実装は境界のどちらかか両側の1つ以上のインタフェースをサポートするかもしれません。
Kent & Seo Standards Track [Page 8] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[8ページ]。
Note the facilities for discarding traffic on either side of the IPsec boundary, the BYPASS facility that allows traffic to transit the boundary without cryptographic protection, and the reference to IKE as a protected-side key and security management function.
IPsec境界(保護されたサイドキーとセキュリティ管理が機能するときトランジットへの暗号の保護のない境界、およびIKEの参照をトラフィックに許すBYPASS施設)のどちらの側でもトラフィックを捨てるので、施設に注意してください。
IPsec optionally supports negotiation of IP compression [SMPT01], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers.
IPsecは任意に暗号化がIPsecの中で使われるとき、低級プロトコル層で有効な圧縮を防ぐという観測で一部動機づけられたIP圧縮[SMPT01]の交渉をサポートします。
3.2. How IPsec Works
3.2. IPsecはどう働いているか。
IPsec uses two protocols to provide traffic security services -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in detail in their respective RFCs [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY support AH. (Support for AH has been downgraded to MAY because experience has shown that there are very few contexts in which ESP cannot provide the requisite security services. Note that ESP can be used to provide only integrity, without confidentiality, making it comparable to AH in most contexts.)
IPsecはトラフィックセキュリティー・サービスを提供するのに2つのプロトコルを使用します--認証Header(AH)とEncapsulating Security有効搭載量(超能力)。 両方のプロトコルはそれらのそれぞれのRFCs[Ken05b、Ken05a]で詳細に説明されます。 IPsec実装は、超能力をサポートしなければならなくて、AHをサポートするかもしれません。 (経験が、超能力が必要なセキュリティー・サービスを提供できないほんのわずかな文脈があるのを示したので、AHのサポートは5月まで格下げされました。 それをほとんどの文脈でAHに匹敵するようにして、秘密性なしで保全だけを提供するのに超能力を使用できることに注意してください。)
o The IP Authentication Header (AH) [Ken05b] offers integrity and
data origin authentication, with optional (at the discretion of
the receiver) anti-replay features.
o IP Authentication Header(AH)[Ken05b]は発生源認証を保全とデータに提供します、任意(受信機の裁量における)の反再生機能で。
o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers
the same set of services, and also offers confidentiality. Use of
ESP to provide confidentiality without integrity is NOT
RECOMMENDED. When ESP is used with confidentiality enabled, there
are provisions for limited traffic flow confidentiality, i.e.,
provisions for concealing packet length, and for facilitating
efficient generation and discard of dummy packets. This
capability is likely to be effective primarily in virtual private
network (VPN) and overlay network contexts.
o Encapsulating Security有効搭載量(超能力)プロトコル[Ken05a]は、同じセットのサービスを提供して、また、秘密性を提供します。 保全なしで秘密性を提供する超能力の使用はNOT RECOMMENDEDです。 超能力が可能にされる秘密性と共に使用されるとき、限られた交通の流れ秘密性のための条項、パケット長を隠して、ダミーのパケットの効率的な世代と破棄を容易にするためのすなわち、条項があります。 この能力は主として仮想私設網(VPN)とオーバレイネットワーク文脈で有効である傾向があります。
o Both AH and ESP offer access control, enforced through the
distribution of cryptographic keys and the management of traffic
flows as dictated by the Security Policy Database (SPD, Section
4.4.1).
o AHと超能力の両方がSecurity Policy Database(SPD、セクション4.4.1)によって書き取られるように暗号化キーの分配と交通の流れの管理で励行されるアクセスコントロールを提供します。
These protocols may be applied individually or in combination with each other to provide IPv4 and IPv6 security services. However, most security requirements can be met through the use of ESP by itself. Each protocol supports two modes of use: transport mode and tunnel mode. In transport mode, AH and ESP provide protection primarily for
これらのプロトコルは、個別か互いと組み合わせてIPv4とIPv6にセキュリティー・サービスを供給するために適用されるかもしれません。 しかしながら、超能力の使用でそれ自体でほとんどのセキュリティ必要条件を満たすことができます。 各プロトコルは使用の2つの方法をサポートします: モードとトンネルモードを輸送してください。 交通機関で、AHと超能力は保護に主として備えます。
Kent & Seo Standards Track [Page 9] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[9ページ]。
next layer protocols; in tunnel mode, AH and ESP are applied to tunneled IP packets. The differences between the two modes are discussed in Section 4.1.
次に、プロトコルは層にされます。 トンネルモードで、AHと超能力はトンネルを堀られたIPパケットに適用されます。 セクション4.1で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, through the SPD management paradigm, incorporates facilities for specifying:
IPsecはユーザ(または、システム管理者)にセキュリティー・サービスが提供される粒状を制御させます。 例えば、1つが2セキュリティ門の間まですべてのトラフィックを運ぶために単一の暗号化されたトンネルを作成できますか、またはこれらのゲートウェイの向こう側に交信するそれぞれの組のホストの間のそれぞれのTCP接続のために別々の暗号化されたトンネルは作成できます。 IPsecは指定するためにSPD経営規範を通して施設を組み込みます:
o which security protocol (AH or ESP) to employ, the mode (transport
or tunnel), security service options, what cryptographic
algorithms to use, and in what combinations to use the specified
protocols and services, and
o そして雇用へのどのセキュリティプロトコル(AHか超能力)、モード(輸送するか、またはトンネルを堀る)、セキュリティがオプションを修理して、どんな暗号アルゴリズムが使用、およびコネへの指定されたプロトコルとサービスを利用するどんな組み合わせであるか。
o the granularity at which protection should be applied.
o 粒状はどの保護のときに適用されるべきであるか。
Because most of the security services provided by IPsec require the use of cryptographic keys, IPsec relies on a separate set of mechanisms for putting these keys in place. This document requires support for both manual and automated distribution of keys. It specifies a specific public-key based approach (IKEv2 [Kau05]) for automated key management, but other automated key distribution techniques MAY be used.
IPsecによって提供されたセキュリティー・サービスの大部分が暗号化キーの使用を必要とするので、IPsecはこれらのキーを適所に置くために別々のセットのメカニズムを当てにします。 このドキュメントはキーの手動の、そして、自動化の両方にされた分配に支持を要します。 それは自動化されたかぎ管理のための特定の公開鍵に基づいているアプローチ(IKEv2[Kau05])を指定しますが、他の自動化された主要な分配技法は使用されるかもしれません。
Note: This document mandates support for several features for which support is available in IKEv2 but not in IKEv1, e.g., negotiation of an SA representing ranges of local and remote ports or negotiation of multiple SAs with the same selectors. Therefore, this document assumes use of IKEv2 or a key and security association management system with comparable features.
以下に注意してください。 命令がサポートがIKEv2で利用可能ですが、IKEv1で利用可能であるというわけではないいくつかの特徴、例えば、地方の、そして、遠く離れたポートの範囲か同じセレクタとの複数のSAsの交渉を表すSAの交渉のために支えるこのドキュメント。 したがって、このドキュメントは匹敵する特徴があるIKEv2かキーとセキュリティ協会マネージメントシステムの使用を仮定します。
3.3. Where IPsec Can Be Implemented
3.3. IPsecを実装することができるところ
There are many ways in which IPsec may be implemented in a host, or in conjunction with a router or firewall to create a security gateway, or as an independent security device.
IPsecがホスト、または、セキュリティゲートウェイを作成するルータかファイアウォールに関連した独立しているセキュリティデバイスとして実装されるかもしれない多くの方法があります。
a. IPsec may be integrated into the native IP stack. This requires
access to the IP source code and is applicable to both hosts and
security gateways, although native host implementations benefit
the most from this strategy, as explained later (Section 4.4.1,
paragraph 6; Section 4.4.1.1, last paragraph).
a。 IPsecはネイティブのIPスタックと統合されるかもしれません。 これは、IPソースコードへのアクセスを必要として、ホストとセキュリティゲートウェイの両方に適切です、ネイティブのホスト導入は最も多くこの戦略の利益を得ますが、後で説明されるように(セクション4.4.1、パラグラフ6; セクション4.4 .1 .1、最後のパラグラフ)
Kent & Seo Standards Track [Page 10] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[10ページ]。
b. In a "bump-in-the-stack" (BITS) implementation, 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はIPプロトコルの既存の実装が積み重ねる“underneath"であると実装されます、ネイティブのIPと企業内情報通信網のドライバーの間で。 IPスタックのためのソースコードアクセスはこのような関係においては必要ではありません、レガシーシステムでこの実装アプローチを使用に適切にして。それが採用されるとき、通常、このアプローチはホストで使われます。
c. The use of a dedicated, inline security protocol processor is a
common design feature of 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. Usually, the
BITW device is itself 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実装に全く類似しているかもしれませんが、ルータかファイアウォールをサポートする際に、それはセキュリティゲートウェイのように作動しなければなりません。
This document often talks in terms of use of IPsec by a host or a security gateway, without regard to whether the implementation is native, BITS, or BITW. When the distinctions among these implementation options are significant, the document makes reference to specific implementation approaches.
このドキュメントはホストかセキュリティゲートウェイのそばでIPsecの使用でしばしば話します、実装がネイティブであるかどうかへの尊敬も、BITSも、またはBITWなしで。 これらの実装オプションの中の区別が重要であるときに、ドキュメントは特定の実装アプローチについて言及します。
A host implementation of IPsec may appear in devices that might not be viewed as "hosts". For example, a router might employ IPsec to protect routing protocols (e.g., BGP) and management functions (e.g., Telnet), without affecting subscriber traffic traversing the router. A security gateway might employ separate IPsec implementations to protect its management traffic and subscriber traffic. The architecture described in this document is very flexible. For example, a computer with a full-featured, compliant, native OS IPsec implementation should be capable of being configured to protect resident (host) applications and to provide security gateway protection for traffic traversing the computer. Such configuration would make use of the forwarding tables and the SPD selection function described in Sections 5.1 and 5.2.
IPsecのホスト導入は「ホスト」として見なされないかもしれないデバイスに現れるかもしれません。 例えば、ルータはルーティング・プロトコル(例えば、BGP)と管理機能(例えば、Telnet)を保護するのにIPsecを使うかもしれません、ルータを横断する加入者トラフィックに影響しないで。 セキュリティゲートウェイは、その管理トラフィックと加入者トラフィックを保護するのに別々のIPsec実装を使うかもしれません。 本書では説明されたアーキテクチャは非常にフレキシブルです。 例えば、完全装備の、そして、言いなりになっていて、ネイティブのOS IPsec実装があるコンピュータは、居住している(ホスト)アプリケーションを保護して、コンピュータを横断しながらトラフィックのためのセキュリティゲートウェイ保護を提供するために構成できるべきです。 そのような構成はセクション5.1と5.2で説明された推進テーブルとSPD選択機能を利用するでしょう。
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 AH and ESP. 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 SAs. All implementations of AH or ESP MUST support the concept of an SA as described below. The remainder of this
このセクションはすべてのIPv6実装とそれらのIPv4実装のためのAH、超能力、または両方がAHと超能力であると実装するSecurity Association管理要件を定義します。 「セキュリティ協会」(SA)の概念はIPsecに基本的です。 IKEの主要な機能は、SAsのAHと超能力の両方がSAsを利用して、設立とメインテナンスです。 AHか超能力のすべての実装が以下で説明されるようにSAの概念をサポートしなければなりません。 この残り
Kent & Seo Standards Track [Page 11] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[11ページ]。
section describes various aspects of SA management, defining required characteristics for SA policy management and SA management techniques.
SA政策管理とSA管理技術のために必要な特性を定義して、セクションはSA管理の種々相について説明します。
4.1. Definition and Scope
4.1. 定義と範囲
An 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 are applied to a traffic stream, then two SAs must be created and coordinated to effect protection through iterated application of the security protocols. To secure typical, bi-directional communication between two IPsec-enabled systems, a pair of SAs (one in each direction) is required. IKE explicitly creates SA pairs in recognition of this common usage requirement.
SAはそれによって運ばれたトラフィックへのセキュリティー・サービスを提供するシンプレクス「接続」です。 セキュリティー・サービスをAH、または超能力の使用でSAに都合しますが、ともに都合するというわけではありません。 AHと超能力保護の両方がトラフィックストリームに適用されるなら、セキュリティプロトコルの繰り返された応用で効果保護に2SAsを作成されて、調整しなければなりません。 2台のIPsecによって可能にされたシステム、1組のSAsの安全な典型的で、双方向のコミュニケーション、(あるコネ、各方向) 必要です。 IKEはこの一般的な用法要件の認識で明らかにSA組を創設します。
For an SA used to carry unicast traffic, the Security Parameters Index (SPI) by itself suffices to specify an SA. (For information on the SPI, see Appendix A and the AH and ESP specifications [Ken05b, Ken05a].) However, as a local matter, an implementation may choose to use the SPI in conjunction with the IPsec protocol type (AH or ESP) for SA identification. If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de- multiplexing algorithm.
ユニキャストトラフィック、それ自体で(SPI)が満足させるSecurity Parameters Indexを運ぶのにおいて中古のSAがSAを指定するように。 (SPIの情報に関して、Appendix A、AH、および超能力仕様[Ken05b、Ken05a]を見てください。) しかしながら、地域にかかわる事柄として、実装は、SA識別のためのIPsecプロトコルタイプ(AHか超能力)に関連してSPIを使用するのを選ぶかもしれません。 IPsec実装がマルチキャストをサポートするなら、本国行きのIPsecデータグラムをSAsに写像するのに以下のアルゴリズムを使用して、それは、マルチキャストがSAsであるとサポートしなければなりません。 ユニキャストトラフィックだけをサポートする実装はこの反-マルチプレクシングアルゴリズムを実装する必要はありません。
In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the Group Security Association's (GSA's) SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that constitute the group. Consequently, it is possible that a GSA and a unicast SA can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions.
多くの安全なマルチキャストアーキテクチャ、例えば、[RFC3740]では、中央のGroup Controller/主要なServerは一方的にGroup Security Associationの(GSA)のSPIを割り当てます。 このSPI課題は、グループを構成する個々のエンドシステムにあるかぎ管理(例えば、IKE)サブシステムで、交渉もされませんし、調整もされません。 その結果、GSAとユニキャストSAが同時に同じSPIを使用できるのは、可能です。 マルチキャストできるIPsec実装は反-正しくSPI衝突の文脈さえにおけるインバウンドトラフィックを多重送信しなければなりません。
Each entry in the SA Database (SAD) (Section 4.4.2) must indicate whether the SA lookup makes use of the destination IP address, or the destination and source IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination address, or destination and source address (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows:
SA Database(SAD)(セクション4.4.2)の各エントリーは、SAルックアップが送付先IPアドレスか、目的地とソースIPアドレスを利用するかどうかを示さなければなりません、SPIに加えて。 マルチキャストSAsにおいて、プロトコル分野はSAルックアップに使われません。 それぞれの本国行きの、そして、IPsecによって保護されたパケットに関しては、実装がSADの検索を行わなければならないので、それは「最も長い」SA識別子に合っているエントリーを見つけます。 2つ以上のSADエントリーがSPI値、次にまた、送付先アドレスに基づいて合っているエントリー、または目的地に基づいて合って、ソースアドレス(SADエントリーにみられるように)が「最も長い」なら、このような関係においては、合ってください。 これは以下のSAD検索の論理的な注文を含意します:
Kent & Seo Standards Track [Page 12] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[12ページ]。
1. Search the SAD for a match on the combination of SPI,
destination address, and source address. If an SAD entry
matches, then process the inbound packet with that
matching SAD entry. Otherwise, proceed to step 2.
1. マッチのためにSPIの組み合わせ、送付先アドレス、およびソースアドレスをSADを捜してください。 SADエントリーが合っているなら、そんなに合っているSADエントリーで本国行きのパケットを処理してください。 さもなければ、ステップ2に進んでください。
2. Search the SAD for a match on both SPI and destination address.
If the SAD entry matches, then process the inbound packet
with that matching SAD entry. Otherwise, proceed to step 3.
2. マッチのためにSPIと送付先アドレスの両方をSADを捜してください。 SADエントリーが合っているなら、そんなに合っているSADエントリーで本国行きのパケットを処理してください。 さもなければ、ステップ3に進んでください。
3. Search the SAD for a match on only SPI if the receiver has
chosen to maintain a single SPI space for AH and ESP, and on
both SPI and protocol, otherwise. If an SAD entry matches,
then process the inbound packet with that matching SAD entry.
Otherwise, discard the packet and log an auditable event.
3. 受信機が、AHと超能力と、SPIとプロトコルの両方の上のただ一つのSPIスペースを維持するのを選んだなら、SPIだけの上のマッチのためにSADを捜してください、そうではありません。 SADエントリーが合っているなら、そんなに合っているSADエントリーで本国行きのパケットを処理してください。 さもなければ、パケットを捨ててください、そして、監査可能イベントを登録してください。
In practice, an implementation may choose any method (or none at all) to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list could be kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers could be sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available Ternary Content-Addressable Memory (TCAM) features.
実際には、実装はこの検索を加速するどんなメソッド(または、全くなにも)も選ぶかもしれません、外部的に目に見える振舞いが上記のオーダーをSADを捜したのに機能上同等でなければなりませんが。 例えば、ソフトウェアベースの実装はSPIでハッシュ表に索引をつけることができました。 最初にその繋がっているリストで最も長いSA識別子で分類されて、それらのSADエントリーを持つようにそれぞれのハッシュ表バケツの繋がっているリストにおけるSADエントリーを保つことができました。 持っている中でSA識別子最も短いそれらのSADエントリーは分類できたので、それらは繋がっているリストで最後のエントリーです。 ハードウェアベースの実装は本質的に最も長いマッチ検索に作用できるかもしれません、一般的に利用可能なTernary Contentアドレス可能なMemory(TCAM)の特徴を使用して。
The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or Group Domain of Interpretation (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier.
ソースと目的地がマッチングを扱うかどうかしるしが、手動のSA構成か交渉使用を通したSA管理プロトコル、例えば、IKEの副作用かInterpretationのGroup Domainとしてのセットが(GDOI)であったに違いない[RFC3547]なら本国行きのIPsecトラフィックをSAsに写像するのに必要です。 通常、Source特有のMulticast(SSM)[HC03]グループはSPIで構成された3-tuple SA識別子、送付先マルチキャストアドレス、およびソースアドレスを使用します。 Any-ソースMulticastグループSAは識別子としてSPIと送付先マルチキャストアドレスだけを必要とします。
If different classes of traffic (distinguished by Differentiated Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in both AH and ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support Quality of Service (QoS) appropriately. To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver,
異なったクラスのトラフィック(Differentiated Services Code Point(DSCP)ビット[NiBlBaBL98]、[Gro02]で、区別される)を同じSAに送って、受信機がAHと超能力の両方で利用可能な任意の反再生機能を使っているなら、これはこの特徴によって使用されるウインドーメカニズムのため低優先度パケットを不適当な捨てることをもたらすかもしれません。 したがって、異なったクラスのトラフィックを置きましたが、送付者SHOULDは、適切にService(QoS)のQualityをサポートするために同じセレクタ値で異なったSAsにそうしました。 これを可能にするために、IPsec実装は与えられた送付者と受信機の間の複数のSAsの設立とメインテナンスを可能にしなければなりません。
Kent & Seo Standards Track [Page 13] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[13ページ]。
with the same selectors. Distribution of traffic among these parallel SAs to support QoS is locally determined by the sender and is not negotiated by IKE. The receiver MUST process the packets from the different SAs without prejudice. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism.
同じセレクタで。 QoSをサポートするこれらの平行なSAsの中のトラフィックの分配は、送付者によって局所的に決定されて、IKEによって交渉されません。 受信機は異なったSAsから偏見なしでパケットを処理しなければなりません。 これらの要件は輸送とトンネルモードSAsの両方に適用されます。 トンネルモードSAsの場合では、問題のDSCP値は内側のIPヘッダーに現れます。 交通機関では、DSCP値は途中で、変化するかもしれませんが、これは、値をSA選択に使わないで、SA/パケット合法化の一部としてチェックしてはいけないので、IPsec処理に関して問題を起こすべきではありません。 しかしながら、パケットの重要な再注文が途中で例えば、SA DSCP値への変化の結果、起こるなら、これは反再生メカニズムの応用のため受信機によって捨てられるパケットの引き金となるかもしれません。
DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit Congestion Notification (ECN) [RaFlBl01] fields are not "selectors", as that term in used in this architecture, the sender will need a mechanism to direct packets with a given (set of) DSCP values to the appropriate SA. This mechanism might be termed a "classifier".
議論: DSCP[NiBlBaBL98、Gro02]とExplicit Congestion Notification(電子証券取引ネットワーク)[RaFlBl01]分野は「セレクタ」ではありませんが、その用語が中で中でこのアーキテクチャを使用したので、送付者はDSCPが適切なSAに評価する当然のこと(設定)でパケットを指示するためにメカニズムを必要とするでしょう。 このメカニズムは「クラシファイア」と呼ばれるかもしれません。
As noted above, two types of SAs are defined: transport mode and tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose to require that both SAs in a pair be of the same mode, transport or tunnel.
上で述べたように、SAsの2つのタイプが定義されます: モードとトンネルモードを輸送してください。 IKEが組のSAsを作成するので、簡単さのために、私たちは、1組の両方のSAsが同じモード、輸送またはトンネルのそうであることが必要であることを選びます。
A transport mode SA is an SA typically employed between a pair of hosts to provide end-to-end security services. When security is desired between two intermediate systems along a path (vs. end-to-end use of IPsec), transport mode MAY be used between security gateways or between a security gateway and a host. In the case where transport mode is used between security gateways or between a security gateway and a host, transport mode may be used to support in-IP tunneling (e.g., IP-in-IP [Per96] or Generic Routing Encapsulation (GRE) tunneling [FaLiHaMeTr00] or dynamic routing [ToEgWa04]) over transport mode SAs. To clarify, the use of transport mode by an intermediate system (e.g., a security gateway) is permitted only when applied to packets whose source address (for outbound packets) or destination address (for inbound packets) is an address belonging to the intermediate system itself. The access control functions that are an important part of IPsec are significantly limited in this context, as they cannot be applied to the end-to-end headers of the packets that traverse a transport mode SA used in this fashion. Thus, this way of using transport mode should be evaluated carefully before being employed in a specific context.
交通機関SAは終わりから終わりへのセキュリティー・サービスを提供するのに1組のホストの間で通常使われたSAです。 セキュリティが経路(IPsecの終わりから最終用途に対する)に沿った2個の中間システムの間で望まれているとき、交通機関はセキュリティゲートウェイの間、または、セキュリティゲートウェイとホストの間で使用されるかもしれません。 交通機関がセキュリティゲートウェイの間、または、セキュリティゲートウェイとホストの間で使用される場合では、交通機関は、交通機関SAsの上でIPにおけるトンネリングが(例えば、中のIP IP[Per96]かGenericルート設定Encapsulation(GRE)トンネリング[FaLiHaMeTr00]かダイナミックルーティング[ToEgWa04])であるとサポートするのに使用されるかもしれません。 はっきりさせるために、ソースアドレス(外国行きのパケットのための)か送付先アドレス(本国行きのパケットのための)が中間システム自体に属すアドレスであるパケットに適用される場合にだけ、中間システム(例えば、セキュリティゲートウェイ)による交通機関の使用は受入れられます。 IPsecの重要な部分であるアクセス制御機能はこのような関係においてはかなり限られています、SAがこんなやり方で使用した交通機関を横断するパケットの終わりから終わりへのヘッダーにそれらを適用できないとき。 したがって、特定の文脈で使われる前に交通機関を使用するこの方法は慎重に評価されるべきです。
Kent & Seo Standards Track [Page 14] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[14ページ]。
In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any next layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and selected extension headers, but may appear before or after destination options; it MUST appear before next layer protocols (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP)). In the case of ESP, a transport mode SA provides security services only for these next 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 preceding it, 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 [Ken05b].
IPv4では、プロトコル(例えば、TCPかUDP)がIPヘッダーとどんなオプション直後、次にいくらか層にされる前に交通機関セキュリティプロトコルヘッダーは現れます。 IPv6では、セキュリティプロトコルヘッダーは、ベースIPヘッダーの後に現れて、拡張ヘッダーを選びますが、目的地オプションの前または後に現れるかもしれません。 プロトコル(例えば、TCP、UDP、Stream Control Transmissionプロトコル(SCTP))が次に層にされる前にそれは現れなければなりません。 超能力の場合では、モードSAがセキュリティを提供する輸送はこれらのためだけにIPヘッダーでない次の層のプロトコルか超能力ヘッダーに先行するどんな拡張ヘッダーにもサービスを提供します。 AHの場合では、また、それに先行するIPヘッダーの選択された部分、拡張ヘッダーの選択された部分、および選択されたオプション(IPv4ヘッダー、ホップによるIPv6 Hop拡張ヘッダー、またはIPv6 Destination拡張ヘッダーでは、含まれている)に広げられて、保護はそうです。 AHによって提供された適用範囲に関するその他の詳細に関しては、AH仕様[Ken05b]を見てください。
A tunnel mode SA is essentially an SA applied to an IP tunnel, with the access controls applied to the headers of the traffic inside the tunnel. Two hosts MAY establish a tunnel mode SA between themselves. Aside from the two exceptions below, 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 typically a tunnel mode SA, as is an SA between a host and a security gateway. The two exceptions are as follows.
トンネルモードSAは本質的にはIPトンネルに適用されたSAです、アクセス制御がトンネルの中でトラフィックのヘッダーに適用されている状態で。 2人のホストが自分たちの間にトンネルモードSAを設立するかもしれません。 セキュリティ協会のどちらかの終わりがセキュリティゲートウェイであるときはいつも、SA MUSTの下の2つの例外は別としてトンネルモードになってください。 したがって、通常、2セキュリティ門の間のSAはホストとセキュリティゲートウェイの間のSAのようにトンネルモードSAです。 2つの例外は以下の通りです。
o Where traffic is destined for a security gateway, e.g., Simple
Network Management Protocol (SNMP) commands, the security gateway
is acting as a host and transport mode is allowed. In this case,
the SA terminates at a host (management) function within a
security gateway and thus merits different treatment.
o 例えば、Simple Network Managementプロトコル(SNMP)は、ホストと交通機関が許容されているときトラフィックがセキュリティゲートウェイに運命づけられているところでセキュリティゲートウェイが作動していると命令します。 この場合、SAはセキュリティゲートウェイの中のホスト(管理)機能で終わって、その結果、異なった処理に値します。
o As noted above, security gateways MAY support a transport mode SA
to provide security for IP traffic between two intermediate
systems along a path, e.g., between a host and a security gateway
or between two security gateways.
o 上で述べたように、セキュリティゲートウェイは、交通機関が経路に沿った2個の中間システムか、例えば、ホストとセキュリティゲートウェイか2セキュリティ門の間のIPトラフィックにセキュリティを提供するSAであるとサポートするかもしれません。
Several concerns motivate the use of tunnel mode for an SA involving a security gateway. For example, if there are multiple paths (e.g., via different security gateways) to the same destination behind a security gateway, it is important that an IPsec packet be sent to the security gateway with which the SA was negotiated. Similarly, a packet that might be fragmented en route must have all the fragments delivered to the same IPsec instance for reassembly prior to cryptographic processing. Also, when a fragment is processed by IPsec and transmitted, then fragmented en route, it is critical that there be inner and outer headers to retain the fragmentation state data for the pre- and post-IPsec packet formats. Hence there are several reasons for employing tunnel mode when either end of an SA is
数回の関心がトンネルモードのセキュリティゲートウェイにかかわるSAの使用を動機づけます。 例えば、セキュリティゲートウェイの後ろに同じ目的地に複数の経路があれば(例えば、異なったセキュリティゲートウェイを通して)、SAが交渉されたセキュリティゲートウェイにIPsecパケットを送るのは重要です。 同様に、途中で断片化されるかもしれないパケットで、暗号の処理の前に再アセンブリのために同じIPsecインスタンスにすべての断片を提供しなければなりません。 そして、また、断片がIPsecによって処理されて、伝えられて、次に、途中で断片化されるときそれも重要である、それ、そこでは、断片化州のデータを保有する内側の、そして、外側のヘッダーになってください、プレ、ポスト-IPsecパケット・フォーマット。 SAのどちらかの端があるとき、したがって、トンネルモードを使ういくつかの理由があります。
Kent & Seo Standards Track [Page 15] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[15ページ]。
a security gateway. (Use of an IP-in-IP tunnel in conjunction with transport mode can also address these fragmentation issues. However, this configuration limits the ability of IPsec to enforce access control policies on traffic.)
セキュリティゲートウェイ。 (また、交通機関に関連したIPにおけるIPトンネルの使用はこれらの断片化問題を扱うことができます。 しかしながら、この構成はIPsecがアクセス制御方針にトラフィックに押しつける能力を制限します。)
Note: AH and ESP cannot be applied using transport mode to IPv4 packets that are fragments. Only tunnel mode can be employed in such cases. For IPv6, it would be feasible to carry a plaintext fragment on a transport mode SA; however, for simplicity, this restriction also applies to IPv6 packets. See Section 7 for more details on handling plaintext fragments on the protected side of the IPsec barrier.
以下に注意してください。 断片であるIPv4パケットに交通機関を使用することでAHと超能力を適用できません。 そのような場合トンネルモードしか使うことができません。 IPv6に関しては、交通機関SAで平文断片を運ぶのは可能でしょう。 しかしながら、簡単さのために、また、この制限はIPv6パケットに申し込まれます。 IPsecバリアの保護された端で取り扱い平文断片に関するその他の詳細に関してセクション7を見てください。
For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing source and destination, plus an "inner" IP header that specifies the (apparently) ultimate source and 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 next 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ヘッダーのすべてが保護されます、次の層のプロトコルと同様に)。 超能力が採用しているなら、外側のヘッダーではなく、トンネルを堀られたパケットだけに保護を提供します。
In summary,
概要で
a) A host implementation of IPsec MUST support both transport and
tunnel mode. This is true for native, BITS, and BITW
implementations for hosts.
a) IPsecのホスト導入は輸送とトンネルモードの両方をサポートしなければなりません。 ネイティブ(BITS)とBITW実装に、これはホストのために本当です。
b) A security gateway MUST support tunnel mode and MAY support
transport 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, or to provide security between two
intermediate systems along a path.
b) セキュリティゲートウェイは、トンネルモードをサポートしなければならなくて、輸送がモードであるとサポートするかもしれません。 セキュリティゲートウェイが例えば、ネットワークマネージメントか経路に沿った2個の中間システムの間にセキュリティを供給するためにホストとして務めているときだけ、輸送がモードであるとサポートするなら、それは使用されるべきです。
4.2. SA Functionality
4.2. SAの機能性
The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and the election of optional services within the protocol.
SAによって提供されたセキュリティー・サービスのセットはプロトコルの中で選択されたセキュリティプロトコル、SAモード、SAの終点、および任意にサービスの選挙に依存します。
For example, both AH and ESP offer integrity and authentication services, but the coverage differs for each protocol and differs for transport vs. tunnel mode. 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 IP or extension headers that may change in a fashion not predictable by the sender.
例えば、AHと超能力の両方が保全と認証サービスを提供しますが、適用範囲は、各プロトコルのために異なって、輸送対トンネルモードのために異なります。 途中で送付者と受信機の間にIPv4オプションかIPv6拡張ヘッダーの保全を保護しなければならないなら、AHはこのサービスを提供できます、送付者が予測できないファッションで変化するかもしれないIPか拡張ヘッダーを除いて。
Kent & Seo Standards Track [Page 16] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[16ページ]。
However, the same security may be achieved in some contexts by applying ESP to a tunnel carrying a packet.
しかしながら、同じセキュリティは、いくつかの文脈でパケットを運びながら超能力をトンネルに適用することによって、達成されるかもしれません。
The granularity of access control provided is determined by the choice of the selectors that define each SA. Moreover, the authentication means employed by IPsec peers, e.g., during creation of an IKE (vs. child) SA also affects the granularity of the access control afforded.
コントロールが提供したアクセスの粒状は各SAを定義するセレクタの選択で決定します。 そのうえ、IPsecによって使われた認証手段はじっと見ます、また、例えば、IKE(子供に対する)の作成の間、SAがコントロールが提供したアクセスの粒状に影響します。
If confidentiality 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 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 that are carrying traffic from many subscribers.
秘密性が選択されるなら、2セキュリティ門の間の超能力(トンネルモード)SAは部分的な交通の流れ秘密性を提供できます。 トンネルモードの使用は、内側のIPヘッダーが暗号化されるのを許容します、(究極)のトラフィックソースと目的地のアイデンティティを隠して。 そのうえ、パケットのサイズを隠すために超能力ペイロード詰め物も呼び出すことができます、さらにトラフィックの外部の特性を隠して。 モバイルユーザが動的IPアドレスがダイアルアップ文脈で割り当てられて、(トンネルモード)ESP SAを法人のファイアウォールに設立するとき(セキュリティゲートウェイとして機能して)、同様の交通の流れ秘密性サービスを提供するかもしれません。 一般に、すばらしい粒状SAsが多くの加入者からトラフィックを運ぶ粗い粒状ものよりトラヒック分析に被害を受け易いことに注意してください。
Note: A compliant implementation MUST NOT allow instantiation of an ESP SA that employs both NULL encryption and no integrity algorithm. An attempt to negotiate such an SA is an auditable event by both initiator and responder. The audit log entry for this event SHOULD include the current date/time, local IKE IP address, and remote IKE IP address. The initiator SHOULD record the relevant SPD entry.
以下に注意してください。 対応する実装はNULL暗号化と保全アルゴリズムがない両方を使うESP SAの具体化を許容してはいけません。 そのようなSAを交渉する試みは創始者と応答者の両方による監査可能イベントです。 このイベントSHOULDのための監査ログエントリーは現在の日付/時間、ローカルのIKE IPアドレス、およびリモートIKE IPアドレスを含んでいます。 創始者SHOULDは関連SPDエントリーを記録します。
4.3. Combining SAs
4.3. SAsを結合します。
This document does not require support for nested security associations or for what RFC 2401 [RFC2401] called "SA bundles". These features still can be effected by appropriate configuration of both the SPD and the local forwarding functions (for inbound and outbound traffic), but this capability is outside of the IPsec module and thus the scope of this specification. As a result, management of nested/bundled SAs is potentially more complex and less assured than under the model implied by RFC 2401 [RFC2401]. An implementation that provides support for nested SAs SHOULD provide a management interface that enables a user or administrator to express the nesting requirement, and then create the appropriate SPD entries and forwarding table entries to effect the requisite processing. (See Appendix E for an example of how to configure nested SAs.)
このドキュメントは入れ子にされたセキュリティ協会かRFC2401[RFC2401]が「SAバンドル」と呼んだものに支持を要しません。 そして、これらの特徴スチール写真がSPDと地方の推進機能の両方の適切な構成で作用できる、(本国行き、アウトバウンドトラフィック)、この能力しかIPsecモジュールとその結果、この仕様の範囲の外にありません。 その結果、入れ子にされたか添付されたSAsの管理は、RFC2401[RFC2401]によって含意されたモデルより潜在的に複雑であって、より確実ではありません。 入れ子にされたSAs SHOULDが管理インタフェースにそれを提供するので、サポートを提供する実装は、ユーザか管理者が巣篭もり要件を言い表して、次に、必要な処理に作用するように適切なSPDエントリーと推進テーブルエントリーを作成するのを可能にします。 (どう入れ子にされたSAsを構成するかに関する例に関してAppendix Eを見てください。)
Kent & Seo Standards Track [Page 17] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[17ページ]。
4.4. Major IPsec Databases
4.4. 主要なIPsecデータベース
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 IPsec functionality, in support of these interoperability and functionality goals. The model described below is nominal; implementations need not match details of this model as presented, but the external behavior of implementations MUST correspond to the externally observable characteristics of this model in order to be compliant.
IPsec実装における処理IPトラフィックに関連している詳細の多くが標準化への対象ではなく、主に地域にかかわる事柄です。 しかしながら、相互運用性を確実にして、IPsecの生産用途に、不可欠の最小の管理能力を提供するために処理のいくつかの外面を標準化しなければなりません。 このセクションは処理IPトラフィックのためにIPsecの機能性に比例して一般的なモデルについて説明します、これらの相互運用性と機能性目標を支持して。 以下で説明されたモデルは名目上です。 実装は提示されるようにこのモデルの細部に合う必要はありませんが、実装の外部の振舞いは、言いなりになるためにこのモデルの外部的に観察可能な特性に対応しなければなりません。
There are three nominal databases in this model: the Security Policy Database (SPD), the Security Association Database (SAD), and the Peer Authorization Database (PAD). The first specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host or security gateway (Section 4.4.1). The second database contains parameters that are associated with each established (keyed) SA (Section 4.4.2). The third database, the PAD, provides a link between an SA management protocol (such as IKE) and the SPD (Section 4.4.3).
このモデルには3つの名目上のデータベースがあります: 安全保障政策データベース(SPD)、セキュリティ協会データベース(悲しい)、および同輩承認データベース(パッド)。 1番目はホストかセキュリティゲートウェイ(セクション4.4.1)からの本国行きの、または、外国行きのすべてのIPトラフィックの気質を決定する方針を指定します。 2番目のデータベースは設立されるそれぞれに関連している(合わせられた)SA(セクション4.4.2)であるパラメタを含んでいます。 3番目のデータベース(PAD)はSA管理プロトコル(IKEなどの)とSPD(セクション4.4.3)とのリンクを提供します。
Multiple Separate IPsec Contexts
複数の別々のIPsec関係
If an IPsec implementation acts as a security gateway for multiple
subscribers, it MAY implement multiple separate IPsec contexts.
Each context MAY have and MAY use completely independent
identities, policies, key management SAs, and/or IPsec SAs. This
is for the most part a local implementation matter. However, a
means for associating inbound (SA) proposals with local contexts
is required. To this end, if supported by the key management
protocol in use, context identifiers MAY be conveyed from
initiator to responder in the signaling messages, with the result
that IPsec SAs are created with a binding to a particular context.
For example, a security gateway that provides VPN service to
multiple customers will be able to associate each customer's
traffic with the correct VPN.
IPsec実装が複数の加入者のためのセキュリティゲートウェイとして機能するなら、それは複数の別々のIPsec関係を実装するかもしれません。 各文脈は、使用して、かぎ管理の完全に独立しているアイデンティティ、方針、SAs、そして/または、IPsec SAsを使用するかもしれません。 これはだいたいローカルの実装問題です。 しかしながら、本国行きの(SA)提案をローカルの関係に関連づけるための手段が必要です。 このために、使用中の主要な管理プロトコルによってサポートされるなら、文脈識別子はシグナリングメッセージで創始者から応答者まで伝えられるかもしれません、その結果、IPsec SAsが結合で特定の文脈に作成されます。 例えば、複数の顧客に対するサービスをVPNに供給するセキュリティゲートウェイは各顧客のトラフィックを正しいVPNに関連づけることができるでしょう。
Forwarding vs Security Decisions
セキュリティに対して決定を送ります。
The IPsec model described here embodies a clear separation between
forwarding (routing) and security decisions, to accommodate a wide
range of contexts where IPsec may be employed. Forwarding may be
trivial, in the case where there are only two interfaces, or it
may be complex, e.g., if the context in which IPsec is implemented
ここで説明されたIPsecモデルは、IPsecが使われるかもしれないさまざまな文脈に対応するために推進(ルーティング)とセキュリティ決定の間の明確な分離を具体化します。 推進は些細であるかもしれません、2つのインタフェースしかないか、またはそれが複雑であるかもしれない場合で、例えば、文脈がどのIPsecで実装されるかなら
Kent & Seo Standards Track [Page 18] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[18ページ]。
employs a sophisticated forwarding function. IPsec assumes only
that outbound and inbound traffic that has passed through IPsec
processing is forwarded in a fashion consistent with the context
in which IPsec is implemented. Support for nested SAs is
optional; if required, it requires coordination between forwarding
tables and SPD entries to cause a packet to traverse the IPsec
boundary more than once.
洗練された推進機能を使います。 IPsecは、それだけが外国行きであると仮定します、そして、IPsecが実装される文脈と一致したファッションでIPsec処理を通り抜けたインバウンドトラフィックを進めます。 入れ子にされたSAsのサポートは任意です。 必要なら、パケットがIPsec境界をさらに横断することを引き起こすのが一度より推進テーブルとSPDエントリーの間のコーディネートを必要とします。
"Local" vs "Remote"
「リモート」に対して「地方です」。
In this document, with respect to IP addresses and ports, the
terms "Local" and "Remote" are used for policy rules. "Local"
refers to the entity being protected by an IPsec implementation,
i.e., the "source" address/port of outbound packets or the
"destination" address/port of inbound packets. "Remote" refers to
a peer entity or peer entities. The terms "source" and
"destination" are used for packet header fields.
本書では、IPアドレスとポートに関して、「地方」という用語と「リモート」は政策ルールに使用されます。 「地方」はIPsec実装(すなわち、外国行きのパケットか本国行きのパケットの「目的地」アドレス/ポートの「ソース」アドレス/ポート)によって保護される実体を示します。 「リモート」は同輩実体か同輩実体を示します。 用語「ソース」と「目的地」はパケットヘッダーフィールドに使用されます。
"Non-initial" vs "Initial" Fragments
「初期」の断片に対して「非初期です」。
Throughout this document, the phrase "non-initial fragments" is
used to mean fragments that do not contain all of the selector
values that may be needed for access control (e.g., they might not
contain Next Layer Protocol, source and destination ports, ICMP
message type/code, Mobility Header type). And the phrase "initial
fragment" is used to mean a fragment that contains all the
selector values needed for access control. However, it should be
noted that for IPv6, which fragment contains the Next Layer
Protocol and ports (or ICMP message type/code or Mobility Header
type [Mobip]) will depend on the kind and number of extension
headers present. The "initial fragment" might not be the first
fragment, in this context.
このドキュメント中では、「非初期の断片」という句は、アクセスコントロールに必要であるかもしれないセレクタ値のすべてを含まない断片を意味するのに使用されます(Next Layerプロトコル、ソース、および仕向港を含まないかもしれません、ICMPメッセージタイプ/コード、Mobility Headerタイプ)。 そして、「初期の断片」という句は、アクセスコントロールに必要であるすべてのセレクタ値を含む断片を意味するのに使用されます。 しかしながら、IPv6のために、どの断片がNext Layerプロトコルとポート(ICMPメッセージタイプ/コードかMobility Headerが[Mobip]をタイプする)を含んでいるかをヘッダーが提示する拡大の種類と数に依存することに注意されるべきです。 「初期の断片」はこの文脈で最初の断片でないかもしれません。
4.4.1. The Security Policy Database (SPD)
4.4.1. 安全保障政策データベース(SPD)
An SA is a management construct used to enforce security policy for traffic crossing the IPsec boundary. 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 specifies minimum management functionality that must be provided, to allow a user or system administrator to control whether and how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway. The SPD, or relevant caches, must be consulted during the processing of all traffic (inbound and outbound), including traffic not protected by IPsec, that traverses the IPsec boundary. This includes IPsec management traffic such as IKE. An IPsec
SAはIPsec境界に交差するトラフィックのための安全保障政策を実施するのに使用される管理構造物です。 したがって、SA処理の必須元素はどんなサービスがデータグラムとどんなファッションでIPに提供されるかことであるかと指定する基本的なSecurity Policy Database(SPD)です。 この仕様の範囲の外にデータベースのフォームとそのインタフェースがあります。 しかしながら、このセクションは伝えられるか、ホストによって受け取られるか、またはセキュリティゲートウェイを通過しながらユーザかシステム管理者が、適用されてIPsecがどのようにトラフィックに適用されるかを制御するのを許容するために提供しなければならない最小の管理の機能性を指定します。 IPsec境界を横断するIPsecによって保護されなかったトラフィックを含むすべてのトラフィック(本国行きの、そして、外国行きの)の処理の間、SPD、または関連キャッシュに相談しなければなりません。 これはIKEなどのIPsec管理トラフィックを含んでいます。 IPsec
Kent & Seo Standards Track [Page 19] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[19ページ]。
implementation MUST have at least one SPD, and it MAY support multiple SPDs, if appropriate for the context in which the IPsec implementation operates. There is no requirement to maintain SPDs on a per-interface basis, as was specified in RFC 2401 [RFC2401]. However, if an implementation supports multiple SPDs, then it MUST include an explicit SPD selection function that is invoked to select the appropriate SPD for outbound traffic processing. The inputs to this function are the outbound packet and any local metadata (e.g., the interface via which the packet arrived) required to effect the SPD selection function. The output of the function is an SPD identifier (SPD-ID).
実装には少なくとも1SPDがなければなりません、そして、複数のSPDsをサポートするかもしれません、IPsec実装が作動する文脈に適切であるなら。 1インタフェースあたり1個のベースでSPDsを維持するという要件が全く指定されていたようにRFC2401[RFC2401]にありません。 しかしながら、実装が複数のSPDsをサポートするなら、それはアウトバウンドトラフィック処理のために適切なSPDを選択するために呼び出される明白なSPD選択機能を含まなければなりません。 この機能への入力は外国行きのパケットです、そして、どんなローカルのメタデータ(例えば、インタフェースを通ってパケットが到着した)もSPD選択機能に作用するのが必要です。 機能の出力はSPD識別子(SPD-ID)です。
The SPD is an ordered database, consistent with the use of Access Control Lists (ACLs) or packet filters in firewalls, routers, etc. The ordering requirement arises because entries often will overlap due to the presence of (non-trivial) ranges as values for selectors. Thus, a user or administrator MUST be able to order the entries to express a desired access control policy. There is no way to impose a general, canonical order on SPD entries, because of the allowed use of wildcards for selector values and because the different types of selectors are not hierarchically related.
SPDは規則正しいデータベースです、ファイアウォール、ルータなどでAccess Control Lists(ACLs)かパケットフィルタの使用と一致しています。 エントリーが(重要)の範囲の存在のためセレクタのための値としてしばしば重なるので、注文要件は起こります。 したがって、ユーザか管理者が、必要なアクセス制御方針を言い表すようエントリーに命令することができなければなりません。 SPDエントリーに一般的で、正準なオーダーを課す方法が全くありません、ワイルドカードのセレクタ値の許容使用のため異なったタイプのセレクタが階層的に関係づけられないので。
Processing Choices: DISCARD, BYPASS, PROTECT
処理選択: 破棄、迂回は保護されます。
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 PROTECT using IPsec. The
first choice refers to traffic that is not allowed to traverse the
IPsec boundary (in the specified direction). The second choice
refers to traffic that is allowed to cross the IPsec boundary
without IPsec protection. The third choice refers to traffic that
is afforded IPsec protection, and for such traffic the SPD must
specify the security protocols to be employed, their mode,
security service options, and the cryptographic algorithms to be
used.
SPDはIPsec保護が提供されているトラフィックとIPsecを迂回させることができるトラフィックの中で差別しなければなりません。 これは、送付者と、そして、受信機に出席するに違いないIPsec保護に適用されるのをIPsec保護に適用します。どんな外国行きの、または、本国行きのデータグラムに関しても、3つの処理選択が可能です: 捨てるか、IPsecを迂回させるか、またはIPsecを使用して、保護してください。 最初の選択はIPsec境界(指定された方向への)を横断できないトラフィックについて言及します。 第二希望はIPsec保護なしでIPsec境界に交差できるトラフィックについて言及します。 3番目の選択はIPsec保護が提供されているトラフィックについて言及します、そして、そのようなトラフィックとして、SPDは使用されるために使われるべきセキュリティプロトコル、それらのモード、セキュリティー・サービスオプション、および暗号アルゴリズムを指定しなければなりません。
SPD-S, SPD-I, SPD-O
SPD-S、SPD-I、SPD-O
An SPD is logically divided into three pieces. The SPD-S (secure
traffic) contains entries for all traffic subject to IPsec
protection. SPD-O (outbound) contains entries for all outbound
traffic that is to be bypassed or discarded. SPD-I (inbound) is
applied to inbound traffic that will be bypassed or discarded.
All three of these can be decorrelated (with the exception noted
above for native host implementations) to facilitate caching. If
SPDはスリーピースに論理的に分割されます。 SPD-S(安全なトラフィック)はIPsec保護を条件としてすべてのトラフィックのためのエントリーを含んでいます。 SPD-O(外国行きの)は迂回することになっているか、または捨てられることになっているすべてのアウトバウンドトラフィックのためのエントリーを含んでいます。 SPD-I(本国行きの)は迂回するか、または捨てられるインバウンドトラフィックに適用されます。 これらのすべての3が、キャッシュするのを容易にするために反関連できます(例外がネイティブのホスト導入によって上に述べられている状態で)。 if
Kent & Seo Standards Track [Page 20] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[20ページ]。
an IPsec implementation supports only one SPD, then the SPD
consists of all three parts. If multiple SPDs are supported, some
of them may be partial, e.g., some SPDs might contain only SPD-I
entries, to control inbound bypassed traffic on a per-interface
basis. The split allows SPD-I to be consulted without having to
consult SPD-S, for such traffic. Since the SPD-I is just a part
of the SPD, if a packet that is looked up in the SPD-I cannot be
matched to an entry there, then the packet MUST be discarded.
Note that for outbound traffic, if a match is not found in SPD-S,
then SPD-O must be checked to see if the traffic should be
bypassed. Similarly, if SPD-O is checked first and no match is
found, then SPD-S must be checked. In an ordered,
non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O
are interleaved. So there is one lookup in the SPD.
IPsec実装は1SPDだけをサポートして、次に、SPDはすべての3つの部品から成ります。 複数のSPDsがサポートされるなら、彼らの何人かが部分的であるかもしれない、例えばいくつかのSPDsが1インタフェースあたり1個のベースで本国行きの迂回しているトラフィックを制御するためにSPD-Iエントリーだけを含むかもしれません。 分裂は、SPD-IがそのようなトラフィックのためにSPD-Sに相談する必要はなくて相談されるのを許容します。 SPD-IがただSPDの一部であるので、そこでSPD-Iで調べられるパケットをエントリーに合わせることができないなら、パケットを捨てなければなりません。 SPD-Sと一致したものが探されないならアウトバウンドトラフィックがないかどうか、トラフィックが迂回するべきであるかどうか確認するためにSPD-Oをチェックしなければならないことに注意してください。 同様に、SPD-Oが最初に、チェックされて、マッチが全く見つけられないなら、SPD-Sをチェックしなければなりません。 命令された非decorrelated SPDでは、SPD-S、SPD-I、およびSPD-Oのためのエントリーははさみ込まれます。 それで、1つのルックアップがSPDにあります。
SPD Entries
SPDエントリー
Each SPD entry specifies packet disposition as BYPASS, DISCARD, or
PROTECT. The entry is keyed by a list of one or more selectors.
The SPD contains an ordered list of these entries. The required
selector types are defined in Section 4.4.1.1. These selectors are
used to define the granularity of the SAs that are created in
response to an outbound packet or in response to a proposal from a
peer. The detailed structure of an SPD entry is described in
Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that
matches anything that is otherwise unmatched, and discards it.
それぞれのSPDエントリーはBYPASS、DISCARD、またはPROTECTとしてパケット気質を指定します。 エントリーは1個以上のセレクタのリストによって合わせられます。 SPDはこれらのエントリーの規則正しいリストを含んでいます。 必要なセレクタタイプはセクション4.4.1で.1に定義されます。 これらのセレクタは、外国行きのパケットに対応して同輩からの提案に対応して作成されるSAsの粒状を定義するのに使用されます。 SPDエントリーの詳細な構造はセクション4.4.1で.2に説明されます。 あらゆるSPD SHOULDには、そうでなければ優れたものは何でも合わせて、それを捨てるノミナルで、最終的なエントリーがあります。
The SPD MUST permit a user or administrator to specify policy
entries as follows:
SPD MUSTは、ユーザか管理者が以下の方針エントリーを指定するのを可能にします:
- SPD-I: For inbound traffic that is to be bypassed or discarded,
the entry consists of the values of the selectors that apply to
the traffic to be bypassed or discarded.
- SPD-I: 迂回することになっているか、または捨てられることになっているインバウンドトラフィックのために、エントリーは迂回するか、または捨てられるのにトラフィックに申し込むセレクタの値から成ります。
- SPD-O: For outbound traffic that is to be bypassed or
discarded, the entry consists of the values of the selectors
that apply to the traffic to be bypassed or discarded.
- SPD-O: 迂回することになっているか、または捨てられることになっているアウトバウンドトラフィックのために、エントリーは迂回するか、または捨てられるのにトラフィックに申し込むセレクタの値から成ります。
- SPD-S: For traffic that is to be protected using IPsec, the
entry consists of the values of the selectors that apply to the
traffic to be protected via AH or ESP, controls on how to
create SAs based on these selectors, and the parameters needed
to effect this protection (e.g., algorithms, modes, etc.). Note
that an SPD-S entry also contains information such as "populate
from packet" (PFP) flag (see paragraphs below on "How To Derive
the Values for an SAD entry") and bits indicating whether the
- SPD-S: IPsecを使用することで保護されることになっているトラフィックのために、エントリーはAHか超能力を通して保護されるのにトラフィックに申し込むセレクタの値から成ります、どうこれらのセレクタに基づくSAs、およびこの保護に作用するのに必要であるパラメタを作成するかにおけるコントロール(例えば、アルゴリズム、モードなど)。 また、SPD-Sエントリーが(PFP)旗に「パケットから居住する」ような(「SADエントリーへのどのようにTo Derive Values」の以下のパラグラフを見るか)情報とビット表示を含むことに注意してください。
Kent & Seo Standards Track [Page 21] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[21ページ]。
SA lookup makes use of the local and remote IP addresses in
addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
specifications).
SAルックアップはSPIに加えた地方の、そして、リモートなIPアドレスを利用します(AH[Ken05b]か超能力[Ken05a]仕様を見てください)。
Representing Directionality in an SPD Entry
SPDエントリーに方向性を表します。
For traffic protected by IPsec, the Local and Remote address and
ports in an SPD entry are swapped to represent directionality,
consistent with IKE conventions. In general, the protocols that
IPsec deals with have the property of requiring symmetric SAs with
flipped Local/Remote IP addresses. However, for ICMP, there is
often no such bi-directional authorization requirement.
Nonetheless, for the sake of uniformity and simplicity, SPD
entries for ICMP are specified in the same way as for other
protocols. Note also that for ICMP, Mobility Header, and
non-initial fragments, there are no port fields in these packets.
ICMP has message type and code and Mobility Header has mobility
header type. Thus, SPD entries have provisions for expressing
access controls appropriate for these protocols, in lieu of the
normal port field controls. For bypassed or discarded traffic,
separate inbound and outbound entries are supported, e.g., to
permit unidirectional flows if required.
IPsecによって保護されたトラフィックにおいてSPDエントリーにおけるLocal、Remoteアドレス、およびポートは方向性を表すために交換されます、IKEコンベンションと一致しています。 一般に、IPsecが対処するプロトコルははじき出されたLocal/リモートなIPアドレスがある左右対称のSAsを必要とする特性を持っています。 しかしながら、ICMPのために、そのようなどんな双方向の承認要件もしばしばあるというわけではありません。 同様に、それにもかかわらず、一様性と簡単さのためにICMPのためのSPDエントリーは他のプロトコルのように指定されます。 また、ICMP、Mobility Header、および非初期の断片のために、ポート分野が全くこれらのパケットにないことに注意してください。 ICMPには、メッセージタイプとコードがあります、そして、Mobility Headerには、移動性ヘッダータイプがあります。 したがって、SPDエントリーでアクセス制御を言い表すための条項はこれらのプロトコルに適切になります、通常のポートフィールド制御の代わりに。 迂回したか捨てられたトラフィックにおいて、別々の本国行きの、そして、外国行きのエントリーは、例えば必要なら、単方向の流れを可能にするためにサポートされます。
OPAQUE and ANY
不透明なものといずれも
For each selector in an SPD entry, in addition to the literal
values that define a match, there are two special values: ANY and
OPAQUE. ANY is a wildcard that matches any value in the
corresponding field of the packet, or that matches packets where
that field is not present or is obscured. OPAQUE indicates that
the corresponding selector field is not available for examination
because it may not be present in a fragment, it does not exist for
the given Next Layer Protocol, or prior application of IPsec may
have encrypted the value. The ANY value encompasses the OPAQUE
value. Thus, OPAQUE need be used only when it is necessary to
distinguish between the case of any allowed value for a field, vs.
the absence or unavailability (e.g., due to encryption) of the
field.
SPDエントリーに加えた各セレクタのために、2つの特別な値があります: いずれと不透明なもの。 何がでパケットの対応する分野でどんな値も合わせるか、またはその分野が存在していないところでパケットに合っているワイルドカードであるかでもあいまいにされます。 OPAQUEが、それが断片に存在していないかもしれないので対応するセレクタ分野が試験に利用可能でないことを示すか、与えられたNext Layerプロトコルのために存在していないか、またはIPsecの先願は値を暗号化したかもしれません。 どんな値もOPAQUE値を取り囲みます。 値が許容されたいずれに関するケースを分野に見分けるのが必要であるときにだけ、したがって、OPAQUEは使用されなければなりません、分野の不在か使用不能(例えば、暗号化による)に対して。
How to Derive the Values for an SAD Entry
悲しいエントリーに値を引き出す方法
For each selector in an SPD entry, the entry specifies how to
derive the corresponding values for a new SA Database (SAD, see
Section 4.4.2) entry from those in the SPD and the packet. The
goal is to allow an SAD entry and an SPD cache entry to be created
based on specific selector values from the packet, or from the
matching SPD entry. For outbound traffic, there are SPD-S cache
entries and SPD-O cache entries. For inbound traffic not
SPDエントリーにおける各セレクタとして、エントリーはSPDとパケットのそれらから換算値を新しいSA Database(SAD、セクション4.4.2を見る)エントリーに引き出す方法を指定します。 目標はSADエントリーとSPDキャッシュエントリーがパケット、または、合っているSPDエントリーからの特定のセレクタ値に基づいて作成されるのを許容することです。 アウトバウンドトラフィックのために、SPD-SキャッシュエントリーとSPD-Oキャッシュエントリーがあります。 インバウンドトラフィック
Kent & Seo Standards Track [Page 22] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[22ページ]。
protected by IPsec, there are SPD-I cache entries and there is the
SAD, which represents the cache for inbound IPsec-protected
traffic (see Section 4.4.2). If IPsec processing is specified for
an entry, a "populate from packet" (PFP) flag may be asserted for
one or more of the selectors in the SPD entry (Local IP address;
Remote IP address; Next Layer Protocol; and, depending on Next
Layer Protocol, Local port and Remote port, or ICMP type/code, or
Mobility Header type). If asserted for a given selector X, the
flag indicates that the SA to be created should take its value for
X from the value in the packet. Otherwise, the SA should take its
value(s) for X from the value(s) in the SPD entry. Note: In the
non-PFP case, the selector values negotiated by the SA management
protocol (e.g., IKEv2) may be a subset of those in the SPD entry,
depending on the SPD policy of the peer. Also, whether a single
flag is used for, e.g., source port, ICMP type/code, and Mobility
Header (MH) type, or a separate flag is used for each, is a local
matter.
IPsecによって保護されて、SPD-Iキャッシュエントリーがあります、そして、SADがあります(セクション4.4.2を見てください)。(SADは本国行きのIPsecによって保護されたトラフィックのためにキャッシュを表します)。 IPsec処理がエントリーに指定されるなら、aは(PFP)旗に「パケットから居住します」。SPDエントリー(ローカルアイピーアドレス; リモートIPアドレス(次のLayerプロトコル)とLocalポートとRemoteポートか、ICMPタイプ/コードか、Mobility HeaderタイプNext Layerプロトコルによって、)におけるセレクタの1つ以上のために断言されるかもしれません。 与えられたセレクタXのために断言されるなら、旗は、作成されるべきSAがパケットで値からXに値を取るはずであるのを示します。 さもなければ、SAはSPDエントリーで値からXに値を取るはずです。 以下に注意してください。 非PFP場合では、SA管理プロトコル(例えば、IKEv2)によって交渉されたセレクタ値はSPDエントリーにおけるそれらの部分集合であるかもしれません、同輩のSPD方針によって。 また、地域にかかわる事柄はただ一つの旗が使用されていて、例えば、ソースポート、ICMPタイプ/コード、およびMobility Header(MH)がタイプするか、または別々の旗がそれぞれに使用されるということであるか否かに関係なく、ことですか?
The following example illustrates the use of the PFP flag in the
context of a security gateway or a BITS/BITW implementation.
Consider an SPD entry where the allowed value for Remote address
is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an
outbound packet arrives with a destination address of 192.0.2.3,
and there is no extant SA to carry this packet. The value used
for the SA created to transmit this packet could be either of the
two values shown below, depending on what the SPD entry for this
selector says is the source of the selector value:
以下の例はセキュリティゲートウェイかBITS/BITW実装の文脈におけるPFP旗の使用を例証します。 SPDがRemoteアドレスのための許容値がさまざまなIPv4アドレスであるエントリーであると考えてください: 192.0.2.1、192.0 .2 .10。 外国行きのパケットが192.0の送付先アドレスと共に到着すると仮定してください、.2、.3、このパケットを運ぶために、どんな実在のSAもありません。 2つのもののどちらかがこのセレクタのためのSPDエントリーがセレクタ価値の源であると言うことによって、以下に示された値であったかもしれないならこのパケットを伝えるために作成されたSAに使用される値:
PFP flag value example of new
for the Remote SAD dest. address
addr. selector selector value
--------------- ------------
a. PFP TRUE 192.0.2.3 (one host)
b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts)
PFPはRemote SAD destに新しいことの値の例に旗を揚げさせます。addrセレクタセレクタ価値を扱ってください。--------------- ------------ a。 PFP TRUE、192.0 .2 .3 (1人のホスト) b。 PFP誤った192.0.2、.1〜192.0、.2、.10(ホストの範囲)
Note that if the SPD entry above had a value of ANY for the Remote
address, then the SAD selector value would have to be ANY for case
(b), but would still be as illustrated for case (a). Thus, the
PFP flag can be used to prohibit sharing of an SA, even among
packets that match the same SPD entry.
上のSPDエントリーにはRemoteアドレスのためのいずれかの値があって、次に、SADセレクタ価値はケース(b)のためのいずれかでなければならないでしょうが、ケース(a)のために例証されるようにまだあるなら、それに注意してください。 したがって、SAを共有するのを禁止するのにPFP旗を使用できます、同じSPDエントリーに合っているパケットの中でさえ。
Management Interface
管理インタフェース
For every IPsec implementation, there MUST be a management
interface that allows a user or system administrator to manage the
SPD. The interface must allow the user (or administrator) to
specify the security processing to be applied to every packet that
traverses the IPsec boundary. (In a native host IPsec
あらゆるIPsec実装のために、ユーザかシステム管理者がSPDを管理できる管理インタフェースがあるに違いありません。 インタフェースで、ユーザ(または、管理者)は、IPsec境界を横断するあらゆるパケットに適用されるためにセキュリティ処理を指定できなければなりません。 (ネイティブホストIPsec
Kent & Seo Standards Track [Page 23] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[23ページ]。
implementation making use of a socket interface, the SPD may not
need to be consulted on a per-packet basis, as noted at the end of
Section 4.4.1.1 and in Section 5.) The management interface for
the SPD MUST allow creation of entries consistent with the
selectors defined in Section 4.4.1.1, and MUST support (total)
ordering of these entries, as seen via this interface. The SPD
entries' selectors are analogous to the ACL or packet filters
commonly found in a stateless firewall or packet filtering router
and which are currently managed this way.
ソケットインタフェースの実装作成使用、セクション4.4.1の終わりで.1に注意してセクション5で1パケットあたり1個のベースに関してSPDは相談される必要はないかもしれません。) SPD MUSTのための管理インタフェースは、このインタフェースを通して見られるようにセクション4.4.1で定義されるセレクタと一致したエントリーの作成に.1を許容して、これらのエントリーの(総)の注文をサポートしなければなりません。 SPDエントリーのセレクタは現在このように管理される状態がないファイアウォールかパケットフィルタリングルータで一般的に見つけられたACLかパケットフィルタに類似しています。
In host systems, applications MAY be allowed to create SPD
entries. (The means of signaling 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. 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.
ホストシステムでは、アプリケーションはSPDエントリーを作成できるかもしれません。 (この規格の範囲の外にIPsec実装にそのような要求に合図する手段があります。) しかしながら、システム管理者は、ユーザかアプリケーションが(デフォルト)システム方針をくつがえすことができるかどうか指定できなければなりません。 管理インタフェースのフォームは、このドキュメントによって指定されないで、ホスト対セキュリティゲートウェイのために異なるかもしれません、そして、ホストの中では、インタフェースはBITSに対するソケットベースの実装のために異なるかもしれません。 しかしながら、このドキュメントはすべてのIPsec実装が支えなければならないSPD要素の標準セットを指定します。
Decorrelation
Decorrelation
The processing model described in this document assumes the
ability to decorrelate overlapping SPD entries to permit caching,
which enables more efficient processing of outbound traffic in
security gateways and BITS/BITW implementations. Decorrelation
[CoSa04] is only a means of improving performance and simplifying
the processing description. This RFC does not require a compliant
implementation to make use of decorrelation. For example, native
host implementations typically make use of caching implicitly
because they bind SAs to socket interfaces, and thus there is no
requirement to be able to decorrelate SPD entries in these
implementations.
本書では説明された処理モデルはキャッシュすることを許可するためにSPDエントリーを重ね合わせる「反-相関物」への能力を仮定します。(「反-相関物」はセキュリティゲートウェイとBITS/BITW実装における、アウトバウンドトラフィックの、より効率的な処理を可能にします)。 Decorrelation[CoSa04]は性能を向上させて、処理記述を簡素化する手段にすぎません。 このRFCは、「反-相関関係」を利用するために対応する実装を必要としません。 例えば、ソケットインタフェースにSAsを縛るので、ネイティブのホスト導入はそれとなくキャッシュを通常利用します、そして、その結果、これらの実装にはdecorrelate SPDエントリーにできるという要件が全くありません。
Note: Unless otherwise qualified, the use of "SPD" refers to the
body of policy information in both ordered or decorrelated
(unordered) state. Appendix B provides an algorithm that can be
used to decorrelate SPD entries, but any algorithm that produces
equivalent output may be used. Note that when an SPD entry is
decorrelated all the resulting entries MUST be linked together, so
that all members of the group derived from an individual, SPD
entry (prior to decorrelation) can all be placed into caches and
into the SAD at the same time. For example, suppose one starts
with an entry A (from an ordered SPD) that when decorrelated,
yields entries A1, A2, and A3. When a packet comes along that
matches, say A2, and triggers the creation of an SA, the SA
management protocol (e.g., IKEv2) negotiates A. And all 3
以下に注意してください。 別の方法で資格がない場合、"SPD"の使用は注文された両方か反関連している(順不同の)状態で方針情報のボディーについて言及します。 付録Bはdecorrelate SPDエントリーに使用できるアルゴリズムを提供しますが、同等な出力を起こすどんなアルゴリズムも使用されるかもしれません。 SPDエントリーが反関連するとき、グループのすべてのメンバーが個人に由来していたようにすべての結果として起こるエントリーを結びつけなければならないというメモ、同時に、SPDエントリー(「反-相関関係」の前の)をキャッシュの中と、そして、SADの中にすべて置くことができます。 例えば、利回りの反関連すると1つがそれをエントリーA(命令されたSPDからの)からの始めであるならエントリーのA1、A2、およびA3。 パケットがたとえば、そのマッチ、A2に沿って来て、SAの作成の引き金となると、SA管理プロトコル(例えば、IKEv2)がA.Andを交渉する、すべての3
Kent & Seo Standards Track [Page 24] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[24ページ]。
decorrelated entries, A1, A2, and A3, are placed in the
appropriate SPD-S cache and linked to the SA. The intent is that
use of a decorrelated SPD ought not to create more SAs than would
have resulted from use of a not-decorrelated SPD.
反関連エントリー(A1、A2、およびA3)は、適切なSPD-Sキャッシュに置かれて、SAにリンクされます。 意図はdecorrelated SPDの使用がdecorrelated SPDでないことの使用から生じただろうより多くのSAsを作成するべきでないということです。
If a decorrelated SPD is employed, there are three options for
what an initiator sends to a peer via an SA management protocol
(e.g., IKE). By sending the complete set of linked, decorrelated
entries that were selected from the SPD, a peer is given the best
possible information to enable selection of the appropriate SPD
entry at its end, especially if the peer has also decorrelated its
SPD. However, if a large number of decorrelated entries are
linked, this may create large packets for SA negotiation, and
hence fragmentation problems for the SA management protocol.
decorrelated SPDが採用しているなら、SA管理プロトコル(例えば、IKE)で創始者が同輩に送るもののための3つのオプションがあります。 SPDから選択された完全な繋がっていて、反関連しているエントリーを送ることによって、選択を可能にするために終わりの適切なSPDエントリーについて可能な限り良い情報を同輩に与えます、また、特に同輩がSPDを反関連させたなら。 しかしながら、多くの反関連エントリーが繋がるなら、これは、SA管理プロトコルのためにSA交渉のための大きいパケットを作成して、したがって、断片化問題を作成するかもしれません。
Alternatively, the original entry from the (correlated) SPD may be
retained and passed to the SA management protocol. Passing the
correlated SPD entry keeps the use of a decorrelated SPD a local
matter, not visible to peers, and avoids possible fragmentation
concerns, although it provides less precise information to a
responder for matching against the responder's SPD.
あるいはまた、(関連する)のSPDからの原始記入は、SA管理プロトコルに保有されて、通り過ぎられるかもしれません。 関連SPDエントリーを通り過ぎると、同輩にとって、目に見えないdecorrelated SPD a地域にかかわる事柄の使用が保たれて、可能な断片化関心は避けられます、応答者のSPDに対して合うように、より少ない正確な情報を応答者に提供しますが。
An intermediate approach is to send a subset of the complete set
of linked, decorrelated SPD entries. This approach can avoid the
fragmentation problems cited above yet provide better information
than the original, correlated entry. The major shortcoming of
this approach is that it may cause additional SAs to be created
later, since only a subset of the linked, decorrelated entries are
sent to a peer. Implementers are free to employ any of the
approaches cited above.
中間的アプローチは繋がっている完全なdecorrelated SPDエントリーの部分集合を送ることです。 上で問題が引用した断片化を避けますが、このアプローチはオリジナルの、そして、関連しているエントリーより良い情報を提供できます。 このアプローチの主要な短所は後でそれで追加SAsを作成するかもしれないということです、繋がりの部分集合だけ以来反関連エントリーを同輩に送ります。 Implementersは自由に上で引用されたアプローチのいずれも使うことができます。
A responder uses the traffic selector proposals it receives via an
SA management protocol to select an appropriate entry in its SPD.
The intent of the matching is to select an SPD entry and create an
SA that most closely matches the intent of the initiator, so that
traffic traversing the resulting SA will be accepted at both ends.
If the responder employs a decorrelated SPD, it SHOULD use the
decorrelated SPD entries for matching, as this will generally
result in creation of SAs that are more likely to match the intent
of both peers. If the responder has a correlated SPD, then it
SHOULD match the proposals against the correlated entries. For
IKEv2, use of a decorrelated SPD offers the best opportunity for a
responder to generate a "narrowed" response.
応答者はそれがSPDで適切なエントリーを選択するためにSA管理プロトコルで受けるトラフィックセレクタ提案を使用します。 マッチングの意図は、SPDエントリーを選択して、最も密接に創始者の意図に合っているSAを作成することです、両端で結果として起こるSAを横断するトラフィックを受け入れるように。 応答者はdecorrelated SPDを使って、それはこれとして合うためのdecorrelated SPDエントリーがそうするSHOULD使用です。一般に、両方の同輩の意図をより合わせそうなSAsの作成をもたらしてください。 応答者がそうしたなら、aはSPDを関連させて、次に、それはSHOULDです。関連エントリーに対して提案に合ってください。 IKEv2のために、decorrelated SPDの使用は応答者が「狭くされた」応答を生成するまたとない機会を提供します。
In all cases, when a decorrelated SPD is available, the
decorrelated entries are used to populate the SPD-S cache. If the
SPD is not decorrelated, caching is not allowed and an ordered
すべての場合では、decorrelated SPDが利用可能であるときに、反関連エントリーは、SPD-Sキャッシュに居住するのに使用されます。 そして、SPDが反関連しないなら、キャッシュが許されていない、注文
Kent & Seo Standards Track [Page 25] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[25ページ]。
search of SPD MUST be performed to verify that inbound traffic
arriving on an SA is consistent with the access control policy
expressed in the SPD.
探してください。SPD MUSTでは、実行されて、SAで到着するインバウンドトラフィックがSPDで言い表されるアクセス制御方針と一致していることを確かめてください。
Handling Changes to the SPD While the System Is Running
システムが動いている間のSPDへの取り扱い変化
If a change is made to the SPD while the system is running, a
check SHOULD be made of the effect of this change on extant SAs.
An implementation SHOULD check the impact of an SPD change on
extant SAs and SHOULD provide a user/administrator with a
mechanism for configuring what actions to take, e.g., delete an
affected SA, allow an affected SA to continue unchanged, etc.
変更がシステムが稼働、チェックSHOULDである間にSPDにされるaであるなら、実在のSAsへのこの変化の効果で作られてください。 実装SHOULDは実在のSAsでSPD変化の影響をチェックして、SHOULDは、例えば取るどんな動作が、影響を受けるSAを削除して、影響を受けるSAが変わりがない状態で続くのを許容するかなどを構成するためにユーザ/管理者にメカニズムを提供します。
4.4.1.1. Selectors
4.4.1.1. セレクタ
An SA 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 Layer Protocol and related fields, e.g., ports), 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 by all IPsec implementations to facilitate control of SA granularity. Note that both Local and Remote addresses should either be IPv4 or IPv6, but not a mix of address types. Also, note that the Local/Remote port selectors (and ICMP message type and code, and Mobility Header type) may be labeled as OPAQUE to accommodate situations where these fields are inaccessible due to packet fragmentation.
SAはきめ細かに粒状である、または下品であるかもしれません、SAのためにトラフィックのセットを定義するのに使用されるセレクタによって。 例えば、2人のホストの間のすべてのトラフィックを独身のSAを通して運んで、セキュリティー・サービスのユニフォームセットに提供するかもしれません。 あるいはまた、1組のホストの間のトラフィックは複数のSAsの上に広げられるかもしれません、使用されるアプリケーションによって(Next Layerプロトコルと関連分野、例えば、ポートによって定義されるように)、異なったセキュリティー・サービスが異なったSAsによって提供されている状態で。 同様に、独身のSAで1組のセキュリティゲートウェイの間のすべてのトラフィックを運ぶことができましたか、またはそれぞれの交信しているホスト組のために1SAを割り当てることができました。 すべてのIPsec実装で以下のセレクタパラメタをサポートして、SA粒状のコントロールを容易にしなければなりません。 LocalとRemoteアドレスの両方がミックスではなく、アドレスタイプのIPv4かIPv6のどちらかであるべきであることに注意してください。 また、Local/リモートなポートセレクタ(そして、ICMPメッセージタイプ、コード、およびMobility Headerタイプ)がこれらの分野がパケット断片化のために近づきがたいところに状況を収容するためにOPAQUEとしてラベルされるかもしれないことに注意してください。
- Remote IP Address(es) (IPv4 or IPv6): This is a list of ranges
of IP addresses (unicast, broadcast (IPv4 only)). This
structure allows expression of a single IP address (via a
trivial range), or a list of addresses (each a trivial range),
or a range of addresses (low and high values, inclusive), as
well as the most generic form of a list of ranges. Address
ranges are used to support more than one remote system sharing
the same SA, e.g., behind a security gateway.
- リモートIPアドレス(es)(IPv4かIPv6): これはIPアドレス(ユニキャスト、放送(IPv4専用))の範囲のリストです。 この構造はアドレス(些細な範囲を通る)、住所録(それぞれのa些細な範囲)、またはさまざまなアドレス(低くて高い値の、そして、包括的な)を単一のIPの式に許容します、範囲のリストの最も多くのジェネリックフォームと同様に。 アドレスの範囲は、例えば、セキュリティゲートウェイの後ろで同じSAを共有する1台以上のリモートシステムをサポートするのに使用されます。
- Local IP Address(es) (IPv4 or IPv6): This is a list of ranges of
IP addresses (unicast, broadcast (IPv4 only)). This structure
allows expression of a single IP address (via a trivial range),
or a list of addresses (each a trivial range), or a range of
addresses (low and high values, inclusive), as well as the most
generic form of a list of ranges. Address ranges are used to
- ローカルのIPアドレス(es)(IPv4かIPv6): これはIPアドレス(ユニキャスト、放送(IPv4専用))の範囲のリストです。 この構造はアドレス(些細な範囲を通る)、住所録(それぞれのa些細な範囲)、またはさまざまなアドレス(低くて高い値の、そして、包括的な)を単一のIPの式に許容します、範囲のリストの最も多くのジェネリックフォームと同様に。 範囲が使用されているアドレス
Kent & Seo Standards Track [Page 26] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[26ページ]。
support more than one source system sharing the same SA, e.g.,
behind a security gateway. Local refers to the address(es)
being protected by this implementation (or policy entry).
例えば、セキュリティゲートウェイの後ろで1つ以上のソースのシステム共有が同じSAであるとサポートしてください。 ローカルはこの実装(または、方針エントリー)によって保護されるアドレス(es)を参照します。
Note: The SPD does not include support for multicast address
entries. To support multicast SAs, an implementation should
make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD
entries require a different structure, i.e., one cannot use the
symmetric relationship associated with local and remote address
values for unicast SAs in a multicast context. Specifically,
outbound traffic directed to a multicast address on an SA would
not be received on a companion, inbound SA with the multicast
address as the source.
以下に注意してください。 SPDはマルチキャストアドレスエントリーのサポートを含んでいません。 マルチキャストがSAsであるとサポートするために、実装は[RFC3740]で定義されるようにGroup SPD(GSPD)を利用するべきです。 GSPDエントリーは異なった構造を必要とします、すなわち、1つがユニキャストSAsにマルチキャスト文脈で地方の、そして、リモートなアドレス値に関連している左右対称の関係を使用できません。 明確に、SAに関するマルチキャストアドレスに向けられたアウトバウンドトラフィックは仲間(ソースとしてのマルチキャストアドレスがある本国行きのSA)の上に受け取られないでしょう。
- Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
IPv6 "Next Header" fields. This is an individual protocol
number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol
is whatever comes after any IP extension headers that are
present. To simplify locating the Next Layer Protocol, there
SHOULD be a mechanism for configuring which IPv6 extension
headers to skip. The default configuration for which protocols
to skip SHOULD include the following protocols: 0 (Hop-by-hop
options), 43 (Routing Header), 44 (Fragmentation Header), and 60
(Destination Options). Note: The default list does NOT include
51 (AH) or 50 (ESP). From a selector lookup point of view,
IPsec treats AH and ESP as Next Layer Protocols.
- 次の層のプロトコル: IPv4「プロトコル」かIPv6「次のヘッダー」分野から、得ます。 OPAQUE、これはいずれ、またはIPv6だけの個々のプロトコル番号です。 Next Layerプロトコルはどんな出席しているIP拡張ヘッダーにも続くことなら何でもです。 そこでNext Layerプロトコルの場所を見つけながら簡素化する、SHOULD、どのIPv6拡張ヘッダーをスキップしたらよいかを構成するためのメカニズムになってください。 SHOULDをスキップするプロトコルが以下のプロトコルを含んでいるデフォルト設定: 0 (ホップごとのオプション)、43 (ルート設定Header)、44(断片化Header)、および60(目的地Options)。 以下に注意してください。 デフォルトリストは51(AH)か50(超能力)を含んでいません。 セレクタルックアップ観点から、IPsecはNext LayerプロトコルとしてAHと超能力を扱います。
Several additional selectors depend on the Next Layer Protocol
value:
数個の追加セレクタをNext Layerプロトコル価値に依存します:
* If the Next Layer Protocol uses two ports (as do TCP, UDP,
SCTP, and others), then there are selectors for Local and
Remote Ports. Each of these selectors has a list of ranges
of values. Note that the Local and Remote ports may not be
available in the case of receipt of a fragmented packet or if
the port fields have been protected by IPsec (encrypted);
thus, a value of OPAQUE also MUST be supported. Note: In a
non-initial fragment, port values will not be available. If
a port selector specifies a value other than ANY or OPAQUE,
it cannot match packets that are non-initial fragments. If
the SA requires a port value other than ANY or OPAQUE, an
arriving fragment without ports MUST be discarded. (See
Section 7, "Handling Fragments".)
* Next Layerプロトコルが2つのポート(TCP、UDP、SCTP、および他のもののような)を使用するなら、LocalとRemote Portsのためのセレクタがあります。 それぞれのこれらのセレクタには、値の範囲のリストがあります。 断片化しているパケットの領収書に関するケースかそれともポート分野がIPsecによって保護されたかどうかでLocalとRemoteポートが利用可能でないかもしれないことに(暗号化された)注意してください。 したがって、OPAQUEの値もサポートしなければなりません。 以下に注意してください。 非初期の断片では、ポート値は利用可能にならないでしょう。 ポートセレクタがいずれかかOPAQUE以外の値を指定するなら、それは非初期の断片であるパケットに合うことができません。 SAがいずれかかOPAQUE以外のポート値を必要とするなら、ポートのない受信フラグメントを捨てなければなりません。 (「断片を扱っ」て、セクション7を見てください。)
* If the Next Layer Protocol is a Mobility Header, then there
is a selector for IPv6 Mobility Header message type (MH type)
[Mobip]. This is an 8-bit value that identifies a particular
mobility message. Note that the MH type may not be available
* Next LayerプロトコルがMobility Headerであるなら、IPv6 Mobility Headerメッセージタイプのためのセレクタがあります(MHはタイプします)[Mobip]。 これは特定の移動性メッセージを特定する8ビット値です。 MHタイプが手があかないかもしれないことに注意してください。
Kent & Seo Standards Track [Page 27] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[27ページ]。
in the case of receipt of a fragmented packet. (See Section
7, "Handling Fragments".) For IKE, the IPv6 Mobility Header
message type (MH type) is placed in the most significant
eight bits of the 16-bit local "port" selector.
断片化しているパケットの領収書の場合で。 (「断片を扱っ」て、セクション7を見てください。) IKEに関しては、IPv6 Mobility Headerメッセージタイプ(MHはタイプする)は16ビットの地方の「ポート」セレクタの最も重要な8ビットに置かれます。
* If the Next Layer Protocol value is ICMP, then there is a
16-bit selector for the ICMP message type and code. The
message type is a single 8-bit value, which defines the type
of an ICMP message, or ANY. The ICMP code is a single 8-bit
value that defines a specific subtype for an ICMP message.
For IKE, the message type is placed in the most significant 8
bits of the 16-bit selector and the code is placed in the
least significant 8 bits. This 16-bit selector can contain a
single type and a range of codes, a single type and ANY code,
and ANY type and ANY code. Given a policy entry with a range
of Types (T-start to T-end) and a range of Codes (C-start to
C-end), and an ICMP packet with Type t and Code c, an
implementation MUST test for a match using
* Next Layerプロトコル価値がICMPであるなら、ICMPメッセージタイプとコードのための16ビットのセレクタがあります。 メッセージタイプは、ただ一つの8ビット値かいずれでもあります。(それは、ICMPメッセージのタイプを定義します)。 ICMPコードはICMPメッセージのために特定の「副-タイプ」を定義するただ一つの8ビット値です。 IKEに関しては、メッセージタイプは16ビットのセレクタの最も重要な8ビットに置かれます、そして、コードは全く重要な8ビット置かれます。 この16ビットのセレクタは単独のタイプ、さまざまなコード、単独のタイプ、どんなコード、どんなタイプ、およびどんなコードも含むことができます。 さまざまなTypes(T-終わりまでのT-始め)とさまざまなCodes(C-終わりまでのC-始め)との方針エントリー、およびType tとCode cがあるICMPパケットを考えて、実装はマッチ使用がないかどうかテストされなければなりません。
(T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
C-end
(T始め*256)+(T終わり*256)C(t*256)+c+ C-スタート<=<=終わり
Note that the ICMP message type and code may not be available
in the case of receipt of a fragmented packet. (See Section
7, "Handling Fragments".)
ICMPメッセージタイプとコードが断片化しているパケットの領収書の場合で手があかないかもしれないことに注意してください。 (「断片を扱っ」て、セクション7を見てください。)
- Name: This is not a selector like the others above. It is not
acquired from a packet. A name may be used as a symbolic
identifier for an IPsec Local or Remote address. Named SPD
entries are used in two ways:
- 以下を命名してください。 これは上の他のもののようにセレクタではありません。 それはパケットから取得されません。 名前はIPsec LocalかRemoteアドレスにシンボリックな識別子として使用されるかもしれません。 命名されたSPDエントリーは2つの方法で使用されます:
1. A named SPD entry is used by a responder (not an initiator)
in support of access control when an IP address would not be
appropriate for the Remote IP address selector, e.g., for
"road warriors". The name used to match this field is
communicated during the IKE negotiation in the ID payload.
In this context, the initiator's Source IP address (inner IP
header in tunnel mode) is bound to the Remote IP address in
the SAD entry created by the IKE negotiation. This address
overrides the Remote IP address value in the SPD, when the
SPD entry is selected in this fashion. All IPsec
implementations MUST support this use of names.
1. Remote IPアドレスセレクタには、IPアドレスが適切でないだろうというときに、命名されたSPDエントリーはアクセスコントロールを支持して応答者(創始者でない)によって使用されます、例えば、「道行く戦士」のために。 この分野を合わせるのに使用される名前はIDペイロードにおけるIKE交渉の間、伝えられます。 このような関係においては、創始者のSource IPアドレス(トンネルモードによる内側のIPヘッダー)はIKE交渉で作成されたSADエントリーにおけるRemote IPアドレスに縛られます。 SPDエントリーがこんなやり方で選択されるとき、このアドレスはSPDでRemote IPアドレス値をくつがえします。 すべてのIPsec実装が名前のこの使用をサポートしなければなりません。
2. A named SPD entry may be used by an initiator to identify a
user for whom an IPsec SA will be created (or for whom
traffic may be bypassed). The initiator's IP source address
(from inner IP header in tunnel mode) is used to replace the
following if and when they are created:
2. 命名されたSPDエントリーは、IPsec SAが作成されるユーザを特定するのに創始者によって使用されるかもしれません(または、トラフィックが迂回するかもしれない)。 それらが作成されるなら、創始者のIPソースアドレス(トンネルモードによる内側のIPヘッダーからの)は以下を取り替えるのに使用されます:
Kent & Seo Standards Track [Page 28] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[28ページ]。
- local address in the SPD cache entry
- local address in the outbound SAD entry
- remote address in the inbound SAD entry
- SPDキャッシュエントリーにおけるローカルアドレス--外国行きのSADエントリーにおけるローカルアドレス--本国行きのSADエントリーにおけるリモートアドレス
Support for this use is optional for multi-user, native host
implementations and not applicable to other implementations.
Note that this name is used only locally; it is not
communicated by the key management protocol. Also, name
forms other than those used for case 1 above (responder) are
applicable in the initiator context (see below).
この使用のサポートは、マルチユーザ、ネイティブのホスト導入に任意であって、他の実装に適切ではありません。 この名前が局所的にだけ使用されることに注意してください。 それはかぎ管理プロトコルによって伝えられません。 また、(応答者)の上のケース1に使用されるもの以外の名前フォームも創始者文脈で適切です(以下を見てください)。
An SPD entry can contain both a name (or a list of names) and
also values for the Local or Remote IP address.
SPDエントリーは名前(または、名簿)とLocalのための値かもRemote IPアドレスの両方を含むことができます。
For case 1, responder, the identifiers employed in named SPD
entries are one of the following four types:
ケース1、応答者にとって、命名されたSPDエントリーで使われた識別子は以下の4つのタイプのひとりです:
a. a fully qualified user name string (email), e.g.,
mozart@foo.example.com
(this corresponds to ID_RFC822_ADDR in IKEv2)
a. 完全に適切なユーザ名前ストリング(メール)、例えば、 mozart@foo.example.com (これはIKEv2で_ID RFC822_ADDRに対応しています)
b. a fully qualified DNS name, e.g.,
foo.example.com
(this corresponds to ID_FQDN in IKEv2)
b. 完全に適切なDNS名、例えば、foo.example.com(これはIKEv2でID_FQDNに対応しています)
c. X.500 distinguished name, e.g., [WaKiHo97],
CN = Stephen T. Kent, O = BBN Technologies,
SP = MA, C = US
(this corresponds to ID_DER_ASN1_DN in IKEv2, after
decoding)
c。 X.500分類名、[WaKiHo97]、例えばスティーブン・T.CN=ケントOはBBN Technologies、SP=MA(米国)とC=等しいです。(これは解読した後に、IKEv2でID_DER_ASN1_DNに対応します)
d. a byte string
(this corresponds to Key_ID in IKEv2)
d. バイトストリング(これはIKEv2でKey_IDに対応しています)
For case 2, initiator, the identifiers employed in named SPD
entries are of type byte string. They are likely to be Unix
UIDs, Windows security IDs, or something similar, but could
also be a user name or account name. In all cases, this
identifier is only of local concern and is not transmitted.
ケース2、創始者にとって、命名されたSPDエントリーで使われた識別子はタイプバイトストリングでできています。 また、それらは、Unix UIDs、WindowsセキュリティID、または何かであること同様のものがありそうですが、ユーザ名かアカウント名であるかもしれません。 すべての場合では、この識別子は、地方の関心しかなくて、また伝えられません。
The IPsec implementation context determines how selectors are used. For example, a native host implementation typically makes use of a socket interface. When a new connection is established, the SPD can be consulted and an SA bound to the socket. Thus, traffic sent via that socket need not result in additional lookups to the SPD (SPD-O and SPD-S) cache. In contrast, a BITS, BITW, or security gateway implementation needs to look at each packet and perform an SPD-O/SPD-S cache lookup based on the selectors.
IPsec実装文脈は、セレクタがどのように使用されているかを決定します。 例えば、ネイティブのホスト導入はソケットインタフェースを通常利用します。 新しい接続が確立されるとき、SPDに相談できました、そして、SAはソケットに付きました。 したがって、そのソケットを通して送られたトラフィックはSPD(SPD-OとSPD-S)キャッシュへの追加ルックアップをもたらす必要はありません。 対照的に、BITS、BITW、または各パケットを見て、SPD-O/SPD-Sキャッシュルックアップを実行するセキュリティゲートウェイ実装の必要性がセレクタを基礎づけました。
Kent & Seo Standards Track [Page 29] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[29ページ]。
4.4.1.2. Structure of an SPD Entry
4.4.1.2. SPDエントリーの構造
This section contains a prose description of an SPD entry. Also, Appendix C provides an example of an ASN.1 definition of an SPD entry.
このセクションはSPDエントリーの散文記述を含みます。 また、Appendix CはSPDエントリーのASN.1定義に関する例を提供します。
This text describes the SPD in a fashion that is intended to map directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. Unfortunately, the semantics of the version of IKEv2 published concurrently with this document [Kau05] do not align precisely with those defined for the SPD. Specifically, IKEv2 does not enable negotiation of a single SA that binds multiple pairs of local and remote addresses and ports to a single SA. Instead, when multiple local and remote addresses and ports are negotiated for an SA, IKEv2 treats these not as pairs, but as (unordered) sets of local and remote values that can be arbitrarily paired. Until IKE provides a facility that conveys the semantics that are expressed in the SPD via selector sets (as described below), users MUST NOT include multiple selector sets in a single SPD entry unless the access control intent aligns with the IKE "mix and match" semantics. An implementation MAY warn users, to alert them to this problem if users create SPD entries with multiple selector sets, the syntax of which indicates possible conflicts with current IKE semantics.
本稿はIKEを通してSPDエントリーで必要である方針を交渉できるのを保証するために直接IKEにペイロードを写像することを意図するファッションでSPDについて説明します。 残念ながら同時に[Kau05]がまさにSPDのために定義されるそれらに並べないこのドキュメントで発行されたIKEv2のバージョンの意味論。 明確に、IKEv2は複数の組の地方の、そして、リモートなアドレスとポートを独身のSAに縛る独身のSAの交渉を可能にしません。 複数の地方の、そして、リモートなアドレスとポートがSAのために交渉されるとき、代わりに、IKEv2は組として扱うのではなく、任意に対にすることができる(順不同の)のセットの地方の、そして、リモートな値としてこれらを扱います。 セレクタセット(以下で説明されるように)を通してSPDで言い表されて、アクセス制御意図がIKE「ミックスとマッチ」意味論に並ばない場合、IKEが意味論を伝える施設を提供するまで、ユーザは単一のSPDエントリーにおける複数のセレクタセットを入れてはいけません。 実装はユーザに警告するかもしれません、ユーザが倍数でSPDエントリーを作成するならセレクタがセットすることにおけるこの問題への注意深い彼らに。その構文は現在のIKE意味論との可能な闘争を示します。
The management GUI can offer the user other forms of data entry and display, e.g., the option of using address prefixes as well as ranges, and symbolic names for protocols, ports, etc. (Do not confuse the use of symbolic names in a management interface with the SPD selector "Name".) Note that Remote/Local apply only to IP addresses and ports, not to ICMP message type/code or Mobility Header type. Also, if the reserved, symbolic selector value OPAQUE or ANY is employed for a given selector type, only that value may appear in the list for that selector, and it must appear only once in the list for that selector. Note that ANY and OPAQUE are local syntax conventions -- IKEv2 negotiates these values via the ranges indicated below:
管理GUIは他の形式のデータエントリーとディスプレイをユーザに提供できます、例えば、範囲と同様にアドレス接頭語を使用して、プロトコル、ポートなどに英字名を使用するオプション (SPDセレクタ「名前」との管理インタフェースでの英字名の使用を混乱させないでください。) Remote/ローカルがICMPメッセージタイプ/コードではなく、IPアドレスとポートだけに適用するか、またはMobility Headerがタイプすることに注意してください。 また、予約されて、シンボリックなセレクタ値のOPAQUEかいずれか与えられたセレクタタイプに使われるなら、その値だけがそのセレクタのためのリストに現れるかもしれません、そして、それはそのセレクタのためのリストに一度だけ現れなければなりません。 いずれとOPAQUEが地方の構文コンベンションであることに注意してください--IKEv2は以下で示された範囲を通ってこれらの値を交渉します:
ANY: start = 0 end = <max>
OPAQUE: start = <max> end = 0
少しも: =0終わり=の<最大>OPAQUEを始動してください: =<最大>終わり=0を始めてください。
An SPD is an ordered list of entries each of which contains the following fields.
SPDはそれのそれぞれが以下の分野を含むエントリーの規則正しいリストです。
o Name -- a list of IDs. This quasi-selector is optional.
The forms that MUST be supported are described above in
Section 4.4.1.1 under "Name".
o 名前--IDのリスト。 この準セレクタは任意です。 サポートしなければならないフォームは上で.1下が「命名する」セクション4.4.1で説明されます。
Kent & Seo Standards Track [Page 30] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[30ページ]。
o PFP flags -- one per traffic selector. A given flag, e.g.,
for Next Layer Protocol, applies to the relevant selector
across all "selector sets" (see below) contained in an SPD
entry. When creating an SA, each flag specifies for the
corresponding traffic selector whether to instantiate the
selector from the corresponding field in the packet that
triggered the creation of the SA or from the value(s) in
the corresponding SPD entry (see Section 4.4.1, "How to
Derive the Values for an SAD Entry"). Whether a single
flag is used for, e.g., source port, ICMP type/code, and
MH type, or a separate flag is used for each, is a local
matter. There are PFP flags for:
- Local Address
- Remote Address
- Next Layer Protocol
- Local Port, or ICMP message type/code or Mobility
Header type (depending on the next layer protocol)
- Remote Port, or ICMP message type/code or Mobility
Header type (depending on the next layer protocol)
o PFPは弛みます--トラフィックセレクタあたり1つ。 例えば、Next Layerプロトコルのために、与えられた旗はSPDエントリーに保管されていたすべての「セレクタセット」(以下を見る)の向こう側に関連セレクタに申し込まれます。 SAを作成するとき、各旗は、対応するSPDエントリーにSAの作成の引き金となったパケットの対応する分野か値からセレクタを例示するかどうか対応するトラフィックセレクタに指定します(セクション4.4.1、「どう悲しいエントリーに値を引き出すこと」を見てください)。 ただ一つの旗が使用されていて、例えば、ソースポート、ICMPタイプ/コード、およびMHがタイプするか、または別々の旗がそれぞれに使用されるということであるか否かに関係なく、地域にかかわる事柄はことですか? PFP旗が以下のためにあります。 - 地方のAddress--リモートAddress--次のLayerプロトコル--地方のPort、ICMPメッセージタイプ/コードまたはMobility Headerタイプ(次の層のプロトコルによる)--リモートPort、ICMPメッセージタイプ/コードまたはMobility Headerタイプ(次の層のプロトコルによります)
o One to N selector sets that correspond to the "condition"
for applying a particular IPsec action. Each selector set
contains:
- Local Address
- Remote Address
- Next Layer Protocol
- Local Port, or ICMP message type/code or Mobility
Header type (depending on the next layer protocol)
- Remote Port, or ICMP message type/code or Mobility
Header type (depending on the next layer protocol)
o 特定のIPsec動作を適用するための「状態」に対応する1〜Nセレクタセット。 それぞれのセレクタセットは以下を含んでいます。 - 地方のAddress--リモートAddress--次のLayerプロトコル--地方のPort、ICMPメッセージタイプ/コードまたはMobility Headerタイプ(次の層のプロトコルによる)--リモートPort、ICMPメッセージタイプ/コードまたはMobility Headerタイプ(次の層のプロトコルによります)
Note: The "next protocol" selector is an individual value
(unlike the local and remote IP addresses) in a selector
set entry. This is consistent with how IKEv2 negotiates
the Traffic Selector (TS) values for an SA. It also makes
sense because one may need to associate different port
fields with different protocols. It is possible to
associate multiple protocols (and ports) with a single SA
by specifying multiple selector sets for that SA.
以下に注意してください。 「次のプロトコル」セレクタはセレクタセット記述項で個人価値(地方の、そして、リモートなIPアドレスと異なった)です。 これはIKEv2がSAのためにどうTraffic Selector(TS)値を交渉するかと一致しています。 また、異なったポート野原を異なったプロトコルに関連づける必要があるかもしれないので、それは理解できます。 複数のセレクタセットをそのSAに指定することによって複数のプロトコル(そして、ポート)を独身のSAに関連づけるのは可能です。
o Processing info -- which action is required -- PROTECT,
BYPASS, or DISCARD. There is just one action that goes
with all the selector sets, not a separate action for each
set. If the required processing is PROTECT, the entry
contains the following information.
- IPsec mode -- tunnel or transport
o 処理インフォメーション(それの動作はある)が必要です--PROTECT、BYPASS、またはDISCARD。 各セットのために別行動ではなく、すべてのセレクタセットを伴うちょうど1つの動作があります。 必要な処理がPROTECTであるなら、エントリーは以下の情報を含んでいます。 - IPsecモード--トンネルか輸送
Kent & Seo Standards Track [Page 31] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[31ページ]。
- (if tunnel mode) local tunnel address -- For a
non-mobile host, if there is just one interface, this
is straightforward; if there are multiple
interfaces, this must be statically configured. For a
mobile host, the specification of the local address
is handled externally to IPsec.
- (if tunnel mode) remote tunnel address -- There is no
standard way to determine this. See 4.5.3, "Locating
a Security Gateway".
- Extended Sequence Number -- Is this SA using extended
sequence numbers?
- stateful fragment checking -- Is this SA using
stateful fragment checking? (See Section 7 for more
details.)
- Bypass DF bit (T/F) -- applicable to tunnel mode SAs
- Bypass DSCP (T/F) or map to unprotected DSCP values
(array) if needed to restrict bypass of DSCP values --
applicable to tunnel mode SAs
- IPsec protocol -- AH or ESP
- algorithms -- which ones to use for AH, which ones to
use for ESP, which ones to use for combined mode,
ordered by decreasing priority
- (トンネルモードであるなら) 非モバイルホストのためのローカルのトンネルアドレス、ちょうど1つのインタフェースがあれば、これは簡単です。 複数のインタフェースがあれば、静的にこれを構成しなければなりません。 モバイルホストに関しては、ローカルアドレスの仕様は外部的にIPsecに扱われます。 - (トンネルモードであるなら) リモートトンネルアドレス--これを決定するどんな標準の方法もありません。 「セキュリティゲートウェイの場所を見つけ」て、4.5に.3を見てください。 - 拡張Sequence Number--このSAは拡張配列番号を使用していますか? - stateful断片の照合--stateful断片を使用するこのSAがチェックしていますか? (その他の詳細に関してセクション7を見てください。) - 優先権を減少させることによって結合したモードの使用に注文された超能力にトンネルモードSAsに適切なDSCP値--IPsecプロトコル--AHか超能力--アルゴリズム--AHの使用へのどの、どれを使用したらよいかに関する迂回を制限するのが必要であるなら、迂回DFビット(T/F)(トンネルモードSAsに適切です)は、DSCP(T/F)を迂回させるか、または値(配列)を保護のないDSCPに写像します。
It is a local matter as to what information is kept with regard to handling extant SAs when the SPD is changed.
どんな情報が取り扱いの実在のSAsに関して保たれるかに関して、いつSPDを変えるかは、地域にかかわる事柄です。
4.4.1.3. More Regarding Fields Associated with Next Layer Protocols
4.4.1.3. 次の層のプロトコルに関連している分野に関する以上
Additional selectors are often associated with fields in the Next Layer Protocol header. A particular Next Layer Protocol can have zero, one, or two selectors. There may be situations where there aren't both local and remote selectors for the fields that are dependent on the Next Layer Protocol. The IPv6 Mobility Header has only a Mobility Header message type. AH and ESP have no further selector fields. A system may be willing to send an ICMP message type and code that it does not want to receive. In the descriptions below, "port" is used to mean a field that is dependent on the Next Layer Protocol.
追加セレクタはしばしばNext Layerプロトコルヘッダーの分野に関連しています。 特定のNext Layerプロトコルはゼロ、1、または2個のセレクタを持つことができます。 状況が地方のものとNext Layerプロトコルに依存する分野への同様にリモートなセレクタがないところにあるかもしれません。 IPv6 Mobility Headerには、Mobility Headerメッセージタイプしかありません。 AHと超能力には、セレクタ分野がこれ以上ありません。 システムは、それが受け取りたがっていないICMPメッセージタイプとコードを送っても構わないと思っているかもしれません。 以下での記述では、「ポート」は、Next Layerプロトコルに依存する分野を意味するのに使用されます。
A. If a Next Layer Protocol has no "port" selectors, then
the Local and Remote "port" selectors are set to OPAQUE in
the relevant SPD entry, e.g.,
A. Next Layerプロトコルに「ポート」セレクタが全くないなら、LocalとRemote「ポート」セレクタは例えば関連SPDエントリーにOPAQUEに設定されます。
Local's
next layer protocol = AH
"port" selector = OPAQUE
ローカルの次の層プロトコル=AH「ポート」セレクタはOPAQUEと等しいです。
Kent & Seo Standards Track [Page 32] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[32ページ]。
Remote's
next layer protocol = AH
"port" selector = OPAQUE
リモートであるのは、次の層プロトコル=AH「ポート」セレクタ=OPAQUEです。
B. Even if a Next Layer Protocol has only one selector, e.g.,
Mobility Header type, then the Local and Remote "port"
selectors are used to indicate whether a system is
willing to send and/or receive traffic with the specified
"port" values. For example, if Mobility Headers of a
specified type are allowed to be sent and received via an
SA, then the relevant SPD entry would be set as follows:
B. Next Layerプロトコルに1個のセレクタしかなくても、例えば、Mobility Headerはタイプして、次に、LocalとRemote「ポート」セレクタは、システムが、指定された「ポート」値でトラフィックを送る、そして/または、受けても構わないと思っているかどうかを示すのに使用されます。 例えば、SAを通して送って、指定されたタイプのMobility Headersが受け取ることができるなら、関連SPDエントリーは以下の通り設定されるでしょう:
Local's
next layer protocol = Mobility Header
"port" selector = Mobility Header message type
ローカルの次の層プロトコル=移動性Header「ポート」セレクタは移動性Headerメッセージタイプと等しいです。
Remote's
next layer protocol = Mobility Header
"port" selector = Mobility Header message type
リモートであるのは、移動性Headerメッセージ次の層プロトコル=移動性Header「ポート」セレクタ=タイプです。
If Mobility Headers of a specified type are allowed to be
sent but NOT received via an SA, then the relevant SPD
entry would be set as follows:
指定されたタイプのMobility Headersが送られるのが許容されていますが、SAを通して受け取られないなら、関連SPDエントリーは以下の通り設定されるでしょう:
Local's
next layer protocol = Mobility Header
"port" selector = Mobility Header message type
ローカルの次の層プロトコル=移動性Header「ポート」セレクタは移動性Headerメッセージタイプと等しいです。
Remote's
next layer protocol = Mobility Header
"port" selector = OPAQUE
リモートであるのは、次の層プロトコル=移動性Header「ポート」セレクタ=OPAQUEです。
If Mobility Headers of a specified type are allowed to be
received but NOT sent via an SA, then the relevant SPD
entry would be set as follows:
指定されたタイプのMobility Headersが受け取られるのが許容されていますが、SAを通して送られないなら、関連SPDエントリーは以下の通り設定されるでしょう:
Local's
next layer protocol = Mobility Header
"port" selector = OPAQUE
ローカルの次の層プロトコル=移動性Header「ポート」セレクタはOPAQUEと等しいです。
Remote's
next layer protocol = Mobility Header
"port" selector = Mobility Header message type
リモートであるのは、移動性Headerメッセージ次の層プロトコル=移動性Header「ポート」セレクタ=タイプです。
C. If a system is willing to send traffic with a particular
"port" value but NOT receive traffic with that kind of
port value, the system's traffic selectors are set as
follows in the relevant SPD entry:
C. システムが、特定の「ポート」値と共にトラフィックを送りますが、その種類のポート価値でトラフィックを受けないでも構わないと思っているなら、関連SPDエントリーは以下の通りシステムのトラフィックセレクタにはめ込まれます:
Kent & Seo Standards Track [Page 33] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[33ページ]。
Local's
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>
ローカル次の層プロトコル=ICMP「ポート」セレクタ=の<の特定のICMPタイプとコードの>。
Remote's
next layer protocol = ICMP
"port" selector = OPAQUE
リモートであるのは、次の層プロトコル=ICMP「ポート」セレクタ=OPAQUEです。
D. To indicate that a system is willing to receive traffic
with a particular "port" value but NOT send that kind of
traffic, the system's traffic selectors are set as follows
in the relevant SPD entry:
D. システムが、特定の「ポート」値でトラフィックを受けますが、その種類のトラフィックを送らないでも構わないと思っているのを示すために、関連SPDエントリーは以下の通りシステムのトラフィックセレクタにはめ込まれます:
Local's
next layer protocol = ICMP
"port" selector = OPAQUE
ローカルの次の層プロトコル=ICMP「ポート」セレクタはOPAQUEと等しいです。
Remote's
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>
リモートであるのは、<の特定のICMPタイプとコード次の層プロトコル=ICMP「ポート」セレクタ=>です。
For example, if a security gateway is willing to allow
systems behind it to send ICMP traceroutes, but is not
willing to let outside systems run ICMP traceroutes to
systems behind it, then the security gateway's traffic
selectors are set as follows in the relevant SPD entry:
例えば、セキュリティゲートウェイがそれの後ろのシステムがトレースルートをICMPに送るのを許容することを望んでいますが、外のシステムにそれの後ろのシステムにICMPトレースルートを実行させることを望んでいないなら、関連SPDエントリーは以下の通りセキュリティゲートウェイのトラフィックセレクタにはめ込まれます:
Local's
next layer protocol = 1 (ICMPv4)
"port" selector = 30 (traceroute)
1個(ICMPv4)の「ポート」ローカルの次の層のプロトコル=セレクタ=30(トレースルート)
Remote's
next layer protocol = 1 (ICMPv4)
"port" selector = OPAQUE
リモートであるのは、1個(ICMPv4)の「ポート」次の層のプロトコル=セレクタ=OPAQUEです。
4.4.2. Security Association Database (SAD)
4.4.2. セキュリティ協会データベース(悲しい)です。
In each IPsec implementation, there is a nominal Security Association Database (SAD), in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache. For inbound processing, for unicast SAs, the SPI is used either alone to look up an SA or in conjunction with the IPsec protocol type. If an IPsec implementation supports multicast, the SPI plus destination address, or SPI plus destination and source addresses are used to look up the SA. (See Section 4.1 for details on the algorithm that MUST be used for mapping inbound IPsec datagrams to SAs.) The following parameters are associated with each entry in
それぞれのIPsec実装には、名目上のSecurity Association Database(SAD)があります。(そこでは、各エントリーが1SAに関連しているパラメタを定義します)。 各SAはSADにエントリーを持っています。 外国行きの処理において、それぞれのSADエントリーはSPDキャッシュのSPD-S部分にエントリーで示されます。 本国行きの処理、ユニキャストSAsにおいて、SPIは、SAの上かIPsecプロトコルタイプに関連して見るのに単独で使用されます。 IPsec実装がマルチキャスト、SPI、および送付先アドレスをサポートするか、またはSPI、目的地、およびソースアドレスがSAを見上げるのに使用されるなら。 (本国行きのIPsecデータグラムをSAsに写像するのに使用しなければならないアルゴリズムに関する詳細に関してセクション4.1を見てください。) 中に各エントリーがある状態で、以下のパラメタは関連しています。
Kent & Seo Standards Track [Page 34] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[34ページ]。
the SAD. They should all be present except where otherwise noted, e.g., AH Authentication algorithm. This description does not purport to be a MIB, only a specification of the minimal data items required to support an SA in an IPsec implementation.
悲しさ。 それらは別の方法で注意されるのを除いたプレゼント、例えば、すべて、AH Authenticationアルゴリズムであるべきです。 この記述は、MIB(IPsec実装でSAをサポートするのに必要である最小量のデータ項目の仕様だけ)であることを意味しません。
For each of the selectors defined in Section 4.4.1.1, the entry for an inbound SA in the SAD MUST be initially populated with the value or values negotiated at the time the SA was created. (See the paragraph in Section 4.4.1 under "Handling Changes to the SPD while the System is Running" for guidance on the effect of SPD changes on extant SAs.) For a receiver, these values are used to check that the header fields of an inbound packet (after IPsec processing) match the selector values negotiated for the SA. Thus, the SAD acts as a cache for checking the selectors of inbound traffic arriving on SAs. For the receiver, this is part of verifying that a packet arriving on an SA is consistent with the policy for the SA. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1, "Selectors". Note also that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD. Since this document does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted. Also, if a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry.
値か値で居住されて、初めはSAD MUSTの本国行きのSAがそうので、SAが作成されたとき交渉されて、それぞれのセレクタがセクション4.4.1で.1、エントリーを定義したので。 (実在のSAsへのSPD変化の効果で指導に関して「SystemがRunningである間のSPDへの取り扱いChanges」でのセクション4.4.1におけるパラグラフを見てください。) 受信機に関しては、これらの値は、本国行きのパケット(IPsec処理の後の)のヘッダーフィールドがSAのために交渉されたセレクタ値に合っているのをチェックするのに使用されます。 したがって、SADはSAsの上のインバウンドトラフィック到着のセレクタをチェックするためのキャッシュとして機能します。 受信機に関しては、これはSAにおいて、SAで到着するパケットが方針と一致していることを確かめる一部です。 (規則に関してICMPメッセージに関してセクション6を見てください。) これらの分野は、セクション4.4.1で.1、「セレクタ」について説明するので、特定の値、範囲、いずれ、またはOPAQUEのフォームを持つことができます。 また、SADがSPDに対応するエントリーを持っていないSAsのためのエントリーを持つことができる2、3の状況があることに注意してください。 このドキュメントが、SPDを変えるとき、選択的にSADをきれいにするのを強制しないので、それらを作成したSPDエントリーを変えるか、または削除するとき、SADエントリーは残ることができます。 また、手動で合わせられたSAが作成されるなら、どんなSPDエントリーにも対応しないこのSAのためのSADエントリーがあるかもしれません。
Note: The SAD can support multicast SAs, if manually configured. An outbound multicast SA has the same structure as a unicast SA. The source address is that of the sender, and the destination address is the multicast group address. An inbound, multicast SA must be configured with the source addresses of each peer authorized to transmit to the multicast SA in question. The SPI value for a multicast SA is provided by a multicast group controller, not by the receiver, as for a unicast SA. Because an SAD entry may be required to accommodate multiple, individual IP source addresses that were part of an SPD entry (for unicast SAs), the required facility for inbound, multicast SAs is a feature already present in an IPsec implementation. However, because the SPD has no provisions for accommodating multicast entries, this document does not specify an automated way to create an SAD entry for a multicast, inbound SA. Only manually configured SAD entries can be created to accommodate inbound, multicast traffic.
以下に注意してください。 手動で構成されるなら、SADは、マルチキャストがSAsであるとサポートすることができます。 外国行きのマルチキャストSAは同じくらいにユニキャストとしてSAを構造化させます。 ソースアドレスは送付者のものです、そして、送付先アドレスはマルチキャストグループアドレスです。 本国行きです、問題のマルチキャストSAに伝わる認可されるそれぞれの同輩のソースアドレスでマルチキャストSAを構成しなければなりません。 マルチキャストSAのためのSPI値は受信機ではなく、マルチキャストグループコントローラによって提供されます、ユニキャストSAのように。 SADエントリーが本国行きで倍数、IPがSPDエントリー(ユニキャストSAsのための)、必要な施設の一部であったアドレスの出典を明示する個人を収容するのに必要であるかもしれないので、マルチキャストSAsはIPsec実装における既に現在の特徴です。 しかしながら、SPDにはマルチキャストエントリーを収容するための条項が全くないので、このドキュメントはマルチキャストのためのSADエントリーを作成する自動化された方法を指定しません、本国行きのSA。 本国行きのマルチキャストトラフィックを収容するために手動で構成されたSADエントリーしか作成できません。
Implementation Guidance: This document does not specify how an SPD-S entry refers to the corresponding SAD entry, as this is an implementation-specific detail. However, some implementations (based on experience from RFC 2401) are known to have problems in this regard. In particular, simply storing the (remote tunnel header IP
実施要項: このドキュメントはSPD-Sエントリーがどう対応するSADエントリーについて言及するかを指定しません、これが実装時固有事項であるので。 しかしながら、いくつかの実装(RFC2401からの経験に基づいている)には問題がこの点であるのが知られています。 特に単に保存、(リモートトンネルヘッダーIP
Kent & Seo Standards Track [Page 35] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[35ページ]。
address, remote SPI) pair in the SPD cache is not sufficient, since the pair does not always uniquely identify a single SAD entry. For instance, two hosts behind the same NAT could choose the same SPI value. The situation also may arise if a host is assigned an IP address (e.g., via DHCP) previously used by some other host, and the SAs associated with the old host have not yet been deleted via dead peer detection mechanisms. This may lead to packets being sent over the wrong SA or, if key management ensures the pair is unique, denying the creation of otherwise valid SAs. Thus, implementors should implement links between the SPD cache and the SAD in a way that does not engender such problems.
アドレス、リモートSPI) SPDキャッシュにおける組は十分ではありません、組がいつも唯一単一のSADエントリーを特定するというわけではないので。 例えば、同じNATの後ろの2人のホストが同じSPI値を選ぶことができました。 以前にある他のホストによって使用されたIPアドレス(例えば、DHCPを通した)がホストに割り当てられるなら、状況も起こるかもしれません、そして、年取ったホストに関連しているSAsは死んでいる同輩検出メカニズムでまだ削除されていません。これは間違ったSAかかぎ管理が組が確実にユニークになるようにするときそうでなければ、有効なSAsの作成を否定する上に送られるパケットに通じるかもしれません。 したがって、作成者はそのような問題を生み出さない方法でSPDキャッシュとSADとのリンクを実装するべきです。
4.4.2.1. Data Items in the SAD
4.4.2.1. 悲しさのデータ項目
The following data items MUST be in the SAD:
以下のデータ項目がSADにあるに違いありません:
o Security Parameter Index (SPI): a 32-bit value selected by the
receiving end of an SA to uniquely identify the SA. In an SAD
entry for an outbound SA, the SPI is used to construct the
packet's AH or ESP header. In an SAD entry for an inbound SA, the
SPI is used to map traffic to the appropriate SA (see text on
unicast/multicast in Section 4.1).
o セキュリティパラメタインデックス(SPI): SAの犠牲者までに唯一SAを特定するのが選択された32ビットの値。 外国行きのSAのためのSADエントリーでは、SPIが、パケットのAHか超能力ヘッダーを組み立てるのに使用されます。 本国行きのSAのためのSADエントリーでは、SPIが、適切なSAにトラフィックを写像するのに使用されます(セクション4.1でユニキャスト/マルチキャストに関するテキストを見てください)。
o Sequence Number Counter: a 64-bit counter used to generate the
Sequence Number field in AH or ESP headers. 64-bit sequence
numbers are the default, but 32-bit sequence numbers are also
supported if negotiated.
o 一連番号カウンタ: 64ビットのカウンタは以前はよくAHか超能力ヘッダーのSequence Number分野を生成していました。 64ビットの一連番号はデフォルトですが、また、交渉されるなら、32ビットの一連番号はサポートされます。
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, or whether
rollover is permitted. The audit log entry for this event SHOULD
include the SPI value, current date/time, Local Address, Remote
Address, and the selectors from the relevant SAD entry.
o 系列カウンタオーバーフロー: 一連番号カウンタのオーバーフローが監査可能イベントを生成して、SAにおける追加パケットのトランスミッションを防ぐべきであるかどうか、またはロールオーバーが受入れられるかどうかを示す旗。 このイベントSHOULDのための監査ログエントリーは関連SADエントリーからのSPI値、現在の日付/時間、Local Address、Remote Address、およびセレクタを含んでいます。
o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
used to determine whether an inbound AH or ESP packet is a replay.
o 反再生ウィンドウ: 64ビットは、再生に対抗して、本国行きのAHか超能力パケットがそうかどうか決定するのに使用されて、少し写像します(または、同等物)。
Note: If anti-replay has been disabled by the receiver for an SA,
e.g., in the case of a manually keyed SA, then the Anti-Replay
Window is ignored for the SA in question. 64-bit sequence numbers
are the default, but this counter size accommodates 32-bit
sequence numbers as well.
以下に注意してください。 反再生が例えば、手動で合わせられたSAの場合におけるSAのために受信機によって無効にされたなら、Anti-再生Windowは問題のSAのために無視されます。 64ビットの一連番号はデフォルトですが、このカウンタサイズはまた、32ビットの一連番号を収容します。
o AH Authentication algorithm, key, etc. This is required only if
AH is supported.
o AH Authenticationアルゴリズム、キーなど AHがサポートされる場合にだけ、これが必要です。
Kent & Seo Standards Track [Page 36] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[36ページ]。
o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode
algorithm is used, these fields will not be applicable.
o 超能力Encryptionアルゴリズム、キー、モード、IVなど 結合したモードアルゴリズムが使用されていると、これらの分野は適切にならないでしょう。
o ESP integrity algorithm, keys, etc. If the integrity service is
not selected, these fields will not be applicable. If a combined
mode algorithm is used, these fields will not be applicable.
o 超能力保全アルゴリズム、キーなど 保全サービスが選択されないと、これらの分野は適切にならないでしょう。 結合したモードアルゴリズムが使用されていると、これらの分野は適切にならないでしょう。
o ESP combined mode algorithms, key(s), etc. This data is used when
a combined mode (encryption and integrity) algorithm is used with
ESP. If a combined mode algorithm is not used, these fields are
not applicable.
o 超能力の結合したモードアルゴリズム、キーなど 結合したモード(暗号化と保全)アルゴリズムが超能力と共に使用されるとき、このデータは使用されています。 結合したモードアルゴリズムが使用されていないなら、これらの分野は適切ではありません。
o Lifetime of this SA: 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
with 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 Certificate Revocation
Lists (CRLs) used in the IKE exchange for the SA. Both initiator
and responder are responsible for constraining the SA lifetime in
this fashion. Note: The details of how to handle the refreshing
of keys when SAs expire is a local matter. However, one
reasonable approach is:
o このSAの生涯: SAを新しいSA(そして、新しいSPI)に取り替えなければならないか、または終えなければならない時間間隔、およびこれらの動作のどれが起こるべきであるかしるし。 これは時間、バイト・カウント、または優先しながら期限が切れる最初の生涯がある両方の同時の使用として言い表されるかもしれません。 対応する実装は、両方のタイプの生涯をサポートしなければならなくて、両方の同時の使用をサポートしなければなりません。 時間が採用していて、IKEがSA設立のためのX.509証明書を使うなら、証明書の正当性間隔、およびSAにIKE交換に使用されるCertificate Revocation Lists(CRLs)のNextIssueDateはSA生涯を抑制しなければなりません。 創始者と応答者の両方がこんなやり方でSA生涯を抑制するのに責任があります。 以下に注意してください。 SAsが期限が切れるとき、どうキーのリフレッシュを扱うかに関する詳細は地域にかかわる事柄です。 しかしながら、1つの合理的なアプローチは以下の通りです。
(a) If byte count is used, then the implementation SHOULD count the
number of bytes to which the IPsec cryptographic 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 MUST 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.
(a) バイト・カウントが使用されているなら、実装SHOULDはIPsec暗号アルゴリズムが適用されているバイト数を数えます。 超能力に関しては、これは暗号化アルゴリズム(Null暗号化を含んでいて)です、そして、AHに関する、認証アルゴリズムです。 これはパッドバイトなどを含んでいます。 実装がSAの端のカウンタが同時性から持ち始めるのを扱うことができなければならないことに注意してください、例えば、パケット損失のため、またはSAの各端の実装が同じようにことをしないことであるので。
(b) There SHOULD be two kinds of lifetime -- a soft lifetime that
warns the implementation to initiate action such as setting up
a replacement SA, and a hard lifetime when the current SA ends
and is destroyed.
SHOULDはそこでは、生涯--現在のSAが終わるとSA、および困難な生涯を交換に決めるのなどように行動を開始するように実装に警告する2種類のa柔らかい生涯であり、(b) 破壊されます。
(c) If the entire packet does not get delivered during the SA's
lifetime, the packet SHOULD be discarded.
(c) 全体のパケットがSAの生涯、パケットSHOULDの間、提供されないなら、捨てられてください。
o IPsec protocol mode: tunnel or transport. Indicates which mode of
AH or ESP is applied to traffic on this SA.
o IPsecはモードを議定書の中で述べます: トンネルを堀るか、または輸送します。 AHか超能力のどのモードがこのSAでトラフィックに適用されるかを示します。
Kent & Seo Standards Track [Page 37] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[37ページ]。
o Stateful fragment checking flag. Indicates whether or not
stateful fragment checking applies to this SA.
o Statefulは、旗をチェックしながら、断片化します。 stateful断片の照合がこのSAに適用されるか否かに関係なく、示します。
o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both
inner and outer headers are IPv4.
o DFビット(T/F)を迂回させてください--内側の、そして、外側の両方のヘッダーがIPv4であるトンネルモードSAsに適切です。
o DSCP values -- the set of DSCP values allowed for packets carried
over this SA. If no values are specified, no DSCP-specific
filtering is applied. If one or more values are specified, these
are used to select one SA among several that match the traffic
selectors for an outbound packet. Note that these values are NOT
checked against inbound traffic arriving on the SA.
o DSCP値--DSCP値のセットはこのSAの上まで運ばれたパケットを考慮しました。 値が全く指定されないなら、どんなDSCP特有のフィルタリングも適用されていません。 1つ以上の値が指定されるなら、これらは、外国行きのパケットのためにトラフィックセレクタに合っている数個の中の1SAを選択するのに使用されます。 これらの値がSAで到着するインバウンドトラフィックに対してチェックされないことに注意してください。
o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
needed to restrict bypass of DSCP values -- applicable to tunnel
mode SAs. This feature maps DSCP values from an inner header to
values in an outer header, e.g., to address covert channel
signaling concerns.
o DSCP値の迂回を制限するのが必要であるなら、値(配列)を保護のないDSCPに写像してください--DSCP(T/F)を迂回させてください、またはトンネルモードSAsに適切です。 この特徴は、例えばひそかなチャンネルシグナリングが関心であると扱うために外側のヘッダーで内側のヘッダーから値までDSCP値を写像します。
o Path MTU: any observed path MTU and aging variables.
o 経路MTU: いずれも経路MTUと古い変数を観測しました。
o Tunnel header IP source and destination address -- both addresses
must be either IPv4 or IPv6 addresses. The version implies the
type of IP header to be used. Only used when the IPsec protocol
mode is tunnel.
o トンネルヘッダーIPソースと送付先アドレス--両方のアドレスは、IPv4かIPv6アドレスのどちらかであるに違いありません。 バージョンは、使用されるためにIPヘッダーのタイプを含意します。 IPsecプロトコルモードがトンネルであるときにだけ、使用されます。
4.4.2.2. Relationship between SPD, PFP flag, packet, and SAD
4.4.2.2. SPDと、PFP旗と、パケットと、SADとの関係
For each selector, the following tables show the relationship
between the value in the SPD, the PFP flag, the value in the
triggering packet, and the resulting value in the SAD. Note that
the administrative interface for IPsec can use various syntactic
options to make it easier for the administrator to enter rules.
For example, although a list of ranges is what IKEv2 sends, it
might be clearer and less error prone for the user to enter a
single IP address or IP address prefix.
各セレクタに関しては、以下のテーブルはSPDの値と、PFP旗と、引き金となるパケットの値と、SADの結果として起こる値との関係を示しています。 IPsecのための管理インタフェースが管理者が規則を入れるのをより簡単にするのに様々な構文のオプションを使用できることに注意してください。 例えば、範囲のリストはIKEv2が送るものですが、それはユーザがただ一つのIPアドレスかIPアドレス接頭語を入れる傾向があるより明確でより少ない誤りであるかもしれません。
Kent & Seo Standards Track [Page 38] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[38ページ]。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc addr list of ranges 0 IP addr "S" list of ranges
ANY 0 IP addr "S" ANY
list of ranges 1 IP addr "S" "S"
ANY 1 IP addr "S" "S"
結果として起こる悲しいセレクタSPDエントリーPFPパケットエントリーの引き金となることにおける値-------- ---------------- --- ------------ -------------- 0IP addr「S」が記載するどんな0IP addr「S」も少しも記載する範囲1IP addr「S」「S」どんな1IP addr「S」「S」の範囲の範囲のloc addrリスト
rem addr list of ranges 0 IP addr "D" list of ranges
ANY 0 IP addr "D" ANY
list of ranges 1 IP addr "D" "D"
ANY 1 IP addr "D" "D"
0IP addr「D」が記載するどんな0IP addr「D」も少しも記載する範囲1IP addr「D」「D」どんな1IP addr「D」「D」の範囲の範囲のレムaddrリスト
protocol list of prot's* 0 prot. "P" list of prot's*
ANY** 0 prot. "P" ANY
OPAQUE**** 0 prot. "P" OPAQUE
prot*の0protのリストについて議定書の中で述べてください。 「P」はprotの*について記載します。どんな**0prot。 「P」ANY OPAQUE****0prot。 「P」不透明なもの
list of prot's* 0 not avail. discard packet
ANY** 0 not avail. ANY
OPAQUE**** 0 not avail. OPAQUE
protの*0のリストの役に立ちません。どんな**0も役に立たないパケットを捨ててください。 ANY OPAQUE****0は役に立ちません。 不透明なもの
list of prot's* 1 prot. "P" "P"
ANY** 1 prot. "P" "P"
OPAQUE**** 1 prot. "P" ***
prot*の1protのリスト。 どんな**1もprotする「P。」「P」 「P」「P」不透明なもの****1prot。 「P」***
list of prot's* 1 not avail. discard packet
ANY** 1 not avail. discard packet
OPAQUE**** 1 not avail. ***
protの*1のリストの役に立ちません。どんな**1も役に立たないパケットを捨ててください。*1が役に立たないパケットOPAQUE***を捨ててください。 ***
Kent & Seo Standards Track [Page 39] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[39ページ]。
If the protocol is one that has two ports, then there will be
selectors for both Local and Remote ports.
プロトコルが2つのポートを持っているものであるなら、LocalとRemoteポートの両方のためのセレクタがあるでしょう。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc port list of ranges 0 src port "s" list of ranges
ANY 0 src port "s" ANY
OPAQUE 0 src port "s" OPAQUE
結果として起こる悲しいセレクタSPDエントリーPFPパケットエントリーの引き金となることにおける値-------- ---------------- --- ------------ -------------- 範囲の範囲0src港「s」のリストに関するloc左舷傾斜はあらゆる0srcポート「s」ANY OPAQUE0srcポート「s」OPAQUEです。
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
範囲0のリストの役に立ちません。どんな0も役に立たないパケットを捨ててください。 ANY OPAQUE0は役に立ちません。 不透明なもの
list of ranges 1 src port "s" "s"
ANY 1 src port "s" "s"
OPAQUE 1 src port "s" ***
範囲1src港「s」の「s」どんな1つのsrcポート「s」「s」OPAQUE1srcポート「s」***のリスト
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
範囲1のリストの役に立ちません。どんな1も役に立たないパケットを捨ててください。OPAQUE1が役に立たないパケットを捨ててください。 ***
rem port list of ranges 0 dst port "d" list of ranges
ANY 0 dst port "d" ANY
OPAQUE 0 dst port "d" OPAQUE
範囲の範囲0dst港「d」のリストに関するレム左舷傾斜はあらゆる0dstポート「d」ANY OPAQUE0dstポート「d」OPAQUEです。
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
範囲0のリストの役に立ちません。どんな0も役に立たないパケットを捨ててください。 ANY OPAQUE0は役に立ちません。 不透明なもの
list of ranges 1 dst port "d" "d"
ANY 1 dst port "d" "d"
OPAQUE 1 dst port "d" ***
範囲1dst港「d」の「d」どんな1つのdstポート「d」「d」OPAQUE1dstポート「d」***のリスト
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
範囲1のリストの役に立ちません。どんな1も役に立たないパケットを捨ててください。OPAQUE1が役に立たないパケットを捨ててください。 ***
Kent & Seo Standards Track [Page 40] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[40ページ]。
If the protocol is mobility header, then there will be a selector
for mh type.
プロトコルが移動性ヘッダーであるなら、mhタイプのためのセレクタがあるでしょう。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
mh type list of ranges 0 mh type "T" list of ranges
ANY 0 mh type "T" ANY
OPAQUE 0 mh type "T" OPAQUE
結果として起こる悲しいセレクタSPDエントリーPFPパケットエントリーの引き金となることにおける値-------- ---------------- --- ------------ -------------- 0mhタイプ「T」が記載するどんな分っている0mhタイプ「T」も不透明にする範囲どんな0mhタイプ「T」の範囲に関するmh型の並び
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
範囲0のリストの役に立ちません。どんな0も役に立たないパケットを捨ててください。 ANY OPAQUE0は役に立ちません。 不透明なもの
list of ranges 1 mh type "T" "T"
ANY 1 mh type "T" "T"
OPAQUE 1 mh type "T" ***
範囲1mhタイプ「T」「T」どんな1mhタイプ「T」「T」不透明なもの1mhタイプ「T」***のリスト
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
範囲1のリストの役に立ちません。どんな1も役に立たないパケットを捨ててください。OPAQUE1が役に立たないパケットを捨ててください。 ***
Kent & Seo Standards Track [Page 41] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[41ページ]。
If the protocol is ICMP, then there will be a 16-bit selector for
ICMP type and ICMP code. Note that the type and code are bound to
each other, i.e., the codes apply to the particular type. This
16-bit selector can contain a single type and a range of codes, a
single type and ANY code, and ANY type and ANY code.
プロトコルがICMPであるなら、ICMPタイプとICMPコードのための16ビットのセレクタがあるでしょう。 タイプとコードが互いに縛られて、すなわち、コードが特定のタイプに適用されることに注意してください。 この16ビットのセレクタは単独のタイプ、さまざまなコード、単独のタイプ、どんなコード、どんなタイプ、およびどんなコードも含むことができます。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
ICMP type a single type & 0 type "t" & single type &
and code range of codes code "c" range of codes
a single type & 0 type "t" & single type &
ANY code code "c" ANY code
ANY type & ANY 0 type "t" & ANY type &
code code "c" ANY code
OPAQUE 0 type "t" & OPAQUE
code "c"
結果として起こる悲しいセレクタSPDエントリーPFPパケットエントリーの引き金となることにおける値--------- ---------------- --- ------------ -------------- 単独のタイプと0タイプ「t」とシングルが範囲をタイプして、そしてコード化するICMPタイプはコード単独のタイプと0タイプ「t」のコード「c」範囲をコード化します、そして、単独のタイプとどんなコードコード「c」も少しもどんなタイプもコード化します、そして、どんな0も「t」をタイプします、そして、どんなタイプとコードコード「c」も少しもOPAQUE0タイプ「t」とOPAQUEコード「c」をコード化します。
a single type & 0 not avail. discard packet
range of codes
a single type & 0 not avail. discard packet
ANY code
ANY type & 0 not avail. ANY type &
ANY code ANY code
OPAQUE 0 not avail. OPAQUE
単独のタイプと0の役に立ちません。単独のタイプと0が役に立たないコードのパケット範囲を捨ててください。どんなコードも何もタイプして、0が役に立たないパケットを捨ててください。 何でもタイプしてください、そして、少しも、OPAQUE0が役に立たないあらゆるコードをコード化してください。 不透明なもの
a single type & 1 type "t" & "t" and "c"
range of codes code "c"
a single type & 1 type "t" & "t" and "c"
ANY code code "c"
ANY type & 1 type "t" & "t" and "c"
ANY code code "c"
OPAQUE 1 type "t" & ***
code "c"
単独のタイプと1つのタイプ「t」と「t」と「c」範囲のコードコード「c」どんなコードコード「c」も何でもタイプして、1つのタイプ「t」、「t」、および「c」が少しもコード化する単独のタイプ、1つのタイプ「t」、「t」、および「c」コード「c」OPAQUE1タイプ「t」と***コード「c」
a single type & 1 not avail. discard packet
range of codes
a single type & 1 not avail. discard packet
ANY code
ANY type & 1 not avail. discard packet
ANY code
OPAQUE 1 not avail. ***
単独のタイプと1は役に立ちません。単独のタイプと1が役に立たないコードのパケット範囲を捨ててください。利益ではなく、どんなコードも少しもタイプするパケットと1を捨ててください。どんなコードOPAQUE1も役に立たないパケットを捨ててください。 ***
Kent & Seo Standards Track [Page 42] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[42ページ]。
If the name selector is used:
名前セレクタが使用されているなら:
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
name list of user or N/A N/A N/A
system names
結果として起こる悲しいセレクタSPDエントリーPFPパケットエントリーの引き金となることにおける値--------- ---------------- --- ------------ -------------- ユーザかN/A N/A N/Aシステム名に関する人名簿
* "List of protocols" is the information, not the way
that the SPD or SAD or IKEv2 have to represent this
information.
** 0 (zero) is used by IKE to indicate ANY for
protocol.
*** Use of PFP=1 with an OPAQUE value is an error and
SHOULD be prohibited by an IPsec implementation.
**** The protocol field cannot be OPAQUE in IPv4. This
table entry applies only to IPv6.
* 「プロトコルのリスト」は道ではなく、SPD、SADまたはIKEv2がこの情報を表さなければならないという情報です。 ** 0 (ゼロ)は、プロトコルのためのいずれも示すのにIKEによって使用されます。 *** OPAQUE値があるPFP=1の使用は、誤りとSHOULDです。IPsec実装で、禁止されます。 **** プロトコル分野はIPv4のOPAQUEであるはずがありません。 このテーブル項目はIPv6だけに適用されます。
4.4.3. Peer Authorization Database (PAD)
4.4.3. 同輩承認データベース(パッド)
The Peer Authorization Database (PAD) provides the link between the SPD and a security association management protocol such as IKE. It embodies several critical functions:
Peer Authorization Database(PAD)はSPDとIKEなどのセキュリティ協会管理プロトコルとのリンクを提供します。 それはいくつかの批判的機能を具体化します:
o identifies the peers or groups of peers that are authorized
to communicate with this IPsec entity
o specifies the protocol and method used to authenticate each
peer
o provides the authentication data for each peer
o constrains the types and values of IDs that can be asserted
by a peer with regard to child SA creation, to ensure that the
peer does not assert identities for lookup in the SPD that it
is not authorized to represent, when child SAs are created
o peer gateway location info, e.g., IP address(es) or DNS names,
MAY be included for peers that are known to be "behind" a
security gateway
o このIPsecとコミュニケートするのが認可されて、実体oがプロトコルを指定して、各同輩oのために、oが認証データを提供する各同輩を認証するのに使用されるメソッドが同輩が同輩がそれが表すのは認可されないSPDのルックアップのためにアイデンティティについて断言しないのを保証するために子供SA作成に関して断言できるIDのタイプと値を抑制するということである同輩の同輩かグループを特定します; 子供SAsが作成されるとき、o同輩ゲートウェイ位置のインフォメーション(例えば、IPアドレス(es)かDNS名)は、“behind"がセキュリティゲートウェイであったなら知られている同輩のために含まれるかもしれません。
The PAD provides these functions for an IKE peer when the peer acts as either the initiator or the responder.
同輩が創始者か応答者を演じるとき、PADはこれらの機能をIKE同輩に提供します。
To perform these functions, the PAD contains an entry for each peer or group of peers with which the IPsec entity will communicate. An entry names an individual peer (a user, end system or security gateway) or specifies a group of peers (using ID matching rules defined below). The entry specifies the authentication protocol (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre- shared secrets) and the authentication data (e.g., the pre-shared
これらの機能を実行するために、PADはIPsec実体が交信する同輩の各同輩かグループのためのエントリーを含んでいます。 個人がじっと見るか(ユーザ、エンドシステムまたはセキュリティゲートウェイ)、またはグループを指定する入口名はじっと見ます(以下で定義されたIDの合っている規則を使用します)。 エントリーがメソッドが使用した認証プロトコル(例えば、IKEv1、IKEv2、KINK)(例えば、証明書かプレ共有秘密キー)と認証データを指定する、(例えば、あらかじめ共有にされる
Kent & Seo Standards Track [Page 43] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[43ページ]。
secret or the trust anchor relative to which the peer's certificate will be validated). For certificate-based authentication, the entry also may provide information to assist in verifying the revocation status of the peer, e.g., a pointer to a CRL repository or the name of an Online Certificate Status Protocol (OCSP) server associated with the peer or with the trust anchor associated with the peer.
秘密か信頼アンカーに比例して同輩の証明書が有効にされる) 証明書ベースの認証のために、エントリーも同輩の取消し状態について確かめる助ける情報を提供するかもしれません、例えば、同輩との関連している同輩か関連している信頼アンカーでOnline Certificate Statusプロトコル(OCSP)サーバのCRL倉庫か名前への指針。
Each entry also specifies whether the IKE ID payload will be used as a symbolic name for SPD lookup, or whether the remote IP address provided in traffic selector payloads will be used for SPD lookups when child SAs are created.
また、各エントリーは、子供SAsが作成されるとき、IKE IDペイロードがSPDルックアップに英字名として使用されるかどうか、またはトラフィックセレクタペイロードに提供されたリモートIPアドレスがSPDルックアップに使用されるかどうか指定します。
Note that the PAD information MAY be used to support creation of more than one tunnel mode SA at a time between two peers, e.g., two tunnels to protect the same addresses/hosts, but with different tunnel endpoints.
PAD情報が使用されるかもしれないことに注意して、一度に同じアドレス/ホストを保護するために例えば、2人の同輩、2つのトンネルの間で1つ以上のトンネルのモードSAの作成をサポートしますが、異なったトンネル終点でサポートしてください。
4.4.3.1. PAD Entry IDs and Matching Rules
4.4.3.1. パッドエントリーIDと合っている規則
The PAD is an ordered database, where the order is defined by an administrator (or a user in the case of a single-user end system). Usually, the same administrator will be responsible for both the PAD and SPD, since the two databases must be coordinated. The ordering requirement for the PAD arises for the same reason as for the SPD, i.e., because use of "star name" entries allows for overlaps in the set of IKE IDs that could match a specific entry.
PADは規則正しいデータベースです。(そこでは、オーダーが管理者(または、シングルユーザーエンドシステムの場合におけるユーザ)によって定義されます)。 通常、同じ管理者は、2つのデータベースを調整しなければならないので、PADとSPDの両方に責任があるでしょう。 PADのための注文要件はSPDのように同じ理由から起こります、すなわち、「星の名」エントリーの使用が特定のエントリーに合うことができたIKE IDのセットでオーバラップを考慮するので。
Six types of IDs are supported for entries in the PAD, consistent with the symbolic name types and IP addresses used to identify SPD entries. The ID for each entry acts as the index for the PAD, i.e., it is the value used to select an entry. All of these ID types can be used to match IKE ID payload types. The six types are:
6つのタイプのIDはPADのエントリーにサポートされます、タイプというシンボリックな名前と一致していて、IPアドレスは以前はよくSPDエントリーを特定していました。 各エントリーへのIDはPADのためのインデックスとして機能して、すなわち、それはエントリーを選択するのに使用される値です。 IKE IDペイロードタイプを合わせるのにこれらのIDタイプのすべてを使用できます。 6つのタイプは以下の通りです。
o DNS name (specific or partial)
o Distinguished Name (complete or sub-tree constrained)
o RFC 822 email address (complete or partially qualified)
o IPv4 address (range)
o IPv6 address (range)
o Key ID (exact match only)
o DNS名(特定の、または、部分的な)のo Distinguished Name(完全であるか下位木強制的な)o RFC822Eメールアドレス(完全であるか部分的に適切な)o IPv4アドレス(範囲)o IPv6は、(範囲)oがKey IDであると扱います。(完全な一致専用)
The first three name types can accommodate sub-tree matching as well as exact matches. A DNS name may be fully qualified and thus match exactly one name, e.g., foo.example.com. Alternatively, the name may encompass a group of peers by being partially specified, e.g., the string ".example.com" could be used to match any DNS name ending in these two domain name components.
タイプという最初の3名は完全な一致と同様に下位木マッチングを収容できます。 DNS名は、完全に適切であり、その結果、まさに1つの名前、例えばfoo.example.comに合うかもしれません。 あるいはまた、名前は部分的に指定されていることによって、同輩のグループを包含するかもしれません、例えば、これらの2つのドメイン名コンポーネントにおけるどんなDNS名前結末も合わせるのにストリング".example.com"は使用できました。
Kent & Seo Standards Track [Page 44] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[44ページ]。
Similarly, a Distinguished Name may specify a complete Distinguished Name to match exactly one entry, e.g., CN = Stephen, O = BBN Technologies, SP = MA, C = US. Alternatively, an entry may encompass a group of peers by specifying a sub-tree, e.g., an entry of the form "C = US, SP = MA" might be used to match all DNs that contain these two attributes as the top two Relative Distinguished Names (RDNs).
同様に、Distinguished Nameは、ちょうど1つのエントリー、例えば、CN=スティーブン(O=BBN Technologies、C=SP=MA(米国))を合わせるために完全なDistinguished Nameを指定するかもしれません。 あるいはまた、エントリーは下位木を指定することによって、同輩のグループを包含するかもしれなくて、例えばフォーム「米国の==C SP MA」のエントリーは2つの最高相対的な分類名(RDNs)としてこれらの2つの属性を含むすべてのDNsを合わせるのに使用されるかもしれません。
For an RFC 822 e-mail addresses, the same options exist. A complete address such as foo@example.com matches one entity, but a sub-tree name such as "@example.com" could be used to match all the entities with names ending in those two domain names to the right of the @.
RFC822に関しては、Eメールアドレスであり、同じオプションは存在しています。 @の右へのそれらの2つのドメイン名に終わる名前にすべての実体を合わせるのに「 foo@example.com などの完全なアドレスは1つの実体、しかし、」 @example.comなどの下位木名に合うこと」を使用できました。
The specific syntax used by an implementation to accommodate sub-tree matching for distinguished names, domain names or RFC 822 e-mail addresses is a local matter. But, at a minimum, sub-tree matching of the sort described above MUST be supported. (Substring matching within a DN, DNS name, or RFC 822 address MAY be supported, but is not required.)
実装によって使用される、分類名のための下位木マッチング、ドメイン名またはRFCが822のEメールアドレスに対応する特定の構文は地域にかかわる事柄です。 しかし、最小限で、上で説明された種類の下位木マッチングをサポートしなければなりません。 (DNの中で合っているサブストリング、DNS名、またはRFC822アドレスは、サポートされるかもしれませんが、必要ではありません。)
For IPv4 and IPv6 addresses, the same address range syntax used for SPD entries MUST be supported. This allows specification of an individual address (via a trivial range), an address prefix (by choosing a range that adheres to Classless Inter-Domain Routing (CIDR)-style prefixes), or an arbitrary address range.
IPv4とIPv6アドレスにおいて、SPDエントリーに使用される同じアドレス範囲構文をサポートしなければなりません。 これは個々のアドレス(些細な範囲を通る)、アドレス接頭語(スタイルが前に置くClassless Inter-ドメインルート設定(CIDR)を固く守る範囲を選ぶのによる)、または任意のアドレスの範囲の仕様を許容します。
The Key ID field is defined as an OCTET string in IKE. For this name type, only exact-match syntax MUST be supported (since there is no explicit structure for this ID type). Additional matching functions MAY be supported for this ID type.
Key ID分野はIKEでOCTETストリングと定義されます。 この名前タイプにおいて、完全な一致構文だけをサポートしなければなりません(このIDタイプのためのどんな明白な構造もないので)。 追加合っている機能はこのIDタイプのためにサポートされるかもしれません。
4.4.3.2. IKE Peer Authentication Data
4.4.3.2. IKE同輩認証データ
Once an entry is located based on an ordered search of the PAD based on ID field matching, it is necessary to verify the asserted identity, i.e., to authenticate the asserted ID. For each PAD entry, there is an indication of the type of authentication to be performed. This document requires support for two required authentication data types:
エントリーがID分野マッチングに基づくPADの命令された検索に基づいていったん見つけられていると、すなわち、断言されたIDを認証するために断言されたアイデンティティについて確かめるのが必要です。 それぞれのPADエントリーには、実行されるために、認証のタイプのしるしがあります。 このドキュメントは2つの必要な認証データ型に支持を要します:
- X.509 certificate
- pre-shared secret
- X.509証明書--プレ共有秘密キー
For authentication based on an X.509 certificate, the PAD entry contains a trust anchor via which the end entity (EE) certificate for the peer must be verifiable, either directly or via a certificate path. See RFC 3280 for the definition of a trust anchor. An entry used with certificate-based authentication MAY include additional data to facilitate certificate revocation status, e.g., a list of
X.509証明書に基づく認証のために、PADエントリーはを通した同輩への終わりの実体(EE)証明書が直接か証明書経路を通して証明可能であるに違いない信頼アンカーを含みます。 信頼アンカーの定義に関してRFC3280を見てください。 証明書ベースの認証と共に使用されるエントリーは証明書取消し状態、例えばリストを容易にする追加データを含むかもしれません。
Kent & Seo Standards Track [Page 45] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[45ページ]。
appropriate OCSP responders or CRL repositories, and associated authentication data. For authentication based on a pre-shared secret, the PAD contains the pre-shared secret to be used by IKE.
OCSP応答者かCRL倉庫と、関連認証データを当ててください。 プレ共有秘密キーに基づく認証のために、PADはIKEによって使用されるべきプレ共有秘密キーを含んでいます。
This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers each of whom may have a distinct SPD entry. Thus, implementations MUST provide a means for an administrator to require a match between an asserted IKE ID and the subject name or subject alt name in a certificate. The former is applicable to IKE IDs expressed as distinguished names; the latter is appropriate for DNS names, RFC 822 e-mail addresses, and IP addresses. Since KEY ID is intended for identifying a peer authenticated via a pre-shared secret, there is no requirement to match this ID type to a certificate field.
このドキュメントは、同輩によって断言されたIKE IDがシンタクス上その同輩のアイデンティティを認証するのに使われる終わりの実体証明書の特定の分野に関連するのを必要としません。 しかしながら、そのような要件を課すのはしばしば適切でしょう、例えば、単一のエントリーがそのそれぞれには異なったSPDエントリーがあるかもしれない1セットの同輩の代理をすると。 したがって、実装は管理者が断言されたIKE IDと対象の名前か対象のalt名とのマッチを必要とする手段を証明書に供給しなければなりません。 前者は分類名として言い表されたIKE IDに適切です。 DNS名、RFC822Eメールアドレス、およびIPアドレスに、後者は適切です。 KEY IDがプレ共有秘密キーで認証された同輩を特定するために意図するので、このIDタイプを証明書分野に合わせるという要件が全くありません。
See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE performs peer authentication using certificates or pre-shared secrets.
IKEが証明書かプレ共有秘密キーを使用することでどう同輩認証を実行するかに関する詳細に関してIKEv1[HarCar98]とIKEv2[Kau05]を見てください。
This document does not mandate support for any other authentication methods, although such methods MAY be employed.
そのようなメソッドは使われるかもしれませんが、このドキュメントはいかなる他の認証方法のサポートも強制しません。
4.4.3.3. Child SA Authorization Data
4.4.3.3. 子供SA承認データ
Once an IKE peer is authenticated, child SAs may be created. Each PAD entry contains data to constrain the set of IDs that can be asserted by an IKE peer, for matching against the SPD. Each PAD entry indicates whether the IKE ID is to be used as a symbolic name for SPD matching, or whether an IP address asserted in a traffic selector payload is to be used.
IKE同輩がいったん認証されると、子供SAsは作成されるかもしれません。 それぞれのPADエントリーはIKE同輩が断言できるIDのセットを抑制するデータを含んでいます、SPDに対して合うように。 それぞれのPADエントリーは、トラフィックセレクタペイロードで断言されたIPアドレスがIKE IDがSPDマッチングに英字名として使用されることになっているかどうか、または使用されているかどうかことであることを示します。
If the entry indicates that the IKE ID is to be used, then the PAD entry ID field defines the authorized set of IDs. If the entry indicates that child SAs traffic selectors are to be used, then an additional data element is required, in the form of IPv4 and/or IPv6 address ranges. (A peer may be authorized for both address types, so there MUST be provision for both a v4 and a v6 address range.)
エントリーが、IKE IDが使用されていることになっているのを示すなら、PADエントリーID分野は認可されたIDを定義します。 エントリーが、子供SAsトラフィックセレクタが使用されていることになっているのを示すなら、追加データ要素がIPv4の形で必要です、そして、IPv6アドレスは及びます。 (同輩が両方のアドレスタイプのために権限を与えられるかもしれないので、v4と1つのv6アドレスの範囲の両方への支給があるに違いありません。)
4.4.3.4. How the PAD Is Used
4.4.3.4. パッドはどう使用されているか。
During the initial IKE exchange, the initiator and responder each assert their identity via the IKE ID payload and send an AUTH payload to verify the asserted identity. One or more CERT payloads may be transmitted to facilitate the verification of each asserted identity.
初期のIKE交換の間、創始者と応答者は、IKE IDペイロードでそれぞれ彼らのアイデンティティについて断言して、断言されたアイデンティティについて確かめるためにAUTHペイロードを送ります。 1個以上のCERTペイロードが、アイデンティティであると断言されたそれぞれの検証を容易にするために伝えられるかもしれません。
Kent & Seo Standards Track [Page 46] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[46ページ]。
When an IKE entity receives an IKE ID payload, it uses the asserted ID to locate an entry in the PAD, using the matching rules described above. The PAD entry specifies the authentication method to be employed for the identified peer. This ensures that the right method is used for each peer and that different methods can be used for different peers. The entry also specifies the authentication data that will be used to verify the asserted identity. This data is employed in conjunction with the specified method to authenticate the peer, before any CHILD SAs are created.
IKE実体がIKE IDペイロードを受けるとき、PADでエントリーの場所を見つけるのに断言されたIDを使用します、上で説明された合っている規則を使用して。 PADエントリーは特定された同輩に使われるべき認証方法を指定します。 これは、各同輩に正しいメソッドを使用して、異なった同輩に異なったメソッドを使用できるのを確実にします。 また、エントリーは断言されたアイデンティティについて確かめるのに使用される認証データを指定します。 どんなCHILD SAsも作成される前にこのデータは同輩を認証する指定されたメソッドに関連して使われます。
Child SAs are created based on the exchange of traffic selector payloads, either at the end of the initial IKE exchange or in subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now authenticated) IKE peer is used to constrain creation of child SAs; specifically, the PAD entry specifies how the SPD is searched using a traffic selector proposal from a peer. There are two choices: either the IKE ID asserted by the peer is used to find an SPD entry via its symbolic name, or peer IP addresses asserted in traffic selector payloads are used for SPD lookups based on the remote IP address field portion of an SPD entry. It is necessary to impose these constraints on creation of child SAs to prevent an authenticated peer from spoofing IDs associated with other, legitimate peers.
子供SAsは初期のIKE交換の終わりかその後のCREATE_CHILD_SA交換における、トラフィックセレクタペイロードの交換に基づいて作成されます。 (現在、認証されています)のIKE同輩のためのPADエントリーは子供SAsの作成を抑制するのに使用されます。 明確に、PADエントリーはSPDが同輩からトラフィックセレクタ提案を使用することでどう捜されるかを指定します。 2つの選択があります: 同輩によって断言されたIKE IDが英字名でSPDエントリーを見つけるのに使用されるか、またはトラフィックセレクタペイロードで断言された同輩IPアドレスはSPDエントリーのリモートIPアドレス・フィールドの部分に基づくSPDルックアップに使用されます。 これらの規制を作成に課すために、認証された同輩が他の、そして、正統の同輩に関連しているIDを偽造するのを防ぎに子供SAsが必要です。
Note that because the PAD is checked before searching for an SPD entry, this safeguard protects an initiator against spoofing attacks. For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 [RFC2401] and this document do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X. Thus, the PAD provides a binding of address ranges (or name sub-spaces) to peers, to counter such attacks.
SPDエントリーを捜し求める前にPADがチェックされるのでこの安全装置がスプーフィング攻撃に対して創始者を保護することに注意してください。 例えば、IKE AがIPアドレスX(セキュリティゲートウェイによって役立たれるホスト)のために運命づけられた外国行きのパケットを受けると仮定してください。 RFC2401[RFC2401]とこのドキュメントはAがどうX.Howeverに勤めているIKE同輩のアドレスを決定するかを指定しません、とどんな同輩もIKE交換が認証されるのを許容するためにPADにXのための推定された代表を登録しなければならないので、Aで連絡しました。 認証された同輩が、トラフィックセレクタ交換におけるXを表すと断言するとき、そのうえ、PADは、問題の同輩がX.Thusを表すのに権限を与えられるなら、PADがそのような攻撃に対抗するためにアドレスの範囲(または、名前サブ空間)の結合を同輩に提供することを決定するために相談されるでしょう。
4.5. SA and Key Management
4.5. SAとKey Management
All IPsec implementations MUST support 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 service available for AH and ESP requires automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. In general, data origin authentication in AH and ESP is limited by the
すべてのIPsec実装が、手動の、そして、自動化の両方にされたSAと暗号化キーが管理であるとサポートしなければなりません。 IPsecプロトコル(AHと超能力)は、関連SA管理技術から主に独立しています、かかわったテクニックがプロトコルによって提供されたセキュリティー・サービスのいくつかに影響しますが。 例えば、AHと超能力に利用可能な任意の反再生サービスは自動化されたSA管理を必要とします。 そのうえ、IPsecと共に使われた主要な分配の粒状は、認証の粒状が提供されたことを決定します。 一般に、AHと超能力におけるデータ発生源認証は制限されます。
Kent & Seo Standards Track [Page 47] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[47ページ]。
extent to which secrets used with the integrity algorithm (or with a key management protocol that creates such secrets) are shared among multiple possible sources.
保全アルゴリズム(またはそのような秘密を作成するかぎ管理プロトコルで)で使用される秘密が複数の可能なソースの中で共有される範囲。
The following text describes the minimum requirements for both types of SA management.
以下のテキストは両方のタイプのSA管理のために必要最小限について説明します。
4.5.1. Manual Techniques
4.5.1. 手動のテクニック
The simplest form of management is manual management, in which a person manually configures each system with keying material and SA 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 might 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.
最も簡単な形式の管理は手動の管理です。(材料を合わせて、SA管理データが関連していた状態で、人は、他のシステムとのコミュニケーションを保証するためにそれで手動で各システムを構成します)。手動のテクニックは小さくて、静的な環境で実用的ですが、それらはよく比例しません。 例えば、会社は、いくつかのサイトでセキュリティゲートウェイでIPsecを使用することで仮想私設網(VPN)を作成できるでしょう。 サイトの数が少なく、すべてのサイトがただ一つの管理ドメインの範囲に該当するので、これは手動の管理技術のための可能な文脈であるかもしれません。 この場合、セキュリティゲートウェイは、他の目的地にトラフィックを保護していない間、組織の中にサイトと他のサイトから手動で構成されたキーを使用することでトラフィックを選択的に保護するかもしれません。 また、選択されるだけであるならコミュニケーションが、機密保護される必要があるのも、適切であるかもしれません。 同様の議論は完全に少ない数のホスト、そして/または、ゲートウェイのための組織の中でIPsecの使用に適用されるかもしれません。 また、別の選択肢は存在していますが、手動の管理技術はしばしば静的に構成されて、左右対称のキーを使います。
4.5.2. Automated SA and Key Management
4.5.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 IKEv2 [Kau05]. This document assumes the availability of certain functions from the key management protocol that are not supported by IKEv1. Other automated SA management protocols MAY be employed.
自動化された主要な管理プロトコルがIPsecとの使用のために選択したデフォルトはIKEv2[Kau05]です。 このドキュメントはかぎ管理プロトコルからのIKEv1によってサポートされないある機能の有用性を仮定します。 他の自動化されたSA管理プロトコルは使われるかもしれません。
When an automated SA/key management protocol is employed, the output from this protocol is used to generate multiple keys for a single SA. This also occurs because distinct keys are used for each of the two
自動化されたSA/かぎ管理プロトコルが採用しているとき、このプロトコルからの出力は、独身のSAのために複数のキーを生成するのに使用されます。 また、異なったキーがそれぞれ2つに使用されるので、これは起こります。
Kent & Seo Standards Track [Page 48] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[48ページ]。
SAs created by IKE. If both integrity and confidentiality are employed, then a minimum of four keys are required. Additionally, some cryptographic algorithms may require multiple keys, e.g., 3DES.
IKEによって作成されたSAs。 保全と秘密性の両方が採用しているなら、最低4個のキーが必要です。 さらに、いくつかの暗号アルゴリズムが複数のキー、例えば3DESを必要とするかもしれません。
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 keys 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 keys MUST be taken from the first (left-most, high-order) bits and the integrity keys MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant cryptographic algorithm specification RFC. In the case of multiple encryption keys or multiple integrity keys, the specification for the cryptographic algorithm must specify the order in which they are to be selected from a single string of bits provided to the cryptographic algorithm.
Key Management Systemがビットの別々のストリングを各キーに供給するかもしれませんか、またはそれはすべてのキーが抽出されるビットの1個のストリングを生成するかもしれません。 ビットの一連を提供するなら、注意は、ビットのストリングを必要なキーに写像するシステムの部分がSAの両端で同じファッションでそうするのを保証するために取られる必要があります。 SAの各端のIPsec実装が同じキーに同じビットを使用して、システムのどの部分がビットのストリングを個々のキーに分割するかの如何にかかわらず1日から暗号化キーを取らなければならないのを保証する(最も左、高位)ために、残っているビットからビットと保全キーを取らなければなりません。 各キーのためのビットの数は関連暗号アルゴリズム仕様RFCで定義されます。 複数の暗号化キーか複数の保全キーの場合では、暗号アルゴリズムのための仕様はそれらが暗号アルゴリズムに提供されたビットの一連から選択されることになっているオーダーを指定しなければなりません。
4.5.3. Locating a Security Gateway
4.5.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, but the Peer Authorization Database (PAD) described in Section 4.4 is the most likely candidate. (Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2 below.)
このセクションはホストが一度これらのセキュリティゲートウェイに連絡したときそれが、これらが正しいセキュリティゲートウェイであることをホストが関連セキュリティゲートウェイの存在に関してどう学ぶか、そして、どう知っているかに関連する問題について論じます。 必須情報が保存されるところに関する詳細は地域にかかわる事柄ですが、セクション4.4で説明されたPeer Authorization Database(PAD)は最もありそうな候補です。 (注意: S*はIPsec、例えばSH1を実行して、以下のSG2であるシステムを示します。)
Consider a situation in which a remote host (SH1) 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 crossing the Internet to his home organization's firewall (SG2). This situation raises several issues:
リモートホスト(SH1)がインターネットを使用している状況がサーバか他のマシン(H2)へのアクセスを得ると考えてください。そうすれば、セキュリティゲートウェイ(SG2)があります、例えば、ファイアウォール、どのH1のトラフィックが終わらなければならないかを通して。 この状況に関する例は彼のホーム組織のファイアウォール(SG2)にインターネットを横断するモバイルホストでしょう。 この状況はいくつかの問題を提起します:
1. How does SH1 know/learn about the existence of the security
gateway SG2?
1. SH1はセキュリティゲートウェイ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?
2. どのようにSG2を認証するか、そして、いったんSG2を認証すると、SG2がH2を表すのがどのように認可されたと確認しますか?
3. How does SG2 authenticate SH1 and verify that SH1 is authorized to
contact H2?
3. SG2は、SH1を認証して、SH1がH2に連絡するのがどのように認可されることを確かめますか?
Kent & Seo Standards Track [Page 49] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[49ページ]。
4. How does SH1 know/learn about any additional gateways that provide
alternate paths to H2?
4. SH1は代替パスをH2に供給するどんな追加ゲートウェイに関しても、どのように知っていますか、学びますか?
To address these problems, an IPsec-supporting host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of one or more security gateways for ranges of destination addresses that require its use. This includes the ability to configure information for locating and authenticating one or more security gateways and verifying the authorization of these gateways to represent the destination host. (The authorization function is implied in the PAD.) This document does not address the issue of how to automate the discovery/verification of security gateways.
これらの問題、IPsecをサポートしているホストまたはセキュリティゲートウェイに演説するのにおいて、ユーザ/管理者が使用を必要とする送付先アドレスの範囲に1セキュリティ門以上のアドレスを構成できる管理インタフェースがなければなりません。 これは、1セキュリティ門以上を場所を見つけて、認証するための情報を構成する能力とあて先ホストの代理をするためにこれらのゲートウェイの承認について確かめるのを含んでいます。 (承認機能はPADで含意されます。) このドキュメントはどうセキュリティゲートウェイの発見/検証を自動化するかに関する問題を扱いません。
4.6. SAs and Multicast
4.6. SAsとマルチキャスト
The receiver-orientation of the SA implies that, in the case of unicast traffic, the destination system will select the SPI value. By having the destination select the SPI value, there is no potential for manually configured SAs to conflict with automatically configured (e.g., via a key management protocol) SAs or for SAs from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems associated with a single SA. 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.
SAの受信機オリエンテーションは、目的地システムがユニキャストトラフィックの場合でSPI値を選択するのを含意します。 目的地にSPI値を選択させることによって、手動で構成されたSAsが自動的に構成された(例えば、かぎ管理プロトコルで)SAsと衝突するか、または複数のソースからのSAsが互いと衝突する可能性が全くありません。 マルチキャストトラフィックのために、独身のSAに関連している複数の目的地システムがあります。 それで、システムか人が、ここで定義されなかったメカニズムでそれぞれのマルチキャストグループを代表してSPIかSPIsを選択して、次に、そのマルチキャストグループの正統のメンバーのすべてにグループのIPsec情報を伝えるためにすべてのマルチキャストグループで調整する必要があるでしょう。
Multiple senders to a multicast group SHOULD use a single Security Association (and hence SPI) for all traffic to that group when a symmetric key encryption or integrity 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 approaches are deferred to the IETF Multicast Security Working Group.
対称鍵暗号化か保全アルゴリズムが採用しているとき、マルチキャストグループSHOULDへの複数の送付者がすべてのトラフィックに、独身のSecurity Association(そして、したがって、SPI)をそのグループに使用します。 そのような事情では、受信機は、メッセージがそのマルチキャストグループにキーを所有しているシステムから来ただけであるのを知っています。 一般に、事情、受信機が認証できないそれのシステムがマルチキャストトラフィックを送ったそのようなもので。 他の、そして、より一般的なマルチキャストアプローチのための仕様はIETF Multicast Security作業部会に延期されます。
5. IP Traffic Processing
5. IPトラフィック処理
As mentioned in Section 4.4.1, "The Security Policy Database (SPD)", the SPD (or associated caches) MUST be consulted during the processing of all traffic that crosses the IPsec protection boundary, including IPsec management traffic. If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded. To simplify processing, and to allow for very fast SA lookups (for SG/BITS/BITW), this document introduces the
.1、「安全保障政策データベース(SPD)」というSPD(または、関連キャッシュ)がそうしなければならないセクション4.4で言及されるように、IPsec保護境界に交差するすべてのトラフィックの処理の間、相談されてください、IPsec管理トラフィックを含んでいて。 または、方針が全くパケットに合っているSPDで見つけられない、(どちらかにおける本国行き、アウトバウンドトラフィック)、パケットを捨てなければなりません。 処理を簡素化して、非常に速くSAルックアップ(SG/BITS/BITWのための)、このドキュメントを考慮する、導入
Kent & Seo Standards Track [Page 50] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[50ページ]。
notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As mentioned earlier, the SAD acts as a cache for checking the selectors of inbound IPsec-protected traffic arriving on SAs.) There is nominally one cache per SPD. For the purposes of this specification, it is assumed that each cached entry will map to exactly one SA. Note, however, exceptions arise when one uses multiple SAs to carry traffic of different priorities (e.g., as indicated by distinct DSCP values) but the same selectors. Note also, that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD. Since this document does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted. Also, if a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry.
すべてのアウトバウンドトラフィック(SPD-OとSPD-S)のためのSPDキャッシュの概念、および本国行きの、そして、非IPsecが保護しているトラフィック(SPD-I)のためのキャッシュ。 (先に述べたように、SADはSAsで到着する本国行きのIPsecによって保護されたトラフィックのセレクタをチェックするためのキャッシュとして機能します。) 名目上は、1SPDあたり1つのキャッシュがあります。 この仕様の目的のために、それぞれのキャッシュされたエントリーがちょうど1つにSAを写像すると思われます。 しかしながら、1つが異なったプライオリティ(例えば、異なったDSCP値によって示されるように)にもかかわらず、同じセレクタのトラフィックを運ぶのに複数のSAsを使用すると例外が起こることに注意してください。 SADがSPDに対応するエントリーを持っていないSAsのためのエントリーを持つことができる2、3の状況があるというメモも。 このドキュメントが、SPDを変えるとき、選択的にSADをきれいにするのを強制しないので、それらを作成したSPDエントリーを変えるか、または削除するとき、SADエントリーは残ることができます。 また、手動で合わせられたSAが作成されるなら、どんなSPDエントリーにも対応しないこのSAのためのSADエントリーがあるかもしれません。
Since SPD entries may overlap, one cannot safely cache these entries in general. Simple caching might result in a match against a cache entry, whereas an ordered search of the SPD would have resulted in a match against a different entry. But, if the SPD entries are first decorrelated, then the resulting entries can safely be cached. Each cached entry will indicate that matching traffic should be bypassed or discarded, appropriately. (Note: The original SPD entry might result in multiple SAs, e.g., because of PFP.) Unless otherwise noted, all references below to the "SPD" or "SPD cache" or "cache" are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache containing entries from the decorrelated SPD.
SPDエントリーが重なるかもしれないので、1つは安全に一般に、これらのエントリーをキャッシュできません。 簡単なキャッシュはキャッシュエントリーに対するマッチをもたらすかもしれませんが、SPDの命令された検索は異なったエントリーに対するマッチをもたらしたでしょう。 しかし、SPDエントリーが最初に反関連するなら、安全に結果として起こるエントリーをキャッシュできます。 それぞれのキャッシュされたエントリーは、合っているトラフィックが迂回するべきであるか、または適切に捨てられるべきであるのを示すでしょう。 (注意: 元のSPDエントリーは例えば、PFPのために複数のSAsをもたらすかもしれません。) 別の方法で注意されない場合、decorrelated SPD(SPD-I、SPD-O、SPD-S)かdecorrelated SPDからのエントリーを含むSPDキャッシュには以下での"SPD"、「SPDキャッシュ」または「キャッシュ」のすべての参照があります。
Note: 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. This provides an implicit caching mechanism, and the portions of the preceding discussion that address caching can be ignored in such implementations.
以下に注意してください。 ソケットに基づくホストIPsec実装では、新しいソケットがIPsec処理がどんなであるも何になるかをそのソケットの上に流れるトラフィックに適用されていた状態で決定するために作成されるときはいつも、SPDに相談するでしょう。 これは内在しているキャッシュメカニズムを提供します、そして、そのような実装でキャッシュを扱う前の議論の部分は無視できます。
Note: It is assumed that one starts with a correlated SPD because that is how users and administrators are accustomed to managing these sorts of access control lists or firewall filter rules. Then the decorrelation algorithm is applied to build a list of cache-able SPD entries. The decorrelation is invisible at the management interface.
以下に注意してください。 それがユーザと管理者がどうこれらの種類のアクセスコントロールリストかファイアウォールフィルタ規則を管理するのに慣れているかということであるので1つが関連SPDから始まると思われます。 そして、「反-相関関係」アルゴリズムは、キャッシュできるSPDエントリーのリストを造るために適用されます。 「反-相関関係」は管理インタフェースで目に見えません。
For inbound IPsec traffic, the SAD entry selected by the SPI serves as the cache for the selectors to be matched against arriving IPsec packets, after AH or ESP processing has been performed.
本国行きのIPsecトラフィックのために、SADエントリーは、SPIでセレクタのためのキャッシュとしてのサーブが到着しているIPsecパケットに取り組まされるのを選択しました、AHか超能力処理が実行された後に。
Kent & Seo Standards Track [Page 51] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[51ページ]。
5.1. Outbound IP Traffic Processing (protected-to-unprotected)
5.1. 外国行きのIPトラフィック処理(保護のなく保護されます)
First consider the path for traffic entering the implementation via a protected interface and exiting via an unprotected interface.
まず最初に、保護されたインタフェースと保護のないインタフェースを通して出ることを通してトラフィックの入る経路が実装であると考えてください。
Unprotected Interface
^
|
(nested SAs) +----------+
-------------------|Forwarding|<-----+
| +----------+ |
| ^ |
| | BYPASS |
V +-----+ |
+-------+ | SPD | +--------+
...| SPD-I |.................|Cache|.....|PROCESS |...IPsec
| (*) | | (*) |---->|(AH/ESP)| boundary
+-------+ +-----+ +--------+
| +-------+ / ^
| |DISCARD| <--/ |
| +-------+ |
| |
| +-------------+
|---------------->|SPD Selection|
+-------------+
^
| +------+
| -->| ICMP |
| / +------+
|/
|
|
Protected Interface
保護のないインタフェース^| (入れ子にされたSAs) +----------+ -------------------|推進| <、-、-、-、--+ | +----------+ | | ^ | | | 迂回| +に対して-----+ | +-------+ | SPD| +--------+ ...| SPD-I|.................|キャッシュ|.....|プロセス|...IPsec| (*) | | (*) |、-、-、--、>|(ああ、/、超能力)| 境界+-------+ +-----+ +--------+ | +-------+ / ^ | |破棄| <--/ | | +-------+ | | | | +-------------+ |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|SPD選択| +-------------+ ^ | +------+ | -->| ICMP| | / +------+ |/ | | 保護されたインタフェース
Figure 2. Processing Model for Outbound Traffic
(*) = The SPD caches are shown here. If there
is a cache miss, then the SPD is checked.
There is no requirement that an
implementation buffer the packet if
there is a cache miss.
図2。 SPD Outbound Traffic(*)のための処理Model=キャッシュはここに示されます。 キャッシュミスがあれば、SPDはチェックされます。 キャッシュミスがあれば実装がパケットをバッファリングするという要件が全くありません。
Kent & Seo Standards Track [Page 52] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[52ページ]。
IPsec MUST perform the following steps when processing outbound packets:
外国行きのパケットを処理するとき、IPsecは以下のステップを実行しなければなりません:
1. When a packet arrives from the subscriber (protected) interface,
invoke the SPD selection function to obtain the SPD-ID needed to
choose the appropriate SPD. (If the implementation uses only one
SPD, this step is a no-op.)
1. パケットが加入者(保護される)インタフェースから到着するときにはSPD選択機能を呼び出して、適切なSPDを選ぶのに必要であるSPD-IDを得てください。 (実装が1SPDだけを使用するなら、このステップはオプアートではありません。)
2. Match the packet headers against the cache for the SPD specified
by the SPD-ID from step 1. Note that this cache contains entries
from SPD-O and SPD-S.
2. SPD-IDによってステップ1から指定されたSPDのためのキャッシュに対してパケットのヘッダーを合わせてください。 このキャッシュがSPD-OとSPD-Sからのエントリーを含むことに注意してください。
3a. If there is a match, then process the packet as specified by the
matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH
or ESP. If IPsec processing is applied, there is a link from the
SPD cache entry to the relevant SAD entry (specifying the mode,
cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec
processing is as previously defined, for tunnel or transport
modes and for AH or ESP, as specified in their respective RFCs
[Ken05b, Ken05a]. Note that the SA PMTU value, plus the value of
the stateful fragment checking flag (and the DF bit in the IP
header of the outbound packet) determine whether the packet can
(must) be fragmented prior to or after IPsec processing, or if it
must be discarded and an ICMP PMTU message is sent.
3a。 マッチがあれば、AHか超能力を使用することで指定されるとしての合っているキャッシュエントリー、すなわち、BYPASS、DISCARD、またはPROTECTによるパケットを処理してください。 IPsec処理が適用されているなら、SPDキャッシュエントリーから関連SADエントリーへのリンクがあります(モード、暗号アルゴリズム、キー、SPI、PMTUなどを指定して)。 IPsec処理は以前に、定義されているか、トンネルか交通機関とAHか超能力のためのものです、それらのそれぞれのRFCs[Ken05b、Ken05a]で指定されるように。 SA PMTUが評価する注意、そのうえ、stateful断片照合旗(そして、外国行きのパケットのIPヘッダーのDFビット)の値はパケットがそうすることができるか否かに関係なく、(must)が断片化される前かIPsec処理、それを捨てなければならないか、そして、またはICMP PMTUメッセージの後に送られることを決定します。
3b. If no match is found in the cache, search the SPD (SPD-S and
SPD-O parts) specified by SPD-ID. If the SPD entry calls for
BYPASS or DISCARD, create one or more new outbound SPD cache
entries and if BYPASS, create one or more new inbound SPD cache
entries. (More than one cache entry may be created since a
decorrelated SPD entry may be linked to other such entries that
were created as a side effect of the decorrelation process.) If
the SPD entry calls for PROTECT, i.e., creation of an SA, the key
management mechanism (e.g., IKEv2) is invoked to create the SA.
If SA creation succeeds, a new outbound (SPD-S) cache entry is
created, along with outbound and inbound SAD entries, otherwise
the packet is discarded. (A packet that triggers an SPD lookup
MAY be discarded by the implementation, or it MAY be processed
against the newly created cache entry, if one is created.) Since
SAs are created in pairs, an SAD entry for the corresponding
inbound SA also is created, and it contains the selector values
derived from the SPD entry (and packet, if any PFP flags were
"true") used to create the inbound SA, for use in checking
inbound traffic delivered via the SA.
3b。 マッチが全くキャッシュで見つけられないなら、SPD-IDによって指定されたSPD(SPD-SとSPD-Oの部品)を捜してください。 SPDエントリーがBYPASSかDISCARDを求めるなら、1つ以上の新しい外国行きのSPDキャッシュエントリーを作成してください、そして、BYPASSであるなら、1つ以上の新しい本国行きのSPDキャッシュエントリーを作成してください。 (decorrelated SPDエントリーが「反-相関関係」プロセスの副作用のような作成された他のエントリーにリンクされるかもしれないので、1つ以上のキャッシュエントリーが作成されるかもしれません。) SPDエントリーがPROTECT、すなわち、SAの作成を求めるなら、かぎ管理メカニズム(例えば、IKEv2)は、SAを作成するために呼び出されます。 SA作成が成功するなら、新しい外国行きの(SPD-S)キャッシュエントリーは外国行きの、そして、本国行きのSADエントリーと共に作成されます。さもなければ、パケットは捨てられます。 (SPDルックアップの引き金となるパケットが実装によって捨てられるかもしれませんか、またはそれは新たに作成されたキャッシュエントリーに対して処理されるかもしれません、1つが作成されるなら。) SAsが組で作成されるので、また、対応する本国行きのSAのためのSADエントリーは作成されます、そして、それはSPDエントリーから得られたセレクタ値を含んでいます。(そして、どんなPFP旗も本国行きのSAを作成するのにおいて中古の「本当であった」SAを通して提供されたインバウンドトラフィックをチェックすることにおける使用のためのパケット。
4. The packet is passed to the outbound forwarding function
(operating outside of the IPsec implementation), to select the
interface to which the packet will be directed. This function
4. パケットは、パケットが向けられるインタフェースを選択するために外国行きの推進機能(IPsec実装の外では、操作する)に通過されます。 この機能
Kent & Seo Standards Track [Page 53] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[53ページ]。
may cause the packet to be passed back across the IPsec boundary,
for additional IPsec processing, e.g., in support of nested SAs.
If so, there MUST be an entry in SPD-I database that permits
inbound bypassing of the packet, otherwise the packet will be
discarded. If necessary, i.e., if there is more than one SPD-I,
the traffic being looped back MAY be tagged as coming from this
internal interface. This would allow the use of a different
SPD-I for "real" external traffic vs. looped traffic, if needed.
パケットがIPsec境界の向こう側に戻されることを引き起こすかもしれません、追加IPsec処理のために、例えば、入れ子にされたSAsを支持して。 そうだとすれば、パケットの本国行きの迂回を可能にするSPD-Iデータベースにはエントリーがあるに違いありません。さもなければ、パケットは捨てられるでしょう。 必要なら、すなわち、1SPD-Iがあれば、輪にし返されるトラフィックはこの内部のインタフェースから来るとしてタグ付けをされるかもしれません。 必要であるなら、これは輪にされたトラフィックに対して異なったSPD-Iの「本当」の域外交通の使用を許すでしょう。
Note: With the exception of IPv4 and IPv6 transport mode, an SG, BITS, or BITW implementation MAY fragment packets before applying IPsec. (This applies only to IPv4. For IPv6 packets, only the originator is allowed to fragment them.) The device SHOULD have a configuration setting to disable this. The resulting fragments are evaluated against the SPD in the normal manner. Thus, fragments not containing port numbers (or ICMP message type and code, or Mobility Header type) will only match rules having port (or ICMP message type and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for more details.)
以下に注意してください。 IPv4とIPv6交通機関を除いて、IPsecを適用する前に、SG、BITS、またはBITW実装がパケットを断片化するかもしれません。 これはIPv4だけに申し込まれます。(IPv6パケットに関して、創始者だけがそれらを断片化できます。) デバイスSHOULDには、これを無効にする構成設定があります。 結果として起こる断片は正常な方法でSPDに対して評価されます。 したがって、ポートナンバー(または、ICMPメッセージタイプとコードか、Mobility Headerタイプ)を含まない断片はOPAQUEかいずれのポート(または、ICMPメッセージタイプとコードか、MHタイプ)セレクタを持っている規則に合うだけでしょう。 (その他の詳細に関してセクション7を見てください。)
Note: With regard to determining and enforcing the PMTU of an SA, the IPsec system MUST follow the steps described in Section 8.2.
以下に注意してください。 SAのPMTUを決定して、実施することに関して、IPsecシステムはセクション8.2で説明された方法に従わなければなりません。
5.1.1. Handling an Outbound Packet That Must Be Discarded
5.1.1. 捨てなければならない外国行きのパケットを扱います。
If an IPsec system receives an outbound packet that it finds it must discard, it SHOULD be capable of generating and sending an ICMP message to indicate to the sender of the outbound packet that the packet was discarded. The type and code of the ICMP message will depend on the reason for discarding the packet, as specified below. The reason SHOULD be recorded in the audit log. The audit log entry for this event SHOULD include the reason, current date/time, and the selector values from the packet.
IPsecシステムがそれが見つける外国行きのパケットを受けるなら、捨てなければならなくて、生成することができて、パケットが捨てられたのを外国行きのパケットの送付者に示すICMPメッセージを送るSHOULDです。 ICMPメッセージのタイプとコードは以下で指定されるとしてパケットを捨てる理由に信頼されるでしょう。 記録されたコネが監査ログであったならSHOULDを推論してください。 このイベントSHOULDのための監査ログエントリーは理由、現在の日付/時間、およびパケットからのセレクタ値を含んでいます。
a. The selectors of the packet matched an SPD entry requiring the
packet to be discarded.
a。 パケットのセレクタはパケットが捨てられるのを必要とするSPDエントリーに合っていました。
IPv4 Type = 3 (destination unreachable) Code = 13
(Communication Administratively Prohibited)
3の(目的地手の届かない)のIPv4 Type=コード=13(行政上禁止されたコミュニケーション)
IPv6 Type = 1 (destination unreachable) Code = 1
(Communication with destination administratively
prohibited)
1つの(目的地手の届かない)のIPv6 Type=コード=1(行政上禁止されている目的地とのコミュニケーション)
b1. The IPsec system successfully reached the remote peer but was
unable to negotiate the SA required by the SPD entry matching the
packet because, for example, the remote peer is administratively
prohibited from communicating with the initiator, the initiating
b1。 IPsecシステムは、首尾よくリモート同輩に届きましたが、例えば、リモート同輩が創始者とコミュニケートする開始から行政上禁じられるのでパケットに合っているSPDエントリーで必要であるSAを交渉できませんでした。
Kent & Seo Standards Track [Page 54] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[54ページ]。
peer was unable to authenticate itself to the remote peer, the
remote peer was unable to authenticate itself to the initiating
peer, or the SPD at the remote peer did not have a suitable
entry.
同輩がリモート同輩にそれ自体を認証できなかった、リモート同輩が開始している同輩にそれ自体を認証できませんでしたか、またはリモート同輩のSPDには適当なエントリーがありませんでした。
IPv4 Type = 3 (destination unreachable) Code = 13
(Communication Administratively Prohibited)
3の(目的地手の届かない)のIPv4 Type=コード=13(行政上禁止されたコミュニケーション)
IPv6 Type = 1 (destination unreachable) Code = 1
(Communication with destination administratively
prohibited)
1つの(目的地手の届かない)のIPv6 Type=コード=1(行政上禁止されている目的地とのコミュニケーション)
b2. The IPsec system was unable to set up the SA required by the SPD
entry matching the packet because the IPsec peer at the other end
of the exchange could not be contacted.
b2。 IPsecシステムは交換のもう一方の端のIPsec同輩に連絡できなかったのでパケットに合っているSPDエントリーで必要であるSAをセットアップできませんでした。
IPv4 Type = 3 (destination unreachable) Code = 1 (host
unreachable)
3の(目的地手の届かない)のIPv4 Type=コード=1(ホスト手の届かない)です。
IPv6 Type = 1 (destination unreachable) Code = 3 (address
unreachable)
1つの(目的地手の届かない)のIPv6 Type=コード=3(アドレス手の届かない)です。
Note that an attacker behind a security gateway could send packets with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it to send ICMP messages to W.X.Y.Z. This creates an opportunity for a denial of service (DoS) attack among hosts behind a security gateway. To address this, a security gateway SHOULD include a management control to allow an administrator to configure an IPsec implementation to send or not send the ICMP messages under these circumstances, and if this facility is selected, to rate limit the transmission of such ICMP responses.
セキュリティゲートウェイの後ろの攻撃者が偽造しているソースアドレスがあるパケットを送ることができたというメモ、それがW.X.Y.Z.ThisへのメッセージをICMPに送るIPsec実体へのW.X.Y.Zはセキュリティゲートウェイの後ろでホストの中でサービス(DoS)攻撃の否定の機会を作成します。 これを扱うなら、こういう事情ですから、この施設が、限界がそのようなICMP応答の送信であると評定するのが選択されるなら、セキュリティゲートウェイSHOULDは、管理者が発信するか、またはICMPメッセージを送らないようにIPsec実装を構成するのを許容するためにマネジメント・コントロールを含んでいます。
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, with regard to outbound traffic processing. This includes how to construct the encapsulating (outer) IP header, how to process fields in the inner IP header, and what other actions should be taken for outbound, tunnel mode traffic. The general processing described here is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]:
このセクションはAHと超能力トンネルのための内側の、そして、外側のIPヘッダー、拡張ヘッダー、およびオプションの取り扱いについて説明します、アウトバウンドトラフィック処理に関して。 これは、どのように要約(外側の)のIPヘッダーを組み立てるか、そして、どのように内側のIPヘッダーの分野を処理するか、そして、どんな他の行動が外国行きのトンネルモードトラフィックに取られるべきであるかを含んでいます。 RFC2003、「IPの中のIPカプセル化」[Per96]にここで説明された一般的な処理は倣われます:
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.
o 外側のIPのヘッダーSource AddressとDestination Addressはトンネル(encapsulatorとdecapsulator)の「終点」を特定します。 内側のIPのヘッダーSource AddressとDestination Addressesはそれぞれデータグラム(このトンネルの見解からの)の元の送り主と受取人を特定します。
Kent & Seo Standards Track [Page 55] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[55ページ]。
(See footnote 3 after the table in 5.1.2.1 for more details on the
encapsulating source IP address.)
(テーブルの後に中で脚注3を見てください、5.1、.2、.1、要約のソースIPアドレスに関するその他の詳細)。
o The inner IP header is not changed except as noted below for TTL
(or Hop Limit) and the DS/ECN Fields. The inner IP header
otherwise remains unchanged during its delivery to the tunnel exit
point.
o TTL(または、Hop Limit)とDS/電子証券取引ネットワークのフィールズによって以下に述べられる以外に、内側のIPヘッダーは変えられません。 そうでなければ、内側のIPヘッダーは配送の間、トンネルエキジットポイントに変わりがないままでいます。
o No change to IP options or extension headers in the inner header
occurs during delivery of the encapsulated datagram through the
tunnel.
o 内側のヘッダーのIPオプションか拡張ヘッダーへの変化は全くトンネルを通るカプセル化されたデータグラムの配送の間、起こりません。
Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC 2003 [Per96]) in several ways:
以下に注意してください。 IPsecトンネルモードはいくつかの方法で(RFC2003[Per96])にトンネルを堀りながら、IPにおけるIPと異なっています:
o IPsec offers certain controls to a security administrator to
manage covert channels (which would not normally be a concern for
tunneling) and to ensure that the receiver examines the right
portions of the received packet with respect to application of
access controls. An IPsec implementation MAY be configurable with
regard to how it processes the outer DS field for tunnel mode for
transmitted packets. For outbound traffic, one configuration
setting for the outer DS field will operate as described in the
following sections on IPv4 and IPv6 header processing for IPsec
tunnels. Another will allow the outer DS field to be mapped to a
fixed value, which MAY be configured on a per-SA basis. (The value
might really be fixed for all traffic outbound from a device, but
per-SA granularity allows that as well.) This configuration option
allows a local administrator to decide whether the covert channel
provided by copying these bits outweighs the benefits of copying.
o IPsecは、ひそかなチャンネル(通常トンネリングに関する心配でない)を管理して、受信機がアクセス制御のアプリケーションに関して容認されたパケットの正しい一部を調べるのを保証するためにあるコントロールをセキュリティ管理者に提供します。 それが伝えられたパケットのためのトンネルモードのためにどう外側のDS分野を処理するかに関してIPsec実装は構成可能であるかもしれません。 アウトバウンドトラフィックのために、外側のDS分野への1つの構成設定がIPsecトンネルのためのIPv4とIPv6ヘッダー処理のときに以下のセクションで説明されるように作動するでしょう。 別のものは、外側のDS分野が一定の価値に写像されるのを許容するでしょう。(一定の価値は1SAあたり1個のベースで構成されるかもしれません)。 (値はデバイスからの外国行きのすべてのトラフィックのために本当に修理されるかもしれませんが、また、1SAあたりの粒状はそれを許容します。) この設定オプションで、地元の管理者は、これらのビットをコピーすることによって提供されたひそかなチャンネルがコピーの利益より重いかどうか決めることができます。
o IPsec describes how to handle ECN or DS and provides the ability
to control propagation of changes in these fields between
unprotected and protected domains. In general, propagation from a
protected to an unprotected domain is a covert channel and thus
controls are provided to manage the bandwidth of this channel.
Propagation of ECN values in the other direction are controlled so
that only legitimate ECN changes (indicating occurrence of
congestion between the tunnel endpoints) are propagated. By
default, DS propagation from an unprotected domain to a protected
domain is not permitted. However, if the sender and receiver do
not share the same DS code space, and the receiver has no way of
learning how to map between the two spaces, then it may be
appropriate to deviate from the default. Specifically, an IPsec
implementation MAY be configurable in terms of how it processes
the outer DS field for tunnel mode for received packets. It may
be configured to either discard the outer DS value (the default)
OR to overwrite the inner DS field with the outer DS field. If
o IPsecは保護のなくて保護されたドメインの間のこれらの分野に電子証券取引ネットワークかDSを扱う方法を説明して、変化の伝播を制御する能力を前提とします。 一般に、保護のないドメインに保護されたaからの伝播はひそかなチャンネルです、そして、その結果、このチャンネルの帯域幅を管理するためにコントロールを提供します。 もう片方の方向への電子証券取引ネットワーク値の伝播が制御されているので、正統の電子証券取引ネットワーク変化(トンネル終点の間の混雑の発生を示す)だけが伝播されます。 デフォルトで、保護のないドメインから保護されたドメインまでのDS伝播は受入れられません。 しかしながら、送付者と受信機が同じDSコードスペースを共有しないで、また受信機に2つの空間の間の地図へのその方法を知る方法が全くないなら、デフォルトから逸れるのは適切であるかもしれません。 明確に、それが容認されたパケットのためのトンネルモードのためにどう外側のDS分野を処理するかにIPsec実装は構成可能であるかもしれません。 外側のDS分野で内側のDS分野を上書きするために外側のDS価値(デフォルト)のORを捨てるのは構成されているかもしれません。 if
Kent & Seo Standards Track [Page 56] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[56ページ]。
offered, the discard vs. overwrite behavior MAY be configured on a
per-SA basis. This configuration option allows a local
administrator to decide whether the vulnerabilities created by
copying these bits outweigh the benefits of copying. See
[RFC2983] for further information on when each of these behaviors
may be useful, and also for the possible need for diffserv traffic
conditioning prior or subsequent to IPsec processing (including
tunnel decapsulation).
提供していて、破棄対重ね書きの振舞いは1SAあたり1個のベースで構成されるかもしれません。 この設定オプションで、地元の管理者は、これらのビットをコピーすることによって作成された脆弱性がコピーの利益より重いかどうか決めることができます。 それぞれのこれらの振舞いが役に立つかもしれない時に関する詳細、および可能ためにもdiffservトラフィック調節の必要性がIPsec処理に先である、またはその後であるのを見てください[RFC2983](トンネル被膜剥離術を含んでいて)。
o IPsec allows the IP version of the encapsulating header to be
different from that of the inner header.
o IPsecは内側のヘッダーのものと異なる要約のヘッダーのIPバージョンを許容します。
The tables in the following sub-sections show the handling for the
different header/option fields ("constructed" means that 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
DS Field copied from inner hdr (5) no change
ECN Field copied from inner hdr constructed (6)
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragment offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP no change
checksum constructed constructed (2)(6)
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change
<--Inner HdrへのどのようにOuter Hdr Relates--IPv4 Encapsulator Decapsulator Header分野のInner Hdrの>Outer Hdr: -------------------- ------------ バージョン4 (1) 変化の組み立てられたノーDS Fieldがどんな変化電子証券取引ネットワークFieldも変化のhdrに組み立てられた内側の(6)全長組み立てられたノーIDを回避しなかった内側のhdr(5)を回避しなかった変化ヘッダ長は全く旗(DF、MF)が組み立てなかった変化を全く組み立てて、DF(4)いいえ、変化断片オフセット変化の組み立てられたノーTTLは(2) 減少(2)プロトコルAHを組み立てて、組み立てられた組み立てられた(2)(6)srcアドレスの変化destアドレスの変化の超能力ノー変化チェックサム組み立てられた(3)ノー組み立てられた(3)ノーOptionsは変化を全く決してコピーしませんでした。
Notes:
注意:
(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 IPv4 checksum changes when the TTL changes.)
(2) パケットを進めるなら、内側のヘッダーのTTLは推進の前のencapsulatorとdecapsulatorによって減少します。 (IPv4チェックサムは、TTLがいつ変化するかを変えます。)
Kent & Seo Standards Track [Page 57] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[57ページ]。
Note: Decrementing the TTL value is a normal part of
forwarding a packet. Thus, a packet originating from the same
node as the encapsulator does not have its TTL decremented,
since the sending node is originating the packet rather than
forwarding it. This applies to BITS and native IPsec
implementations in hosts and routers. However, the IPsec
processing model includes an external forwarding capability.
TTL processing can be used to prevent looping of packets,
e.g., due to configuration errors, within the context of this
processing model.
以下に注意してください。 TTL値を減少させるのは、パケットを進める標準の部分です。 したがって、TTLはencapsulatorと同じノードから発するパケットで減少しません、むしろ送付ノードがそれを進めるよりパケットを溯源しているので。 これはホストとルータにおけるBITSとネイティブのIPsec実装に適用されます。 しかしながら、IPsec処理モデルは外部の推進能力を入れます。 パケットのループ、例えば支払われるべきものを構成誤りに防ぐのにTTL処理を使用できます、この処理モデルの文脈の中で。
(3) Local and Remote addresses depend on the SA, which is used to
determine the Remote address, which in turn determines which
Local address (net interface) is used to forward the packet.
(3) 地方とRemoteアドレスはSAによります。(SAは、Remoteアドレスを決定するのに使用されます)。(順番に、アドレスは、どのLocalアドレス(ネットのインタフェース)がパケットを進めるのに使用されるかを決定します)。
Note: For multicast traffic, the destination address, or
source and destination addresses, may be required for
demuxing. In that case, it is important to ensure consistency
over the lifetime of the SA by ensuring that the source
address that appears in the encapsulating tunnel header is the
same as the one that was negotiated during the SA
establishment process. There is an exception to this general
rule, i.e., a mobile IPsec implementation will update its
source address as it moves.
以下に注意してください。 マルチキャストトラフィックにおいて、送付先アドレスか、ソースと送付先アドレスが、demuxingするのに必要であるかもしれません。 その場合、要約のトンネルヘッダーに現れるソースアドレスがSA設立プロセスの間に交渉されたものと同じであることを確実にすることによってSAの生涯一貫性があることを保証するのは重要です。 この一般的な規則への例外があります、すなわち、移行するとき、モバイルIPsec実装はソースアドレスをアップデートするでしょう。
(4) Configuration determines whether to copy from the inner header
(IPv4 only), clear, or set the DF.
(4) 構成は、内側のヘッダー(IPv4専用)からコピーするか、クリアするか、またはDFを設定するかを決定します。
(5) If the packet will immediately enter a domain for which the
DSCP value in the outer header is not appropriate, that value
MUST be mapped to an appropriate value for the domain
[NiBlBaBL98]. See RFC 2475 [BBCDWW98] for further
information.
(5) パケットがすぐに外側のヘッダーのDSCP値が適切でないドメインに入るなら、ドメイン[NiBlBaBL98]のためにその値を適切な値に写像しなければなりません。 詳細に関してRFC2475[BBCDWW98]を見てください。
(6) If the ECN field in the inner header is set to ECT(0) or
ECT(1), where ECT is ECN-Capable Transport (ECT), and if the
ECN field in the outer header is set to Congestion Experienced
(CE), then set the ECN field in the inner header to CE;
otherwise, make no change to the ECN field in the inner
header. (The IPv4 checksum changes when the ECN changes.)
(6) 内側のヘッダーの電子証券取引ネットワーク分野がECT(0)かECT(1)に設定されて、外側のヘッダーの電子証券取引ネットワーク分野がCongestion Experienced(CE)に設定されるなら、CEへの内側のヘッダーに電子証券取引ネットワーク分野をはめ込んでください。そこでは、ECTが電子証券取引ネットワークできるTransport(ECT)です。 さもなければ、内側のヘッダーの電子証券取引ネットワーク分野への変更を全く行わないでください。 (IPv4チェックサムは、電子証券取引ネットワークがいつ変化するかを変えます。)
Note: IPsec does not copy the options from the inner header into the outer header, nor does IPsec construct the options in the outer header. However, post-IPsec code MAY insert/construct options for the outer header.
以下に注意してください。 IPsecは内側のヘッダーを外側のヘッダーにオプションを回避しません、そして、IPsecは外側のヘッダーでオプションを構成しません。 しかしながら、ポスト-IPsecコードは、外側のヘッダーのためにオプションを挿入するか、または構成するかもしれません。
Kent & Seo Standards Track [Page 58] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[58ページ]。
5.1.2.2. IPv6: Header Construction for Tunnel Mode
5.1.2.2. IPv6: トンネル・モードのためのヘッダー工事
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
DS Field copied from inner hdr (5) no change (9)
ECN Field copied from inner hdr constructed (6)
flow label copied or configured (8) no change
payload length 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 (7) no change
<--外側のHdrはどう内側のHdrを関係づけるか。---IPv6 Encapsulator Decapsulator Header分野のInner Hdrの>の外側のHdr: -------------------- ------------ バージョン6 (1) DS Fieldがどんな変化(9)電子証券取引ネットワークFieldも組み立てられた(6)流れラベルが次の(8) 変化ペイロード長がない変化のヘッダーの組み立てられたノーAHにコピーもしませんでしたし、構成もしなかった内側のhdrを回避しなかった内側のhdr(5)を回避しなかった変化、全く超能力、組み立てられた(2)減少(2)srcアドレスの変化destアドレスの変化のhdrノー変化ホップ限界組み立てられた(3)ノー組み立てられた(3)ノーExtensionを発送して、ヘッダーは(7) 変化を全く決してコピーしませんでした。
Notes:
注意:
(1) - (6) See Section 5.1.2.1.
(1)--(6) .1にセクション5.1.2を見てください。
(7) IPsec does not copy the extension headers from the inner
packet into outer headers, nor does IPsec construct extension
headers in the outer header. However, post-IPsec code MAY
insert/construct extension headers for the outer header.
(7) IPsecは内側のパケットから外側のヘッダーに拡張ヘッダーをコピーしないで、外側のヘッダーで構造物拡張ヘッダーをIPsecにします。 しかしながら、ポスト-IPsecコードは、外側のヘッダーのために拡張ヘッダーを挿入するか、または組み立てるかもしれません。
(8) See [RaCoCaDe04]. Copying is acceptable only for end systems,
not SGs. If an SG copied flow labels from the inner header to
the outer header, collisions might result.
(8) [RaCoCaDe04]を見てください。 SGsではなく、エンドシステムだけにおいて、コピーは許容できます。 SGが内側のヘッダーから外側のヘッダーまで流れラベルをコピーするなら、衝突は結果として生じるでしょうに。
(9) An implementation MAY choose to provide a facility to pass the
DS value from the outer header to the inner header, on a per-
SA basis, for received tunnel mode packets. The motivation
for providing this feature is to accommodate situations in
which the DS code space at the receiver is different from that
of the sender and the receiver has no way of knowing how to
translate from the sender's space. There is a danger in
copying this value from the outer header to the inner header,
since it enables an attacker to modify the outer DSCP value in
a fashion that may adversely affect other traffic at the
receiver. Hence the default behavior for IPsec
implementations is NOT to permit such copying.
(9) 実装は、外側のヘッダーから内側のヘッダーまでDS値を通過するために施設を提供するのを選ぶかもしれません、aで-、容認されたトンネルモードパケットのSA基礎。 この特徴を提供することに関する動機は受信機のDSコードスペースが送付者のものと異なっていて、受信機が送付者のスペースから翻訳する方法を知る方法を全く持っていない状況を収容することです。 外側のヘッダーから内側のヘッダーまでこの値をコピーするのにおいて危険があります、攻撃者が受信機で他のトラフィックに悪影響を与えるかもしれないファッションで外側のDSCP値を変更するのを可能にするので。したがって、コピーをそのようなものに可能にするために、IPsec実装のためのデフォルトの振舞いはありません。
5.2. Processing Inbound IP Traffic (unprotected-to-protected)
5.2. 本国行きのIPトラフィックを処理します。(保護されるのに保護のない)です。
Inbound processing is somewhat different from outbound processing, because of the use of SPIs to map IPsec-protected traffic to SAs. The inbound SPD cache (SPD-I) is applied only to bypassed or
本国行きの処理はいくらかIPsecによって保護されたトラフィックを写像するSPIsの使用による外国行きの処理からSAsまで異なっています。 または本国行きのSPDキャッシュ(SPD-I)が迂回するだけに適用される。
Kent & Seo Standards Track [Page 59] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[59ページ]。
discarded traffic. If an arriving packet appears to be an IPsec fragment from an unprotected interface, reassembly is performed prior to IPsec processing. The intent for any SPD cache is that a packet that fails to match any entry is then referred to the corresponding SPD. Every SPD SHOULD have a nominal, final entry that catches anything that is otherwise unmatched, and discards it. This ensures that non-IPsec-protected traffic that arrives and does not match any SPD-I entry will be discarded.
捨てられたトラフィック。 到着パケットが保護のないインタフェースからのIPsec断片であるように見えるなら、再アセンブリはIPsec処理の前に実行されます。 どんなSPDキャッシュに関する意図も次に、少しのエントリーにも合っていないパケットは対応するSPDを参照されるということです。 あらゆるSPD SHOULDには、そうでなければ優れたものは何でも捕らえて、それを捨てるノミナルで、最終的なエントリーがあります。 これは、到着して、少しのSPD-Iエントリーにも合っていない非IPsecが保護しているトラフィックが捨てられるのを確実にします。
Unprotected Interface
|
V
+-----+ IPsec protected
------------------->|Demux|-------------------+
| +-----+ |
| | |
| Not IPsec | |
| | |
| V |
| +-------+ +---------+ |
| |DISCARD|<---|SPD-I (*)| |
| +-------+ +---------+ |
| | |
| |-----+ |
| | | |
| | V |
| | +------+ |
| | | ICMP | |
| | +------+ |
| | V
+---------+ | +-----------+
....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
+---------+ | | (AH/ESP) | Boundary
^ | +-----------+
| | +---+ |
| BYPASS | +-->|IKE| |
| | | +---+ |
| V | V
| +----------+ +---------+ +----+
|--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
nested SAs +----------+ | (***) | +----+
| +---------+
V
Protected Interface
保護のないインタフェース| +に対して-----+ IPsecは保護しました。------------------->|Demux|-------------------+ | +-----+ | | | | | IPsecでない| | | | | | V| | +-------+ +---------+ | | |破棄| <、-、--、|SPD-I(*)| | | +-------+ +---------+ | | | | | |-----+ | | | | | | | V| | | +------+ | | | | ICMP| | | | +------+ | | | +に対して---------+ | +-----------+ ....|SPD-O(*)|............|...................|(**)を処理してください。|...IPsec+---------+ | | (ああ、/、超能力) | 境界^| +-----------+ | | +---+ | | 迂回| +-->|イケ| | | | | +---+ | | V| V| +----------+ +---------+ +----+ |、-、-、-、-、-、-、--、<、-、-、-、-、--、|推進| <、-、-、-、-、-、-、-、--、|悲しいチェック| -->、|ICMP| 入れ子にされたSAs+----------+ | (***) | +----+ | +---------+ V保護されたインタフェース
Figure 3. Processing Model for Inbound Traffic
図3。 インバウンドトラフィックのための処理モデル
Kent & Seo Standards Track [Page 60] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[60ページ]。
(*) = The caches are shown here. If there is
a cache miss, then the SPD is checked.
There is no requirement that an
implementation buffer the packet if
there is a cache miss.
(**) = This processing includes using the
packet's SPI, etc., to look up the SA
in the SAD, which forms a cache of the
SPD for inbound packets (except for
cases noted in Sections 4.4.2 and 5).
See step 3a below.
(***) = This SAD check refers to step 4 below.
(*) = キャッシュはここに示されます。 キャッシュミスがあれば、SPDはチェックされます。 キャッシュミスがあれば実装がパケットをバッファリングするという要件が全くありません。 (**) = この処理は、本国行きのパケット(セクション4.4.2と5で注意したケースを除いた)のためにSPDのキャッシュを形成するSADでSAを見上げるのにパケットのSPIなどを使用するのを含んでいます。 以下のステップ3aを見てください。 (***) = このSADチェックは下でのステップ4を示します。
Prior to performing AH or ESP processing, any IP fragments that arrive via the unprotected interface are reassembled (by IP). 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 a next layer protocol in the IPv6 context).
AHか超能力処理を実行する前に、保護のないインタフェースを通して届くどんなIP断片も組み立て直されます(IP)。 IPsec処理が適用されるそれぞれの本国行きのIPデータグラムはIP Nextプロトコル分野(またはIPv6文脈の次の層のプロトコルとしてのAHか超能力について)のAHか超能力値の外観で特定されます。
IPsec MUST perform the following steps:
IPsecは以下のステップを実行しなければなりません:
1. When a packet arrives, it may be tagged with the ID of the
interface (physical or virtual) via which it arrived, if
necessary, to support multiple SPDs and associated SPD-I caches.
(The interface ID is mapped to a corresponding SPD-ID.)
1. パケットが到着するとき、それはを通した必要なら、それが複数のSPDsと関連SPD-Iがキャッシュであるとサポートするために到着したインタフェース(物理的であるか仮想の)のIDと共にタグ付けをされるかもしれません。 (インタフェースIDは対応するSPD-IDに写像されます。)
2. The packet is examined and demuxed into one of two categories:
- If the packet appears to be IPsec protected and it is addressed
to this device, an attempt is made to map it to an active SA
via the SAD. Note that the device may have multiple IP
addresses that may be used in the SAD lookup, e.g., in the case
of protocols such as SCTP.
- Traffic not addressed to this device, or addressed to this
device and not AH or ESP, is directed to SPD-I lookup. (This
implies that IKE traffic MUST have an explicit BYPASS entry in
the SPD.) If multiple SPDs are employed, the tag assigned to
the packet in step 1 is used to select the appropriate SPD-I
(and cache) to search. SPD-I lookup determines whether the
action is DISCARD or BYPASS.
2. パケットは、2つのカテゴリの1つに調べられて、demuxedされます: - パケットが保護されたIPsecであるように見えて、このデバイスにそれを扱うなら、SADを通してアクティブなSAにそれを写像するのを試みをします。 デバイスにはSADルックアップ、例えば、SCTPなどのプロトコルの場合に使用されるかもしれない複数のIPアドレスがあるかもしれないことに注意してください。 - このデバイスに扱われないか、またはAHではなく、このデバイスに扱われなかったトラフィックか超能力がSPD-Iルックアップに向けられます。 (これは、IKEトラフィックがSPDに明白なBYPASSエントリーを持たなければならないのを含意します。) 複数のSPDsが採用しているなら、適切なSPD-私(そして、キャッシュ)が捜すのを選択するのにおいてステップ1におけるパケットに割り当てられたタグは使用されています。 SPD-Iルックアップは、動作がDISCARDかそれともBYPASSであるかを決定します。
3a. If the packet is addressed to the IPsec device and AH or ESP is
specified as the protocol, the packet is looked up in the SAD.
For unicast traffic, use only the SPI (or SPI plus protocol).
For multicast traffic, use the SPI plus the destination or SPI
plus destination and source addresses, as specified in Section
4.1. In either case (unicast or multicast), if there is no match,
discard the traffic. This is an auditable event. The audit log
3a。 パケットがIPsecデバイスに扱われて、AHか超能力がプロトコルとして指定されるなら、パケットはSADで調べられます。 ユニキャストトラフィックには、SPIだけを使用してください(SPIはそのうえ、議定書を作ります)。 マルチキャストトラフィックには、SPIと目的地かSPIと、目的地とソースアドレスを使用してください、セクション4.1で指定されるように。 どちらの場合(ユニキャストかマルチキャスト)ではも、マッチが全くなければ、トラフィックを捨ててください。 これは監査可能イベントです。 監査ログ
Kent & Seo Standards Track [Page 61] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[61ページ]。
entry for this event SHOULD include the current date/time, SPI,
source and destination of the packet, IPsec protocol, and any
other selector values of the packet that are available. If the
packet is found in the SAD, process it accordingly (see step 4).
このイベントSHOULDのためのエントリーはパケット、IPsecプロトコル、およびパケットのいかなる他の利用可能なセレクタ値の現在の日付/時間、SPI、ソース、および目的地も含んでいます。 パケットがSADで見つけられるなら、それに従って、それを処理してください(ステップ4を見てください)。
3b. If the packet is not addressed to the device or is addressed to
this device and is not AH or ESP, look up the packet header in
the (appropriate) SPD-I cache. If there is a match and the
packet is to be discarded or bypassed, do so. If there is no
cache match, look up the packet in the corresponding SPD-I and
create a cache entry as appropriate. (No SAs are created in
response to receipt of a packet that requires IPsec protection;
only BYPASS or DISCARD cache entries can be created this way.) If
there is no match, discard the traffic. This is an auditable
event. The audit log entry for this event SHOULD include the
current date/time, SPI if available, IPsec protocol if available,
source and destination of the packet, and any other selector
values of the packet that are available.
3b。 パケットがデバイスに扱われないか、このデバイスに扱われて、AHでなくて、またまたは超能力でもないなら、(適切)のSPD-Iキャッシュでパケットのヘッダーを訪ねてください。 マッチがあって、パケットが捨てられるつもりであるか、または迂回するつもりであるなら、そうしてください。 キャッシュマッチが全くなければ、対応するSPD-Iでパケットを見上げてください、そして、適宜キャッシュエントリーを作成してください。 (SAsは全くIPsec保護を必要とするパケットの領収書に対応して作成されません; このようにBYPASSかDISCARDキャッシュエントリーしか作成できません。) マッチが全くなければ、トラフィックを捨ててください。 これは監査可能イベントです。 このイベントSHOULDのための監査ログエントリーが現在の日付/時間を含んでいて、SPIがパケットの利用可能であることで、利用可能であるならIPsecが議定書を作るか、そして、ソースと目的地であり、いかなる他のセレクタもパケットの利用可能な値です。
3c. Processing of ICMP messages is assumed to take place on the
unprotected side of the IPsec boundary. Unprotected ICMP
messages are examined and local policy is applied to determine
whether to accept or reject these messages and, if accepted, what
action to take as a result. For example, if an ICMP unreachable
message is received, the implementation must decide whether to
act on it, reject it, or act on it with constraints. (See Section
6.)
3c。 ICMPメッセージの処理がIPsec境界保護のない側で行われると思われます。 保護のないICMPメッセージは調べられます、そして、ローカルの方針は、これらのメッセージを受け入れるか、または拒絶して、その結果どんな行動を受け入れるなら取ったらよいかを決定するために適用されます。 例えば、ICMPの手の届かないメッセージが受信されているなら、実装は、規制でそれに影響するかどうか決めなければならないか、それを拒絶しなければならないか、またはそれに影響しなければなりません。 (セクション6を見てください。)
4. Apply AH or ESP processing as specified, using the SAD entry
selected in step 3a above. Then match the packet against the
inbound selectors identified by the SAD entry to verify that the
received packet is appropriate for the SA via which it was
received.
4. 上のステップ3aで選択されたSADエントリーを使用して、指定されるとしてAHか超能力処理を適用してください。 そして、SAに、容認されたパケットが適切であることを確かめるためにSADエントリーで特定された本国行きのセレクタに対してパケットを合わせてください。
5. If an IPsec system receives an inbound packet on an SA and the
packet's header fields are not consistent with the selectors for
the SA, it MUST discard the packet. This is an auditable event.
The audit log entry for this event SHOULD include the current
date/time, SPI, IPsec protocol(s), source and destination of the
packet, any other selector values of the packet that are
available, and the selector values from the relevant SAD entry.
The system SHOULD also be capable of generating and sending an
IKE notification of INVALID_SELECTORS to the sender (IPsec peer),
indicating that the received packet was discarded because of
failure to pass selector checks.
5. IPsecシステムがSAで本国行きのパケットを受けて、SAにおいて、パケットのヘッダーフィールドがセレクタと一致していないなら、それはパケットを捨てなければなりません。 これは監査可能イベントです。 このイベントSHOULDのための監査ログエントリーはパケット、パケットのいかなる他の利用可能なセレクタ値、および関連SADエントリーからのセレクタ値の現在の日付/時間、SPI、IPsecプロトコル、ソース、および目的地も含んでいます。 容認されたパケットが失敗のためにセレクタチェックを通過するために捨てられたまた、INVALID_SELECTORSのIKE通知を送付者(IPsecはじっと見る)に生成して、送ることができて、示しているシステムSHOULD。
Kent & Seo Standards Track [Page 62] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[62ページ]。
To minimize the impact of a DoS attack, or a mis-configured peer, the IPsec system SHOULD include a management control to allow an administrator to configure the IPsec implementation to send or not send this IKE notification, and if this facility is selected, to rate limit the transmission of such notifications.
DoS攻撃の影響、または誤構成された同輩を最小にするなら、IPsecシステムSHOULDは管理者が発信するか、またはこのIKE通知を送らないようにIPsec実装を構成するのを許容するためにマネジメント・コントロールを含んでいます、そして、この施設が選択されるなら、評価するのはそのような通知の伝達を制限します。
After traffic is bypassed or processed through IPsec, it is handed to the inbound forwarding function for disposition. This function may cause the packet to be sent (outbound) across the IPsec boundary for additional inbound IPsec processing, e.g., in support of nested SAs. If so, then as with ALL outbound traffic that is to be bypassed, the packet MUST be matched against an SPD-O entry. Ultimately, the packet should be forwarded to the destination host or process for disposition.
トラフィックがIPsecを通して迂回するか、または処理された後に、それは気質のために本国行きの推進機能に手渡されます。 追加本国行きのIPsec処理のためにIPsec境界の向こう側にこの機能でパケットを送るかもしれません(外国行きの)、例えば、入れ子にされたSAsを支持して。 そうだとすれば、それはそして、すべてのアウトバウンドトラフィックのように迂回することになっていて、パケットはSPD-Oエントリーに取り組ませなければなりません。 結局、気質のためにあて先ホストかプロセスにパケットを送るべきです。
6. ICMP Processing
6. ICMP処理
This section describes IPsec handling of ICMP traffic. There are two categories of ICMP traffic: error messages (e.g., type = destination unreachable) and non-error messages (e.g., type = echo). This section applies exclusively to error messages. Disposition of non-error, ICMP messages (that are not addressed to the IPsec implementation itself) MUST be explicitly accounted for using SPD entries.
このセクションはICMPトラフィックのIPsec取り扱いについて説明します。 ICMPトラフィックの2つのカテゴリがあります: エラーメッセージ、(例えば、タイプ=目的地手の届かない、)、そして、非エラーメッセージ(例えば、タイプ=は反響します)。 このセクションは排他的にエラーメッセージに適用されます。 非誤りの気質、SPDエントリーを使用して、明らかに、ICMPメッセージ(それはIPsec実装自体に扱われない)を説明しなければなりません。
The discussion in this section applies to ICMPv6 as well as to ICMPv4. Also, a mechanism SHOULD be provided to allow an administrator to cause ICMP error messages (selected, all, or none) to be logged as an aid to problem diagnosis.
このセクションでの議論はICMPv4に関してまた、ICMPv6に適用されます。 メカニズムSHOULD、も提供して、管理者が問題診断への援助としてICMPエラーメッセージ(すべて、またはなにもに選択される)を登録させるのを許容してください。
6.1. Processing ICMP Error Messages Directed to an IPsec Implementation
6.1. IPsec実装に向けられた処理ICMPエラーメッセージ
6.1.1. ICMP Error Messages Received on the Unprotected Side of the
Boundary
6.1.1. 境界保護のない側に受け取られたICMPエラーメッセージ
Figure 3 in Section 5.2 shows a distinct ICMP processing module on the unprotected side of the IPsec boundary, for processing ICMP messages (error or otherwise) that are addressed to the IPsec device and that are not protected via AH or ESP. An ICMP message of this sort is unauthenticated, and its processing may result in denial or degradation of service. This suggests that, in general, it would be desirable to ignore such messages. However, many ICMP messages will be received by hosts or security gateways from unauthenticated sources, e.g., routers in the public Internet. Ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTU message and redirection messages. Thus, there is also a motivation for accepting and acting upon unauthenticated ICMP messages.
セクション5.2の図3はIPsec境界保護のない側に異なったICMP処理モジュールを示しています、IPsecデバイスに扱われて、AHか超能力を通して保護されない処理ICMPメッセージ(誤りの、または、そうでない)のために。 この種類に関するICMPメッセージは非認証されます、そして、処理はサービスの否定か退行をもたらすかもしれません。 これは、一般に、そのようなメッセージを無視するのが望ましいと示唆します。 しかしながら、ホストかセキュリティゲートウェイは非認証されたソース(例えば、公共のインターネットのルータ)から多くのICMPメッセージを受け取るでしょう。 これらのICMPメッセージを無視するのは例えば、PMTUメッセージとリダイレクションメッセージを処理しないことのためにサービスを下がらせることができます。 したがって、また、unauthenticated ICMPメッセージを受け入れて、作用することに関する動機があります。
Kent & Seo Standards Track [Page 63] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[63ページ]。
To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size.
このスペクトルの両端を収容するために、対応するIPsec実装は、地元の管理者がunauthenticated ICMPトラフィックを受け入れるか、または拒絶するためにIPsec実装を構成することを許可しなければなりません。 このコントロールは、ICMPタイプの粒状にあるに違いなくて、ICMPタイプとコードの粒状にあるかもしれません。 さらに、実装SHOULDはそのようなトラフィックに対処するためのメカニズムとパラメタを組み込みます。 例えば、unauthenticated ICMPの領収書が些細なサイズにPMTUを設定するのを防ぐために、トラフィック(目的地基礎あたりのaの)のために最小のPMTUを設立する能力があるかもしれません。
If an ICMP PMTU message passes the checks above and the system is configured to accept it, then there are two possibilities. If the implementation applies fragmentation on the ciphertext side of the boundary, then the accepted PMTU information is passed to the forwarding module (outside of the IPsec implementation), which uses it to manage outbound packet fragmentation. If the implementation is configured to effect plaintext side fragmentation, then the PMTU information is passed to the plaintext side and processed as described in Section 8.2.
ICMP PMTUメッセージが上のチェックを通過して、システムがそれを受け入れるために構成されるなら、2つの可能性があります。 実装が境界の暗号文側で断片化を適用するなら、受け入れられたPMTU情報は推進モジュール(IPsec実装の外部)に通過されます。(それは、外国行きのパケット断片化を管理するのにそれを使用します)。 実装が効果平文サイド断片化に構成されるなら、PMTU情報は、セクション8.2で説明されるように平文側に向かって、処理されます。
6.1.2. ICMP Error Messages Received on the Protected Side of the
Boundary
6.1.2. 境界保護側に受け取られたICMPエラーメッセージ
These ICMP messages are not authenticated, but they do come from sources on the protected side of the IPsec boundary. Thus, these messages generally are viewed as more "trustworthy" than their counterparts arriving from sources on the unprotected side of the boundary. The major security concern here is that a compromised host or router might emit erroneous ICMP error messages that could degrade service for other devices "behind" the security gateway, or that could even result in violations of confidentiality. For example, if a bogus ICMP redirect were consumed by a security gateway, it could cause the forwarding table on the protected side of the boundary to be modified so as to deliver traffic to an inappropriate destination "behind" the gateway. Thus, implementers MUST provide controls to allow local administrators to constrain the processing of ICMP error messages received on the protected side of the boundary, and directed to the IPsec implementation. These controls are of the same type as those employed on the unprotected side, described above in Section 6.1.1.
これらのICMPメッセージは認証されませんが、それらはIPsec境界保護側の上のソースから来ます。 したがって、一般に、これらのメッセージは境界保護のない側の上のソースから到着する彼らの対応者より「信頼できる」と見なされます。 ここの主要なセキュリティ関心は感染されたホストかルータが下がることができた誤ったICMPエラーメッセージを放つかもしれないのが対向機器“behind"のためにセキュリティゲートウェイを調整するか、またはそれが秘密性の違反をもたらしさえするかもしれないということです。 例えば、aにせのICMP再直接のは、セキュリティゲートウェイによって消費されています、不適当な目的地“behind"へのゲートウェイをトラフィックに提供するようにそれで境界保護側の上の推進テーブルを変更できたということでした。 したがって、implementersは、地元の管理者が境界保護側に受け取られて、IPsec実装に向けられたICMPエラーメッセージの処理を抑制するのを許容するためにコントロールを提供しなければなりません。 上でセクション6.1.1で説明された保護のない側で使われたものと同じタイプにはこれらのコントロールがあります。
6.2. Processing Protected, Transit ICMP Error Messages
6.2. 保護された処理、トランジットICMPエラーメッセージ
When an ICMP error message is transmitted via an SA to a device "behind" an IPsec implementation, both the payload and the header of the ICMP message require checking from an access control perspective. If one of these messages is forwarded to a host behind a security
ICMPエラーメッセージがIPsec実装、両方のペイロード、およびICMPメッセージのヘッダーがアクセス制御見解からチェックするのを必要とするデバイス“behind"へのSAを通して伝えられるとき。 セキュリティの後ろでこれらのメッセージの1つをホストに送るなら
Kent & Seo Standards Track [Page 64] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[64ページ]。
gateway, the receiving host IP implementation will make decisions based on the payload, i.e., the header of the packet that purportedly triggered the error response. Thus, an IPsec implementation MUST be configurable to check that this payload header information is consistent with the SA via which it arrives. (This means that the payload header, with source and destination address and port fields reversed, matches the traffic selectors for the SA.) If this sort of check is not performed, then, for example, anyone with whom the receiving IPsec system (A) has an active SA could send an ICMP Destination Unreachable message that refers to any host/net with which A is currently communicating, and thus effect a highly efficient DoS attack regarding communication with other peers of A. Normal IPsec receiver processing of traffic is not sufficient to protect against such attacks. However, not all contexts may require such checks, so it is also necessary to allow a local administrator to configure an implementation to NOT perform such checks.
ゲートウェイ、受信ホストIP実装はペイロード(すなわち、表面上誤り応答の引き金となったパケットのヘッダー)に基づく決定をするでしょう。 したがって、このペイロードヘッダー情報がを通したそれが到着するSAと一致しているのをチェックするのにおいてIPsec実装は構成可能であるに違いありません。 (これは、ペイロードヘッダーが逆にされるソース、送付先アドレス、およびポート分野にSAのためのトラフィックセレクタを合わせることを意味します。) 次に、例えば、この種類のチェックが実行されないなら、受信IPsecシステム(A)にはアクティブなSAがあるだれでもAが現在交信しているどんなホスト/ネットも示すICMP Destination Unreachableメッセージを送るかもしれません、そして、その結果、高能率的なDoSがトラフィックのA.Normal IPsec受信機処理の他の同輩とのコミュニケーションに関して攻撃する効果は、そのような攻撃から守るために十分ではありません。 しかしながら、すべての文脈がそのようなチェックを必要とするかもしれないというわけではないので、したがって、また、地元の管理者がそのようなチェックを実行しないように実装を構成するのを許容するのも必要です。
To accommodate both policies, the following convention is adopted. If an administrator wants to allow ICMP error messages to be carried by an SA without inspection of the payload, then configure an SPD entry that explicitly allows for carriage of such traffic. If an administrator wants IPsec to check the payload of ICMP error messages for consistency, then do not create any SPD entries that accommodate carriage of such traffic based on the ICMP packet header. This convention motivates the following processing description.
両方の方針に対応するために、以下のコンベンションは採用されます。 管理者が、ICMPエラーメッセージがペイロードの点検なしでSAによって運ばれるのを許したいなら、明らかにそのようなトラフィックのキャリッジを考慮するSPDエントリーを構成してください。 管理者が、IPsecに一貫性がないかどうかICMPエラーメッセージのペイロードをチェックして欲しいなら、ICMPパケットのヘッダーに基づくそのようなトラフィックのキャリッジを収容する少しのSPDエントリーも作成しないでください。 このコンベンションは以下の処理記述を動機づけます。
IPsec senders and receivers MUST support the following processing for ICMP error messages that are sent and received via SAs.
IPsec送付者と受信機はSAsを通して送られて、受け取られるICMPエラーメッセージのための以下の処理をサポートしなければなりません。
If an SA exists that accommodates an outbound ICMP error message, then the message is mapped to the SA and only the IP and ICMP headers are checked upon receipt, just as would be the case for other traffic. If no SA exists that matches the traffic selectors associated with an ICMP error message, then the SPD is searched to determine if such an SA can be created. If so, the SA is created and the ICMP error message is transmitted via that SA. Upon receipt, this message is subject to the usual traffic selector checks at the receiver. This processing is exactly what would happen for traffic in general, and thus does not represent any special processing for ICMP error messages.
外国行きのICMPエラーメッセージに対応するSAが存在しているなら、メッセージはSAとIPだけに写像されます、そして、ICMPヘッダーは領収書でチェックされます、ちょうど他のトラフィックのためにそうであるように。 ICMPエラーメッセージに関連しているトラフィックセレクタに合っているどんなSAも存在していないなら、SPDは、そのようなSAを作成できるかどうか決定するために捜されます。 そうだとすれば、SAは作成されます、そして、ICMPエラーメッセージはそのSAを通して伝えられます。 領収書では、このメッセージは受信機での普通のトラフィックセレクタチェックを受けることがあります。この処理はまさに一般に、トラフィックのために起こって、その結果ICMPエラーメッセージのために少しの特別な処理も表さないことです。
If no SA exists that would carry the outbound ICMP message in question, and if no SPD entry would allow carriage of this outbound ICMP error message, then an IPsec implementation MUST map the message to the SA that would carry the return traffic associated with the packet that triggered the ICMP error message. This requires an IPsec implementation to detect outbound ICMP error messages that map to no extant SA or SPD entry, and treat them specially with regard to SA
問題の外国行きのICMPメッセージを伝えるどんなSAも存在していなくて、またどんなSPDエントリーもこの外国行きのICMPエラーメッセージのキャリッジを許容しないなら、IPsec実装はICMPエラーメッセージの引き金となったパケットに関連しているリターントラフィックを運ぶSAにメッセージを写像しなければなりません。 これは、SAかSPDエントリーを実在に写像しない外国行きのICMPエラーメッセージを検出して、特に、SAに関してそれらを扱うためにIPsec実装を必要とします。
Kent & Seo Standards Track [Page 65] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[65ページ]。
creation and lookup. The implementation extracts the header for the packet that triggered the error (from the ICMP message payload), reverses the source and destination IP address fields, extracts the protocol field, and reverses the port fields (if accessible). It then uses this extracted information to locate an appropriate, active outbound SA, and transmits the error message via this SA. If no such SA exists, no SA will be created, and this is an auditable event.
作成とルックアップ。 実装は、誤り(ICMPメッセージペイロードからの)の引き金となったパケットのためにヘッダーを抽出して、ソースと目的地IPアドレス・フィールドを逆にして、プロトコル野原を抽出して、ポート分野を逆にします(アクセスしやすいなら)。 それは、次に、適切で、アクティブな外国行きのSAの場所を見つけるのにこの抽出された情報を使用して、このSAを通してエラーメッセージを伝えます。 どれかそのようなSAが存在していないと、SAは全く作成されないでしょう、そして、これは監査可能イベントです。
If an IPsec implementation receives an inbound ICMP error message on an SA, and the IP and ICMP headers of the message do not match the traffic selectors for the SA, the receiver MUST process the received message in a special fashion. Specifically, the receiver must extract the header of the triggering packet from the ICMP payload, and reverse fields as described above to determine if the packet is consistent with the selectors for the SA via which the ICMP error message was received. If the packet fails this check, the IPsec implementation MUST NOT forwarded the ICMP message to the destination. This is an auditable event.
IPsec実装がSAに関する本国行きのICMPエラーメッセージを受け取って、メッセージのIPとICMPヘッダーがSAのためのトラフィックセレクタに合っていないなら、受信機は特別なファッションによる受信されたメッセージを処理しなければなりません。 明確に、受信機は、SAにおいて、パケットがセレクタと一致しているかどうか決定するために上で説明されるようにICMPペイロードから引き金となるパケットのヘッダーを抽出して、分野を逆にしなければなりません。 パケットがこのチェックに失敗するなら、ICMPメッセージが目的地に転送されないで、IPsec実装は失敗しなければなりません。 これは監査可能イベントです。
7. Handling Fragments (on the protected side of the IPsec boundary)
7. 取り扱い断片(IPsec境界保護側の)
Earlier sections of this document describe mechanisms for (a) fragmenting an outbound packet after IPsec processing has been applied and reassembling it at the receiver before IPsec processing and (b) handling inbound fragments received from the unprotected side of the IPsec boundary. This section describes how an implementation should handle the processing of outbound plaintext fragments on the protected side of the IPsec boundary. (See Appendix D, "Fragment Handling Rationale".) In particular, it addresses:
このドキュメントの以前のセクションは、(a)のためにIPsec処理と本国行きの断片を扱う(b)がIPsec境界保護のない側から受信される前に、IPsec処理が適用された後に外国行きのパケットを断片化して、受信機でそれを組み立て直しながら、メカニズムについて説明します。 このセクションは実装がどうIPsec境界保護側における外国行きの平文断片の処理を扱うべきであるかを説明します。 (付録D、「断片取り扱い原理」を見てください。) 特に、それは以下を扱います。
o mapping an outbound non-initial fragment to the right SA
(or finding the right SPD entry)
o verifying that a received non-initial fragment is
authorized for the SA via which it was received
o mapping outbound and inbound non-initial fragments to the
right SPD-O/SPD-I entry or the relevant cache entry, for
BYPASS/DISCARD traffic
o BYPASS/DISCARDトラフィックのために容認された非初期の断片がを通した○ 正しいSPD-O/SPD-Iエントリーか関連キャッシュエントリーに外国行きの、そして、本国行きの非初期の断片を写像しながらそれを受け取ったSAのために認可されることを確かめながら、右のSA(正しいSPDエントリーを見つけて)oに外国行きの非初期の断片を写像します。
Note: In Section 4.1, transport mode SAs have been defined to not carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two special values, ANY and OPAQUE, were defined for selectors and that ANY includes OPAQUE. The term "non-trivial" is used to mean that the selector has a value other than OPAQUE or ANY.
以下に注意してください。 セクション4.1では、交通機関SAsは、断片(IPv4かIPv6)を運ばないように定義されました。 また、セクション4.4では、.1、2つの特別な値(いずれとOPAQUE)がセレクタのために定義されて、いずれもOPAQUEを含んでいることに注意してください。 「重要である」という用語は、セレクタにはOPAQUEかいずれを除いた値があることを意味するのに使用されます。
Note: The term "non-initial fragment" is used here to indicate a fragment that does not contain all the selector values that may be needed for access control. As observed in Section 4.4.1, depending on the Next Layer Protocol, in addition to Ports, the ICMP message
以下に注意してください。 「非初期の断片」という用語は、アクセスコントロールに必要であるかもしれないすべてのセレクタ値を含まない断片を示すのにここで使用されます。 セクション4.4.1で見て、Ports、ICMPメッセージに加えてNext Layerプロトコルによるとして
Kent & Seo Standards Track [Page 66] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[66ページ]。
type/code or Mobility Header type could be missing from non-initial fragments. Also, for IPv6, even the first fragment might NOT contain the Next Layer Protocol or Ports (or ICMP message type/code, or Mobility Header type) depending on the kind and number of extension headers present. If a non-initial fragment contains the Port (or ICMP type and code or Mobility Header type) but not the Next Layer Protocol, then unless there is an SPD entry for the relevant Local/Remote addresses with ANY for Next Layer Protocol and Port (or ICMP type and code or Mobility Header type), the fragment would not contain all the selector information needed for access control.
タイプ/コードかMobility Headerタイプが非初期の断片から行方不明であるかもしれません。 また、IPv6に関して、ヘッダーが提示する拡大の種類と数によって、最初の断片さえNext LayerプロトコルかPorts(または、ICMPメッセージタイプ/コード、またはMobility Headerタイプ)を含まないかもしれません。 非初期の断片がNext Layerプロトコルではなく、Port(ICMPはタイプして、コードかMobility Headerがタイプする)を含んでいて、Next LayerプロトコルとPortのためのいずれかがある関連Local/リモートなアドレスのためのSPDエントリーがない場合(ICMPはタイプして、コードかMobility Headerがタイプします)、断片はアクセスコントロールに必要であるすべてのセレクタ情報を含んでいないでしょう。
To address the above issues, three approaches have been defined:
上記の問題を扱うために、3つのアプローチが定義されました:
o Tunnel mode SAs that carry initial and non-initial fragments
(See Section 7.1.)
o Separate tunnel mode SAs for non-initial fragments (See
Section 7.2.)
o Stateful fragment checking (See Section 7.3.)
o o SeparateがモードSAsに非初期でトンネルを堀る初期の、そして、非初期の断片(セクション7.1を見る)を運ぶトンネルモードSAsがo Stateful断片の照合を断片化します(セクション7.2を見ます)。(セクション7.3を見てください。)
7.1. Tunnel Mode SAs that Carry Initial and Non-Initial Fragments
7.1. トンネル・モードのSAsのそのCarry Initialの、そして、Non初期のFragments
All implementations MUST support tunnel mode SAs that are configured to pass traffic without regard to port field (or ICMP type/code or Mobility Header type) values. If the SA will carry traffic for specified protocols, the selector set for the SA MUST specify the port fields (or ICMP type/code or Mobility Header type) as ANY. An SA defined in this fashion will carry all traffic including initial and non-initial fragments for the indicated Local/Remote addresses and specified Next Layer protocol(s). If the SA will carry traffic without regard to a specific protocol value (i.e., ANY is specified as the (Next Layer) protocol selector value), then the port field values are undefined and MUST be set to ANY as well. (As noted in 4.4.1, ANY includes OPAQUE as well as all specific values.)
すべての実装が、トンネルモードが分野(ICMPタイプ/コードかMobility Headerがタイプする)値を移植するために関係なしでトラフィックを通過するために構成されるSAsであるとサポートしなければなりません。 SAがトラフィックを運ぶなら、指定されたプロトコル、SA MUSTに設定されたセレクタにいずれとしてもポート分野(ICMPタイプ/コードかMobility Headerがタイプする)を指定してください。 こんなやり方で定義されたSAは示されたLocal/リモートなアドレスと指定されたNext Layerプロトコルのために初期の、そして、非初期の断片を含むすべてのトラフィックを運ぶでしょう。 SAが関係なしで特定のプロトコル値(すなわち、何でも(次のLayer)プロトコルセレクタ価値として指定される)までトラフィックを運ぶなら、ポート分野値を未定義であり、また、いずれにも設定しなければなりません。 (4.4で.1に注意するので、いずれもすべての特定の値と同様にOPAQUEを含んでいます。)
7.2. Separate Tunnel Mode SAs for Non-Initial Fragments
7.2. 非初期の断片のための別々のトンネル・モードSAs
An implementation MAY support tunnel mode SAs that will carry only non-initial fragments, separate from non-fragmented packets and initial fragments. The OPAQUE value will be used to specify port (or ICMP type/code or Mobility Header type) field selectors for an SA to carry such fragments. Receivers MUST perform a minimum offset check on IPv4 (non-initial) fragments to protect against overlapping fragment attacks when SAs of this type are employed. Because such checks cannot be performed on IPv6 non-initial fragments, users and administrators are advised that carriage of such fragments may be dangerous, and implementers may choose to NOT support such SAs for IPv6 traffic. Also, an SA of this sort will carry all non-initial fragments that match a specified Local/Remote address pair and
実装は、非初期であるだけであることで運ぶトンネルモードSAsに断片を支えて、非断片化しているパケットから分離して、断片に頭文字をつけるかもしれません。 OPAQUE値は、SAがそのような断片を運ぶようにポート(ICMPタイプ/コードかMobility Headerがタイプする)分野セレクタを指定するのに使用されるでしょう。 受信機はこのタイプのSAsが採用しているとき断片攻撃を重ね合わせる守るIPv4の(非初期)の断片に最小のオフセットチェックを実行しなければなりません。 IPv6の非初期の断片にそのようなチェックを実行できないので、ユーザと管理者はそのような断片の運搬が危険であるかもしれなく、implementersが、IPv6トラフィックのためにそのようなSAsをサポートしないのを選ぶかもしれないと忠告されます。 そしてまた、この種類のSAが指定されたLocal/リモートなアドレス組に合っているすべての非初期の断片を運ぶ。
Kent & Seo Standards Track [Page 67] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[67ページ]。
protocol value, i.e., the fragments carried on this SA belong to packets that if not fragmented, might have gone on separate SAs of differing security. Therefore, users and administrators are advised to protect such traffic using ESP (with integrity) and the "strongest" integrity and encryption algorithms in use between both peers. (Determination of the "strongest" algorithms requires imposing an ordering of the available algorithms, a local determination at the discretion of the initiator of the SA.)
プロトコル値、そんなにそうでなければ、すなわち、このSAで運ばれた断片はパケットに断片化されていた状態で属します、と異なったセキュリティの別々のSAsが続けたかもしれません。 したがって、ユーザと管理者が超能力(保全がある)、「最も強い」保全、および両方の同輩の間で使用中の暗号化アルゴリズムを使用することでそのようなトラフィックを保護するようにアドバイスされます。 (「最も強い」アルゴリズムの決断は、利用可能なアルゴリズム(SAの創始者の裁量における地方の決断)の注文を課すのを必要とします)
Specific port (or ICMP type/code or Mobility Header type) selector values will be used to define SAs to carry initial fragments and non-fragmented packets. This approach can be used if a user or administrator wants to create one or more tunnel mode SAs between the same Local/Remote addresses that discriminate based on port (or ICMP type/code or Mobility Header type) fields. These SAs MUST have non-trivial protocol selector values, otherwise approach #1 above MUST be used.
特定のポート(ICMPタイプ/コードかMobility Headerがタイプする)セレクタ値は、初期の断片と非断片化しているパケットを運ぶためにSAsを定義するのに使用されるでしょう。 ユーザか管理者がポート(ICMPタイプ/コードかMobility Headerがタイプする)分野に基づいて差別する同じLocal/リモートなアドレスの間で1つ以上のトンネルのモードSAsを作成したいなら、このアプローチを使用できます。 これらのSAsには、重要なプロトコルセレクタ値がなければなりません。さもなければ、上のアプローチ#1を使用しなければなりません。
Note: In general, for the approach described in this section, one needs only a single SA between two implementations to carry all non-initial fragments. However, if one chooses to have multiple SAs between the two implementations for QoS differentiation, then one might also want multiple SAs to carry fragments-without-ports, one for each supported QoS class. Since support for QoS via distinct SAs is a local matter, not mandated by this document, the choice to have multiple SAs to carry non-initial fragments should also be local.
以下に注意してください。 一般に、このセクションで説明されたアプローチのために、人は、2つの実装の間の独身のSAだけがすべての非初期の断片を運ぶ必要があります。 しかしながら、人が、QoS分化のための2つの実装の間に複数のSAsを持っているのを選ぶなら、また、人は、複数のSAsにポートのない断片(それぞれのサポートしているQoSのクラスあたり1つ)を運んで欲しいかもしれません。 異なったSAsを通したQoSのサポートがこのドキュメントによって強制されるのではなく、地域にかかわる事柄であるので、また、非初期の断片を運ぶ複数のSAsを持つ選択もローカルであるべきです。
7.3. Stateful Fragment Checking
7.3. Stateful断片の照合
An implementation MAY support some form of stateful fragment checking for a tunnel mode SA with non-trivial port (or ICMP type/code or MH type) field values (not ANY or OPAQUE). Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port (or ICMP type/code or MH type) selectors MUST notify a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.
或るものが形成する重要なポート(ICMPタイプ/コードかMHがタイプする)があるSAがさばくトンネルモードがないかどうかチェックするstateful断片の実装5月のサポートは(いずれでないOPAQUEでない)を評価します。 IKE NOTIFY NON_FIRST_FRAGMENTS_ALSOペイロードで重要なポート(ICMPタイプ/コードかMHがタイプする)セレクタを利用するトンネルモードSAで非初期の断片を伝える実装は同輩に通知しなければなりません。
The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA. This standard does not specify how peers will deal with such fragments, e.g., via reassembly or other means, at either sender or receiver. However, a receiver MUST discard non-initial fragments that arrive on an SA with non-trivial port (or ICMP type/code or MH type) selector values unless this feature has been negotiated. Also, the receiver MUST discard non-initial fragments that do not comply with the security policy applied to the overall packet. Discarding such packets is an auditable event. Note that in network configurations where fragments
このような関係においては非初期の断片を受け入れないなら、同輩はこの提案を拒絶しなければなりません。 実装がそのようなSAのために首尾よく非初期の断片のトランスミッションを交渉しないなら、それはそのような断片をSAの上に送ってはいけません。 この規格は同輩がどうそのような断片に対処するかを指定しません、再アセンブリか例えば、他の手段で、送付者か受信機のどちらかで。しかしながら、受信機はこの特徴が交渉されていない場合重要なポート(ICMPタイプ/コードかMHがタイプする)セレクタ値と共にSAで届く非初期の断片を捨てなければなりません。 また、受信機は総合的なパケットに適用される安全保障政策に応じない非初期の断片を捨てなければなりません。 そのようなパケットを捨てるのは、監査可能イベントです。 ネットワーク・コンフィギュレーションでは、どこが断片化するかに注意してください。
Kent & Seo Standards Track [Page 68] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[68ページ]。
of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail.
送るかもしれないか、または異なったセキュリティゲートウェイかBITW実装で受け取るパケットでは、追跡断片のためのstateful戦略は失敗するかもしれません。
7.4. BYPASS/DISCARD Traffic
7.4. トラフィックを迂回するか、または捨ててください。
All implementations MUST support DISCARDing of fragments using the normal SPD packet classification mechanisms. All implementations MUST support stateful fragment checking to accommodate BYPASS traffic for which a non-trivial port range is specified. The concern is that BYPASS of a cleartext, non-initial fragment arriving at an IPsec implementation could undermine the security afforded IPsec-protected traffic directed to the same destination. For example, consider an IPsec implementation configured with an SPD entry that calls for IPsec protection of traffic between a specific source/destination address pair, and for a specific protocol and destination port, e.g., TCP traffic on port 23 (Telnet). Assume that the implementation also allows BYPASS of traffic from the same source/destination address pair and protocol, but for a different destination port, e.g., port 119 (NNTP). An attacker could send a non-initial fragment (with a forged source address) that, if bypassed, could overlap with IPsec-protected traffic from the same source and thus violate the integrity of the IPsec-protected traffic. Requiring stateful fragment checking for BYPASS entries with non-trivial port ranges prevents attacks of this sort. As noted above, in network configurations where fragments of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail.
正常なSPDパケット分類メカニズムを使用して、すべての実装が断片のDISCARDingをサポートしなければなりません。すべての実装が重要なポート範囲が指定されるBYPASSトラフィックを収容するためにチェックするstateful断片を支えなければなりません。 関心はcleartext(IPsec実装に到着するのが同じ目的地に向けられたIPsecによって保護されたトラフィックが提供されたセキュリティを弱体化させることができた非初期の断片)のそのBYPASSです。 例えば、特定のソース/目的地アドレス組の間と、そして、特定のプロトコルようにトラフィックのIPsec保護を求めるSPDエントリーによって構成されたIPsec実装と仕向港(例えば、ポート23(telnet)に関するTCPトラフィック)を考えてください。 また、実装が同じソース/目的地アドレス組からトラフィックのBYPASSを許容すると仮定してください、そして、議定書を作ってくださいが、例えば、異なった仕向港に関して、119(NNTP)を移植してください。 攻撃者は、迂回するなら非初期の断片(偽造ソースアドレスがある)にそれを送るかもしれなくて、同じソースからのIPsecによって保護されたトラフィックに重なって、その結果、IPsecによって保護されたトラフィックの保全に違反できました。 BYPASSエントリーがないかどうか重要なポート範囲に問い合わせるstateful断片を必要とすると、この種類の攻撃は防がれます。 上で述べたように、ネットワーク・コンフィギュレーションでは、追跡断片のためのstateful戦略は異なったセキュリティゲートウェイかBITW実装でパケットの断片を送るか、または受け取るかもしれないところで失敗するかもしれません。
8. Path MTU/DF Processing
8. 経路MTU/DF処理
The application of AH or ESP to an outbound packet increases the size of a packet and thus may cause a packet to exceed the PMTU for the SA via which the packet will travel. An IPsec implementation also may receive an unprotected ICMP PMTU message and, if it chooses to act upon the message, the result will affect outbound traffic processing. This section describes the processing required of an IPsec implementation to deal with these two PMTU issues.
外国行きのパケットへのAHか超能力のアプリケーションで、パケットは、パケットのサイズを増強して、その結果、SAのためにを通ってパケットが移動するPMTUを超えるかもしれません。 IPsec実装も保護のないICMP PMTUメッセージを受け取るかもしれません、そして、メッセージに作用するのを選ぶと、結果はアウトバウンドトラフィック処理に影響するでしょう。 このセクションはこれらの2PMTU冊に対処するのにIPsec実装について必要である処理について説明します。
8.1. DF Bit
8.1. DFビット
All IPsec implementations MUST support the option of copying the DF bit from an outbound packet to the tunnel mode header that it emits, when traffic is carried via a tunnel mode SA. This means that it MUST be possible to configure the implementation's treatment of the DF bit (set, clear, copy from inner header) for each SA. This applies to SAs where both inner and outer headers are IPv4.
すべてのIPsec実装が外国行きのパケットからそれが放つトンネルモードヘッダーまでDFビットをコピーするオプションをサポートしなければなりません、トラフィックがトンネルモードSAを通して運ばれるとき。 これは、各SAのために実装のDFビット(はっきりと、内側のヘッダーからコピーを設定する)の処理を構成するのが可能であるに違いないことを意味します。 これは内側の、そして、外側の両方のヘッダーがIPv4であるSAsに適用されます。
Kent & Seo Standards Track [Page 69] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[69ページ]。
8.2. Path MTU (PMTU) Discovery
8.2. 経路MTU(PMTU)発見
This section discusses IPsec handling for unprotected 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 [Pos81b]):
- 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 (labeled "unused"
in RFC 792), with high-order 16 bits set to zero)
IPv4(RFC792[Pos81b]): - タイプ=3(目的地Unreachable)--コード=4(必要である断片化とDFはセットしました)--ICMPヘッダー(RFC792で「未使用である」とラベルされる)の2番目の単語の下位の16ビットの次のホップMTU高位16ビットでゼロに設定されて、
IPv6 (RFC 2463 [CD98]):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed)
- Next-Hop MTU in the 32-bit MTU field of the ICMP6
message
IPv6(RFC2463[CD98]): - =2(パケットToo Big)--コード=0(必要である断片化)--次のホップMTUをICMP6メッセージの32ビットのMTU分野にタイプしてください。
8.2.1. Propagation of PMTU
8.2.1. PMTUの伝播
When an IPsec implementation receives an unauthenticated PMTU message, and it is configured to process (vs. ignore) such messages, it maps the message to the SA to which it corresponds. This mapping is effected by extracting the header information from the payload of the PMTU message and applying the procedure described in Section 5.2. The PMTU determined by this message is used to update the SAD PMTU field, taking into account the size of the AH or ESP header that will be applied, any crypto synchronization data, and the overhead imposed by an additional IP header, in the case of a tunnel mode SA.
IPsec実装がunauthenticated PMTUメッセージを受け取って、処理するのが構成されている、(無視、)、そのようなメッセージ、それは相当するSAにメッセージを写像します。 PMTUメッセージのペイロードからヘッダー情報を抜粋して、セクション5.2で説明された手順を適用することによって、このマッピングは作用します。 このメッセージで断固としたPMTUはSAD PMTU分野をアップデートするのに使用されます、適用されるAHか超能力ヘッダーの規模、どんな暗号同期データ、および追加IPヘッダーによって課されたオーバーヘッドも考慮に入れて、トンネルモードSAの場合で。
In a native host implementation, it is possible to maintain PMTU data at the same granularity as for unprotected communication, so there is no loss of functionality. Signaling of the PMTU information is internal to the host. For all other IPsec implementation options, the PMTU data must be propagated via a synthesized ICMP PMTU. In these cases, the IPsec implementation SHOULD wait for outbound traffic to be mapped to the SAD entry. When such traffic arrives, if the traffic would exceed the updated PMTU value the traffic MUST be handled as follows:
ネイティブのホスト導入では、保護のないコミュニケーションのように同じ粒状でPMTUデータを保守するのは、機能性の損失が全くないように可能です。 ホストにとって、PMTU情報のシグナリングは内部です。 他のすべてのIPsec実装オプションにおいて、統合ICMP PMTUを通してPMTUデータを伝播しなければなりません。 これらの場合では、IPsec実装SHOULDは、アウトバウンドトラフィックがSADエントリーに写像されるのを待っています。 そのようなトラフィックが到着するとき、トラフィックがアップデートされたPMTU値を超えているなら、以下の通りトラフィックを扱わなければなりません:
Case 1: Original (cleartext) packet is IPv4 and has the DF
bit set. The implementation SHOULD discard the packet
and send a PMTU ICMP message.
ケース1: オリジナルの(cleartext)パケットで、IPv4であり、DFビットを設定します。 実装SHOULDはパケットを捨てて、PMTU ICMPメッセージを送ります。
Kent & Seo Standards Track [Page 70] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[70ページ]。
Case 2: Original (cleartext) packet is IPv4 and has the DF
bit clear. The implementation SHOULD fragment (before or
after encryption per its configuration) and then forward
the fragments. It SHOULD NOT send a PMTU ICMP message.
ケース2: オリジナルの(cleartext)パケットで、IPv4であり、DFビットは明確になります。 実装SHOULDは断片を断片化して(1構成あたりの暗号化の前または後に)、次に、進めます。 それ、SHOULD NOTはPMTU ICMPメッセージを送ります。
Case 3: Original (cleartext) packet is IPv6. The implementation
SHOULD discard the packet and send a PMTU ICMP message.
ケース3: オリジナルの(cleartext)パケットはIPv6です。 実装SHOULDはパケットを捨てて、PMTU ICMPメッセージを送ります。
8.2.2. PMTU Aging
8.2.2. PMTUの年をとること
In all IPsec implementations, the PMTU associated with an SA MUST be "aged" and some mechanism is required to update the PMTU in a timely manner, especially for discovering if the PMTU is smaller than required by current network conditions. A given PMTU has to remain in place long enough for a packet to get from the source of the SA to the peer, and to propagate an ICMP error message if the current PMTU is too big.
「熟成して」何らかのメカニズムが直ちにPMTUをアップデートするのに必要です、特にPMTUが現在のネットワーク状態によって必要とされるより小さいかどうか発見するためにすべてのIPsec実装、SA MUSTに関連づけられたPMTUではことになってください。 現在のPMTUが大き過ぎるなら、与えられたPMTUはSAの源から同輩まで得るパケット、ICMPエラーメッセージを伝播できるくらいの長い間、適所に残らなければなりません。
Implementations SHOULD use the approach described in the Path MTU Discovery document (RFC 1191 [MD90], 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[MD90]、セクション6.3)で説明されたアプローチを使用します。ドキュメントは、定期的に最初に、ホップデータ・リンクMTUにPMTUをリセットして、次に、正常なPMTUディスカバリープロセスに必要に応じてPMTUをアップデートさせるのを示します。 以上、SHOULD。構成可能であってください。
9. Auditing
9. 監査
IPsec implementations are not required to support auditing. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this document, 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実装は、監査をサポートするのに必要ではありません。 監査の粒状はだいたい、地域にかかわる事柄です。 しかしながら、いくつかの監査可能イベントが本書では特定されます、そして、それぞれのこれらのイベントにおいて、SHOULDが監査ログに含まれているという最小の情報は定義されます。 追加情報もこの仕様で明らかに大声で叫んで、また、監査航空日誌記入事項をもたらすかもしれないのではなく、それぞれのこれらのイベント、および追加イベントのための監査ログに含まれるかもしれません。 受信機が監査可能イベントの検出に対応してどんなメッセージも主張された送信機に送るという要件が全くありません、そのような動作でサービスの否定を引き起こす可能性のために。
10. Conformance Requirements
10. 順応要件
All IPv4 IPsec implementations MUST comply with all requirements of this document. All IPv6 implementations MUST comply with all requirements of this document.
すべてのIPv4 IPsec実装がこのドキュメントのすべての要件に従わなければなりません。 すべてのIPv6実装がこのドキュメントのすべての要件に従わなければなりません。
Kent & Seo Standards Track [Page 71] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[71ページ]。
11. Security Considerations
11. セキュリティ問題
The focus of this document is security; hence security considerations permeate this specification.
このドキュメントの焦点はセキュリティです。 したがって、セキュリティ問題はこの仕様を普及させます。
IPsec imposes stringent constraints on bypass of IP header data in both directions, across the IPsec barrier, especially when tunnel mode SAs are employed. Some constraints are absolute, while others are subject to local administrative controls, often on a per-SA basis. For outbound traffic, these constraints are designed to limit covert channel bandwidth. For inbound traffic, the constraints are designed to prevent an adversary who has the ability to tamper with one data stream (on the unprotected side of the IPsec barrier) from adversely affecting other data streams (on the protected side of the barrier). The discussion in Section 5 dealing with processing DSCP values for tunnel mode SAs illustrates this concern.
IPsecは両方の方向によるIPヘッダー・データの迂回に厳しい規制を課します、IPsecバリアの向こう側に、特にトンネルモードSAsが採用しているとき。 いくつかの規制が絶対ですが、他のものはしばしば1SAあたり1個のベースで地方の運営管理コントロールを受けることがあります。 アウトバウンドトラフィックにおいて、これらの規制は、ひそかなチャンネル帯域幅を制限するように設計されています。 インバウンドトラフィックにおいて、規制は、1つのデータ・ストリーム(IPsecバリアの保護のない端の)をいじる能力を持っている敵が他のデータ・ストリーム(バリアの保護された端の)に悪影響を与えるのを防ぐように設計されています。 トンネルモードSAsのための処理DSCP値に対処するセクション5における議論はこの関心を例証します。
If an IPsec implementation is configured to pass ICMP error messages over SAs based on the ICMP header values, without checking the header information from the ICMP message payload, serious vulnerabilities may arise. Consider a scenario in which several sites (A, B, and C) are connected to one another via ESP-protected tunnels: A-B, A-C, and B-C. Also assume that the traffic selectors for each tunnel specify ANY for protocol and port fields and IP source/destination address ranges that encompass the address range for the systems behind the security gateways serving each site. This would allow a host at site B to send an ICMP Destination Unreachable message to any host at site A, that declares all hosts on the net at site C to be unreachable. This is a very efficient DoS attack that could have been prevented if the ICMP error messages were subjected to the checks that IPsec provides, if the SPD is suitably configured, as described in Section 6.2.
IPsec実装がICMPヘッダー値に基づくSAsの上でエラーメッセージをICMPに通過するために構成されるなら、ICMPメッセージペイロードからのヘッダー情報をチェックしないで、重大な脆弱性は起こるかもしれません。 いくつかのサイト(A、B、およびC)が超能力で保護されたトンネルを通ってお互いにつなげられるシナリオを考えてください: A-B、A-C、およびB-C。 また、各トンネルへのトラフィックセレクタが少しもシステムのために各サイトに役立ちながらセキュリティゲートウェイの後ろでアドレスの範囲を取り囲むプロトコル、ポート分野、およびIPのソース/目的地のアドレスの範囲に指定すると仮定してください。 これで、サイトBのホストはサイトAのどんなホストにもICMP Destination Unreachableメッセージを送ることができて、それは、サイトCのネットのすべてのホストが手が届かないと宣言します。 これはICMPエラーメッセージがIPsecが提供するチェックにかけられたなら防がれたかもしれない、非常に効率的なDoS攻撃です、SPDが適当に構成されるなら、セクション6.2で説明されるように。
12. IANA Considerations
12. IANA問題
The IANA has assigned the value (3) for the asn1-modules registry and has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD module. See Appendix C, "ASN.1 for an SPD Entry".
IANAはasn1-モジュール登録に値(3)を割り当てて、オブジェクト識別子1.3に.6を割り当てました。.1 .5 .8 .3 .1 SPDモジュールのために。 付録C、「SPDエントリーへのASN.1」を見てください。
13. Differences from RFC 2401
13. RFC2401からの違い
This architecture document differs substantially from RFC 2401 [RFC2401] in detail and in organization, but the fundamental notions are unchanged.
このアーキテクチャドキュメントは詳細と組織において実質的にRFC2401[RFC2401]と異なっていますが、根本的な観念は変わりがありません。
o The processing model has been revised to address new IPsec
scenarios, improve performance, and simplify implementation. This
includes a separation between forwarding (routing) and SPD
o 処理モデルは、新しいIPsecシナリオを扱って、性能を向上させて、実装を簡素化するために改訂されました。 これは推進(ルーティング)とSPDの間の分離を含んでいます。
Kent & Seo Standards Track [Page 72] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[72ページ]。
selection, several SPD changes, and the addition of an outbound SPD
cache and an inbound SPD cache for bypassed or discarded traffic.
There is also a new database, the Peer Authorization Database
(PAD). This provides a link between an SA management protocol
(such as IKE) and the SPD.
迂回したか捨てられたトラフィックのための外国行きのSPDキャッシュと本国行きのSPDキャッシュの選択、数回のSPD変化、および追加。 また、新しいデータベース、Peer Authorization Database(PAD)があります。 これはSA管理プロトコル(IKEなどの)とSPDとのリンクを提供します。
o There is no longer a requirement to support nested SAs or "SA
bundles". Instead this functionality can be achieved through SPD
and forwarding table configuration. An example of a configuration
has been added in Appendix E.
o もう、入れ子にされたSAsか「SAバンドル」をサポートするという要件がありません。 代わりに、この機能性は、SPDを通して実現されて、テーブル構成を進めることができます。 構成に関する例はAppendix Eで加えられます。
o SPD entries were redefined to provide more flexibility. Each SPD
entry now consists of 1 to N sets of selectors, where each selector
set contains one protocol and a "list of ranges" can now be
specified for the Local IP address, Remote IP address, and whatever
fields (if any) are associated with the Next Layer Protocol (Local
Port, Remote Port, ICMP message type and code, and Mobility Header
type). An individual value for a selector is represented via a
trivial range and ANY is represented via a range than spans all
values for the selector. An example of an ASN.1 description is
included in Appendix C.
o SPDエントリーは、より多くの柔軟性を提供するために再定義されました。 現在、それぞれのSPDエントリーはNセットのセレクタに1から成ります。そこでは、それぞれのセレクタセットが1つのプロトコルを含んでいて、現在、Local IPアドレス、Remote IPアドレス、およびNext Layerプロトコルに関連しているいかなる分野(もしあれば)にも「範囲のリスト」を指定できます(地方のPort、Remote Port、ICMPメッセージタイプ、コード、およびMobility Headerがタイプします)。 セレクタのための個人価値は、セレクタのためのすべての値にかかっているより些細な範囲を通って表されて、範囲を通って少しも表されます。 ASN.1記述に関する例はAppendix Cに含まれています。
o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and
ECN. The tunnel section has been updated to explain how to handle
DSCP and ECN bits.
o TOS(IPv4)とTraffic Class(IPv6)をDSCPと電子証券取引ネットワークに取り替えました。 DSCPと電子証券取引ネットワークビットを扱う方法を説明するためにトンネルの部分をアップデートしました。
o For tunnel mode SAs, an SG, BITS, or BITW implementation is now
allowed to fragment packets before applying IPsec. This applies
only to IPv4. For IPv6 packets, only the originator is allowed to
fragment them.
o トンネルモードSAs、SG、BITS、またはBITWに関しては、IPsecを適用する前に、実装は現在、パケットを断片化できます。 これはIPv4だけに適用されます。 IPv6パケットに関しては、創始者だけがそれらを断片化できます。
o When security is desired between two intermediate systems along a
path or between an intermediate system and an end system, transport
mode may now be used between security gateways and between a
security gateway and a host.
o セキュリティが現在経路に沿った2個の中間システムの間、または、中間システムとエンドシステムの間で望まれているとき、交通機関はセキュリティゲートウェイの間と、そして、セキュリティゲートウェイとホストの間で使用されるかもしれません。
o This document clarifies that for all traffic that crosses the IPsec
boundary, including IPsec management traffic, the SPD or associated
caches must be consulted.
o このドキュメントはIPsec境界に交差するすべてのトラフィックのためにそれをはっきりさせます、IPsec管理トラフィックを含んでいてSPDか関連キャッシュに相談しなければなりません。
o This document defines how to handle the situation of a security
gateway with multiple subscribers requiring separate IPsec
contexts.
o 複数の加入者が別々のIPsec関係を必要とすることで、このドキュメントはセキュリティゲートウェイの状況を扱う方法を定義します。
o A definition of reserved SPIs has been added.
o 予約されたSPIsの定義は加えられます。
Kent & Seo Standards Track [Page 73] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[73ページ]。
o Text has been added explaining why ALL IP packets must be checked
-- IPsec includes minimal firewall functionality to support access
control at the IP layer.
o すべてのIPパケットをチェックしなければなりません--IPsecがなぜIP層でアクセスがコントロールであるとサポートするために最小量のファイアウォールの機能性を含んでいるかを説明しながら、テキストは加えられます。
o The tunnel section has been updated to clarify how to handle the IP
options field and IPv6 extension headers when constructing the
outer header.
o 外側のヘッダーを組み立てるとき、IPオプション分野とIPv6拡張ヘッダーを扱う方法をはっきりさせるためにトンネルの部分をアップデートしました。
o SA mapping for inbound traffic has been updated to be consistent
with the changes made in AH and ESP for support of unicast and
multicast SAs.
o ユニキャストとマルチキャストSAsのサポートのためにAHと超能力で行われる変更と一致しているようにインバウンドトラフィックのためのSAマッピングをアップデートしました。
o Guidance has been added regarding how to handle the covert channel
created in tunnel mode by copying the DSCP value to outer header.
o 指導はどう外側のヘッダーにDSCP値をコピーすることによってトンネルモードで創造されたひそかなチャンネルを扱うかに関して加えられます。
o Support for AH in both IPv4 and IPv6 is no longer required.
o IPv4とIPv6の両方のAHのサポートはもう必要ではありません。
o PMTU handling has been updated. The appendix on
PMTU/DF/Fragmentation has been deleted.
o PMTU取り扱いをアップデートしました。 PMTU/DF/断片化での付録は削除されました。
o Three approaches have been added for handling plaintext fragments
on the protected side of the IPsec boundary. Appendix D documents
the rationale behind them.
o 3つのアプローチがIPsec境界保護側の上の取り扱い平文断片のために加えられます。 付録Dはそれらの後ろに原理を記録します。
o Added revised text describing how to derive selector values for SAs
(from the SPD entry or from the packet, etc.)
o SAsのためにセレクタ値を引き出す方法を説明する加えられた校訂本(SPDエントリーや、パケットなどからの)
o Added a new table describing the relationship between selector
values in an SPD entry, the PFP flag, and resulting selector values
in the corresponding SAD entry.
o 対応するSADエントリーでSPDエントリーにおけるセレクタ値と、PFP旗と、結果として起こるセレクタ値との関係について説明する新しいテーブルを加えました。
o Added Appendix B to describe decorrelation.
o 「反-相関関係」について説明するためにAppendix Bを加えました。
o Added text describing how to handle an outbound packet that must be
discarded.
o 捨てなければならない外国行きのパケットを扱う方法を説明するテキストを加えました。
o Added text describing how to handle a DISCARDED inbound packet,
i.e., one that does not match the SA upon which it arrived.
o DISCARDEDの本国行きのパケット(すなわち、それが到着したSAに合っていないもの)を扱う方法を説明する加えられたテキスト。
o IPv6 mobility header has been added as a possible Next Layer
Protocol. IPv6 Mobility Header message type has been added as a
selector.
o IPv6移動性ヘッダーは可能なNext Layerプロトコルとして加えられます。 IPv6 Mobility Headerメッセージタイプはセレクタとして加えられます。
o ICMP message type and code have been added as selectors.
o ICMPメッセージタイプとコードはセレクタとして加えられます。
o The selector "data sensitivity level" has been removed to simplify
things.
o ものを簡素化するためにセレクタ「データ感度レベル」を取り除きました。
Kent & Seo Standards Track [Page 74] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[74ページ]。
o Updated text describing handling ICMP error messages. The appendix
on "Categorization of ICMP Messages" has been deleted.
o ICMPエラーメッセージを扱うと説明するテキストをアップデートしました。 「ICMPメッセージの分類」での付録は削除されました。
o The text for the selector name has been updated and clarified.
o セレクタ名のためのテキストをアップデートして、はっきりさせました。
o The "Next Layer Protocol" has been further explained and a default
list of protocols to skip when looking for the Next Layer Protocol
has been added.
o 「次の層のプロトコル」はさらに説明されました、そして、Next Layerプロトコルを探すときスキップするプロトコルのデフォルトリストは加えられます。
o The text has been amended to say that this document assumes use of
IKEv2 or an SA management protocol with comparable features.
o このドキュメントが匹敵する特徴があるIKEv2の使用かSA管理プロトコルを仮定すると言うためにテキストを修正してあります。
o Text has been added clarifying the algorithm for mapping inbound
IPsec datagrams to SAs in the presence of multicast SAs.
o テキストは、マルチキャストSAsの面前で本国行きのIPsecデータグラムをSAsに写像するためのアルゴリズムをはっきりさせながら、加えられます。
o The appendix "Sequence Space Window Code Example" has been removed.
o 付録「系列スペース窓のコードの例」を取り除きました。
o With respect to IP addresses and ports, the terms "Local" and
"Remote" are used for policy rules (replacing source and
destination). "Local" refers to the entity being protected by an
IPsec implementation, i.e., the "source" address/port of outbound
packets or the "destination" address/port of inbound packets.
"Remote" refers to a peer entity or peer entities. The terms
"source" and "destination" are still used for packet header fields.
o IPアドレスとポートに関して、「地方」という用語と「リモート」は政策ルールに使用されます(ソースと目的地を置き換えて)。 「地方」はIPsec実装(すなわち、外国行きのパケットか本国行きのパケットの「目的地」アドレス/ポートの「ソース」アドレス/ポート)によって保護される実体を示します。 「リモート」は同輩実体か同輩実体を示します。 用語「ソース」と「目的地」はパケットヘッダーフィールドにまだ使用されています。
14. Acknowledgements
14. 承認
The authors would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827; and Charlie Lynn, who made significant contributions to the second series of IPsec standards (RFCs 2401, 2402, and 2406) and to the current versions, especially with regard to IPv6 issues. The authors also would like to thank the members of the IPsec and MSEC working groups who have contributed to the development of this protocol specification.
作者は初期のIPsec活動における重要な役割を果たして、最初のシリーズのIPsec規格を書いたRanアトキンソンの貢献を承諾したがっています: RFCs1825-1827。 そして、チャーリーリン。(そのリンは、2番目のシリーズのIPsec規格(RFCs2401、2402、および2406)と、そして、特にIPv6に関する最新版への重要な貢献を問題にしました)。 作者もこのプロトコル仕様の開発に貢献したIPsecとMSECワーキンググループのメンバーに感謝したがっています。
Kent & Seo Standards Track [Page 75] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[75ページ]。
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., [Shi00], [VK83], and [HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms.
このセクションは本書では使われるいくつかの主要な期間、定義を提供します。 他のドキュメントは例えば[Shi00]、この技術の[VK83]、および[HA94]に関連している追加定義と基礎的な情報を提供します。 この用語集に含まれているのは、ジェネリックセキュリティー・サービスと、セキュリティー対策用語と、IPsec-種の用語です。
Access Control
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:
リソースの無断使用を防ぐControl Aセキュリティー・サービスにアクセスしてください、権限のない方法によるリソースで役に立つ防止を含んでいて。 IPsec文脈では、しばしばアクセスが制御されているリソースは以下の通りです。
o for a host, computing cycles or data
o for a security gateway, a network behind the gateway
or bandwidth on that network.
o セキュリティゲートウェイへのo、ゲートウェイの後ろのネットワークまたはそれにおける帯域幅がネットワークでつなぐホスト、コンピューティングサイクルまたはデータのために。
Anti-replay
See "Integrity" below.
以下の反再生See「保全。」
Authentication
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.
非公式に2つの名目上は異なったセキュリティー・サービス、データ発生源認証、およびコネクションレスな保全の組み合わせについて言及する認証Used。 それぞれのこれらのサービスに関して以下での定義を見てください。
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.
有用性Whenはセキュリティをサービスとみなしました、安全上の配慮がサービスを否定するか、または下がらせるネットワークに対する攻撃で生み出したアドレス。 例えば、IPsec文脈では、AHと超能力における反再生メカニズムの使用は有用性をサポートします。
Confidentiality
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.)
不当開示からデータを保護するセキュリティが修理する秘密性。 プライマリ機密保持の懸念はたいていの場合アプリケーションレベルデータの不当開示ですが、コミュニケーションの外部の特性の公開もいくつかの事情において関心であるかもしれません。 交通の流れ秘密性はコミュニケーションのソースと送付先アドレスか、メッセージ長か、頻度を隠すことによってこの後者の関心を扱うサービスです。 IPsec文脈に、特にセキュリティゲートウェイでトンネルモードで超能力を使用すると、何らかのレベルの交通の流れ秘密性を提供できます。 (また、以下の「トラヒック分析」を見てください。)
Kent & Seo Standards Track [Page 76] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[76ページ]。
Data Origin Authentication
A security service that verifies the identity of the claimed
source of data. This service is usually bundled with
connectionless integrity service.
データの要求された源のアイデンティティについて確かめるデータOrigin Authentication Aセキュリティー・サービス。 通常、このサービスはコネクションレスな保全サービスで添付されます。
Encryption
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". Often the term "encryption" is used to
generically refer to both processes.
暗号化Aセキュリティー対策は、明瞭なフォーム(平文)からのデータを難解なフォーム(暗号文)に変えて、以前はよく秘密性を提供していました。 逆さの変換プロセスは「復号化」に指定されます。 しばしば、「暗号化」という用語は、一般的に両方のプロセスについて言及するのに使用されます。
Integrity
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.
データへの変更が確実に検出可能になるようにする保全Aセキュリティー・サービス。 保全は、アプリケーション要件を合わせるために様々な風味で登場します。 IPsecは2つのフォームの保全をサポートします: 部分的な系列保全のコネクションレス、そして、aフォーム。 コネクションレスな保全は個々のIPデータグラムの変更を検出するサービスです、トラフィックのストリームにおける、データグラムの注文への尊敬なしで。 IPsecで提供された部分的な系列保全の書式は反再生保全と呼ばれます、そして、それは写しIPデータグラム(強制的な窓の中の)の到着を検出します。 これは接続指向の保全と対照的になっています。保全は、例えば無くなっているか再規則正しいメッセージを検出できるように、より厳しい配列要件をトラフィックに課します。 認証と保全サービスは別々にしばしば引用されますが、それらは、実際には、親密に接続されていて2人乗り自転車でほとんどいつも提供されています。
Protected vs. Unprotected
"Protected" refers to the systems or interfaces that are inside
the IPsec protection boundary, and "unprotected" refers to the
systems or interfaces that are outside the IPsec protection
boundary. IPsec provides a boundary through which traffic passes.
There is an asymmetry to this barrier, which is reflected in the
processing model. Outbound data, if not discarded or bypassed, is
protected via the application of AH or ESP and the addition of the
corresponding headers. Inbound data, if not discarded or
bypassed, is processed via the removal of AH or ESP headers. In
this document, inbound traffic enters an IPsec implementation from
the "unprotected" interface. Outbound traffic enters the
implementation via the "protected" interface, or is internally
generated by the implementation on the "protected" side of the
boundary and directed toward the "unprotected" interface. An
IPsec implementation may support more than one interface on either
or both sides of the boundary. The protected interface may be
Unprotectedに対して保護されて、「保護されたこと」はIPsec保護境界の中にあるシステムかインタフェースを参照します、そして、「保護のないこと」はIPsec保護境界の外にあるシステムかインタフェースを示します。 IPsecはトラフィックが終わる境界を提供します。 このバリアへの非対称があります。(バリアは処理モデルに反映されます)。 捨てられないか、または迂回しないなら、アウトバウンドデータはAHか超能力のアプリケーションと対応するヘッダーの追加で保護されます。 捨てられないか、または迂回しないなら、インバウンドデータはAHか超能力ヘッダーの解任で処理されます。 本書では、インバウンドトラフィックは「保護のない」インタフェースからIPsec実装に入ります。 アウトバウンドトラフィックは、「保護された」インタフェースを通して実装を入れるか、境界「保護された」側の上の実装によって内部的に生成されて、または「保護のない」インタフェースに向けられます。 IPsec実装は境界のどちらかか両側の1つ以上のインタフェースをサポートするかもしれません。 保護されたインタフェースはそうです。
Kent & Seo Standards Track [Page 77] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[77ページ]。
internal, e.g., in a host implementation of IPsec. The protected
interface may link to a socket layer interface presented by the
OS.
例えば、IPsecのホスト導入では、内部です。 保護されたインタフェースはOSで提示されたソケットレイヤーインタフェースにリンクされるかもしれません。
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. State data
associated with an SA is represented in the SA Database (SAD).
シンプレクスの(uni方向)の論理的な接続であって、セキュリティ目的のために作成されたセキュリティAssociation(SA)。 SAを横断するすべてのトラフィックに同じセキュリティ処理を提供します。 IPsecでは、SAはAHか超能力の使用で実装されたインターネット層の抽象化です。 SAに関連している州のデータはSA Database(SAD)に表されます。
Security Gateway
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 termed unprotected (they
are generally at least less protected than those "behind" the SG),
while the networks and hosts on the internal side are viewed as
protected. The internal subnets and hosts served by a security
gateway are presumed to be trusted by virtue of sharing a common,
local, security administration. In the IPsec context, a security
gateway is a point at which AH and/or ESP is implemented in order
to serve 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).
コミュニケーションが2つのネットワークの間で連結するとき作動するセキュリティゲートウェイAn中間システム。 セキュリティゲートウェイの外部の側面の上のホスト(そして、ネットワーク)のセットが呼ばれる、保護のなさ、(それら、一般に、それらより少なくとも保護されなかった“behind"がSGである、)、内部側の上のネットワークとホストは保護されるように見られますが。 一般的で、地方のセキュリティ管理を共有することによってセキュリティゲートウェイによって役立たれる内部サブネットとホストはあえて信じられます。 IPsec文脈では、セキュリティゲートウェイはAH、そして/または、超能力が1セットの内部のホストに役立つように実装されるポイントです、彼らがまた、IPsec(直接かもう1セキュリティ門を通した)を使う外部のホストとコミュニケートするとき、これらのホストのためのセキュリティー・サービスを提供して。
Security Parameters Index (SPI)
An arbitrary 32-bit value that is used by a receiver to identify
the SA to which an incoming packet should be bound. For a unicast
SA, the SPI can be used by itself to specify an SA, or it may be
used in conjunction with the IPsec protocol type. Additional IP
address information is used to identify multicast SAs. 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.
セキュリティParameters Index、(SPI) 受信機によって使用される、入って来るパケットが制限されているべきであるSAを特定する任意の32ビットの値。 ユニキャストにおいて、SAを指定するのにSA、SPIをそれ自体で使用できますか、またはそれはIPsecプロトコルタイプに関連して使用されるかもしれません。 追加IPアドレス情報は、マルチキャストSAsを特定するのに使用されます。 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, and flow identifiers
[Sch94].
ネットワークトラフィックの分析が目的のために敵の役に立つ情報を推論しながら流れるトラフィックAnalysis。 そのような情報に関する例は、トランスミッションの頻度と、話しパーティーのアイデンティティと、パケットのサイズと、流れ識別子[Sch94]です。
Kent & Seo Standards Track [Page 78] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[78ページ]。
Appendix B: Decorrelation
付録B: Decorrelation
This appendix is based on work done for caching of policies in the IP Security Policy Working Group by Luis Sanchez, Matt Condell, and John Zao.
この付録はIP Security Policy作業部会における、方針のキャッシュのためにルイス・サンチェス、マット・コンデル、およびジョンZaoによって行われた仕事に基づいています。
Two SPD entries are correlated if there is a non-null intersection between the values of corresponding selectors in each entry. Caching correlated SPD entries can lead to incorrect policy enforcement. A solution to this problem, which still allows for caching, is to remove the ambiguities by decorrelating the entries. That is, the SPD entries must be rewritten so that for every pair of entries there exists a selector for which there is a null intersection between the values in both of the entries. Once the entries are decorrelated, there is no longer any ordering requirement on them, since only one entry will match any lookup. The next section describes decorrelation in more detail and presents an algorithm that may be used to implement decorrelation.
各エントリーにおける、対応するセレクタの値の間には、非ヌル交差点があれば、2つのSPDエントリーが関連されています。 関連SPDエントリーをキャッシュするのは不正確な方針実施に通じることができます。 キャッシュするとまだ考慮しているこの問題への解決はエントリーを反関連させることによってあいまいさを取り除くことです。 エントリーの両方の値の間にヌル交差点があるセレクタがすべての組のエントリーに存在するように、すなわち、SPDエントリーを書き直さなければなりません。 エントリーがいったん反関連すると、それらに関するどんな注文要件ももうありません、1つのエントリーだけがどんなルックアップにも合うので。 次のセクションは、「反-相関関係」を実装するためにさらに詳細に「反-相関関係」について説明して、使用されるかもしれないアルゴリズムを提示します。
B.1. Decorrelation Algorithm
B.1。 Decorrelationアルゴリズム
The basic decorrelation algorithm takes each entry in a correlated SPD and divides it into a set of entries using a tree structure. The nodes of the tree are the selectors that may overlap between the policies. At each node, the algorithm creates a branch for each of the values of the selector. It also creates one branch for the complement of the union of all selector values. Policies are then formed by traversing the tree from the root to each leaf. The policies at the leaves are compared to the set of already decorrelated policy rules. Each policy at a leaf is either completely overridden by a policy in the already decorrelated set and is discarded or is decorrelated with all the policies in the decorrelated set and is added to it.
基本的な「反-相関関係」アルゴリズムは、関連SPDで各エントリーを取って、木構造を使用することでそれを1セットのエントリーに分割します。 木の節は方針の間に重なるかもしれないセレクタです。 各ノードでは、アルゴリズムはそれぞれのセレクタの値のためにブランチを創設します。 また、それはすべてのセレクタ値の組合の補数のために1つのブランチを創設します。 そして、方針は、根から各葉まで木を横断することによって、形成されます。 葉の方針は既に反関連している政策ルールのセットにたとえられます。 葉の各方針は、既に反関連しているセットにおける方針で完全にくつがえされて、捨てられるか、反関連セットにおけるすべての方針で反関連して、またはそれに加えられます。
The basic algorithm does not guarantee an optimal set of decorrelated entries. That is, the entries may be broken up into smaller sets than is necessary, though they will still provide all the necessary policy information. Some extensions to the basic algorithm are described later to improve this and improve the performance of the algorithm.
基本的なアルゴリズムは最適の反関連エントリーを保証しません。 すなわち、エントリーは必要とするより小さいセットに壊れるかもしれません、それでも、すべての必要な政策情報を提供するでしょうが。 いくつかの拡大が、後でこれを改良して、アルゴリズムの性能を向上させるために基本的なアルゴリズムに説明されます。
C A set of ordered, correlated entries (a correlated SPD).
Ci The ith entry in C.
U The set of decorrelated entries being built from C.
Ui The ith entry in U.
Sik The kth selection for policy Ci.
Ai The action for policy Ci.
注文されて、関連しているエントリー(関連SPD)のC Aセット。 ithエントリーをCiする、C.UのC.ウイからのithエントリーがU.シクで組み込まれる反関連エントリーのセット、方針Ciのためのkth選択。 Ai、方針Ciのための動作。
Kent & Seo Standards Track [Page 79] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[79ページ]。
A policy (SPD entry) P may be expressed as a sequence of selector values and an action (BYPASS, DISCARD, or PROTECT):
方針(SPDエントリー)Pはセレクタ値の系列と動作(BYPASS、DISCARD、またはPROTECT)として言い表されるかもしれません:
Ci = Si1 x Si2 x ... x Sik -> Ai
CiはSi1x Si2x…xシク->Aiと等しいです。
1) Put C1 in set U as U1
1) U1としてセットUにC1を入れてください。
For each policy Cj (j > 1) in C
Cの各方針Cj(j>1)のために
2) If Cj is decorrelated with every entry in U, then add it to U.
2) あらゆるエントリーがUにある状態でCjが反関連するなら、Uにそれを加えてください。
3) If Cj is correlated with one or more entries in U, create a tree rooted at the policy Cj that partitions Cj into a set of decorrelated entries. The algorithm starts with a root node where no selectors have yet been chosen.
3) 1つ以上のエントリーがUにある状態でCjが関連するなら、1セットの反関連エントリーにCjを仕切る方針Cjに根づいていた状態で木を作成してください。 アルゴリズムはセレクタが全くまだ選ばれていない根のノードから始まります。
A) Choose a selector in Cj, Sjn, that has not yet been chosen when
traversing the tree from the root to this node. If there are no
selectors not yet used, continue to the next unfinished branch
until all branches have been completed. When the tree is
completed, go to step D.
a) Cj、根からこのノードまで木を横断するときまだ選ばれていないSjnでセレクタを選んでください。 まだ使用されていなかったセレクタが全くなければ、すべてのブランチが完成するまで、次の未完成のブランチに続いてください。 木が完成したら、Dを踏みに行ってください。
T is the set of entries in U that are correlated with the entry
at this node.
TはUのエントリーがこのノードにある状態で関連するエントリーのセットです。
The entry at this node is the entry formed by the selector
values of each of the branches between the root and this node.
Any selector values that are not yet represented by branches
assume the corresponding selector value in Cj, since the values
in Cj represent the maximum value for each selector.
このノードのエントリーは根とこのノードの間でそれぞれのブランチのセレクタ値によって形成されたエントリーです。 ブランチによってまだ表されていない少しのセレクタ値もCjで対応するセレクタ値を仮定します、Cjの値が各セレクタのために最大値を表すので。
B) Add a branch to the tree for each value of the selector Sjn that
appears in any of the entries in T. (If the value is a superset
of the value of Sjn in Cj, then use the value in Cj, since that
value represents the universal set.) Also add a branch for the
complement of the union of all the values of the selector Sjn
in T. When taking the complement, remember that the universal
set is the value of Sjn in Cj. A branch need not be created
for the null set.
B) T.のエントリーのいずれにも現れるセレクタSjnの各値のために木にブランチを加えてください。(値がCjのSjnの価値のスーパーセットであるならCjで値を使用してください、その値が全集合を表すので。) また、T.WhenのセレクタSjnのすべての値の組合の補数のために補数を取りながら、ブランチを言い足してください、そして、全集合がCjのSjnの値であることを覚えていてください。 ブランチは零集合のために創設される必要はありません。
C) Repeat A and B until the tree is completed.
C) 木が完成するまで、AとBを繰り返してください。
D) The entry to each leaf now represents an entry that is a subset
of Cj. The entries at the leaves completely partition Cj in
such a way that each entry is either completely overridden by
an entry in U, or is decorrelated with the entries in U.
D) 各葉へのエントリーは現在、Cjの部分集合であるエントリーを表します。 葉のエントリーは各エントリーがUでエントリーで完全にくつがえされるか、またはエントリーがUにある状態で反関連するような方法でCjを完全に仕切ります。
Add all the decorrelated entries at the leaves of the tree to U.
木の葉ですべての反関連エントリーをUに加えてください。
Kent & Seo Standards Track [Page 80] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[80ページ]。
4) Get next Cj and go to 2.
4) 次のCjを手に入れてください、そして、2まで行ってください。
5) When all entries in C have been processed, then U will contain an decorrelated version of C.
5) Cのすべてのエントリーを処理してあると、UはCの反関連バージョンを含むでしょう。
There are several optimizations that can be made to this algorithm. A few of them are presented here.
このアルゴリズムにすることができるいくつかの最適化があります。 それらのいくつかはここに提示されます。
It is possible to optimize, or at least improve, the amount of branching that occurs by carefully choosing the order of the selectors used for the next branch. For example, if a selector Sjn can be chosen so that all the values for that selector in T are equal to or a superset of the value of Sjn in Cj, then only a single branch needs to be created (since the complement will be null).
最適化するか、または少なくとも向上するのが可能です、慎重に次のブランチに使用されるセレクタの注文を選ぶことによって起こる分岐する量。 例えば、セレクタであるならSjnを選ぶことができるので、Tのそのセレクタのためのすべての値が等しくて、CjのSjnの価値のスーパーセットである、そして、単一のブランチだけが作成される必要があります(補数がヌルになるので)。
Branches of the tree do not have to proceed with the entire decorrelation algorithm. For example, if a node represents an entry that is decorrelated with all the entries in U, then there is no reason to continue decorrelating that branch. Also, if a branch is completely overridden by an entry in U, then there is no reason to continue decorrelating the branch.
木の枝は全体の「反-相関関係」アルゴリズムを続ける必要はありません。 例えば、ノードがすべてのエントリーがUにある状態で反関連するエントリーを表すなら、そのブランチを反関連させ続ける理由が全くありません。 また、ブランチがUでエントリーで完全にくつがえされるなら、ブランチを反関連させ続ける理由が全くありません。
An additional optimization is to check to see if a branch is overridden by one of the CORRELATED entries in set C that has already been decorrelated. That is, if the branch is part of decorrelating Cj, then check to see if it was overridden by an entry Cm, m < j. This is a valid check, since all the entries Cm are already expressed in U.
追加最適化はブランチが既に反関連したセットCにおけるCORRELATEDエントリーの1つまでにくつがえされるかどうか確認するためにチェックすることです。 それはそうです、ブランチがdecorrelating Cjの一部です、とそして、Cm(m<j)はそれがエントリーでくつがえされたかどうか確認するためにチェックします。 これが有効なチェックである、すべてのエントリー以来、CmはUで既に急送されます。
Along with checking if an entry is already decorrelated in step 2, check if Cj is overridden by any entry in U. If it is, skip it since it is not relevant. An entry x is overridden by another entry y if every selector in x is equal to or a subset of the corresponding selector in entry y.
それはあって、それが関連していないので、CjがU.Ifのどんなエントリーでもくつがえされるならエントリーがステップ2、チェックで既に反関連するかどうかチェックすると共に、それをスキップしてください。 エントリーxはxのあらゆるセレクタが等しくて、エントリーyにおける対応するセレクタの部分集合であるなら別のエントリーyでくつがえされます。
Kent & Seo Standards Track [Page 81] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[81ページ]。
Appendix C: ASN.1 for an SPD Entry
付録C: SPDエントリーへのASN.1
This appendix is included as an additional way to describe SPD entries, as defined in Section 4.4.1. It uses ASN.1 syntax that has been successfully compiled. This syntax is merely illustrative and need not be employed in an implementation to achieve compliance. The SPD description in Section 4.4.1 is normative.
この付録はSPDエントリーについて説明する追加方法セクション4.4.1で定義されるように含まれています。 それは首尾よくコンパイルされたASN.1構文を使用します。 この構文は、単に説明に役立って、コンプライアンスを達成するのに実装で使われる必要はありません。 セクション4.4.1におけるSPD記述は規範的です。
SPDModule
SPDModule
{iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
ipsec (8) asn1-modules (3) spd-module (1) }
iso(1) org(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)ipsec(8)asn1-モジュール(3)spd-モジュール(1)
DEFINITIONS IMPLICIT TAGS ::=
定義、内在しているタグ:、:=
BEGIN
始まってください。
IMPORTS
RDNSequence FROM PKIX1Explicit88
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
IMPORTS RDNSequence FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)。
-- An SPD is a list of policies in decreasing order of preference
SPD ::= SEQUENCE OF SPDEntry
-- SPDによる減少における方針のリストが好みのSPDについて以下を注文するということです:= SPDEntryの系列
SPDEntry ::= CHOICE {
iPsecEntry IPsecEntry, -- PROTECT traffic
bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS
SPDEntry:、:= CHOICE、iPsecEntry IPsecEntry、--、PROTECTがbypassOrDiscard[0]BypassOrDiscardEntryを交通である--、DISCARD/BYPASS
IPsecEntry ::= SEQUENCE { -- Each entry consists of
name NameSets OPTIONAL,
pFPs PacketFlags, -- Populate from packet flags
-- Applies to ALL of the corresponding
-- traffic selectors in the SelectorLists
condition SelectorLists, -- Policy "condition"
processing Processing -- Policy "action"
}
IPsecEntry:、:= 系列--各エントリーは名前NameSets OPTIONALから成ります、pFPs PacketFlags--、居住、パケットは弛みます--対応のすべて--SelectorLists状態SelectorListsでセレクタを取引します--方針「状態」処理Processing--方針「動作」に適用します。
BypassOrDiscardEntry ::= SEQUENCE {
bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD
condition InOutBound }
BypassOrDiscardEntry:、:= 系列迂回ブール、--TRUE BYPASS、FALSE DISCARDがInOutBoundを条件とさせる
InOutBound ::= CHOICE {
outbound [0] SelectorLists,
inbound [1] SelectorLists,
bothways [2] BothWays }
InOutBound:、:= 選択外国行きの[0]SelectorLists、本国行きの[1]SelectorLists、bothways[2]BothWays
Kent & Seo Standards Track [Page 82] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[82ページ]。
BothWays ::= SEQUENCE {
inbound SelectorLists,
outbound SelectorLists }
BothWays:、:= 系列本国行きのSelectorLists、外国行きのSelectorLists
NameSets ::= SEQUENCE {
passed SET OF Names-R, -- Matched to IKE ID by
-- responder
local SET OF Names-I } -- Used internally by IKE
-- initiator
NameSets:、:= SEQUENCEは応答者地方のSET OF Names-IをSET OF Names-R(IKE IDに合わせられている)に通過しました--IKEで、内用します--、創始者
Names-R ::= CHOICE { -- IKEv2 IDs
dName RDNSequence, -- ID_DER_ASN1_DN
fqdn FQDN, -- ID_FQDN
rfc822 [0] RFC822Name, -- ID_RFC822_ADDR
keyID OCTET STRING } -- KEY_ID
名前R:、:= CHOICE--IKEv2ID dName RDNSequence--ID_DER_ASN1_DN fqdn FQDN、--_ID FQDN rfc822[0]RFC822Name--ID_RFC822_ADDR keyID OCTET STRING--KEY_ID
Names-I ::= OCTET STRING -- Used internally by IKE
-- initiator
名前I:、:= OCTET STRING(IKEによって内部的に使用される)、創始者
FQDN ::= IA5String
FQDN:、:= IA5String
RFC822Name ::= IA5String
RFC822Name:、:= IA5String
PacketFlags ::= BIT STRING {
-- if set, take selector value from packet
-- establishing SA
-- else use value in SPD entry
localAddr (0),
remoteAddr (1),
protocol (2),
localPort (3),
remotePort (4) }
PacketFlags:、:= ビット列--設定されるなら、SPDエントリーlocalAddr(0)でパケット--SAを設立します--ほかの使用価値からセレクタ値を取ってください、remoteAddr(1)、プロトコル(2)、localPort(3)、remotePort(4)
SelectorLists ::= SET OF SelectorList
SelectorLists:、:= SelectorListのセット
SelectorList ::= SEQUENCE {
localAddr AddrList,
remoteAddr AddrList,
protocol ProtocolChoice }
SelectorList:、:= 系列localAddr AddrList(remoteAddr AddrList)はProtocolChoiceについて議定書の中で述べます。
Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment checking
lifetime SALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
以下を処理します:= SEQUENCE、extSeqNumのブール(TRUE64の噛み付いているカウンタ、seqOverflowブールであることで噛み付かれたFALSE32)のTRUE rekey、FALSEは生涯SALifetimeをチェックするfragCheckのブールの、そして、FALSEノーstatefulなTRUE stateful断片がチェックして、断片を、終えて、監査します、spi ManualSPI、アルゴリズムProcessingAlgs
Kent & Seo Standards Track [Page 83] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[83ページ]。
tunnel TunnelOptions OPTIONAL } -- if absent, use
-- transport mode
TunnelOptions OPTIONALにトンネルを堀ってください。 -- 使用--休んで、モードを輸送してくださいなら
SALifetime ::= SEQUENCE {
seconds [0] INTEGER OPTIONAL,
bytes [1] INTEGER OPTIONAL }
SALifetime ::= SEQUENCE { seconds [0] INTEGER OPTIONAL, bytes [1] INTEGER OPTIONAL }
ManualSPI ::= SEQUENCE {
spi INTEGER,
keys KeyIDs }
ManualSPI ::= SEQUENCE { spi INTEGER, keys KeyIDs }
KeyIDs ::= SEQUENCE OF OCTET STRING
KeyIDs ::= SEQUENCE OF OCTET STRING
ProcessingAlgs ::= CHOICE {
ah [0] IntegrityAlgs, -- AH
esp [1] ESPAlgs} -- ESP
ProcessingAlgs ::= CHOICE { ah [0] IntegrityAlgs, -- AH esp [1] ESPAlgs} -- ESP
ESPAlgs ::= CHOICE {
integrity [0] IntegrityAlgs, -- integrity only
confidentiality [1] ConfidentialityAlgs, -- confidentiality
-- only
both [2] IntegrityConfidentialityAlgs,
combined [3] CombinedModeAlgs }
ESPAlgs ::= CHOICE { integrity [0] IntegrityAlgs, -- integrity only confidentiality [1] ConfidentialityAlgs, -- confidentiality -- only both [2] IntegrityConfidentialityAlgs, combined [3] CombinedModeAlgs }
IntegrityConfidentialityAlgs ::= SEQUENCE {
integrity IntegrityAlgs,
confidentiality ConfidentialityAlgs }
IntegrityConfidentialityAlgs ::= SEQUENCE { integrity IntegrityAlgs, confidentiality ConfidentialityAlgs }
-- Integrity Algorithms, ordered by decreasing preference
IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
-- Integrity Algorithms, ordered by decreasing preference IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
-- Confidentiality Algorithms, ordered by decreasing preference
ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
-- Confidentiality Algorithms, ordered by decreasing preference ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
-- Integrity Algorithms
IntegrityAlg ::= SEQUENCE {
algorithm IntegrityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
-- Integrity Algorithms IntegrityAlg ::= SEQUENCE { algorithm IntegrityAlgType, parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
IntegrityAlgType ::= INTEGER {
none (0),
auth-HMAC-MD5-96 (1),
auth-HMAC-SHA1-96 (2),
auth-DES-MAC (3),
auth-KPDK-MD5 (4),
auth-AES-XCBC-96 (5)
-- tbd (6..65535)
}
IntegrityAlgType ::= INTEGER { none (0), auth-HMAC-MD5-96 (1), auth-HMAC-SHA1-96 (2), auth-DES-MAC (3), auth-KPDK-MD5 (4), auth-AES-XCBC-96 (5) -- tbd (6..65535) }
Kent & Seo Standards Track [Page 84] RFC 4301 Security Architecture for IP December 2005
Kent & Seo Standards Track [Page 84] RFC 4301 Security Architecture for IP December 2005
-- Confidentiality Algorithms
ConfidentialityAlg ::= SEQUENCE {
algorithm ConfidentialityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
-- Confidentiality Algorithms ConfidentialityAlg ::= SEQUENCE { algorithm ConfidentialityAlgType, parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
ConfidentialityAlgType ::= INTEGER {
encr-DES-IV64 (1),
encr-DES (2),
encr-3DES (3),
encr-RC5 (4),
encr-IDEA (5),
encr-CAST (6),
encr-BLOWFISH (7),
encr-3IDEA (8),
encr-DES-IV32 (9),
encr-RC4 (10),
encr-NULL (11),
encr-AES-CBC (12),
encr-AES-CTR (13)
-- tbd (14..65535)
}
ConfidentialityAlgType ::= INTEGER { encr-DES-IV64 (1), encr-DES (2), encr-3DES (3), encr-RC5 (4), encr-IDEA (5), encr-CAST (6), encr-BLOWFISH (7), encr-3IDEA (8), encr-DES-IV32 (9), encr-RC4 (10), encr-NULL (11), encr-AES-CBC (12), encr-AES-CTR (13) -- tbd (14..65535) }
CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
CombinedModeAlg ::= SEQUENCE {
algorithm CombinedModeType,
parameters ANY -- DEFINED BY algorithm} -- defined outside
-- of this document for AES modes.
CombinedModeAlg ::= SEQUENCE { algorithm CombinedModeType, parameters ANY -- DEFINED BY algorithm} -- defined outside -- of this document for AES modes.
CombinedModeType ::= INTEGER {
comb-AES-CCM (1),
comb-AES-GCM (2)
-- tbd (3..65535)
}
CombinedModeType ::= INTEGER { comb-AES-CCM (1), comb-AES-GCM (2) -- tbd (3..65535) }
TunnelOptions ::= SEQUENCE {
dscp DSCP,
ecn BOOLEAN, -- TRUE Copy CE to inner header
df DF,
addresses TunnelAddresses }
TunnelOptions ::= SEQUENCE { dscp DSCP, ecn BOOLEAN, -- TRUE Copy CE to inner header df DF, addresses TunnelAddresses }
TunnelAddresses ::= CHOICE {
ipv4 IPv4Pair,
ipv6 [0] IPv6Pair }
TunnelAddresses ::= CHOICE { ipv4 IPv4Pair, ipv6 [0] IPv6Pair }
IPv4Pair ::= SEQUENCE {
local OCTET STRING (SIZE(4)),
remote OCTET STRING (SIZE(4)) }
IPv4Pair ::= SEQUENCE { local OCTET STRING (SIZE(4)), remote OCTET STRING (SIZE(4)) }
Kent & Seo Standards Track [Page 85] RFC 4301 Security Architecture for IP December 2005
Kent & Seo Standards Track [Page 85] RFC 4301 Security Architecture for IP December 2005
IPv6Pair ::= SEQUENCE {
local OCTET STRING (SIZE(16)),
remote OCTET STRING (SIZE(16)) }
IPv6Pair ::= SEQUENCE { local OCTET STRING (SIZE(16)), remote OCTET STRING (SIZE(16)) }
DSCP ::= SEQUENCE {
copy BOOLEAN, -- TRUE copy from inner header
-- FALSE do not copy
mapping OCTET STRING OPTIONAL} -- points to table
-- if no copy
DSCP ::= SEQUENCE { copy BOOLEAN, -- TRUE copy from inner header -- FALSE do not copy mapping OCTET STRING OPTIONAL} -- points to table -- if no copy
DF ::= INTEGER {
clear (0),
set (1),
copy (2) }
DF ::= INTEGER { clear (0), set (1), copy (2) }
ProtocolChoice::= CHOICE {
anyProt AnyProtocol, -- for ANY protocol
noNext [0] NoNextLayerProtocol, -- has no next layer
-- items
oneNext [1] OneNextLayerProtocol, -- has one next layer
-- item
twoNext [2] TwoNextLayerProtocol, -- has two next layer
-- items
fragment FragmentNoNext } -- has no next layer
-- info
ProtocolChoice::= CHOICE { anyProt AnyProtocol, -- for ANY protocol noNext [0] NoNextLayerProtocol, -- has no next layer -- items oneNext [1] OneNextLayerProtocol, -- has one next layer -- item twoNext [2] TwoNextLayerProtocol, -- has two next layer -- items fragment FragmentNoNext } -- has no next layer -- info
AnyProtocol ::= SEQUENCE {
id INTEGER (0), -- ANY protocol
nextLayer AnyNextLayers }
AnyProtocol ::= SEQUENCE { id INTEGER (0), -- ANY protocol nextLayer AnyNextLayers }
AnyNextLayers ::= SEQUENCE { -- with either
first AnyNextLayer, -- ANY next layer selector
second AnyNextLayer } -- ANY next layer selector
AnyNextLayers ::= SEQUENCE { -- with either first AnyNextLayer, -- ANY next layer selector second AnyNextLayer } -- ANY next layer selector
NoNextLayerProtocol ::= INTEGER (2..254)
NoNextLayerProtocol ::= INTEGER (2..254)
FragmentNoNext ::= INTEGER (44) -- Fragment identifier
FragmentNoNext ::= INTEGER (44) -- Fragment identifier
OneNextLayerProtocol ::= SEQUENCE {
id INTEGER (1..254), -- ICMP, MH, ICMPv6
nextLayer NextLayerChoice } -- ICMP Type*256+Code
-- MH Type*256
OneNextLayerProtocol ::= SEQUENCE { id INTEGER (1..254), -- ICMP, MH, ICMPv6 nextLayer NextLayerChoice } -- ICMP Type*256+Code -- MH Type*256
TwoNextLayerProtocol ::= SEQUENCE {
id INTEGER (2..254), -- Protocol
local NextLayerChoice, -- Local and
remote NextLayerChoice } -- Remote ports
TwoNextLayerProtocol ::= SEQUENCE { id INTEGER (2..254), -- Protocol local NextLayerChoice, -- Local and remote NextLayerChoice } -- Remote ports
Kent & Seo Standards Track [Page 86] RFC 4301 Security Architecture for IP December 2005
Kent & Seo Standards Track [Page 86] RFC 4301 Security Architecture for IP December 2005
NextLayerChoice ::= CHOICE {
any AnyNextLayer,
opaque [0] OpaqueNextLayer,
range [1] NextLayerRange }
NextLayerChoice ::= CHOICE { any AnyNextLayer, opaque [0] OpaqueNextLayer, range [1] NextLayerRange }
-- Representation of ANY in next layer field
AnyNextLayer ::= SEQUENCE {
start INTEGER (0),
end INTEGER (65535) }
-- Representation of ANY in next layer field AnyNextLayer ::= SEQUENCE { start INTEGER (0), end INTEGER (65535) }
-- Representation of OPAQUE in next layer field.
-- Matches IKE convention
OpaqueNextLayer ::= SEQUENCE {
start INTEGER (65535),
end INTEGER (0) }
-- Representation of OPAQUE in next layer field. -- Matches IKE convention OpaqueNextLayer ::= SEQUENCE { start INTEGER (65535), end INTEGER (0) }
-- Range for a next layer field
NextLayerRange ::= SEQUENCE {
start INTEGER (0..65535),
end INTEGER (0..65535) }
-- Range for a next layer field NextLayerRange ::= SEQUENCE { start INTEGER (0..65535), end INTEGER (0..65535) }
-- List of IP addresses
AddrList ::= SEQUENCE {
v4List IPv4List OPTIONAL,
v6List [0] IPv6List OPTIONAL }
-- List of IP addresses AddrList ::= SEQUENCE { v4List IPv4List OPTIONAL, v6List [0] IPv6List OPTIONAL }
-- IPv4 address representations
IPv4List ::= SEQUENCE OF IPv4Range
-- IPv4 address representations IPv4List ::= SEQUENCE OF IPv4Range
IPv4Range ::= SEQUENCE { -- close, but not quite right ...
ipv4Start OCTET STRING (SIZE (4)),
ipv4End OCTET STRING (SIZE (4)) }
IPv4Range ::= SEQUENCE { -- close, but not quite right ... ipv4Start OCTET STRING (SIZE (4)), ipv4End OCTET STRING (SIZE (4)) }
-- IPv6 address representations
IPv6List ::= SEQUENCE OF IPv6Range
-- IPv6 address representations IPv6List ::= SEQUENCE OF IPv6Range
IPv6Range ::= SEQUENCE { -- close, but not quite right ...
ipv6Start OCTET STRING (SIZE (16)),
ipv6End OCTET STRING (SIZE (16)) }
IPv6Range ::= SEQUENCE { -- close, but not quite right ... ipv6Start OCTET STRING (SIZE (16)), ipv6End OCTET STRING (SIZE (16)) }
END
END
Kent & Seo Standards Track [Page 87] RFC 4301 Security Architecture for IP December 2005
Kent & Seo Standards Track [Page 87] RFC 4301 Security Architecture for IP December 2005
Appendix D: Fragment Handling Rationale
Appendix D: Fragment Handling Rationale
There are three issues that must be resolved regarding processing of (plaintext) fragments in IPsec:
There are three issues that must be resolved regarding processing of (plaintext) fragments in IPsec:
- mapping a non-initial, outbound fragment to the right SA
(or finding the right SPD entry)
- verifying that a received, non-initial fragment is authorized
for the SA via which it is received
- mapping outbound and inbound non-initial fragments to the
right SPD/cache entry, for BYPASS/DISCARD traffic
- mapping a non-initial, outbound fragment to the right SA (or finding the right SPD entry) - verifying that a received, non-initial fragment is authorized for the SA via which it is received - mapping outbound and inbound non-initial fragments to the right SPD/cache entry, for BYPASS/DISCARD traffic
The first and third issues arise because we need a deterministic algorithm for mapping traffic to SAs (and SPD/cache entries). All three issues are important because we want to make sure that non-initial fragments that cross the IPsec boundary do not cause the access control policies in place at the receiver (or transmitter) to be violated.
The first and third issues arise because we need a deterministic algorithm for mapping traffic to SAs (and SPD/cache entries). All three issues are important because we want to make sure that non-initial fragments that cross the IPsec boundary do not cause the access control policies in place at the receiver (or transmitter) to be violated.
D.1. Transport Mode and Fragments
D.1. Transport Mode and Fragments
First, we note that transport mode SAs have been defined to not carry fragments. This is a carryover from RFC 2401, where transport mode SAs always terminated at endpoints. This is a fundamental requirement because, in the worst case, an IPv4 fragment to which IPsec was applied might then be fragmented (as a ciphertext packet), en route to the destination. IP fragment reassembly procedures at the IPsec receiver would not be able to distinguish between pre-IPsec fragments and fragments created after IPsec processing.
First, we note that transport mode SAs have been defined to not carry fragments. This is a carryover from RFC 2401, where transport mode SAs always terminated at endpoints. This is a fundamental requirement because, in the worst case, an IPv4 fragment to which IPsec was applied might then be fragmented (as a ciphertext packet), en route to the destination. IP fragment reassembly procedures at the IPsec receiver would not be able to distinguish between pre-IPsec fragments and fragments created after IPsec processing.
For IPv6, only the sender is allowed to fragment a packet. As for IPv4, an IPsec implementation is allowed to fragment tunnel mode packets after IPsec processing, because it is the sender relative to the (outer) tunnel header. However, unlike IPv4, it would be feasible to carry a plaintext fragment on a transport mode SA, because the fragment header in IPv6 would appear after the AH or ESP header, and thus would not cause confusion at the receiver with respect to reassembly. Specifically, the receiver would not attempt reassembly for the fragment until after IPsec processing. To keep things simple, this specification prohibits carriage of fragments on transport mode SAs for IPv6 traffic.
For IPv6, only the sender is allowed to fragment a packet. As for IPv4, an IPsec implementation is allowed to fragment tunnel mode packets after IPsec processing, because it is the sender relative to the (outer) tunnel header. However, unlike IPv4, it would be feasible to carry a plaintext fragment on a transport mode SA, because the fragment header in IPv6 would appear after the AH or ESP header, and thus would not cause confusion at the receiver with respect to reassembly. Specifically, the receiver would not attempt reassembly for the fragment until after IPsec processing. To keep things simple, this specification prohibits carriage of fragments on transport mode SAs for IPv6 traffic.
When only end systems used transport mode SAs, the prohibition on carriage of fragments was not a problem, since we assumed that the end system could be configured to not offer a fragment to IPsec. For a native host implementation, this seems reasonable, and, as someone already noted, RFC 2401 warned that a BITS implementation might have to reassemble fragments before performing an SA lookup. (It would
When only end systems used transport mode SAs, the prohibition on carriage of fragments was not a problem, since we assumed that the end system could be configured to not offer a fragment to IPsec. For a native host implementation, this seems reasonable, and, as someone already noted, RFC 2401 warned that a BITS implementation might have to reassemble fragments before performing an SA lookup. (It would
Kent & Seo Standards Track [Page 88] RFC 4301 Security Architecture for IP December 2005
Kent & Seo Standards Track [Page 88] RFC 4301 Security Architecture for IP December 2005
then apply AH or ESP and could re-fragment the packet after IPsec processing.) Because a BITS implementation is assumed to be able to have access to all traffic emanating from its host, even if the host has multiple interfaces, this was deemed a reasonable mandate.
then apply AH or ESP and could re-fragment the packet after IPsec processing.) Because a BITS implementation is assumed to be able to have access to all traffic emanating from its host, even if the host has multiple interfaces, this was deemed a reasonable mandate.
In this specification, it is acceptable to use transport mode in cases where the IPsec implementation is not the ultimate destination, e.g., between two SGs. In principle, this creates a new opportunity for outbound, plaintext fragments to be mapped to a transport mode SA for IPsec processing. However, in these new contexts in which a transport mode SA is now approved for use, it seems likely that we can continue to prohibit transmission of fragments, as seen by IPsec, i.e., packets that have an "outer header" with a non-zero fragment offset field. For example, in an IP overlay network, packets being sent over transport mode SAs are IP-in-IP tunneled and thus have the necessary inner header to accommodate fragmentation prior to IPsec processing. When carried via a transport mode SA, IPsec would not examine the inner IP header for such traffic, and thus would not consider the packet to be a fragment.
In this specification, it is acceptable to use transport mode in cases where the IPsec implementation is not the ultimate destination, e.g., between two SGs. In principle, this creates a new opportunity for outbound, plaintext fragments to be mapped to a transport mode SA for IPsec processing. However, in these new contexts in which a transport mode SA is now approved for use, it seems likely that we can continue to prohibit transmission of fragments, as seen by IPsec, i.e., packets that have an "outer header" with a non-zero fragment offset field. For example, in an IP overlay network, packets being sent over transport mode SAs are IP-in-IP tunneled and thus have the necessary inner header to accommodate fragmentation prior to IPsec processing. When carried via a transport mode SA, IPsec would not examine the inner IP header for such traffic, and thus would not consider the packet to be a fragment.
D.2. Tunnel Mode and Fragments
D.2. Tunnel Mode and Fragments
For tunnel mode SAs, it has always been the case that outbound fragments might arrive for processing at an IPsec implementation. The need to accommodate fragmented outbound packets can pose a problem because a non-initial fragment generally will not contain the port fields associated with a next layer protocol such as TCP, UDP, or SCTP. Thus, depending on the SPD configuration for a given IPsec implementation, plaintext fragments might or might not pose a problem.
For tunnel mode SAs, it has always been the case that outbound fragments might arrive for processing at an IPsec implementation. The need to accommodate fragmented outbound packets can pose a problem because a non-initial fragment generally will not contain the port fields associated with a next layer protocol such as TCP, UDP, or SCTP. Thus, depending on the SPD configuration for a given IPsec implementation, plaintext fragments might or might not pose a problem.
For example, if the SPD requires that all traffic between two address ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries apply to this address range), then it should be easy to carry non-initial fragments on the SA defined for this address range, since the SPD entry implies an intent to carry ALL traffic between the address ranges. But, if there are multiple SPD entries that could match a fragment, and if these entries reference different subsets of port fields (vs. ANY), then it is not possible to map an outbound non-initial fragment to the right entry, unambiguously. (If we choose to allow carriage of fragments on transport mode SAs for IPv6, the problems arises in that context as well.)
For example, if the SPD requires that all traffic between two address ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries apply to this address range), then it should be easy to carry non-initial fragments on the SA defined for this address range, since the SPD entry implies an intent to carry ALL traffic between the address ranges. But, if there are multiple SPD entries that could match a fragment, and if these entries reference different subsets of port fields (vs. ANY), then it is not possible to map an outbound non-initial fragment to the right entry, unambiguously. (If we choose to allow carriage of fragments on transport mode SAs for IPv6, the problems arises in that context as well.)
This problem largely, though not exclusively, motivated the definition of OPAQUE as a selector value for port fields in RFC 2401. The other motivation for OPAQUE is the observation that port fields might not be accessible due to the prior application of IPsec. For example, if a host applied IPsec to its traffic and that traffic
This problem largely, though not exclusively, motivated the definition of OPAQUE as a selector value for port fields in RFC 2401. The other motivation for OPAQUE is the observation that port fields might not be accessible due to the prior application of IPsec. For example, if a host applied IPsec to its traffic and that traffic
Kent & Seo Standards Track [Page 89] RFC 4301 Security Architecture for IP December 2005
Kent & Seo Standards Track [Page 89] RFC 4301 Security Architecture for IP December 2005
arrived at an SG, these fields would be encrypted. The algorithm specified for locating the "next layer protocol" described in RFC 2401 also motivated use of OPAQUE to accommodate an encrypted next layer protocol field in such circumstances. Nonetheless, the primary use of the OPAQUE value was to match traffic selector fields in packets that did not contain port fields (non-initial fragments), or packets in which the port fields were already encrypted (as a result of nested application of IPsec). RFC 2401 was ambiguous in discussing the use of OPAQUE vs. ANY, suggesting in some places that ANY might be an alternative to OPAQUE.
arrived at an SG, these fields would be encrypted. The algorithm specified for locating the "next layer protocol" described in RFC 2401 also motivated use of OPAQUE to accommodate an encrypted next layer protocol field in such circumstances. Nonetheless, the primary use of the OPAQUE value was to match traffic selector fields in packets that did not contain port fields (non-initial fragments), or packets in which the port fields were already encrypted (as a result of nested application of IPsec). RFC 2401 was ambiguous in discussing the use of OPAQUE vs. ANY, suggesting in some places that ANY might be an alternative to OPAQUE.
We gain additional access control capability by defining both ANY and OPAQUE values. OPAQUE can be defined to match only fields that are not accessible. We could define ANY as the complement of OPAQUE, i.e., it would match all values but only for accessible port fields. We have therefore simplified the procedure employed to locate the next layer protocol in this document, so that we treat ESP and AH as next layer protocols. As a result, the notion of an encrypted next layer protocol field has vanished, and there is also no need to worry about encrypted port fields either. And accordingly, OPAQUE will be applicable only to non-initial fragments.
We gain additional access control capability by defining both ANY and OPAQUE values. OPAQUE can be defined to match only fields that are not accessible. We could define ANY as the complement of OPAQUE, i.e., it would match all values but only for accessible port fields. We have therefore simplified the procedure employed to locate the next layer protocol in this document, so that we treat ESP and AH as next layer protocols. As a result, the notion of an encrypted next layer protocol field has vanished, and there is also no need to worry about encrypted port fields either. And accordingly, OPAQUE will be applicable only to non-initial fragments.
Since we have adopted the definitions above for ANY and OPAQUE, we need to clarify how these values work when the specified protocol does not have port fields, and when ANY is used for the protocol selector. Accordingly, if a specific protocol value is used as a selector, and if that protocol has no port fields, then the port field selectors are to be ignored and ANY MUST be specified as the value for the port fields. (In this context, ICMP TYPE and CODE values are lumped together as a single port field (for IKEv2 negotiation), as is the IPv6 Mobility Header TYPE value.) If the protocol selector is ANY, then this should be treated as equivalent to specifying a protocol for which no port fields are defined, and thus the port selectors should be ignored, and MUST be set to ANY.
Since we have adopted the definitions above for ANY and OPAQUE, we need to clarify how these values work when the specified protocol does not have port fields, and when ANY is used for the protocol selector. Accordingly, if a specific protocol value is used as a selector, and if that protocol has no port fields, then the port field selectors are to be ignored and ANY MUST be specified as the value for the port fields. (In this context, ICMP TYPE and CODE values are lumped together as a single port field (for IKEv2 negotiation), as is the IPv6 Mobility Header TYPE value.) If the protocol selector is ANY, then this should be treated as equivalent to specifying a protocol for which no port fields are defined, and thus the port selectors should be ignored, and MUST be set to ANY.
D.3. The Problem of Non-Initial Fragments
D.3. The Problem of Non-Initial Fragments
For an SG implementation, it is obvious that fragments might arrive from end systems behind the SG. A BITW implementation also may encounter fragments from a host or gateway behind it. (As noted earlier, native host implementations and BITS implementations probably can avoid the problems described below.) In the worst case, fragments from a packet might arrive at distinct BITW or SG instantiations and thus preclude reassembly as a solution option. Hence, in RFC 2401 we adopted a general requirement that fragments must be accommodated in tunnel mode for all implementations. However,
For an SG implementation, it is obvious that fragments might arrive from end systems behind the SG. A BITW implementation also may encounter fragments from a host or gateway behind it. (As noted earlier, native host implementations and BITS implementations probably can avoid the problems described below.) In the worst case, fragments from a packet might arrive at distinct BITW or SG instantiations and thus preclude reassembly as a solution option. Hence, in RFC 2401 we adopted a general requirement that fragments must be accommodated in tunnel mode for all implementations. However,
Kent & Seo Standards Track [Page 90] RFC 4301 Security Architecture for IP December 2005
Kent & Seo Standards Track [Page 90] RFC 4301 Security Architecture for IP December 2005
RFC 2401 did not provide a perfect solution. The use of OPAQUE as a selector value for port fields (a SHOULD in RFC 2401) allowed an SA to carry non-initial fragments.
RFC 2401 did not provide a perfect solution. The use of OPAQUE as a selector value for port fields (a SHOULD in RFC 2401) allowed an SA to carry non-initial fragments.
Using the features defined in RFC 2401, if one defined an SA between two IPsec (SG or BITW) implementations using the OPAQUE value for both port fields, then all non-initial fragments matching the source/destination (S/D) address and protocol values for the SA would be mapped to that SA. Initial fragments would NOT map to this SA, if we adopt a strict definition of OPAQUE. However, RFC 2401 did not provide detailed guidance on this and thus it may not have been apparent that use of this feature would essentially create a "non-initial fragment only" SA.
Using the features defined in RFC 2401, if one defined an SA between two IPsec (SG or BITW) implementations using the OPAQUE value for both port fields, then all non-initial fragments matching the source/destination (S/D) address and protocol values for the SA would be mapped to that SA. Initial fragments would NOT map to this SA, if we adopt a strict definition of OPAQUE. However, RFC 2401 did not provide detailed guidance on this and thus it may not have been apparent that use of this feature would essentially create a "non-initial fragment only" SA.
In the course of discussing the "fragment-only" SA approach, it was noted that some subtle problems, problems not considered in RFC 2401, would have to be avoided. For example, an SA of this sort must be configured to offer the "highest quality" security services for any traffic between the indicated S/D addresses (for the specified protocol). This is necessary to ensure that any traffic captured by the fragment-only SA is not offered degraded security relative to what it would have been offered if the packet were not fragmented. A possible problem here is that we may not be able to identify the "highest quality" security services defined for use between two IPsec implementation, since the choice of security protocols, options, and algorithms is a lattice, not a totally ordered set. (We might safely say that BYPASS < AH < ESP w/integrity, but it gets complicated if we have multiple ESP encryption or integrity algorithm options.) So, one has to impose a total ordering on these security parameters to make this work, but this can be done locally.
In the course of discussing the "fragment-only" SA approach, it was noted that some subtle problems, problems not considered in RFC 2401, would have to be avoided. For example, an SA of this sort must be configured to offer the "highest quality" security services for any traffic between the indicated S/D addresses (for the specified protocol). This is necessary to ensure that any traffic captured by the fragment-only SA is not offered degraded security relative to what it would have been offered if the packet were not fragmented. A possible problem here is that we may not be able to identify the "highest quality" security services defined for use between two IPsec implementation, since the choice of security protocols, options, and algorithms is a lattice, not a totally ordered set. (We might safely say that BYPASS < AH < ESP w/integrity, but it gets complicated if we have multiple ESP encryption or integrity algorithm options.) So, one has to impose a total ordering on these security parameters to make this work, but this can be done locally.
However, this conservative strategy has a possible performance downside. If most traffic traversing an IPsec implementation for a given S/D address pair (and specified protocol) is bypassed, then a fragment-only SA for that address pair might cause a dramatic increase in the volume of traffic afforded crypto processing. If the crypto implementation cannot support high traffic rates, this could cause problems. (An IPsec implementation that is capable of line rate or near line rate crypto performance would not be adversely affected by this SA configuration approach. Nonetheless, the performance impact is a potential concern, specific to implementation capabilities.)
However, this conservative strategy has a possible performance downside. If most traffic traversing an IPsec implementation for a given S/D address pair (and specified protocol) is bypassed, then a fragment-only SA for that address pair might cause a dramatic increase in the volume of traffic afforded crypto processing. If the crypto implementation cannot support high traffic rates, this could cause problems. (An IPsec implementation that is capable of line rate or near line rate crypto performance would not be adversely affected by this SA configuration approach. Nonetheless, the performance impact is a potential concern, specific to implementation capabilities.)
Another concern is that non-initial fragments sent over a dedicated SA might be used to effect overlapping reassembly attacks, when combined with an apparently acceptable initial fragment. (This sort of attack assumes creation of bogus fragments and is not a side effect of normal fragmentation.) This concern is easily addressed in
Another concern is that non-initial fragments sent over a dedicated SA might be used to effect overlapping reassembly attacks, when combined with an apparently acceptable initial fragment. (This sort of attack assumes creation of bogus fragments and is not a side effect of normal fragmentation.) This concern is easily addressed in
Kent & Seo Standards Track [Page 91] RFC 4301 Security Architecture for IP December 2005
Kent & Seo Standards Track [Page 91] RFC 4301 Security Architecture for IP December 2005
IPv4, by checking the fragment offset value to ensure that no non-initial fragments have a small enough offset to overlap port fields that should be contained in the initial fragment. Recall that the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 bytes, so any ports should be present in the initial fragment. If we require all non-initial fragments to have an offset of, say, 128 or greater, just to be on the safe side, this should prevent successful attacks of this sort. If the intent is only to protect against this sort of reassembly attack, this check need be implemented only by a receiver.
IPv4, by checking the fragment offset value to ensure that no non-initial fragments have a small enough offset to overlap port fields that should be contained in the initial fragment. Recall that the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 bytes, so any ports should be present in the initial fragment. If we require all non-initial fragments to have an offset of, say, 128 or greater, just to be on the safe side, this should prevent successful attacks of this sort. If the intent is only to protect against this sort of reassembly attack, this check need be implemented only by a receiver.
IPv6 also has a fragment offset, carried in the fragmentation extension header. However, IPv6 extension headers are variable in length and there is no analogous max header length value that we can use to check non-initial fragments, to reject ones that might be used for an attack of the sort noted above. A receiver would need to maintain state analogous to reassembly state, to provide equivalent protection. So, only for IPv4 is it feasible to impose a fragment offset check that would reject attacks designed to circumvent port field checks by IPsec (or firewalls) when passing non-initial fragments.
IPv6 also has a fragment offset, carried in the fragmentation extension header. However, IPv6 extension headers are variable in length and there is no analogous max header length value that we can use to check non-initial fragments, to reject ones that might be used for an attack of the sort noted above. A receiver would need to maintain state analogous to reassembly state, to provide equivalent protection. So, only for IPv4 is it feasible to impose a fragment offset check that would reject attacks designed to circumvent port field checks by IPsec (or firewalls) when passing non-initial fragments.
Another possible concern is that in some topologies and SPD configurations this approach might result in an access control surprise. The notion is that if we create an SA to carry ALL (non-initial) fragments, then that SA would carry some traffic that might otherwise arrive as plaintext via a separate path, e.g., a path monitored by a proxy firewall. But, this concern arises only if the other path allows initial fragments to traverse it without requiring reassembly, presumably a bad idea for a proxy firewall. Nonetheless, this does represent a potential problem in some topologies and under certain assumptions with respect to SPD and (other) firewall rule sets, and administrators need to be warned of this possibility.
Another possible concern is that in some topologies and SPD configurations this approach might result in an access control surprise. The notion is that if we create an SA to carry ALL (non-initial) fragments, then that SA would carry some traffic that might otherwise arrive as plaintext via a separate path, e.g., a path monitored by a proxy firewall. But, this concern arises only if the other path allows initial fragments to traverse it without requiring reassembly, presumably a bad idea for a proxy firewall. Nonetheless, this does represent a potential problem in some topologies and under certain assumptions with respect to SPD and (other) firewall rule sets, and administrators need to be warned of this possibility.
A less serious concern is that non-initial fragments sent over a non-initial fragment-only SA might represent a DoS opportunity, in that they could be sent when no valid, initial fragment will ever arrive. This might be used to attack hosts behind an SG or BITW device. However, the incremental risk posed by this sort of attack, which can be mounted only by hosts behind an SG or BITW device, seems small.
A less serious concern is that non-initial fragments sent over a non-initial fragment-only SA might represent a DoS opportunity, in that they could be sent when no valid, initial fragment will ever arrive. This might be used to attack hosts behind an SG or BITW device. However, the incremental risk posed by this sort of attack, which can be mounted only by hosts behind an SG or BITW device, seems small.
If we interpret the ANY selector value as encompassing OPAQUE, then a single SA with ANY values for both port fields would be able to accommodate all traffic matching the S/D address and protocol traffic selectors, an alternative to using the OPAQUE value. But, using ANY
If we interpret the ANY selector value as encompassing OPAQUE, then a single SA with ANY values for both port fields would be able to accommodate all traffic matching the S/D address and protocol traffic selectors, an alternative to using the OPAQUE value. But, using ANY
Kent & Seo Standards Track [Page 92] RFC 4301 Security Architecture for IP December 2005
Kent & Seo Standards Track [Page 92] RFC 4301 Security Architecture for IP December 2005
here precludes multiple, distinct SAs between the same IPsec implementations for the same address pairs and protocol. So, it is not an exactly equivalent alternative.
here precludes multiple, distinct SAs between the same IPsec implementations for the same address pairs and protocol. So, it is not an exactly equivalent alternative.
Fundamentally, fragment handling problems arise only when more than one SA is defined with the same S/D address and protocol selector values, but with different port field selector values.
Fundamentally, fragment handling problems arise only when more than one SA is defined with the same S/D address and protocol selector values, but with different port field selector values.
D.4. BYPASS/DISCARD Traffic
D.4. BYPASS/DISCARD Traffic
We also have to address the non-initial fragment processing issue for BYPASS/DISCARD entries, independent of SA processing. This is largely a local matter for two reasons:
We also have to address the non-initial fragment processing issue for BYPASS/DISCARD entries, independent of SA processing. This is largely a local matter for two reasons:
1) We have no means for coordinating SPD entries for such
traffic between IPsec implementations since IKE is not
invoked.
2) Many of these entries refer to traffic that is NOT
directed to or received from a location that is using
IPsec. So there is no peer IPsec implementation with
which to coordinate via any means.
1) We have no means for coordinating SPD entries for such traffic between IPsec implementations since IKE is not invoked. 2) Many of these entries refer to traffic that is NOT directed to or received from a location that is using IPsec. So there is no peer IPsec implementation with which to coordinate via any means.
However, this document should provide guidance here, consistent with our goal of offering a well-defined, access control function for all traffic, relative to the IPsec boundary. To that end, this document says that implementations MUST support fragment reassembly for BYPASS/DISCARD traffic when port fields are specified. An implementation also MUST permit a user or administrator to accept such traffic or reject such traffic using the SPD conventions described in Section 4.4.1. The concern is that BYPASS of a cleartext, non-initial fragment arriving at an IPsec implementation could undermine the security afforded IPsec-protected traffic directed to the same destination. For example, consider an IPsec implementation configured with an SPD entry that calls for IPsec-protection of traffic between a specific source/destination address pair, and for a specific protocol and destination port, e.g., TCP traffic on port 23 (Telnet). Assume that the implementation also allows BYPASS of traffic from the same source/destination address pair and protocol, but for a different destination port, e.g., port 119 (NNTP). An attacker could send a non-initial fragment (with a forged source address) that, if bypassed, could overlap with IPsec-protected traffic from the same source and thus violate the integrity of the IPsec-protected traffic. Requiring stateful fragment checking for BYPASS entries with non-trivial port ranges prevents attacks of this sort.
However, this document should provide guidance here, consistent with our goal of offering a well-defined, access control function for all traffic, relative to the IPsec boundary. To that end, this document says that implementations MUST support fragment reassembly for BYPASS/DISCARD traffic when port fields are specified. An implementation also MUST permit a user or administrator to accept such traffic or reject such traffic using the SPD conventions described in Section 4.4.1. The concern is that BYPASS of a cleartext, non-initial fragment arriving at an IPsec implementation could undermine the security afforded IPsec-protected traffic directed to the same destination. For example, consider an IPsec implementation configured with an SPD entry that calls for IPsec-protection of traffic between a specific source/destination address pair, and for a specific protocol and destination port, e.g., TCP traffic on port 23 (Telnet). Assume that the implementation also allows BYPASS of traffic from the same source/destination address pair and protocol, but for a different destination port, e.g., port 119 (NNTP). An attacker could send a non-initial fragment (with a forged source address) that, if bypassed, could overlap with IPsec-protected traffic from the same source and thus violate the integrity of the IPsec-protected traffic. Requiring stateful fragment checking for BYPASS entries with non-trivial port ranges prevents attacks of this sort.
Kent & Seo Standards Track [Page 93] RFC 4301 Security Architecture for IP December 2005
Kent & Seo Standards Track [Page 93] RFC 4301 Security Architecture for IP December 2005
D.5. Just say no to ports?
D.5. Just say no to ports?
It has been suggested that we could avoid the problems described above by not allowing port field selectors to be used in tunnel mode. But the discussion above shows this to be an unnecessarily stringent approach, i.e., since no problems arise for the native OS and BITS implementations. Moreover, some WG members have described scenarios where use of tunnel mode SAs with (non-trivial) port field selectors is appropriate. So the challenge is defining a strategy that can deal with this problem in BITW and SG contexts. Also note that BYPASS/DISCARD entries in the SPD that make use of ports pose the same problems, irrespective of tunnel vs. transport mode notions.
私たちがポート分野セレクタがトンネルモードで使用されるのを許容しないことによって上で説明された問題を避けることができたことが提案されました。 しかし、上の議論は、これが不必要に厳しいアプローチであることを示します、すなわち、問題が全く固有のOSとBITS実装のために起こらないので。 そのうえ、何人かのWGメンバーが(重要)のポート分野セレクタによるトンネルモードSAsの使用が適切であるシナリオについて説明しました。 それで、挑戦はBITWとSG文脈でこの問題に対処できる戦略を定義しています。 また、ポートを利用するSPDのBYPASS/DISCARDエントリーが同じ問題を引き起こすことに注意してください、トンネルでは、交通機関概念に対して関係ありません。
Some folks have suggested that a firewall behind an SG or BITW should be left to enforce port-level access controls and the effects of fragmentation. However, this seems to be an incongruous suggestion in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned about firewalls that always discard fragments. If many firewalls don't pass fragments in general, why should we expect them to deal with fragments in this case? So, this analysis rejects the suggestion of disallowing use of port field selectors with tunnel mode SAs.
人々の中にはSGかBITWの後ろのファイアウォールがポートレベルアクセス制御と断片化の効果を実施するのが残されるべきであると示唆した人もいました。 しかしながら、これは断片が私たちがIPsec(例えば、IKEペイロードの)では、ファイアウォールに関して心配しているほかの場所でそんなにいつも捨てられるので不適当な提案であるように思えます。 多くのファイアウォールが一般に、断片を渡さないなら、私たちは、なぜそれらがこの場合断片に対処すると予想するべきですか? それで、この分析はトンネルモードSAsがあるポート分野セレクタの禁じる使用の提案を拒絶します。
D.6. Other Suggested Solutions
D.6。 他の提案された解決法
One suggestion is to reassemble fragments at the sending IPsec implementation, and thus avoid the problem entirely. This approach is invisible to a receiver and thus could be adopted as a purely local implementation option.
1つの提案は、送付IPsec実装で断片を組み立て直して、その結果、問題を完全に避けることです。 このアプローチは、受信機に目に見えなく、その結果、純粋にローカルの実装オプションとして取られることができました。
A more sophisticated version of this suggestion calls for establishing and maintaining minimal state from each initial fragment encountered, to allow non-initial fragments to be matched to the right SAs or SPD/cache entries. This implies an extension to the current processing model (and the old one). The IPsec implementation would intercept all fragments; capture Source/Destination IP addresses, protocol, packet ID, and port fields from initial fragments; and then use this data to map non-initial fragments to SAs that require port fields. If this approach is employed, the receiver needs to employ an equivalent scheme, as it too must verify that received fragments are consistent with SA selector values. A non-initial fragment that arrives prior to an initial fragment could be cached or discarded, awaiting arrival of the corresponding initial fragment.
この提案の、より洗練されたバージョンは、右のSAsか非初期の断片が合わせられるのを許容するために遭遇するそれぞれの初期の断片からSPD/キャッシュエントリーまで最小量の状態を設置して、維持するように求めます。 これは現在の処理モデル(そして、古い方)に拡大を含意します。 IPsec実装はすべての断片を傍受するでしょう。 初期の断片からアドレス、プロトコル、パケットID、およびポート分野をSource/目的地IPとして得てください。 そして、このデータを使用して、ポート分野を必要とするSAsに非初期の断片を写像してください。 このアプローチが採用しているなら、受信機は、同等な体系を使う必要があります、容認された断片がSAセレクタ値と一致していることを確かめなければならないとき。 初期の断片の前で届く非初期の断片は、キャッシュしたか、または捨てることができました、対応する初期の断片の到着を待って。
A downside of both approaches noted above is that they will not always work. When a BITW device or SG is configured in a topology that might allow some fragments for a packet to be processed at different SGs or BITW devices, then there is no guarantee that all
上に述べられた両方のアプローチの下落傾向はいつも働くというわけではないということです。 BITWデバイスかSGが構成されるとき、いくつかを許容するかもしれないトポロジーでは、異なったSGsかBITWデバイスに処理されています、そこのその時によるいいえがそれを保証するということであるということであるパケットのために、すべてが断片化しています。
Kent & Seo Standards Track [Page 94] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[94ページ]。
fragments will ever arrive at the same IPsec device. This approach also raises possible processing problems. If the sender caches non-initial fragments until the corresponding initial fragment arrives, buffering problems might arise, especially at high speeds. If the non-initial fragments are discarded rather than cached, there is no guarantee that traffic will ever pass, e.g., retransmission will result in different packet IDs that cannot be matched with prior transmissions. In any case, housekeeping procedures will be needed to decide when to delete the fragment state data, adding some complexity to the system. Nonetheless, this is a viable solution in some topologies, and these are likely to be common topologies.
断片は同じIPsecデバイスに届くでしょう。 また、このアプローチは可能な加工上の問題を提起します。対応する初期の断片が届くまで送付者が非初期の断片をキャッシュするなら、問題をバッファリングするのは起こるかもしれません、特に高速で。 非初期の断片がキャッシュされるよりむしろ捨てられるなら、トラフィックが終わって、例えば、「再-トランスミッション」が先のトランスミッションに合わせることができない異なったパケットIDをもたらすという保証が全くありません。 どのような場合でも、家事の手順がいつ断片州のデータを削除するかを決めるのに必要でしょう、何らかの複雑さをシステムに追加して。 それにもかかわらず、これはいくらかのtopologiesの実行可能なソリューションです、そして、これらは一般的なtopologiesである傾向があります。
The Working Group rejected an earlier version of the convention of creating an SA to carry only non-initial fragments, something that was supported implicitly under the RFC 2401 model via use of OPAQUE port fields, but never clearly articulated in RFC 2401. The (rejected) text called for each non-initial fragment to be treated as protocol 44 (the IPv6 fragment header protocol ID) by the sender and receiver. This approach has the potential to make IPv4 and IPv6 fragment handling more uniform, but it does not fundamentally change the problem, nor does it address the issue of fragment handling for BYPASS/DISCARD traffic. Given the fragment overlap attack problem that IPv6 poses, it does not seem that it is worth the effort to adopt this strategy.
作業部会は、非初期の断片だけ、2401年のRFCモデルの下でそれとなくOPAQUEポート分野の使用でサポートされた何かを運ぶためにSAを作成するコンベンションの以前のバージョンを拒絶しましたが、RFC2401で明確に決して文節に分けられませんでした。 (拒絶されます)テキストは、それぞれの非初期の断片が送付者と受信機によってプロトコル44(IPv6断片ヘッダープロトコルID)として扱われるように求めました。基本的に問題を変えません、そして、このアプローチには、IPv4とIPv6断片取り扱いをより一定にする可能性がありますが、それはBYPASS/DISCARDトラフィックのための断片取り扱いの問題を扱いません。 IPv6がポーズをとるという断片オーバラップ攻撃問題を考えて、この戦略を採用するのは取り組みの価値があるように思えません。
D.7. Consistency
D.7。 一貫性
Earlier, the WG agreed to allow an IPsec BITS, BITW, or SG to perform fragmentation prior to IPsec processing. If this fragmentation is performed after SA lookup at the sender, there is no "mapping to the right SA" problem. But, the receiver still needs to be able to verify that the non-initial fragments are consistent with the SA via which they are received. Since the initial fragment might be lost en route, the receiver encounters all of the potential problems noted above. Thus, if we are to be consistent in our decisions, we need to say how a receiver will deal with the non-initial fragments that arrive.
より早く、WGは、IPsec BITS、BITW、またはSGがIPsec処理の前に断片化を実行するのを許容するのに同意しました。 この断片化がSAルックアップの後に送付者で実行されるなら、問題が「右のSAへの写像」であることがありません。 しかし、受信機は、まだ非初期の断片がを通したそれらが受け取られているSAと一致していることを確かめることができる必要があります。 初期の断片が途中でなくされるかもしれないので、受信機は上に述べられた潜在的な問題のすべてに遭遇します。 したがって、決定で一貫しているつもりであるなら、私たちは、受信機がどう届く非初期の断片に対処するかを言う必要があります。
D.8. Conclusions
D.8。 結論
There is no simple, uniform way to handle fragments in all contexts. Different approaches work better in different contexts. Thus, this document offers 3 choices -- one MUST and two MAYs. At some point in the future, if the community gains experience with the two MAYs, they may become SHOULDs or MUSTs or other approaches may be proposed.
すべての文脈で断片を扱うどんな簡単で、一定の方法もありません。 異なるアプローチは異なった文脈でうまくいきます。 したがって、これは3選択--1つがそうしなければならない申し出と2回の5月を記録します。 未来の何らかのポイントでは、共同体が2回の5月と共に経験を積むなら、SHOULDsかMUSTsになるかもしれませんか、または他のアプローチは提案されるかもしれません。
Kent & Seo Standards Track [Page 95] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[95ページ]。
Appendix E: Example of Supporting Nested SAs via SPD and Forwarding
Table Entries
付録E: SPDとForwarding Table Entriesを通したSupporting Nested SAsに関する例
This appendix provides an example of how to configure the SPD and forwarding tables to support a nested pair of SAs, consistent with the new processing model. For simplicity, this example assumes just one SPD-I.
この付録はSAsの入れ子にされた組をサポートするためにどうSPDと推進テーブルを構成するかに関する例を提供します、新しい処理モデルと一致しています。 簡単さのために、この例はちょうど1SPD-Iを仮定します。
The goal in this example is to support a transport mode SA from A to C, carried over a tunnel mode SA from A to B. For example, A might be a laptop connected to the public Internet, B might be a firewall that protects a corporate network, and C might be a server on the corporate network that demands end-to-end authentication of A's traffic.
Bは企業ネットワークを保護するファイアウォールであるかもしれません、そして、この例の目標が交通機関がSAであるとAからCまでサポートすることであり、公共のインターネットに接続されたラップトップになってください、そして、AからB.Forの例までのSA、Aがそうするかもしれないトンネルモードの上まで運ばれて、Cは終わりから終わりへのAのトラフィックの認証を要求する企業ネットワークのサーバであるかもしれません。
+---+ +---+ +---+
| A |=====| B | | C |
| |------------| |
| |=====| | | |
+---+ +---+ +---+
+---+ +---+ +---+ | A|=====| B| | C| | |------------| | | |=====| | | | +---+ +---+ +---+
A's SPD contains entries of the form:
AのSPDは形式のエントリーを含んでいます:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- -----------------------
1 C A ESP BYPASS
2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf)
3 A C ANY PROTECT(ESP,transport,integr-only)
4 A B ICMP,IKE BYPASS
次の層の規則の地方のリモートプロトコル動き---- ----- ------ ---------- ----------------------- 1つのC A超能力迂回2A C ICMP、超能力は3A Cを保護します(超能力、トンネル、integr+conf)。いずれもB ICMPあたり4を保護する、(超能力、輸送、integr専用)イケBYPASS
A's unprotected-side forwarding table is set so that outbound packets destined for C are looped back to the protected side. A's protected-side forwarding table is set so that inbound ESP packets are looped back to the unprotected side. A's forwarding tables contain entries of the form:
Aの保護のないサイド推進テーブルが用意をされるので、Cのために運命づけられた外国行きのパケットは保護側に輪にして戻されます。 Aの保護されたサイド推進テーブルが用意をされるので、本国行きの超能力パケットは保護のない側に輪にして戻されます。 Aの推進テーブルは形式のエントリーを含んでいます:
Unprotected-side forwarding table
保護のないサイド推進テーブル
Rule Local Remote Protocol Action
---- ----- ------ -------- ---------------------------
1 A C ANY loop back to protected side
2 A B ANY forward to B
地方のリモートプロトコル動きを統治してください。---- ----- ------ -------- --------------------------- 1 A Cは少しもBへのどんなフォワードも保護されたサイド2A Bに輪にして戻します。
Kent & Seo Standards Track [Page 96] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[96ページ]。
Protected-side forwarding table
保護されたサイド推進テーブル
Rule Local Remote Protocol Action
---- ----- ------ -------- -----------------------------
1 A C ESP loop back to unprotected side
地方のリモートプロトコル動きを統治してください。---- ----- ------ -------- ----------------------------- 1 保護のない側へのC超能力ループバック
An outbound TCP packet from A to C would match SPD rule 3 and have transport mode ESP applied to it. The unprotected-side forwarding table would then loop back the packet. The packet is compared against SPD-I (see Figure 2), matches SPD rule 1, and so it is BYPASSed. The packet is treated as an outbound packet and compared against the SPD for a third time. This time it matches SPD rule 2, so ESP is applied in tunnel mode. This time the forwarding table doesn't loop back the packet, because the outer destination address is B, so the packet goes out onto the wire.
AからCまでの外国行きのTCPパケットは、SPD規則3を合わせて、超能力がそれに適用した交通機関を持っているでしょう。 そして、保護のないサイド推進テーブルはパケットを輪にし返すでしょう。 パケットがSPD-Iに対して比較されて(図2を見てください)、マッチがSPD定規1であるので、それはBYPASSedです。 パケットは、外国行きのパケットとして扱われて、第3の回SPDに対して比較されます。 今回SPD規則2を合わせるので、超能力はトンネルモードで適用されます。 今回、推進テーブルはパケットを輪にし返しません、パケットがワイヤに出て外側の送付先アドレスがBであるので。
An inbound TCP packet from C to A is wrapped in two ESP headers; the outer header (ESP in tunnel mode) shows B as the source, whereas the inner header (ESP transport mode) shows C as the source. Upon arrival at A, the packet would be mapped to an SA based on the SPI, have the outer header removed, and be decrypted and integrity-checked. Then it would be matched against the SAD selectors for this SA, which would specify C as the source and A as the destination, derived from SPD rule 2. The protected-side forwarding function would then send it back to the unprotected side based on the addresses and the next layer protocol (ESP), indicative of nesting. It is compared against SPD-O (see Figure 3) and found to match SPD rule 1, so it is BYPASSed. The packet is mapped to an SA based on the SPI, integrity-checked, and compared against the SAD selectors derived from SPD rule 3. The forwarding function then passes it up to the next layer, because it isn't an ESP packet.
CからAまでの本国行きのTCP荷は2個の超能力ヘッダーで包装されます。 外側のヘッダー(トンネルモードにおける超能力)はソースとしてBを示していますが、内側のヘッダー(超能力交通機関)はソースとしてCを示しています。 Aへの到着のときに、パケットは、SPIに基づくSAに写像されて、外側のヘッダーを取り除かせて、解読されて保全によるチェックでしょう。 そして、それはこのSAとSPD規則2から得られた目的地としてのAのためのSADセレクタに取り組まされるでしょう。SAはソースとしてCを指定するでしょう。 次に、保護されたサイド推進機能はアドレスに基づく保護のない側と次の層のプロトコル(超能力)にそれを送り返すでしょう、巣篭もりを暗示しています。 SPD-O(図3を見る)に対して比較されて、SPD規則1を合わせるのがわかっているので、それはBYPASSedです。 パケットはSPIに基づいていて、保全によるチェックの、そして、SPD規則3から得られたSADセレクタに対して比較されたSAに写像されます。 そして、それが超能力パケットでないので、推進機能はそれを次の層まで通過します。
Kent & Seo Standards Track [Page 97] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[97ページ]。
References
参照
Normative References
引用規格
[BBCDWW98] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[BBCDWW98] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」RFC2475、1998年12月。
[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月。
[CD98] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[CD98] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC2463、1998年12月。
[DH98] Deering, S., and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460, December
1998.
[DH98]のデアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[Eas05] 3rd Eastlake, D., "Cryptographic Algorithm
Implementation Requirements For Encapsulating Security
Payload (ESP) and Authentication Header (AH)", RFC
4305, December 2005.
[Eas05] 第3イーストレーク、D.、「セキュリティが有効搭載量(超能力)と認証ヘッダー(ああ)であるとカプセル化するための暗号アルゴリズム実装要件」、RFC4305(2005年12月)。
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[HarCar98]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[Kau05] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[Ken05a]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[Ken05b] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[Ken05b] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[MD90] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[Mobip] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[Mobip] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[Pos81a] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[Pos81b] Postel, J., "Internet Control Message Protocol", RFC
792, September 1981.
[Pos81b] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、RFC792、1981年9月。
Kent & Seo Standards Track [Page 98] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[98ページ]。
[Sch05] Schiller, J., "Cryptographic Algorithms for use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[Sch05] シラー、J.、「インターネット・キー・エクスチェンジバージョン2(IKEv2)における使用のための暗号のAlgorithms」、RFC4307、2005年12月。
[WaKiHo97] Wahl, M., Kille, S., and T. Howes, "Lightweight
Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names", RFC 2253,
December 1997.
[WaKiHo97] ウォール、M.、Kille、S.、およびT.ハウズ、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「分類名のUTF-8ストリング表現」、RFC2253、1997年12月。
Informative References
有益な参照
[CoSa04] Condell, M., and L. Sanchez, "On the Deterministic
Enforcement of Un-ordered Security Policies", BBN
Technical Memo 1346, March 2004.
[CoSa04] コンデル、M.、およびL.サンチェス、「順不同の安全保障政策の決定論的な実施」、BBNの技術的なメモ1346、2004年3月。
[FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC
2784, March 2000.
2000年3月の[FaLiHaMeTr00]ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
[Gro02] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[HC03] Holbrook, H. and B. Cain, "Source Specific Multicast
for IP", Work in Progress, November 3, 2002.
[Gro02] グロースマンと、D.と、「Diffservのための新しい用語と明確化」、RFC3260、4月2002日 [HC03] 「IPのためのソースの特定のマルチキャスト」というホルブルック、H.、およびB.カインは進歩、2002年11月3日に働いています。
[HA94] Haller, N. and R. Atkinson, "On Internet
Authentication", RFC 1704, October 1994.
[HA94] ハラーとN.とR.アトキンソン、「インターネット認証」、RFC1704、1994年10月。
[NiBlBaBL98] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[NiBlBaBL98] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[Per96] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[RaFlBl01] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RaFlBl01] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知のIPへの追加(電子証券取引ネットワーク)」、RFC3168(2001年9月)。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2983]黒(D.)が「サービスとトンネルを差別化した」、RFC2983、10月2000日
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
"The Group Domain of Interpretation", RFC 3547, July
2003.
2003年7月の[RFC3547]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
Kent & Seo Standards Track [Page 99] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[99ページ]。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group
Security Architecture", RFC 3740, March 2004.
[RFC3740] HardjonoとT.とB.ウィス、「マルチキャストグループセキュリティー体系」、RFC3740、2004年3月。
[RaCoCaDe04] Rajahalme, J., Conta, A., Carpenter, B., and S.
Deering, "IPv6 Flow Label Specification", RFC 3697,
March 2004.
[RaCoCaDe04] RajahalmeとJ.とコンタとA.と大工、B.とS.デアリング、「IPv6流れラベル仕様」、RFC3697、2004年3月。
[Sch94] Schneier, B., Applied Cryptography, Section 8.6, John
Wiley & Sons, New York, NY, 1994.
[Sch94]シュナイアー(B.)は暗号、セクション8.6、ジョンワイリーと息子、ニューヨーク(ニューヨーク)1994を適用しました。
[Shi00] Shirey, R., "Internet Security Glossary", RFC 2828,
May 2000.
[Shi00]Shirey(R.、「インターネットセキュリティ用語集」、RFC2828)は2000がそうするかもしれません。
[SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
"IP Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[SMPT01]Shacham、A.、Monsour、B.、ペレイラ、R.、およびM.トーマス、「IP有効搭載量圧縮プロトコル(IPComp)」、RFC3173 2001年9月。
[ToEgWa04] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Transport Mode for Dynamic Routing", RFC 3884,
September 2004.
[ToEgWa04] 接触、J.、エッゲルト、L.、およびY.ワング、「IPsec交通機関のダイナミックルーティングの使用」、RFC3884、2004年9月。
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in
High-level Networks", ACM Computing Surveys, Vol. 15,
No. 2, June 1983.
[VK83] L.VoydockとS.T.ケントに対して、ACMコンピューティングは、Vol.15、1983年6月No.日2に「ハイレベル・ネットワークにおけるセキュリティー対策」と調査します。
Authors' Addresses
作者のアドレス
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
スティーブンケントBBN技術10モールトン・通りMA02138ケンブリッジ(米国)
Phone: +1 (617) 873-3988 EMail: kent@bbn.com
以下に電話をしてください。 +1 (617) 873-3988 メールしてください: kent@bbn.com
Karen Seo BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
カレンSeo BBN Technologies10モールトン・通りMA02138ケンブリッジ(米国)
Phone: +1 (617) 873-3152 EMail: kseo@bbn.com
以下に電話をしてください。 +1 (617) 873-3152 メールしてください: kseo@bbn.com
Kent & Seo Standards Track [Page 100] RFC 4301 Security Architecture for IP December 2005
ケントとSeo規格は2005年12月にIPのためにRFC4301セキュリティー体系を追跡します[100ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kent & Seo Standards Track [Page 101]
ケントとSeo標準化過程[101ページ]
一覧
スポンサーリンク
