没有合适的资源?快使用搜索试试~ 我知道了~
RFC4301 IPsec IP Security Protocol RFC 4301 IPSec 英文版
资源推荐
资源详情
资源评论
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![application/x-rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![application/x-rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![application/x-rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![txt](https://img-home.csdnimg.cn/images/20210720083642.png)
![](https://csdnimg.cn/release/download_crawler_static/10300674/bg1.jpg)
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.
Copyright Notice
Copyright (C) The Internet Society (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).
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]
![](https://csdnimg.cn/release/download_crawler_static/10300674/bg2.jpg)
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 .................
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
Kent & Seo Standards Track [Page 2]
![](https://csdnimg.cn/release/download_crawler_static/10300674/bg3.jpg)
RFC 4301
Security Architecture for IP December 2005
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
Kent & Seo Standards Track [Page 3]
![](https://csdnimg.cn/release/download_crawler_static/10300674/bg4.jpg)
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]
![](https://csdnimg.cn/release/download_crawler_static/10300674/bg5.jpg)
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页未读,继续阅读
资源评论
![avatar-default](https://csdnimg.cn/release/downloadcmsfe/public/img/lazyLogo2.1882d7f4.png)
![avatar](https://profile-avatar.csdnimg.cn/default.jpg!1)
leanna_li
- 粉丝: 0
- 资源: 4
上传资源 快速赚钱
我的内容管理 展开
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助
![voice](https://csdnimg.cn/release/downloadcmsfe/public/img/voice.245cc511.png)
![center-task](https://csdnimg.cn/release/downloadcmsfe/public/img/center-task.c2eda91a.png)
安全验证
文档复制为VIP权益,开通VIP直接复制
![dialog-icon](https://csdnimg.cn/release/downloadcmsfe/public/img/green-success.6a4acb44.png)