封包標記

4.1 Identification 封包標記

標記設計是使用目前已有的 IP Protocol，不更改它的欄位設定，並且使用 Identification 欄位和 Flags 欄位的保留設定位元。IP Protocol 中，IP 標頭欄位的 設定如圖 18，前 20 bytes 為每一個封包必定要有的資料，而 Options 是在需要特 定的控制時，才會利用到，Padding 則是在 IP Header 不為 32 bits 倍數時，進行 補足的位元。

圖 18、IP 表頭

我們的設計是使用 Identification 欄位的 16 bits，做為我們標記資訊放置的 位置，且使用 Flags 欄位的保留設定位元，有 1bit 來識別是否以經經過第一台 MPC 標記過。Flags 總共佔 3bits，如圖 19，主要與 IP 封包的切割與重組有關，

第一個 bit 為保留用途用，預設值為 0，第二個 bit 為 DF(Don’tFragment)，用來 定義 IP 封包是否可以加以切割，第三個 bit 為 MF(May Fragment)，用來定義此 IP fragment 是否為原始封包的最後一個 IP fragment。我們針對欄位的設定結果如

67

圖 19、Flags 欄位設計

圖 20、Identification 欄位

欄位說明:

(1) Identification: 16bits，只有對未切割過封包，才會將此欄位分成兩欄，分別記 錄第一個經過的 MPC 的 IID 值，和目前所處的 MPC IID 值，範圍 0~255[註 1]。

(2) IID：8bits，標記內容，只有對未切割過封包才會在 Identification 欄位標記 IID 值，每經過在 gateway 附近的 MPC，就會將 MPC 特定的 IID 值放置在這個欄位，

在相同網域內的 MPC 會有相同 IID 值，不同網域間，設定不同的 IID 值，IID 的範圍是從 0~255，然而因為 IID 要有未使用時的數值，因此將 0 保留下來，當 作還未填 IID 資料進去，因此真正能夠使用的 IID 就只 1~255，如圖 20。

圖 21、標記示意圖

68

Header Checksum 欄位代表標頭檢驗值，當我們修改了 IID 欄位的內容後，檢驗 值必需要重新計算，放入一個修改過後的新值，避免在後續的傳送中，封包遭到

STime 與 ETime 兩個欄位的格式型態是 DATETIME，用來記錄日期以及時 間，STime 全名為 Start Time，記錄這個標記內容的起始時間，而 ETime 全名為 End Time，記錄這個標記內容的結束時間，SIP 為來源 IP，DIP 為目的 IP，Protocol 為 IP 通訊協定，DPORT 為目的 Port，IIDNUM 為封包內標記的 IID 數量，IID1、

69

IID2、IID3 代表的是經過的 MPC 的各個 IID。

表格 18、MySQL 的 Table 設計

每當一個封包經過 MPC，具有標記的內容如果直接寫入資料庫，會使記錄 資料大量產生，短時間內擁有數筆相同的數據資料，為了將這些重覆資料在短時 間內能夠集合成同一筆資料，我們在監聽的部份加入 Buffer，使標記的資料能夠 在短時間保留在 Buffer 內，直到 Buffer 滿載或者一段時間後，再寫入資料庫，

以減少短時間內相同資料的產生。Buffer 是使用動態產生，並且擁有一個數值限 制 Buffer 的最大量，並且可以設定保留在 Buffer 的時間。

當一個標記資料進入 MPC 後，它會先將這筆標記資料記錄放到 Buffer，並 且會在 Buffer 內的 STime 與 ETime 寫入現在的時間與其它數值，當下一筆標記 資料進入時，在 Buffer 中如果也擁有這筆相同資料時，它會將 ETime 更新為目 前時間，直到 STime 超過我們所設定的時間限制，就會寫入資料庫。或者是目 前的 Buffer 已達到最大量，我們就將 Buffer 中 STime 最舊的那一個，寫入資料 庫。

假如是切割過的封包，即使沒做標記，出口端 MPC 的監聽程式依舊要將其 寫入資料庫，作類似 logging 的動作，且 IIDNUM 為 1，IID1 為本身 IID，而 IID2、

IID3 皆為 0。

4.3 資料庫記錄縮減

為了將標記內容寫入資料庫的量縮減，我們會在監聽時，藉由檢查 TCP 封 包是否完成三向交握程序，再決定是否將其記錄到 Buffer。將沒完成三向交握的 連線，記錄為需要寫進 Buffer 的連線封包；若完成三向交握程序的連線，在此連 線傳送的封包將不予以記錄到 Buffer，藉此可減少寫入資料庫的資料量，演算法

70

見圖 22，修改 mylistener.c 程式，以達到資料庫量再縮減的目標，mylistener.c 會 記錄哪些 flow 已經完成三向交握程序，並將此 flow 的 source IP、source port、

destination IP 和 destination port 存入陣列，以供 mylistener.c 判斷封包是否需要 先記錄到 Buffer 的依據。

圖 22、mylistener.c 演算法修改

表格 19、Table 和 list

71

監聽封包程式:

(1)若監聽到的為 SYN 封包，則將 Source 和 Destination 的 IP 、port 存入 table(由六個ㄧ維陣列組成，見圖 22)，寫入 Buffer 暫存區。

(2)若監聽到的為(SYN+ACK)封包，則先檢查在 table 內是否有記 錄，若有，則修改相對應的欄位，將 state 設為 1，且記錄下此 寫入 Buffer，若有，則不寫入 Buffer。

(5) 若監聽到的為其它封包，則檢查 list 有無記錄，若無，則 寫入 Buffer，若有，則不寫入 Buffer。

4.4 路徑追蹤

路徑追蹤的方式由一台中央控管主機(MCC)發出查詢，在 MCC 會建一個資料 庫，有所有 MPC IID 和 subnet、IP、Gateway 的對照表，由輸入的條件之一—封 包的 destination IP，由 destination IP 得知向特定 subnet 裡的 MPC 做資料查詢，

MPC 依照中央控管主機所設定的查詢條件，由本身的資料庫找到前一個 MPC IID 值，再跟前一個 subnet 裡的 MPC 作查詢，陸續往回查詢相關的 MPC，直到 此封包經過的第一台 MPC，即可將資料回傳至 MCC 呈現，路徑的呈現方式是以 gateway 呈現。

72

圖 23、Traceback 方式

從圖 23 中，了解路徑重建的步驟。

Step1:MCC 依據查詢條件 destination IP，知道要向 subnet3 裡的 MPC3 做 查詢。

Step2~3:MPC3 根據資料庫內的資料，知道要向 MPC2 做查詢，MPC2 根據 資料庫內的資料，知道要向 MPC1 做查詢，因為 MPC1 是第一個經 過的 MPC，所以查詢做到此即可。

Step4: MPC1 作回傳資料的動作，回傳路徑給 MCC。

找出整條路徑的 IID 後，需要將 IID 轉換為 gateway，這時藉由中央控管主 機內的 MPC IID 與 gateway 相對應的記錄，將 IID 轉回所處的 gateway。

有關於切割過的封包，則是由MCC向全部MPC查詢是否有此筆記錄，找出 出口端gateway，在MCC呈現出入口gateway。

73