Question

“ip xfrm state add”命令中的selector（参数sel）实现了什么？

源ID和目标地址（以及端口和协议等附加参数）在ID部分中设置，但选择器包含一组补充。例如：

   ip xfrm state add src 10.0.0.1 dst 10.0.0.2 proto esp spi 123456 sel src 10.0.0.3 dst 10.0.0.4 enc blowfish  0xaabbccddee

这导致以下结果：

    src 10.0.0.1 dst 10.0.0.2
proto esp spi 0x0001e240 reqid 0 mode transport
replay-window 0 
enc cbc(blowfish) 0xaabbccddee
sel src 10.0.0.3/32 dst 10.0.0.4/32

Setkey似乎没有机会添加这样的选择器值。它也不会在输出中显示选择器。上面的xfrm命令产生以下“setkey -D”输出：

   10.0.0.1 10.0.0.2 
esp mode=transport spi=123456(0x0001e240) reqid=0(0x00000000)
E: blowfish-cbc  aabbccdd ee
seq=0x00000000 replay=0 flags=0x00000000 state=mature 
created: Nov 26 01:25:39 2013   current: Nov 26 01:26:07 2013
diff: 28(s) hard: 0(s)  soft: 0(s)
last:                       hard: 0(s)  soft: 0(s)
current: 0(bytes)   hard: 0(bytes)  soft: 0(bytes)
allocated: 0    hard: 0 soft: 0
sadb_seq=0 pid=6959 refcnt=0

那么IPsec子系统最终会对这个选择器做些什么呢？

Answer 1

选择器用于隧道模式。即通过隧道（相互）连接的网络。

Answer 2

它直接来自IPsec标准（RFC 4301: Security Architecture for the Internet Protocol）。
可能。
可能是因为该标准描述了“标称模型” ，即实施方式不一定与所描述的完全相同。

在Section 4.4.2. Security Association Database (SAD)中：

对于第4.4.1.1节中定义的每个选择器，必须首先用SA创建时协商的一个或多个值来填充SAD中入站SA的条目。 ...对于接收者，这些值用于检查入站数据包的头字段（在IPsec处理之后）是否与为SA协商的选举者值匹配。因此，SAD充当用于检查到达SA的入站流量选择器的缓存。对于接收方，这是验证到达SA的数据包与SA的策略一致的一部分。

在Section 5.2. Processing Inbound IP Traffic (unprotected-to-protected)中：

IPsec必须执行以下步骤：
...
3a。如果将数据包寻址到IPsec设备，并且将AH或ESP指定为协议，则在SAD中查找该数据包。 ...如果在SAD中找到该数据包，则对其进行相应处理（请参阅步骤4）。
4.使用在上面的步骤3a中选择的SAD条目，按照指定的要求应用AH或ESP处理。然后将数据包与SAD条目标识的入站选择器进行匹配，以验证接收到的数据包是否适合通过其接收SA的SA。
5.如果IPsec系统在SA上收到入站数据包，并且该数据包的标头字段与该SA的选择器不一致，则必须丢弃该数据包。

简而言之，您的例子

ip xfrm state add src 10.0.0.1 dst 10.0.0.2 proto esp spi 123456 sel src 10.0.0.3 dst 10.0.0.4 enc blowfish  0xaabbccddee

当IPsec（在这种情况下为ESP）数据包到达服务器时，可能会发生以下情况：

部分src 10.0.0.1 dst 10.0.0.2 proto esp spi 123456用于查找对应的SA。
SA用于解密数据包的有效负载。
传输模式IPsec中的有效负载是另一个IP数据包。
sel src 10.0.0.3 dst 10.0.0.4部分是来自SP的选择器，用于创建我们的SA。
该选择器应用于内部IP数据包，以验证其与SP一致。

ip xfrm state add中选择器的用途

2 个答案: