# 傳輸層 Transport Layer 規格需求書

## Table of Contents
[TOC]

## Group members

- A1075512 蔡秉祐
- A1075523 陳弘斌
- A1051265 戴均諺
- A1065540 吳宛貞
- A1075543 侯德威
- A1075504 吳偲如
- A1075520 蔡孟萱
- A1075526 張明承
- A1075536 許俊義

## **1. 簡介 Introduction**
這份文件定義了傳輸層中的一些規格的要求或是防範的方法，基於討論的結果，主要分出五大類的方向，分別是安全、紀錄、傳輸、流量和格式，而以下會針對這五大點分別敘述以及整理。

### **1.1 Requirements Language**
* MUST **[必須]** - indicates an absolute requirement

* SHOULD **[應該]** - indicates a strong recommendation of a desired result

* MAY **[可以]** - indicates a willingness to allow an optional outcome

### **1.2 術語 Terminology**
* **1.2.1 TCP SYN flood**<br>利用TCP協議缺陷 (<font color="red">Three-way Handshake</font>)，通常會透過操控殭屍電腦來對目標發送大量偽造的TCP連接請求，從而使得被攻擊方資源耗盡（CPU滿負荷或記憶體不足）的攻擊方式。
* **1.2.2 Three-way Handshake**<br> TCP Protocol 建立連線的過程。<br>```Step1. client發送TCP連線請求SYN給server ```<br>```Step2. server回復SYN + ACK給client表示接受請求``` <br>```Step3. client再返送一個ACK給server，連線建立成功。```

* **1.2.3 Syn Timeout**<br>Server在發出 ( <font color="red">SYN+ACK</font> ) 給client後，遲遲無法收到client的ACK回覆（第三次握手無法完成)。通常這種情況下server一般會重試（再次發送SYN+ACK給用戶端）並等待一段時間後，還是沒收到client ACK的話就會丟棄這個未完成的連接，而這段時間的長度就是SYN Timeout。
* **1.2.4 數位簽章**<br>利用公鑰非對稱加密技術，簽名者利用私鑰對簽章，進行加密，接收端透過公鑰解密，以驗證簽章者。數位簽章具有不可否認之特性。

* **1.2.5 TCP Land Attack**<br>是阻斷服務攻擊（<font color="red">DoS攻擊</font>）的一種，通過傳送精心構造的、具有相同源位址和目標位址的欺騙封包，癱瘓缺乏相應防護機制的目標裝置，採用方式是使目標機器開啟一個source address與destination address均為自身IP位址的空連接，持續自我應答，消耗系統資源直至崩潰。

## **2. Requirements**

### **2.1 安全 ( Security Requirements )**
* 2.1.1 偵測到異常流量時，引流到清洗系統裡，剃除異常來源 **【應該】**
對數據流量進行實時監控，發現包括DOS/DDOS以內的異常流量，在不影響系統的情況，引流到清洗系統。

* 2.1.2 檢查TCP編號防止攻擊者透過偽裝資訊截取封包 **【可以】**
接收封包時一併檢查TCP編號，防止攻擊者透過偽造IP並以ARP欺騙的方式，讓目標主機錯認目標位址，藉機擷取封包。

* 2.1.3 透過路由器的入口過濾阻擋來源地址有問題的封包 **【應該】**<br>當 IP 封包經過某一路由器時，路由器將會拆解它，再由封包標頭上的目的位址決定如何轉送（或是否給予轉送）。如果路由器除了判斷目的位址之外，還增加判斷其他訊息（如來源位址或協定型態），再決定是否給予轉送，便成為『封包過濾器』。

* 2.1.4 在protocol header新增數位簽章欄 **【應該】**<br>用於接收資料時，多重驗證對方身分(安全)，在傳輸資料的過程中，或者接受連線請求的過程裡，當傳輸方偽造其IP或是利用跳板的時候，接收端只知道source IP為當前的IP，卻無法辨認其是否真的是由該IP的裝置所發送出來的訊息，那麼可以在protocol header資料欄位中，增加一個欄位，作為數位簽章( Digital Signature )用，讓接收端除了透過IP位址確認傳輸者身分外，還多了另外一層數位簽章，以做身分確認的雙重驗證。

* 2.1.5 防止惡意程式入侵 **【必須】**<br>特定的port，只對信任裝置開放，或是中間加一個過濾測試(安全)為防止駭客從遠端，透過一些沒有使用的port，進行遠端下指令入侵電腦，或是其他惡意程式的入侵( 例如:病毒 )。<font color="red">必須關閉沒有使用的port</font>，而不同的port也需要有所限制，給予行為限制，以及權限限制。中間設置一層哨站，利用系統內設置的黑/白名單，允許信任的白名單裝置通行，另外黑名單中的裝置，則中斷其連線，至於灰色地帶的模糊名單，需要在通過另外一層過濾系統，才可以判別其行為是否放行，不過這也會延伸出是否只要出現在白名單的port就是一定安全的，會不會有駭客透過駭進那些白名單中的port在嘗試攻擊內部?這也是我們之後必須思考的。

* 2.1.6 安排多層認證機制（如：數位簽章、金鑰等），須全數通過才接收後續請求 **【應該】**
若該Protocol在進行傳輸前，需要建立連線，那麼在建立連線之前，應該設置數位簽章以及亂數金鑰等驗證方式，必須通過所有的驗證要求才能進行連線，若有任何一項驗證失敗，便即刻斷開連線，不接受後續任何請求處理。

* 2.1.7 設置黑名單，若有IP傳送可疑封包次數過多，即加入黑名單 **【必須】**
紀錄傳送過封包的IP，並對於其傳送次數進行紀錄，若傳送次數高於異常數量的上限，則將其加入黑名單。在黑名單中的IP位址所傳送的封包不會進行封包的處理。

### **2.2 傳輸 ( Transmission Requirements )**
* 2.2.1 危險傳輸防禦 **【必須】** <br>TCP SYN flood，降低 syn timeout，或是分散式(代理式)處理，建立連線，亦可以建立黑名單系統屏蔽異常使用者建立連線的請求。當服務端( server )，受到TCP SYN flood 攻擊時<font color=red>藉由降低或動態調整syn time out時間，以加速屏棄掉那些沒有回應的連線裝置，以減輕CPU的負載</font>，以及記憶體資源被佔滿的情況。另外也可以以代理的方式，分成<font color=red>接受窗口</font>和<font color=red>服務窗口</font>。<br>接受窗口只負責導引申請建立連線者，去給服務窗口。<br>而多個服務窗口再來負責回應連線請求和建立連線等工作。<br>最後系統內可以設置黑名單，屏蔽掉或暫停那些異常傳輸封包的使用者IP。

* 2.2.2 將接收端收到的封包存到buffer中，藉由buffer的大小決定傳送端可以傳多少的封包 **【應該】**<br>當電腦傳送資料時，將資料以每次傳送封包大小，依序填入傳送緩衝器中。傳送端必須確認已完成傳送後再將資料封包由傳送緩衝器上刪除。
* 2.2.3 調整傳輸速度 **【必須】**<br>連線剛建立時，傳輸速度為線性加速，當發生timeout或網路壅塞時，調整傳輸速度。
* 2.2.4 TCP遺失片段超過設定上限不進行重傳直接捨棄；反之，則重傳遺失片段 **【應該】**
TCP具有流量控制功能，當雙方傳輸時不斷遺失封包，便視為連線出現異常，並將其將其連線切斷，若未超過設定數量便修復遺失的片段
* 2.2.5 由封包大小計算傳送時間，超過計算後的時間未收到ACK，重新傳送封包 **【可以】**<br>給較大的封包較長的傳輸允許時間，反之較小的則給較短，若未收到ACK則視為封包遺失、延遲或損毀，這時候就重新傳送封包。
* 2.2.6 連結建立時，對其封包內的序列值進行比較驗證，超過一定接收次數即更改序列值判斷條件 **【必須】**<br>TCP傳輸時並不一定能夠按照順序接收，因此可利用表頭中的序列號進行排序。若出現排序錯誤或遺失編號便回報。
* 2.2.7 TCP以三向交握的方式確保建立穩定連線 **【可以】**<br>選擇用TCP進行傳輸，利用其三向交握的特性，也就是(1)SYN (2)ACK+SYN (3)ACK 來進行較UDP安全的封包傳送。
* 2.2.8 通訊協定必須提供認證方式、機密性和完整性 **【必須】**<br>如同HTTPS網站相較其他網頁瀏覽方式安全，因為HTTPS能利用「傳輸層安全性」通訊協定(TLS)提供資安防護<br>驗證方式：驗證是否與正確的網站進行通訊，能夠預防攔截式攻擊。<br>機密性：對資料加密，以防止資料遭到偷竊，使瀏覽網站時，無法被竊聽或追蹤網頁與網頁之間的活動。<br>完整性：系統會檢查資料在傳送的過程中是否遭到修改或破壞。
* 2.2.9 TCP封包的最大長度，應以記憶體處理量較少的終端為主 **【必須】**<br>TCP傳送封包時所限定的最大長度應該根據不同終端設定，給予不同的處理最大值

### **2.3 流量 ( Transmission Traffic Requirements )**

主要是為了不讓過大的流量崩潰整個系統，因此必須設置一些檢測器或是條件狀況處理的方式。

* 2.3.1 限制流量，在超出負載前，捨去累積封包 **【必須】** <br>對於服務接收端設置流量限制，而且須要低於服務接收端的可接受容量，再因為接受過量封包之前，就須做出提前預防，若有異常流量的前兆，就將先前累積的封包刪除，並對於有需求但被捨棄的封包重新發出要求，請求重新傳送。

* 2.3.2 設置負載平衡器，限定最大流量 **【可以】**
自動把流量分配至多個目標，然後監控目標的運作狀態，並將流量傳送到運作狀態良好的目標。

* 2.3.3 當封包大小超過設定的上限時，將封包拆成數個計算後的固定大小片段傳送 **【可以】**
先設定封包大小的上限，判斷封包超過後，再分配到緩衝區，接著在緩衝區依照數據的長度判斷包頭和包體的長度，以此決定要不要拆包，最後再取出封包。

* 2.3.4 確認封包遺失的時間，是否應該依據連線品質，動態調整 **【可以】**
以連線品質來判斷封包正常的遺失時間，以免因連線不佳而遭加入黑名單

* 2.3.5 當連接埠，收到大量同一來源的封包時，應該中斷連線或捨棄封包 **【應該】**
將發送大量封包的來源當作可疑來源，進行連線中斷或捨棄封包以維持整體連線品質。

* 2.3.6 一定時間內不能發送太多UDP或TCP封包 **【應該】**
從主機端自行限制限定時間內的封包數量傳輸，設定計數器累積時間內封包傳送次數，若超過上限便回報，並暫時將其關閉，禁止接收封包。

### **2.4 格式 ( Format Requirements )**

若是傳輸的格式不同的話有可能會導致無法成功建立連線請求，所以必須統一規定好傳輸層封包的標準格式。

* 2.4.1 允許最大傳輸單位 **【必須】**
TCP大小:1500-IP頭(20)-TCP頭(20) = 1460BYTES
UDP大小:1500-IP頭(20)-TCP頭(8) = 1472BYTES
若超過則需要拆包
* 2.4.2 格式必須按照標準格式來填寫 **【必須】**
傳送的data需要按照標準的格式來傳輸，可以用較安全的方式檢查封包，並規避掉不合格式的封包，避免overflow等可能影響傳輸接收的狀況發生。

## 外部連結
* [Transport Layer HackMD](https://hackmd.io/TLfPXBABSxeGvcD9BDT9kQ?both)