zzzzy09

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理
ipsec 详细分析 一

IPSec的相关概念

IPSec(IP Security)是一种由IETF设计的端到端的确保IP层通信安全的机制。IPSec协议可以为IP网络通信提供透明的安全服务，保护TCP/IP通信免遭窃听和篡改，保证数据的完整性和机密性，有效抵御网络攻击。IPSec不是一个单独的协议，而是一组协议，IPSec协议的定义文件包括了12个RFC文件和几十个Internet草案，已经成为工业标准的网络安全协议。

IPSec静态隧道工作原理

IPSec VPN分为两个协商阶段，ISAKMP阶段及IPSec阶段，ISAKMP阶段主要是协商两端的保护策略，验证对等体的合法性，产生加密密钥，保护第二阶段IPSec SA的协商。第二阶段IPSec阶段，主要是确定IPSec SA的保护策略，使用AH还是ESP、传输模式还是隧道模式、被保护的数据是什么等等。第二阶段协商的目标就是产生真正用于保护IP数据的IPSec SA。IPSec通信实体双方对于一、二阶段的这些安全策略必须达成一致，否则IPSec协商将无法通过。

 https://en.wikipedia.org/wiki/IPsec

In computing, Internet Protocol Security (IPsec) is a secure network protocol suite that authenticates and encrypts the packets of data to provide secure encrypted communication between two computers over an Internet Protocol network. It is used in virtual private networks (VPNs).在计算中，Internet协议安全性（IPsec）是一个安全的网络协议套件，它对数据包进行身份验证和加密，以通过Internet协议网络在两台计算机之间提供安全的加密通信。它用于虚拟专用网络（VPN）。

IPsec includes protocols for establishing mutual authentication between agents at the beginning of a session and negotiation of cryptographic keys to use during the session. IPsec can protect data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host).[1] IPsec uses cryptographic security services to protect communications over Internet Protocol (IP) networks. It supports network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and replay protection.IPsec包括用于在会话开始时在代理之间建立相互身份验证和会话期间使用的加密密钥协商的协议。IPsec可以保护一对主机（主机到主机）、一对安全网关（网络到网络）或安全网关和主机（网络到主机）之间的数据流。[1] IPsec使用加密安全服务来保护Internet协议（IP）网络上的通信。它支持网络级对等身份验证、数据源身份验证、数据完整性、数据机密性（加密）和重播保护。

The initial IPv4 suite was developed with few security provisions. As a part of the IPv4 enhancement, IPsec is a layer 3 OSI model or internet layer end-to-end security scheme. In contrast, while some other Internet security systems in widespread use operate above layer 3, such as Transport Layer Security (TLS) that operates above the Transport Layer and Secure Shell (SSH) that operates at the Application layer, IPsec can automatically secure applications at the IP layer.最初的IPv4套件是在几乎没有安全规定的情况下开发的。作为IPv4增强的一部分，IPsec是第3层OSI模型或internet层端到端安全方案。相比之下，尽管一些其他广泛使用的Internet安全系统在第3层之上运行，例如在传输层之上运行的传输层安全（TLS）和在应用层上运行的安全外壳（SSH），但IPsec可以自动保护IP层上的应用程序。

History[edit]历史[编辑]

Starting in the early 1970s, the Advanced Research Projects Agency sponsored a series of experimental ARPANET encryption devices, at first for native ARPANET packet encryption and subsequently for TCP/IP packet encryption; some of these were certified and fielded. From 1986 to 1991, the NSA sponsored the development of security protocols for the Internet under its Secure Data Network Systems (SDNS) program.[2] This brought together various vendors including Motorola who produced a network encryption device in 1988. The work was openly published from about 1988 by NIST and, of these, Security Protocol at Layer 3 (SP3) would eventually morph into the ISO standard Network Layer Security Protocol (NLSP).[3]从20世纪70年代初开始，美国高级研究计划署（Advanced Research Projects Agency）赞助了一系列实验性的ARPANET加密设备，最初用于本地ARPANET数据包加密，随后用于TCP/IP数据包加密；其中一些已经认证并部署。从1986年到1991年，国家安全局在其安全数据网络系统（SDNS）计划下赞助了互联网安全协议的开发。[2] 这使得包括1988年生产网络加密设备的摩托罗拉（Motorola）在内的多家供应商聚集在一起。这项工作大约于1988年由NIST公开发表，其中第3层安全协议（SP3）将最终演变为ISO标准网络层安全协议（NLSP）。[3]

From 1992 to 1995, various groups conducted research into IP-layer encryption.从1992年到1995年，各个小组对IP层加密进行了研究。

  • 1. In 1992, the US Naval Research Laboratory (NRL) began the Simple Internet Protocol Plus (SIPP) project to research and implement IP encryption.1.1992年，美国海军研究实验室（NRL）开始了简单互联网协议增强（SIPP）项目，以研究和实施IP加密。
  • 2. In 1993, at Columbia University and AT&T Bell Labs, John Ioannidis and others researched the software experimental Software IP Encryption Protocol (swIPe) on SunOS.2.1993年，在哥伦比亚大学和at&T贝尔实验室，John Ioannidis和其他人研究了SunOS上的软件实验软件IP加密协议（swIPe）。
  • 3. In 1993, Sponsored by Whitehouse internet service project, Wei Xu at Trusted Information Systems (TIS) further researched the Software IP Security Protocols and developed the hardware support for the triple DES Data Encryption Standard,[4] which was coded in the BSD 4.1 kernel and supported both x86 and SUNOS architectures. By December 1994, TIS released their DARPA-sponsored open-source Gauntlet Firewall product with the integrated 3DES hardware encryption at over T1 speeds. It was the first-time using IPSec VPN connections between the east and west coast of the States, known as the first commercial IPSec VPN product.3.1993年，在Whitehouse internet service project的赞助下，Trusted Information Systems（TIS）的徐伟进一步研究了软件IP安全协议，并开发了对三重DES数据加密标准[4]的硬件支持，该标准在BSD 4.1内核中编码，支持x86和SUNOS体系结构。到1994年12月，TIS发布了DARPA赞助的开源Gauntlet防火墙产品，该产品集成了3DES硬件加密，速度超过T1。这是美国东西海岸首次使用IPSecVPN连接，被称为第一个商用IPSecVPN产品。
  • 4. Under NRL's DARPA-funded research effort, NRL developed the IETF standards-track specifications (RFC 1825 through RFC 1827) for IPsec, which was coded in the BSD 4.4 kernel and supported both x86 and SPARC CPU architectures.[5] NRL's IPsec implementation was described in their paper in the 1996 USENIX Conference Proceedings.[6] NRL's open-source IPsec implementation was made available online by MIT and became the basis for most initial commercial implementations.[5]4.在NRL的DARPA资助的研究工作下，NRL为IPsec开发了IETF标准跟踪规范（RFC 1825到RFC 1827），该规范在BSD 4.4内核中编码，支持x86和SPARC CPU体系结构。[5] NRL的IPsec实现在1996年USENIX会议记录中的论文中进行了描述。[6] NRL的开源IPsec实现由MIT在线提供，并成为大多数初始商业实现的基础。[5]

The Internet Engineering Task Force (IETF) formed the IP Security Working Group in 1992[7] to standardize openly specified security extensions to IP, called IPsec.[8] In 1995, the working group organized a few of the workshops with members from the five companies (TIS, CISCO, FTP, Checkpoint, etc.). During the IPSec workshops, the NRL's standards and Cisco and TIS' software are standardized as the public references, published as RFC-1825 through RFC-1827.[9]Internet工程任务组（IETF）于1992年成立了IP安全工作组[7]，以标准化公开指定的IP安全扩展，称为IPsec。[8] 1995年，工作组与五家公司（TIS、CISCO、FTP、Checkpoint等）的成员组织了一些研讨会。在IPSec研讨会期间，NRL的标准以及Cisco和TIS的软件被标准化为公共参考，发布为RFC-1825至RFC-1827。[9]

Security architecture[edit]安全体系结构[编辑]

The IPsec is an open standard as a part of the IPv4 suite. IPsec uses the following protocols to perform various functions:[10][11]IPsec是作为IPv4套件一部分的开放标准。IPsec使用以下协议执行各种功能：[10][11]

Authentication Header[edit]身份验证标头[编辑]

 
Usage of IPsec Authentication Header format in Tunnel and Transport modes在隧道和传输模式中使用IPsec身份验证头格式

The Security Authentication Header (AH) was developed at the US Naval Research Laboratory in the early 1990s and is derived in part from previous IETF standards' work for authentication of the Simple Network Management Protocol (SNMP) version 2. Authentication Header (AH) is a member of the IPsec protocol suite. AH ensures connectionless integrity by using a hash function and a secret shared key in the AH algorithm. AH also guarantees the data origin by authenticating IP packets. Optionally a sequence number can protect the IPsec packet's contents against replay attacks,[19] using the sliding window technique and discarding old packets.安全认证头（AH）于20世纪90年代初在美国海军研究实验室开发，部分源自先前IETF标准对简单网络管理协议（SNMP）版本2的认证工作。身份验证标头（AH）是IPsec协议套件的成员。AH通过在AH算法中使用哈希函数和秘密共享密钥来确保无连接完整性。AH还通过验证IP数据包来保证数据来源。可选地，序列号可以保护IPsec数据包的内容免受重播攻击，[19]使用滑动窗口技术并丢弃旧数据包。

  • In IPv4, AH prevents option-insertion attacks. In IPv6, AH protects both against header insertion attacks and option insertion attacks.在IPv4中，AH可防止选项插入攻击。在IPv6中，AH既可以防止头插入攻击，也可以防止选项插入攻击。
  • In IPv4, the AH protects the IP payload and all header fields of an IP datagram except for mutable fields (i.e. those that might be altered in transit), and also IP options such as the IP Security Option (RFC 1108). Mutable (and therefore unauthenticated) IPv4 header fields are DSCP/ToS, ECN, Flags, Fragment Offset, TTL and Header Checksum.[13]在IPv4中，AH保护IP数据报的IP有效负载和所有报头字段，但可变字段（即在传输过程中可能更改的字段）以及IP安全选项（RFC 1108）等IP选项除外。可变（因此未经验证）IPv4报头字段是DSCP/ToS、ECN、标志、片段偏移量、TTL和报头校验和。[13]
  • In IPv6, the AH protects most of the IPv6 base header, AH itself, non-mutable extension headers after the AH, and the IP payload. Protection for the IPv6 header excludes the mutable fields: DSCP, ECN, Flow Label, and Hop Limit.[13]在IPv6中，AH保护大部分IPv6基本头、AH本身、AH之后的不可变扩展头以及IP有效负载。对IPv6标头的保护不包括可变字段：DSCP、ECN、流标签和跃点限制。[13]

AH operates directly on top of IP, using IP protocol number 51.[20]AH使用51号IP协议直接在IP之上运行。[20]

The following AH packet diagram shows how an AH packet is constructed and interpreted:[12][13]以下AH数据包图显示了AH数据包是如何构造和解释的：[12][13]

Authentication Header format身份验证标头格式
Offsets抵消Octet16八月十六日0123
Octet16八月十六日Bit10比特10012345678910111213141516171819202122232425262728293031
00 Next Header下一包头 Payload Len有效载荷透镜 Reserved含蓄的
432 Security Parameters Index (SPI)安全参数索引（SPI）
864 Sequence Number序列号
CC96 Integrity Check Value (ICV)完整性检查值（ICV）
...
......
Next Header (8 bits)下一个报头（8位）
Type of the next header, indicating what upper-layer protocol was protected. The value is taken from the list of IP protocol numbers.下一个标头的类型，指示受保护的上层协议。该值取自IP协议编号列表。
Payload Len (8 bits)有效负载Len（8位）
The length of this Authentication Header in 4-octet units, minus 2. For example, an AH value of 4 equals 3×(32-bit fixed-length AH fields) + 3×(32-bit ICV fields) − 2 and thus an AH value of 4 means 24 octets. Although the size is measured in 4-octet units, the length of this header needs to be a multiple of 8 octets if carried in an IPv6 packet. This restriction does not apply to an Authentication Header carried in an IPv4 packet.此身份验证标头的长度，以4个八位字节为单位，减去2。例如，AH值4等于3×（32位固定长度AH字段）+3×（32位ICV字段）− 因此，AH值为4意味着24个八位组。虽然大小是以4个八位字节为单位测量的，但如果在IPv6数据包中携带，则该报头的长度需要是8个八位字节的倍数。此限制不适用于IPv4数据包中携带的身份验证标头。
Reserved (16 bits)保留（16位）
Reserved for future use (all zeroes until then).保留供将来使用（在此之前均为零）。
Security Parameters Index (32 bits)安全参数索引（32位）
Arbitrary value which is used (together with the destination IP address) to identify the security association of the receiving party.用于（与目标IP地址一起）标识接收方安全关联的任意值。
Sequence Number (32 bits)序列号（32位）
A monotonic strictly increasing sequence number (incremented by 1 for every packet sent) to prevent replay attacks. When replay detection is enabled, sequence numbers are never reused, because a new security association must be renegotiated before an attempt to increment the sequence number beyond its maximum value.[13]一种单调严格递增的序列号（每个发送的数据包递增1），用于防止重播攻击。启用重播检测时，序列号永远不会重复使用，因为在尝试将序列号增加到超过其最大值之前，必须重新协商新的安全关联。[13]
Integrity Check Value (multiple of 32 bits)完整性检查值（32位的倍数）
Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.可变长度检查值。它可能包含填充，用于将字段与IPv6的8位字节边界对齐，或与IPv4的4位字节边界对齐。

Encapsulating Security Payload[edit]封装安全有效负载[编辑]

 
Usage of IPsec Encapsulating Security Payload (ESP) in Tunnel and Transport modes在隧道和传输模式中使用IPsec封装安全有效负载（ESP）

 

 

 

 

The IP Encapsulating Security Payload (ESP)[21] was developed at the Naval Research Laboratory starting in 1992 as part of a DARPA-sponsored research project, and was openly published by IETF SIPP[22] Working Group drafted in December 1993 as a security extension for SIPP. This ESP was originally derived from the US Department of Defense SP3D protocol, rather than being derived from the ISO Network-Layer Security Protocol (NLSP). The SP3D protocol specification was published by NIST in the late 1980s, but designed by the Secure Data Network System project of the US Department of Defense. Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. It provides origin authenticity through source authentication, data integrity through hash functions and confidentiality through encryption protection for IP packets. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is strongly discouraged because it is insecure.[23][24][25]IP封装安全有效载荷（ESP）[21]于1992年开始在海军研究实验室开发，作为DARPA赞助的研究项目的一部分，并由IETF SIPP[22]工作组于1993年12月作为SIPP的安全扩展公开发布。此ESP最初源自美国国防部SP3D协议，而不是源自ISO网络层安全协议（NLSP）。SP3D协议规范由NIST在20世纪80年代末发布，但由美国国防部的安全数据网络系统项目设计。封装安全有效负载（ESP）是IPsec协议套件的成员。它通过源身份验证提供源真实性，通过哈希函数提供数据完整性，并通过对IP数据包的加密保护提供机密性。ESP还支持仅加密和仅身份验证配置，但强烈建议不使用身份验证而使用加密，因为这是不安全的。[23][24][25]

Unlike Authentication Header (AH), ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. ESP operates directly on top of IP, using IP protocol number 50.[20]与身份验证标头（AH）不同，传输模式下的ESP不为整个IP数据包提供完整性和身份验证。但是，在隧道模式下，当整个原始IP数据包被封装并添加新的数据包头时，ESP保护将提供给整个内部IP数据包（包括内部数据包），而外部数据包（包括任何外部IPv4选项或IPv6扩展数据包头）将保持不受保护。ESP直接在IP上运行，使用IP协议编号50。[20]

The following ESP packet diagram shows how an ESP packet is constructed and interpreted:[1][26]以下ESP数据包图显示了如何构造和解释ESP数据包：[1][26]

Encapsulating Security Payload format封装安全有效负载格式
Offsets抵消Octet16八月十六日0123
Octet16八月十六日Bit10比特10012345678910111213141516171819202122232425262728293031
00 Security Parameters Index (SPI)安全参数索引（SPI）
432 Sequence Number序列号
864 Payload data有效载荷数据
......
......    
......   Padding (0-255 octets)填充（0-255个八位字节）  
......   Pad Length衬垫长度 Next Header下一包头
...... Integrity Check Value (ICV)完整性检查值（ICV）
...
......
Security Parameters Index (32 bits)安全参数索引（32位）
Arbitrary value used (together with the destination IP address) to identify the security association of the receiving party.用于标识接收方安全关联的任意值（与目标IP地址一起）。
Sequence Number (32 bits)序列号（32位）
A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect against replay attacks. There is a separate counter kept for every security association.一种单调递增的序列号（每个发送的数据包递增1），用于防止重播攻击。每个安全协会都有一个单独的柜台。
Payload data (variable)有效载荷数据（可变）
The protected contents of the original IP packet, including any data used to protect the contents (e.g. an Initialisation Vector for the cryptographic algorithm). The type of content that was protected is indicated by the Next Header field.原始IP数据包的受保护内容，包括用于保护内容的任何数据（例如，加密算法的初始化向量）。受保护的内容类型由下一个标题字段指示。
Padding (0-255 octets)填充（0-255个八位字节）
Padding for encryption, to extend the payload data to a size that fits the encryption's cipher block size, and to align the next field.加密填充，将有效负载数据扩展到适合加密密码块大小的大小，并对齐下一个字段。
Pad Length (8 bits)焊盘长度（8位）
Size of the padding (in octets).填充的大小（以八位字节为单位）。
Next Header (8 bits)下一个报头（8位）
Type of the next header. The value is taken from the list of IP protocol numbers.下一个标题的类型。该值取自IP协议编号列表。
Integrity Check Value (multiple of 32 bits)完整性检查值（32位的倍数）
Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.可变长度检查值。它可能包含填充，用于将字段与IPv6的8位字节边界对齐，或与IPv4的4位字节边界对齐。

Security association[edit]安全协会[编辑]

Main article: Security association主要条款：安全协会

The IPsec protocols use a security association, where the communicating parties establish shared security attributes such as algorithms and keys. As such IPsec provides a range of options once it has been determined whether AH or ESP is used. Before exchanging data the two hosts agree on which algorithm is used to encrypt the IP packet, for example DES or IDEA, and which hash function is used to ensure the integrity of the data, such as MD5 or SHA. These parameters are agreed for the particular session, for which a lifetime must be agreed and a session key.[27]IPsec协议使用安全关联，其中通信各方建立共享的安全属性，如算法和密钥。因此，一旦确定使用AH还是ESP，IPsec提供了一系列选项。在交换数据之前，两台主机就使用哪种算法来加密IP数据包（例如DES或IDEA）以及使用哪种哈希函数来确保数据的完整性（例如MD5或SHA）达成一致。这些参数是为特定会话商定的，必须为特定会话商定生存期和会话密钥。[27]

The algorithm for authentication is also agreed before the data transfer takes place and IPsec supports a range of methods. Authentication is possible through pre-shared key, where a symmetric key is already in the possession of both hosts, and the hosts send each other hashes of the shared key to prove that they are in possession of the same key. IPsec also supports public key encryption, where each host has a public and a private key, they exchange their public keys and each host sends the other a nonce encrypted with the other host's public key. Alternatively if both hosts hold a public key certificate from a certificate authority, this can be used for IPsec authentication.[28]在进行数据传输之前，身份验证的算法也得到了认可，IPsec支持一系列方法。可以通过预共享密钥进行身份验证，其中对称密钥已经由两台主机拥有，并且主机彼此发送共享密钥的哈希值以证明它们拥有相同的密钥。IPsec还支持公钥加密，其中每个主机都有一个公钥和一个私钥，它们交换公钥，每个主机向另一个主机发送一个用另一个主机的公钥加密的nonce。或者，如果两台主机都持有来自证书颁发机构的公钥证书，则可以将其用于IPsec身份验证。[28]

The security associations of IPsec are established using the Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP is implemented by manual configuration with pre-shared secrets, Internet Key Exchange (IKE and IKEv2), Kerberized Internet Negotiation of Keys (KINK), and the use of IPSECKEY DNS records.[18][29][30] RFC 5386 defines Better-Than-Nothing Security (BTNS) as an unauthenticated mode of IPsec using an extended IKE protocol. C. Meadows, C. Cremers, and others have used Formal Methods to identify various anomalies which exist in IKEv1 and also in IKEv2.[31]IPsec的安全关联是使用Internet安全关联和密钥管理协议（ISAKMP）建立的。ISAKMP通过手动配置预共享机密、Internet密钥交换（IKE和IKEv2）、密钥的Kerberized Internet协商（KINK）以及使用IPSECKEY DNS记录来实现。[18] [29][30]RFC 5386将优于无的安全性（BTN）定义为使用扩展IKE协议的未经验证的IPsec模式。C.Meadows、C.Cremers和其他人使用正式方法识别IKEv1和IKEv2中存在的各种异常。[31]

In order to decide what protection is to be provided for an outgoing packet, IPsec uses the Security Parameter Index (SPI), an index to the security association database (SADB), along with the destination address in a packet header, which together uniquely identifies a security association for that packet. A similar procedure is performed for an incoming packet, where IPsec gathers decryption and verification keys from the security association database.为了决定为传出数据包提供什么保护，IPsec使用安全参数索引（SPI），一个指向安全关联数据库（SADB）的索引，以及数据包头中的目标地址，它们共同唯一地标识该数据包的安全关联。对传入数据包执行类似的过程，其中IPsec从安全关联数据库收集解密和验证密钥。

For IP multicast a security association is provided for the group, and is duplicated across all authorized receivers of the group. There may be more than one security association for a group, using different SPIs, thereby allowing multiple levels and sets of security within a group. Indeed, each sender can have multiple security associations, allowing authentication, since a receiver can only know that someone knowing the keys sent the data. Note that the relevant standard does not describe how the association is chosen and duplicated across the group; it is assumed that a responsible party will have made the choice.对于IP多播，为组提供安全关联，并在组的所有授权接收者之间复制。一个组可能有多个安全关联，使用不同的SPI，从而允许在一个组中使用多个级别和多组安全性。实际上，每个发送方都可以有多个安全关联，从而允许身份验证，因为接收方只能知道知道知道密钥的人发送了数据。请注意，相关标准并未说明如何在整个集团内选择和复制协会；假设责任方做出了选择。

Modes of operation[edit]操作模式[编辑]

The IPsec protocols AH and ESP can be implemented in a host-to-host transport mode, as well as in a network tunneling mode.IPsec协议AH和ESP可以在主机到主机传输模式以及网络隧道模式下实现。

 
IPsec ModesIPsec模式

Transport mode[edit]运输模式[编辑]

In transport mode, only the payload of the IP packet is usually encrypted or authenticated. The routing is intact, since the IP header is neither modified nor encrypted; however, when the authentication header is used, the IP addresses cannot be modified by network address translation, as this always invalidates the hash value. The transport and application layers are always secured by a hash, so they cannot be modified in any way, for example by translating the port numbers.在传输模式下，通常仅对IP数据包的有效负载进行加密或身份验证。路由是完整的，因为IP报头既没有修改也没有加密；但是，当使用身份验证标头时，无法通过网络地址转换修改IP地址，因为这总是使哈希值无效。传输层和应用层始终由哈希保护，因此不能以任何方式修改它们，例如通过转换端口号。

A means to encapsulate IPsec messages for NAT traversal has been defined by RFC documents describing the NAT-T mechanism.描述NAT-T机制的RFC文档定义了封装用于NAT遍历的IPsec消息的方法。

Tunnel mode[edit]隧道模式[编辑]

Main article: Tunneling protocol主要文章：隧道协议

In tunnel mode, the entire IP packet is encrypted and authenticated. It is then encapsulated into a new IP packet with a new IP header. Tunnel mode is used to create virtual private networks for network-to-network communications (e.g. between routers to link sites), host-to-network communications (e.g. remote user access) and host-to-host communications (e.g. private chat).[32]在隧道模式下，对整个IP数据包进行加密和身份验证。然后，它被封装到一个具有新IP报头的新IP数据包中。隧道模式用于创建虚拟专用网络，用于网络对网络通信（例如路由器到链接站点之间）、主机对网络通信（例如远程用户访问）和主机对主机通信（例如私人聊天）。[32]

Tunnel mode supports NAT traversal.隧道模式支持NAT穿越。

Algorithms[edit]算法[编辑]

Symmetric encryption algorithms[edit]对称加密算法[编辑]

Cryptographic algorithms defined for use with IPsec include:定义用于IPsec的加密算法包括：

  • HMAC-SHA1/SHA2 for integrity protection and authenticity.HMAC-SHA1/SHA2用于完整性保护和真实性。
  • TripleDES-CBC for confidentiality三倍于CBC的保密性
  • AES-CBC and AES-CTR for confidentiality.AES-CBC和AES-CTR保密。
  • AES-GCM and ChaCha20-Poly1305 providing confidentiality and authentication together efficiently.AES-GCM和ChaCha20-Poly1305一起有效地提供机密性和身份验证。

Refer to RFC 8221 for details.有关详细信息，请参阅RFC 8221。

Key exchange algorithms[edit]密钥交换算法[编辑]

Authentication algorithms[edit]验证算法[编辑]

  • RSARSA
  • ECDSA (RFC 4754)ECDSA（RFC 4754）
  • PSK (RFC 6617)PSK（RFC 6617）

Implementations[edit]实现[编辑]

The IPsec can be implemented in the IP stack of an operating system, which requires modification of the source code. This method of implementation is done for hosts and security gateways. Various IPsec capable IP stacks are available from companies, such as HP or IBM.[33] An alternative is so called bump-in-the-stack (BITS) implementation, where the operating system source code does not have to be modified. Here IPsec is installed between the IP stack and the network drivers. This way operating systems can be retrofitted with IPsec. This method of implementation is also used for both hosts and gateways. However, when retrofitting IPsec the encapsulation of IP packets may cause problems for the automatic path MTU discovery, where the maximum transmission unit (MTU) size on the network path between two IP hosts is established. If a host or gateway has a separate cryptoprocessor, which is common in the military and can also be found in commercial systems, a so-called bump-in-the-wire (BITW) implementation of IPsec is possible.[34]IPsec可以在操作系统的IP堆栈中实现，这需要修改源代码。这种实现方法适用于主机和安全网关。HP或IBM等公司提供各种支持IPsec的IP堆栈。[33]另一种方法称为堆栈中的bump（位）实现，操作系统源代码无需修改。此处，IPsec安装在IP堆栈和网络驱动程序之间。通过这种方式，可以使用IPsec对操作系统进行改造。这种实现方法也可用于主机和网关。但是，在改装IPsec时，IP数据包的封装可能会导致自动路径MTU发现出现问题，其中在两个IP主机之间的网络路径上建立了最大传输单元（MTU）大小。如果主机或网关具有单独的密码处理器，这在军事上很常见，在商业系统中也可以找到，则可以使用IPsec的所谓线内碰撞（bump in the wire，BITW）实现。[34]

When IPsec is implemented in the kernel, the key management and ISAKMP/IKE negotiation is carried out from user space. The NRL-developed and openly specified "PF_KEY Key Management API, Version 2" is often used to enable the application-space key management application to update the IPsec Security Associations stored within the kernel-space IPsec implementation.[35] Existing IPsec implementations usually include ESP, AH, and IKE version 2. Existing IPsec implementations on UNIX-like operating systems, for example, Solaris or Linux, usually include PF_KEY version 2.当IPsec在内核中实现时，密钥管理和ISAKMP/IKE协商是从用户空间进行的。NRL开发并公开指定的“PF_密钥管理API，版本2”通常用于使应用程序空间密钥管理应用程序能够更新存储在内核空间IPsec实现中的IPsec安全关联。[35]现有的IPsec实施通常包括ESP、AH和IKE版本2。在类似UNIX的操作系统（例如Solaris或Linux）上现有的IPsec实现通常包括PF_密钥版本2。

Embedded IPsec can be used to ensure the secure communication among applications running over constrained resource systems with a small overhead.[36]嵌入式IPsec可用于以较小的开销确保在受限资源系统上运行的应用程序之间的安全通信。[36]

Standards status[edit]标准状态[编辑]

IPsec was developed in conjunction with IPv6 and was originally required to be supported by all standards-compliant implementations of IPv6 before RFC 6434 made it only a recommendation.[37] IPsec is also optional for IPv4 implementations. IPsec is most commonly used to secure IPv4 traffic.[citation needed]IPsec是与IPv6一起开发的，最初要求所有符合标准的IPv6实现都支持IPsec，而RFC 6434仅将其作为一项建议。[37]IPsec对于IPv4实现也是可选的。IPsec最常用于保护IPv4通信。[需要引用]

IPsec protocols were originally defined in RFC 1825 through RFC 1829, which were published in 1995. In 1998, these documents were superseded by RFC 2401 and RFC 2412 with a few incompatible engineering details, although they were conceptually identical. In addition, a mutual authentication and key exchange protocol Internet Key Exchange (IKE) was defined to create and manage security associations. In December 2005, new standards were defined in RFC 4301 and RFC 4309 which are largely a superset of the previous editions with a second version of the Internet Key Exchange standard IKEv2. These third-generation documents standardized the abbreviation of IPsec to uppercase “IP” and lowercase “sec”. “ESP” generally refers to RFC 4303, which is the most recent version of the specification.IPsec协议最初是在1995年发布的RFC1825到RFC1829中定义的。1998年，这些文件被RFC 2401和RFC 2412取代，但有一些不兼容的工程细节，尽管它们在概念上是相同的。此外，还定义了相互认证和密钥交换协议Internet密钥交换（IKE），以创建和管理安全关联。2005年12月，RFC 4301和RFC 4309中定义了新标准，这两个标准主要是先前版本的超集，第二个版本是Internet密钥交换标准IKEv2。这些第三代文档将IPsec的缩写标准化为大写“IP”和小写“sec”。“ESP”通常指RFC 4303，它是本规范的最新版本。

Since mid-2008, an IPsec Maintenance and Extensions (ipsecme) working group is active at the IETF.[38][39]自2008年年中以来，一个IPsec维护和扩展（ipsecme）工作组在IETF积极开展工作。[38][39]

Alleged NSA interference[edit]所谓的国家安全局干扰[编辑]

In 2013, as part of Snowden leaks, it was revealed that the US National Security Agency had been actively working to "Insert vulnerabilities into commercial encryption systems, IT systems, networks, and endpoint communications devices used by targets" as part of the Bullrun program.[40] There are allegations that IPsec was a targeted encryption system.[41]2013年，作为斯诺登泄密事件的一部分，据透露美国国家安全局一直在积极努力“将漏洞插入商业加密系统、it系统、网络和目标使用的端点通信设备”，作为Bullrun计划的一部分。[40]有指控称IPsec是一个目标加密系统。[41]

The OpenBSD IPsec stack came later on and also was widely copied. In a letter which OpenBSD lead developer Theo de Raadt received on 11 Dec 2010 from Gregory Perry, it is alleged that Jason Wright and others, working for the FBI, inserted "a number of backdoors and side channel key leaking mechanisms" into the OpenBSD crypto code. In the forwarded email from 2010, Theo de Raadt did not at first express an official position on the validity of the claims, apart from the implicit endorsement from forwarding the email.[42] Jason Wright's response to the allegations: "Every urban legend is made more real by the inclusion of real names, dates, and times. Gregory Perry's email falls into this category. … I will state clearly that I did not add backdoors to the OpenBSD operating system or the OpenBSD crypto framework (OCF)."[43] Some days later, de Raadt commented that "I believe that NETSEC was probably contracted to write backdoors as alleged. … If those were written, I don't believe they made it into our tree."[44] This was published before the Snowden leaks.OpenBSD IPsec堆栈后来出现，也被广泛复制。OpenBSD首席开发人员Theo de Raadt于2010年12月11日收到Gregory Perry的一封信，信中称Jason Wright和其他为FBI工作的人在OpenBSD密码中插入了“大量后门和侧通道密钥泄漏机制”。在2010年转发的电子邮件中，西奥·德·拉阿德特（Theo de Raadt）最初没有就索赔的有效性表达官方立场，只是在转发电子邮件时暗示了支持。[42]杰森·赖特（Jason Wright）对这些指控的回应：“每一个城市传奇都通过包含真实姓名、日期和时间而变得更加真实。格雷戈里·佩里（Gregory Perry）的电子邮件属于这一类……我将明确指出，我没有向OpenBSD操作系统或OpenBSD加密框架（OCF）添加后门。”[43]几天后，de Raadt评论道：“我相信NETSEC可能与我们签订了所谓的写后门的合同……如果这些都是写的，我不相信他们能进入我们的树。”[44]这是在斯诺登泄密之前发表的。

An alternative explanation put forward by the authors of the Logjam attack suggests that the NSA compromised IPsec VPNs by undermining the Diffie-Hellman algorithm used in the key exchange. In their paper[45] they allege the NSA specially built a computing cluster to precompute multiplicative subgroups for specific primes and generators, such as for the second Oakley group defined in RFC 2409. As of May 2015, 90% of addressable IPsec VPNs supported the second Oakley group as part of IKE. If an organization were to precompute this group, they could derive the keys being exchanged and decrypt traffic without inserting any software backdoors.Logjam攻击的作者提出的另一种解释表明，NSA破坏了密钥交换中使用的Diffie-Hellman算法，从而破坏了IPsec VPN。在他们的论文[45]中，他们声称国家安全局专门构建了一个计算集群，以预计算特定素数和生成器的乘法子群，例如RFC 2409中定义的第二个Oakley群。截至2015年5月，90%的可寻址IPsec VPN支持第二个Oakley组作为IKE的一部分。如果一个组织要预计算这个组，他们可以导出正在交换的密钥并解密流量，而无需插入任何软件后门。

A second alternative explanation that was put forward was that the Equation Group used zero-day exploits against several manufacturers' VPN equipment which were validated by Kaspersky Lab as being tied to the Equation Group[46] and validated by those manufacturers as being real exploits, some of which were zero-day exploits at the time of their exposure.[47][48][49] The Cisco PIX and ASA firewalls had vulnerabilities that were used for wiretapping by the NSA[citation needed].提出的第二种替代解释是，等式组对多家制造商的VPN设备使用了零天漏洞利用，这些设备经卡巴斯基实验室验证为与等式组相关[46]，并经这些制造商验证为真正的漏洞利用，其中一些在曝光时是零日攻击。[47][48][49]Cisco PIX和ASA防火墙存在漏洞，被NSA用于窃听[需要引证]。

Furthermore, IPsec VPNs using "Aggressive Mode" settings send a hash of the PSK in the clear. This can be and apparently is targeted by the NSA using offline dictionary attacks.[50][51][52]此外，使用“攻击模式”设置的IPsec VPN以明文形式发送PSK哈希。NSA使用离线字典攻击可以而且显然是针对这一点的。[50][51][52]

I

posted on 2022-01-05 17:17  zzzzy09  阅读(1158)  评论(0)  编辑  收藏  举报