ipsec ikev1总框架
主动模式=野蛮模式
华为的ike 默认同时支持v1和v2，因此可以向下兼容，当隧道两端同时支持v2时，使用v2.
dis ike peer bri
2022-03-30 12:25:59.510
Current ike peer number: 1
---------------------------------------------------------------------------
Peer name Version Exchange-mode Proposal Id-type RemoteAddr
---------------------------------------------------------------------------
a v1v2 main 10 IP 1.1.3.1
如果只使用v1的话，就需要去使能v2。
ike peer a
undo version 2
v1有两个阶段，阶段1有主模式和野蛮模式，默认是主模式。主模式有6个报文。
这是第一阶段的ike报文格式。也叫做isakmp报文，这是ipsec的信令协议。
ietf中对于ipsec ikev1的说明是rfc2409.RFC 2409 - The Internet Key Exchange (IKE) (ietf.org)
https://datatracker.ietf.org/doc/html/rfc2409#section-5.7
这是ipsec中报文字段的解析。
IPSec报文格式 (023wg.com)http://www.023wg.com/message/message/cd_feature_ipsec_format.html
ike的第一阶段主模式协商过程
rfc2409中对于ikev1主模式阶段说明
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
HDR is an ISAKMP header whose exchange type is the mode. When
writen as HDR* it indicates payload encryption.
SA is an SA negotiation payload with one or more proposals. An
initiator MAY provide multiple proposals for negotiation; a
responder MUST reply with only one.
KE is the key exchange payload which contains the public
information exchanged in a Diffie-Hellman exchange.
Nx is the nonce payload; x can be: i or r for the ISAKMP initiator
and responder respectively.
IDx is the identification payload for "x". x can be: "ii" or "ir"
for the ISAKMP initiator and responder respectively during phase
one negotiation
HASH (and any derivitive such as HASH(2) or HASH_I) is the hash
payload. The contents of the hash are specific to the
authentication method.
1、消息1和2用于参数协商（明文）
发起方发送一个或者多个ike安全提议，响应方查找最先匹配的ike安全提议，并将这个ike安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方式和dh组标识。
2、消息3和4用于密钥信息交换
双方交换dh公共值和nonce值（随机数、时间戳），用于ike sa（isakmp sa）的认证和加密密钥的产生。
3、消息5和6用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。
下面逐包分析。
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
第一个包
作用：协商发起方，发送ike安全提议给响应方。
从报文中我们可以得到的信息：
1、报文封装在udp报文中，单播，端口号500.
3、isakmp header包括spi、next payload、version、exchange type、flags、message id、message length
3.1、spi抓包中显示为cookie，cookie标识唯一的ipsec会话，防止重放攻击，取值基于ip地址、端口号、时间等进行散列，生成8位数的随机数。init cookie由发起者产生，res cookie由响应者产生。
3.2、next payload是下一载荷类型。sa用0x21（即十进制33）标识。
3.3、version是ike v1
3.4、exchange type表示是主模式
3.5、flags表示后续报文是否进行了加密和认证
3.6、message id表示消息标识符，请求消息和响应消息是对应的，以便控制丢弃消息的重复发送，在抑制重放攻击时对保障协议的安全性很关键。
4、type payload为sa，里面还有type payload的封装，分别是proposal（提议）和transform（转换）。
第二个包：通过查找第一个包的安全提议，给发送者回复一个确认的安全提议。主要内容是对方的cookie号和一个提议一个策略，注意这个提议和策略是和开始里面的一个对应的，否则回失败消息。
第三个包：如果发起方接受了安全提议，就给对方发送密钥生成信息，对方用来生成IKE的密钥。
Initiator Responder
---------- -----------
HDR, KE, Ni -->
<-- HDR, KE, Nr
第四个包:协商响应方给协商发起方发送密钥生成信息，使得协议发起方能生成密钥。
发起方和响应方利用isakmp消息的key exchange和nonce载荷交换彼此的密钥材料。通过dh算法，得到公共的K值。
key exchange用于交换dh公开值
nonce用于传送临时随机数
Diffie-Hellman密钥交换算法的有效性依赖于计算离散对数的难度。
对于一个整数A和素数p的一个原根g，可以找到惟一的指数a，使得 A = g^a mod p ,指数a称为A的以g为基数的模p的离散对数.
Diffie-Hellman密钥交换算法的安全性依赖于这样一个事实：虽然计算以一个素数为模的指数相对容易，但计算离散对数却很困难.对于大的素数，计算出离散对数几乎是不可能的. 下面给出例子.密钥交换基于素数p = 97和97的一个原根g = 5.Alice和Bob分别选择私有密钥a = 36和b = 58.每人计算其公开密钥A = 5^36mod97 = 50 ,B = 5^58 mod97 = 44 . 在他们相互获取了公开密钥之后，各自通过计算得到双方共享的秘密密钥如下： K = B^a mod 97 = 44^36mod97 = 75, K = A^b mod 97 = 50^58 mod 97 = 75 从|50,44|出发，攻击者要计算出75很不容易.
dh算法解决了在不安全的网络环境中安全的交换密钥。该例中，Alice和Bob希望在不安全的信道中共享一个密钥K，该密钥可以用来进行后续的其他操作，并仅为Alice和Bob所知，第三方无法得知，Bob无法通过g、p、A逆推得到a。即使网络中其他人得到了g、p、A、B，但是不知道a、b，就无法得到K值。
现在我们通过dh算法得到了K值。
在4、5步中，使用K值推导密钥。
数字证书：SKEYID = prf(Ni | Nr, K)
预共享密钥：SKEYID = prf(pre-shared-key, Ni|Nr)
SKEYID_d：推导因子
SKEYID_d = prf(SKEYID,K| Ci | Cr | 0)
SKEYID_a：用于验证的密钥
SKEYID_a = prf(SKEYID, SKEYID_d |K| Ci | Cr| 1)
SKEYID_e：用于加密的密钥，用于后续5-6消息的加密以及快速模式的加密
SKEYID_e = prf(SKEYID, SKEYID_a |K| Ci | Cr| 2)
prf是伪随机函数
5，6包用于身份认证
Initiator Responder
---------- -----------
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
ID是身份信息。一般使用ip地址。HASH是作为完整性验证。
HASH_I = prf(SKEYID, K| Ci | Cr | SAi | IDii_b )
HASH_R = prf(SKEYID, K| Ci | Cr | SAi | IDir_b )
SAi is the entire body of the SA payload (minus the ISAKMP
generic header)-- i.e. the DOI, situation, all proposals and all
transforms offered by the Initiator.
第五个包
第六个包
第一阶段除了主模式，还有一种模式是野蛮模式
只需要3个包。
第一个包
第二个包
第三个包（加密）
Initiator Responder
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
HDR*, HASH_I -->
相比主模式，减少了交换信息的数目，效率高，但是最大的问题是IDii和IDir是通过明文传输的，没有对身份信息进行加密保护，不安全。华为不推荐使用野蛮模式，因为野蛮模式也需要配置remote-address。
野蛮模式可以满足特定的网络环境需求。
1、当ipsec隧道中存在nat设备时，需要启用nat穿越功能，而NAT转换会改变对等体的ip地址，由于野蛮模式不依赖ip地址标识身份，使得采用预共享密钥验证方法时，nat穿越只能在野蛮模式中实现。主模式需要开启nat-t功能适应这种环境。
2、如果发起方的ip地址不固定或者无法预先知道，比如pppoe。而双方都希望采用预共享密钥验证方法来创建ike sa，则只能采用野蛮模式。除了野蛮模式，对于这一种场景，还可以使用模板方式。
3、如果发起方已知响应方的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快创建ike sa。
第二阶段：ipsec sa
只有一种：快速模式
双方需要协商生成ipsec sa各项参数，包括可选参数pfs。并为ipsec sa生成ipsec sa生成认证/加密密钥。
Initiator Responder
----------- -----------
HDR*, HASH(1), SA, Ni,
[ KE ], [ IDci, IDcr ] -->
<-- HDR*, HASH(2), SA, Nr,
[ KE ], [IDci, IDcr ]
HDR*, HASH(3) -->
HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
打[]的参数是可选的。如果不开启pfs，则这些参数是没有的。
PFS:完美向前安全性，短暂的一次性密钥系统称为完美向前保密，perfect forward secrecy。解决了衍生密钥被坡解导致后续密钥都被坡解的问题。
如果加密系统中有一个密钥是所有对称密钥的衍生者（始祖），便不能认为那是一个完美向前保密的系统，在这种情况下，一旦坡解了根密钥，便能拿到其他衍生的所有密钥，受那些密钥保护的全部数据都会曝光。
在ipsec中，pfs是通过在ipsec sa协商阶段重新进行一次dh交换来实现的，即再产生一个K值。
SKEYID_e只保护第一阶段5、6包和第二阶段的包，隧道中的感兴趣流的报文不用SKEYID_e加密保护，而是使用KEYMAT。
If PFS is not needed, and KE payloads are not exchanged, the new keying material is defined as
KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b)
If PFS is desired and KE payloads were exchanged, the new keying material is defined as
KEYMAT = prf(SKEYID_d, K | protocol | SPI | Ni_b | Nr_b)
主模式和野蛮模式的区别？
1、交换的消息：主模式为6个包，野蛮模式为3个包，野蛮模式能够更快创建ike sa
2、nat支持：对预共享密钥认证：主模式不支持nat转换（需要额外开启nat-t），而野蛮模式支持。对于证书方式认证：两种模式都支持。
3、对等体标识：主模式只能采用ip地址方式标识对等体，而野蛮模式可以采用ip地址或者name方式（DN\FQDN\User-FQDN)标识对等体。这是由于主模式在交换完3、4消息后，需要使用预共享密钥来计算skeyid，当一个设备有多个对等体时，必须查找到该对等体对应的预共享密钥，但是由于其对等体的id 信息在消息5.6中才会发送，此时主模式的设备只能使用3.4中的ip地址源地址来找到与其对应的预共享密钥，如果主模式采用name方式，name信息却包含在消息5.6中，而设备必须在消息5.6之前找到其对等体的预共享密钥，所以就造成了矛盾，无法完成name方式的标识。
而在野蛮模式中，id消息在消息1.2中就已经发送了，设备可以根据id信息查找到对应的预共享密钥，从而计算skeyid，但是由于野蛮模式交换的2个消息没有经过加密，所以id信息也是明文的，也相应造成了安全隐患。
4、提议转换对数量：在野蛮模式中，由于第一个消息就需要交换dh消息，而dh消息本身就决定采用哪个dh组，这样在提议转换对中就确定了使用哪个dh组，如果第一个消息中包含多个提议转换对，那么这多个转换对的dh组必须相同（和dh消息确定的dh组一致），否则消息1中只能携带和确定dh组相同的提议转换对。
5、协商能力：由于野蛮模式交换次数的限制，因此野蛮模式协商能力低于主模式。
6、主模式的认证是在加密的环境中进行，野蛮模式在非加密的环境中进行，野蛮模式采用预共享密钥的场景下不依赖于ip地址的标识，因此支持动态ip地址的场景。
7、两者之间的协商过程不同。
