[crypto][ipsec] 简述ESP协议的sequence number机制

预备

首先提及一个概念叫重放攻击，对应的机制叫做：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.