[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）

見包結構：

   0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               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 (0-255 bytes)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |  Pad Length   | Next Header   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Integrity Check Value-ICV   (variable)                |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                          What    What    What
                          # of     Requ'd  Encrypt Integ    is
                          bytes      [1]   Covers  Covers  Xmtd
                          ------   ------  ------  ------  ------
   SPI                       4        M              Y     plain
   Seq# (low-order bits)     4        M              Y     plain       p
                                                                ------ a
   IV                     variable    O              Y     plain     | y
   IP datagram [2]        variable  M or D    Y      Y     cipher[3] |-l
   TFC padding [4]        variable    O       Y      Y     cipher[3] | o
                                                                ------ a
   Padding                 0-255      M       Y      Y     cipher[3]   d
   Pad Length                1        M       Y      Y     cipher[3]
   Next Header               1        M       Y      Y     cipher[3]
   Seq# (high-order bits)    4     if ESN [5]        Y     not xmtd
   ICV Padding            variable if need           Y     not xmtd
   ICV                    variable   M [6]                 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 32 bits of the
   sequence number are transmitted in the Sequence Number field,
   although both sender and receiver maintain full 64-bit ESN counters.
   The high order 32 bits are included in the integrity check in an
   algorithm/mode-specific fashion, e.g., the high-order 32 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.1.  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.2.  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.