预备
首先提及一个概念叫重放攻击，对应的机制叫做：anti-replay
https://en.wikipedia.org/wiki/Anti-replay
IPsec协议的anti-replay特性就是用来应对重放攻击的一种机制，方法是：
增加两个机制：序列号（seqence number）和收包窗口（sliding window）
发包方从0开始计数，每发一个包就把序号加1。 收包方拥有一个长度为N的滑动窗口，序号在窗口外的包都认为是无效包。
序号在窗口内的重复包，也被认为是无效包。窗口下边界处的包会导致窗口向前滑动。
一
以下内容都在ESP内讨论。
基于前文，我们已经了解到了ESP内的两个概念seq num，reply window，和一个属性anti-replay
seq num
是在报文内的，由发包者决定，并加到报文上。见图：
reply window
replay window是收包方本地的，自维护不协商。
anti-replay
anti-replay可以理解为是一个特性。
RFC中规定任何IPsec实现中都必须实现，且默认开启，不可以协商。 但是接收端可以关掉这个特效。（这好像矛盾了？？--！）
另外，ipsec还支持多播和单播，这个时候以上讨论的内容都没有区别。
但是同时ipsec还支持多个sender共用一个SA。在这种情况下，anti-replay就是失效的，自然seq num和reply window也就没有用了。
当anti-replay生效的时候，seq number满了之后就只能重协商chlidsa。
当anti-replay不生效的是，sender不再关心seq number，就一直加加加，然后溢出就变成0.
二
于是，这里有了一个新的问题，
seq number满了就要重协商。看包我们发现这个字段是uint32的，所以，在高速网络中，每2^32个包就要重协商一次。
为了解决这个问题，现在引入一个新的概念，叫做：Extended Sequence Number（ESN）
见包结构：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (- bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What What What
# of Requ'd Encrypt Integ is
bytes [] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI M Y plain
Seq# (low-order bits) M Y plain p
------ a
IV variable O Y plain | y
IP datagram [] variable M or D Y Y cipher[] |-l
TFC padding [] variable O Y Y cipher[] | o
------ a
Padding - M Y Y cipher[] d
Pad Length M Y Y cipher[]
Next Header M Y Y cipher[]
Seq# (high-order bits) if ESN [] Y not xmtd
ICV Padding variable if need Y not xmtd
ICV variable M [] plain
这样的话，seq number便扩展到了64个bit。
ESN塞在了Next Header的后面。包头里面的seq number和原来一样是明文传输的，用来存这个数的低32位。 ESN是密文传输的（或者不传输），用来存储这个数的高32位。
需要注意的是，这个地方还有点复杂我还没有深入分析。这个ESN在不同的场景下的作用好像还不一样。还会被用于做完整性验证信息？
详见：
https://tools.ietf.org/html/rfc4303#section-2.2
https://tools.ietf.org/html/rfc4303#section-3.3.2.2
https://tools.ietf.org/html/rfc4303#section-3.4.3
二点一
ESN number的高32bit会被双方计数维护，不会被放在报文的payload里参与传输。但是在计算消息认证码的时候，会把它放进去一起参与计算。
https://tools.ietf.org/html/rfc4303#section-3.3.3
If ESN (see Appendix) is selected, only the low-order bits of the
sequence number are transmitted in the Sequence Number field,
although both sender and receiver maintain full -bit ESN counters.
The high order bits are included in the integrity check in an
algorithm/mode-specific fashion, e.g., the high-order bits may be
appended after the Next Header field when a separate integrity
algorithm is employed.
见下图，这是一张启用了ESN的esp包结构，与没有ESN的包，并没有什么区别。
三
丢包与乱序。
https://tools.ietf.org/html/rfc4303#page-38
在这个机制里，有几个值W（anti window的大小），T（合法包的seq的上限），B（合法包的seq的下限）
当累计的连续的不合法包的数量（T-B）大于2^32个的时候，将触发ESP的重认证（re-synchronization）机制。收到了一个合法包之后，计数将被重置为0
为什么是，2^32这么大的一个数呢？
因为ESP认为，上层应该会更早的感知链路出来问题。如TCP会自行发现。有交互的UDP，应用层也会发现。
这里的re-synchronization机制只针对一种情况，就是udp单侧发包，对方无回应的应用场景。
写到这里。。突然发现后边的内容理解的不是很好。。。就先这样了。。。。
到底re-synchronization机制是什么？？
TO BE continue
A3.. Triggering Re-synchronization For each SA, the receiver records the number of consecutive packets
that fail authentication. This count is used to trigger the re-
synchronization process, which should be performed in the background
or using a separate processor. Receipt of a valid packet on the SA
resets the counter to zero. The value used to trigger the re-
synchronization process is a local parameter. There is no
requirement to support distinct trigger values for different SAs,
although an implementer may choose to do so. A3.. Re-synchronization Process When the above trigger point is reached, a "bad" packet is selected
for which authentication is retried using successively larger values
for the upper half of the sequence number (Seqh). These values are
generated by incrementing by one for each retry. The number of
retries should be limited, in case this is a packet from the "past"
or a bogus packet. The limit value is a local parameter. (Because
the Seqh value is implicitly placed after the ESP (or AH) payload, it
may be possible to optimize this procedure by executing the integrity
algorithm over the packet up to the endpoint of the payload, then
compute different candidate ICVs by varying the value of Seqh.)
Successful authentication of a packet via this procedure resets the
consecutive failure count and sets the value of T to that of the
received packet. This solution requires support only on the part of the receiver,
thereby allowing for backward compatibility. Also, because re-
synchronization efforts would either occur in the background or
utilize an additional processor, this solution does not impact
traffic processing and a denial of service attack cannot divert
resources away from traffic processing.