rfc4301IPsec_ipsecrfc资源-CSDN文库

需积分: 27 150 浏览量 2018-03-21 18:14:06 上传评论收藏 221KB PDF 举报

RFC 4301是互联网工程任务组(IETF)发布的互联网标准草案，旨在为互联网社区提供一种标准的协议，其全名为“互联网协议的安全架构”，它取代了之前1998年11月发布的RFC 2401标准。RFC 4301文档由S. Kent和K. Seo共同撰写，是互联网标准路径上的协议，广泛分布在各个网络文档中，具有无限的分发性，且其版权归互联网协会所有。RFC 4301文档描述了更新版本的IP层安全架构，提供了为IP层流量提供安全服务的机制。本标准文档适用于任何对IPsec感兴趣的读者，并在当前的“互联网官方协议标准”中详细说明了此协议的状态和标准化程度。 RFC 4301详细介绍了IPsec的设计目标，包括其目标、安全需求和问题描述。同时，文档强调了使用此协议时需要注意的事项和相关假设。系统概览部分解释了IPsec的作用，以及它是如何工作的，以及在哪些地方可以实施IPsec。RFC 4301定义了IPsec的三个主要组成部分：安全关联(SA)、安全策略数据库(SPD)和安全关联数据库(SAD)。安全关联是IPsec的基础概念，它代表了两个或多个使用IPsec协议通信实体之间的单向连接的状态信息。SA是通信双方进行安全通信的必要条件，并且可以进行不同的操作，如数据加密和数据源认证等。一个SA可以包含一个或多个SA组合，这样的组合提供了复杂的安全服务。为了建立和维护SA，IPsec使用了几个关键数据库：SPD、SAD和对等授权数据库(PAD)。SPD负责选择IP流量并应用相应的安全策略，而SAD存储与SA相关的数据项，用于处理通过IPsec保护的IP数据包。在SA和密钥管理部分，RFC 4301提到了手动和自动两种技术，以及它们在建立SA时的使用场景。自动密钥管理通常通过互联网密钥交换(IKE)协议来实现，IKE负责协商和建立SA，同时也负责密钥的生成、交换和更新。另外，文档还提到了如何利用这些机制来定位安全网关，并且讨论了SA在多播通信中的应用。 IP流量处理部分则详细说明了数据包在离开主机或者到达主机时的处理流程，包括如何通过安全策略来决定是否对数据包进行IPsec处理，以及如何通过SA来应用相应的加密和认证算法。整体上，RFC 4301是研究和应用IPsec技术的基础文献，它不仅为IPsec技术的实现和应用提供了框架，还详细描述了相关数据库结构和操作流程，同时，它也是网络安全领域的专业人员必须熟悉的文档之一。通过对RFC 4301的学习，可以系统地掌握IPsec的设计原理、安全机制、以及在网络安全架构中的具体应用。

资源推荐

资源详情

资源评论

Network Working Group S. Kent

Request for Comments: 4301 K. Seo

Obsoletes:

2401 BBN Technologies

Category: Standards Track December 2005

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.

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).

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.

Kent & Seo Standards Track [Page 1]

RFC 4301

Security Architecture for IP December 2005

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 .................

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 .....................

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) ................................

5.1.1. Handling an Outbound Packet That Must Be

Discarded ..........................................

5.1.2. Header Construction for Tunnel Mode ................55

5.1.2.1. IPv4: Header Construction for

Tunnel Mode ...............................

5.1.2.2. IPv6: Header Construction for

Tunnel Mode ...............................

5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59

Kent & Seo Standards Track [Page 2]

RFC 4301

Security Architecture for IP December 2005

6. ICMP Processing ................................................63

6.1. Processing ICMP Error Messages Directed to an

IPsec Implementation ......................................

6.1.1. ICMP Error Messages Received on the

Unprotected Side of the Boundary ...................

6.1.2. ICMP Error Messages Received on the

Protected Side of the Boundary .....................

6.2. Processing Protected, Transit ICMP Error Messages .........64

7. Handling Fragments (on the protected side of the IPsec

boundary) ......................................................

7.1. Tunnel Mode SAs that Carry Initial and Non-Initial

Fragments .................................................

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...............................

References.........................................................98

Normative References............................................98

Informative References..........................................99

Kent & Seo Standards Track [Page 3]

RFC 4301

Security Architecture for IP December 2005

1. Introduction

1.1. Summary of Contents of Document

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).

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

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.

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.

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].

1.2. Audience

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

Kent & Seo Standards Track [Page 4]

RFC 4301

Security Architecture for IP December 2005

(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.

1.3. Related Documents

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:

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].

2. Design Objectives

2.1. Goals/Objectives/Requirements/Problem Description

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 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

Kent & Seo Standards Track [Page 5]

剩余100页未读，继续阅读

评论收藏

内容反馈

leanna_li

粉丝: 0
资源: 4

rfc4301 IPsec

最新资源

rfc4301 IPsec

RFC4301(中文) IP安全架构(废除了RFC2401)

RFC6071(中文) IPsec和IKE文件路线图

esp数据包,ipsec数据包

Linux’s IPsec implementation.pdf

IPsec_1_8_1.pdf

IPsec和SSL介绍

IPsec安全策略自动

IPsec Introduction

RFC之IPSec-SSL

RFC中文文档-txt

中文版RFC，共456

rfc中文文档目录，包含部分翻译

RFC文档大全 网络人员必备

IPsec（IP Security）.xmind

IPsec简单配置.zip

让win10支持IPsec

IPsec封包和拆包

IPsec及PKI

PDF版RFC：rfc3501-4000。(共12部分)

rfc3588.rar_Dimater协议_IETF RFC 3588_RFC 3588_rfc_rfc3588中文版

中文RFC文档（路由部分）

RFC2406-IP封装安全有效载荷(ESP).pdf

Tcp/IP之IPSec详解

服务器防采集IPsec

IPsec自动设置工具

IPsec 数据库1

GRE over IPsec

rfc6733 Diameter Base Protocol

最新资源

RFC文档大全网络人员必备