邵雯娟 金仙力 馬 嚴
(北京郵電大學信息網(wǎng)絡(luò)中心 北京100876)
摘 要 流控制傳輸協(xié)議(SCTP)是IETF新近提出的一種傳輸協(xié)議,用于在基于IP的網(wǎng)絡(luò)上傳輸PSTN信令。本文詳細研究了SCTP數(shù)據(jù)傳輸過程,特別是SCTP四路握手,并進一步展望了SCTP的發(fā)展前景。
關(guān)鍵詞 SCTP SS7 over IP 關(guān)聯(lián) DoS 狀態(tài)Cookie SYN Flooding
1 引言
在過去的20年內(nèi),作為一種可靠的數(shù)據(jù)傳輸方式,TCP提供了許多應(yīng)用服務(wù),但隨著IP網(wǎng)的多業(yè)務(wù)化,尤其是VoIP的發(fā)展,TCP出現(xiàn)了很多局限性,例如對于VoIP信令及異步基于事務(wù)應(yīng)用的處理。因此,IEFT的信令傳輸工作組(SIGTRAN)提出了一種面向多媒體通信的流控制傳輸協(xié)議(SCTP),用于在IP網(wǎng)絡(luò)上傳輸PSTN信令消息,即通常所說的SS7 over IP。目前,IEFT將SCTP傳輸層協(xié)議作為主要研究目的,與TCP和UDP共筑于IP層之上。
同TCP一樣,SCTP提供面向連接的、點到點的可靠傳輸,它繼承了TCP強大的擁塞控制、數(shù)據(jù)包丟失發(fā)現(xiàn)等功能,任何在TCP上運行的應(yīng)用都可被移至SCTP上運行。
不同于TCP的是,SCTP提供了許多對于信令傳輸很重要的功能,同時,對于其他一些對性能和可靠性有額外需要的應(yīng)用,它能提供傳輸優(yōu)勢來滿足這些需要。SCTP和TCP最大的區(qū)別在于SCTP對多宿(multihoming)和部分有序(partial ordering)的支持。SCTP的多宿使得每個端點可被多個傳輸?shù)刂吩L問到,選擇不同傳輸?shù)刂窌䦟?dǎo)致兩個端點間不同的數(shù)據(jù)路徑,理想情況是在每一條路徑都建立一條獨立的擁塞控制。所以,SCTP的多主機擁塞控制仍需改進。
2 SCTP的特點
SCTP處于SCTP用戶應(yīng)用層與IP網(wǎng)絡(luò)層之間,它運用“關(guān)聯(lián)”(association)這個術(shù)語定義交換信息的兩個對等SCTP用戶間的協(xié)議狀態(tài) 。SCTP也是面向連接的,但在概念上,SCTP“關(guān)聯(lián)”比TCP連接更為廣泛:TCP的連接只有一個源地址和一個目的地址,SCTP提供一種方式使得每個SCTP端點能為另一個對等端點提供一組傳輸?shù)刂罚磦鬏數(shù)刂? 一組IP地址+端口號。
在繼承TCP特點的基礎(chǔ)上,SCTP提供了一些額外的功能:
1. 在多個“流”(stream)中實現(xiàn)用戶數(shù)據(jù)的有序發(fā)送
“流”在TCP中指一系列的字節(jié),而在SCTP中是指發(fā)送到上層協(xié)議的一定系列的用戶消息,這些消息的順序與流內(nèi)其他消息相關(guān)。SCTP用戶在建立關(guān)聯(lián)時,可以規(guī)定關(guān)聯(lián)支持的流的數(shù)目。這個數(shù)目是與源端商定的,用戶消息與流數(shù)目關(guān)聯(lián)。在鏈路中,SCTP為每個送到對等端的消息分配一個流序號。在接收端,SCTP確保在給定流中消息按順序發(fā)送。同時,當一個流正在等待下一個非順序的用戶消息時,其他流的發(fā)送會繼續(xù)。
2. 根據(jù)已發(fā)現(xiàn)的路徑MTU(最大傳輸單元)大小進行用戶數(shù)據(jù)分片
為了確保發(fā)送到下層的SCTP數(shù)據(jù)包與路徑MTU一致,SCTP對用戶消息分片。在接收端,分片被重組后傳給上層SCTP用戶。
3. 選擇性確認(SACK)和擁塞控制
選擇性確認用于數(shù)據(jù)包丟失發(fā)現(xiàn),TCP中確認序號返回的是發(fā)送方已成功收到數(shù)據(jù)字節(jié)序號(不包含確認序號所指的字節(jié)),而SCTP反饋給發(fā)送端的是丟失的并且要求重傳的消息序號。
SCTP運用了TCP中的擁塞控制技術(shù),包括慢啟動,擁塞避免和快速重傳。因此,當和TCP應(yīng)用共存時,SCTP應(yīng)用可接收屬于SCTP的網(wǎng)絡(luò)資源部分。
4. 塊(chunk)綁定
即多個用戶消息可選擇地綁定到一個SCTP包上,通過將消息放到一個或多個SCTP數(shù)據(jù)結(jié)構(gòu)——“塊”中,SCTP保留了應(yīng)用程序的消息框架邊界。不同類型的塊可綁定到一個SCTP包中,但是控制塊必須放在任何一個數(shù)據(jù)塊之前。
5. 路徑管理
SCTP 路徑管理功能主要負責從遠端提供的一組傳輸?shù)刂分羞x擇目的傳輸?shù)刂,它根?jù)兩個方面來選擇目的地址:SCTP用戶指示和當前可達的合格目的地。當其他流控制不能提供可達性信息時,路徑管理功能定時地掃描鏈路的可達性,并向SCTP報告遠端傳輸?shù)刂匪l(fā)生的變化。SCTP 路徑管理功能模塊同時還負責在建立鏈路時,向遠端報告可用的本地地址,并把遠端返回的傳輸?shù)刂犯嬖VSCTP用戶。
6. 支持多宿
當SCTP傳送數(shù)據(jù)包給目的IP地址時,如果此IP地址是不可達的,SCTP可以將消息重路由給一個交替的IP地址。這樣,在關(guān)聯(lián)的一端甚至兩端,可容忍網(wǎng)絡(luò)級錯誤。
7. 防范拒絕服務(wù)(DoS)攻擊
DoS的攻擊方式有很多種,最基本的DoS攻擊就是利用合理的服務(wù)請求來占用過多的服務(wù)資源,從而使合法用戶無法得到服務(wù)的響應(yīng)。SYN Flooding攻擊是DoS攻擊的一種實例,是目前效果最好的一種黑客攻擊方式。為了抵抗SYN Flooding對目標主機攻擊,SCTP在關(guān)聯(lián)初始化階段實施了一種安全的“Cookie”機制。
8. 支持多種傳輸模式
嚴格有序傳輸(像TCP),部分有序傳輸(像per-stream)和無序傳輸(像UDP)。
3 SCTP包結(jié)構(gòu)
SCTP包的結(jié)構(gòu),一個數(shù)據(jù)包首部可跟一個或多個可變長的塊。塊采用“類型—長度—值”(TLV)的格式。源端口、目的端口、校驗碼的意義同TCP中的意義相似。確認標簽保存著在SCTP握手中第一次交換的初始標簽的值。在關(guān)聯(lián)中,任何SCTP數(shù)據(jù)包若不包含這樣一個標簽,當?shù)竭_時會被接收端丟棄。
在每個塊中,TLV包括塊類型、傳輸處理標記、塊長度。不同的塊類型可用來傳輸控制信息或數(shù)據(jù)。
傳輸序列號(TSN)和流序列號(SSN)是兩種不同的序列號,TSN保證整個關(guān)聯(lián)的可靠性,而SSN保證整個流的有序性,這樣,在傳輸中,將數(shù)據(jù)的可靠性與有序性獨立分開。
4 SCTP數(shù)據(jù)傳輸
4.1 SCTP四路握手及抵抗SYN Flooding攻擊的原理
一個SCTP關(guān)聯(lián)定義為:[主機A的一組IP地址]+[主機A的端口]+ [主機B的一組IP地址]+[主機B的端口]。 因此,每一端對應(yīng)組中的任何一個IP地址都可作為相應(yīng)的源/目的地址來標示本次關(guān)聯(lián),通過四路握手,兩端SCTP主機交換通信狀態(tài)。
SYN Flooding利用了TCP/IP的固有漏洞,面向連接的TCP三次握手是SYN Flooding存在的基礎(chǔ)。SYN Flooding攻擊的原理是:惡意的攻擊者大量向服務(wù)器發(fā)送SYN報文,服務(wù)器在發(fā)出SYN+ACK應(yīng)答報文后無法收到客戶端的ACK報文(第三次握手無法完成),服務(wù)器端將為維護一個非常大的半連接列表而消耗非常多的CPU時間和內(nèi)存資源,還要不斷對這個列表中的IP進行SYN+ACK的重試。服務(wù)器端將忙于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求,此時從正?蛻舻慕嵌瓤磥,服務(wù)器失去響應(yīng)。
而在一次SCTP四路握手中,INIT消息的接收端不必保存任何狀態(tài)信息或者分配任何資源,這樣就可防范SYN Flooding等DoS攻擊。它在發(fā)送INIT-ACK消息時,采用了一種機制——“狀態(tài)Cookie”,該Cookie具有發(fā)送端要建立自己狀態(tài)所需的全部信息。
SCTP產(chǎn)生一個狀態(tài)Cookie的過程如下:
1. 使用收到的INIT和發(fā)出的INIT- ACK塊中的信息創(chuàng)建一個關(guān)聯(lián)的TCB(傳輸控制塊)。
2. 在TCB中,將當前日期設(shè)為創(chuàng)建日期,將協(xié)議參數(shù)“有效Cookie時間”設(shè)為生存期間。
3. 根據(jù)TCB,收集重建TCB所需的最小信息子集,將該子集和密鑰產(chǎn)生一個MAC(信息認證編碼)。
4. 結(jié)合上述最小信息子集和MAC產(chǎn)生狀態(tài)Cookie。
5. 在發(fā)送完INIT ACK(包含狀態(tài)Cookie參數(shù))后,發(fā)送方必須刪除TCB以及任何與新關(guān)聯(lián)有關(guān)的本地資源。
INIT和INIT-ACK都必須包含建立初始狀態(tài)所需的參數(shù):一組IP地址,保證可靠傳輸?shù)某跏糡SN,每個被接收的SCTP包中必須含有的初始標簽,每一端請求發(fā)出的流數(shù)目和每一端能支持接收的流數(shù)目。交換完這些消息之后,INIT的發(fā)送端以COOKIE-ECHO消息的方式發(fā)送回狀態(tài)Cookie。接收端根據(jù)所接收到的COOKIE-ECHO中的狀態(tài)Cookie,完整地重建自己的狀態(tài),并回送COOKIE-
ACK來確認關(guān)聯(lián)已建立。COOKIE-ECHO和COOKIE-ACK都可將用戶數(shù)據(jù)消息綁定到各自的包中。
由此可見,采用以上這種方式,即使接收再多的INIT消息, 接收端也沒有任何資源的消耗:它既不分配任何系統(tǒng)資源,也不保存此次新關(guān)聯(lián)的狀態(tài),它只是把相應(yīng)重建狀態(tài)所用的狀態(tài)Cookie作為參數(shù),包含在每一個回送的INIT-ACK消息中,最后該狀態(tài)Cookie會被COOKIE-ECHO消息發(fā)送回來。
4.2 SCTP數(shù)據(jù)交換
在兩個SCTP主機間的正常數(shù)據(jù)交換。SCTP主機發(fā)送SACK塊,用來確認每一個收到的SCTP包。因為SACK能完整地描述接收端的狀態(tài),因此,依據(jù)SACK,發(fā)送端能做出重傳判決。SCTP支持類似于TCP中的快速重傳和time-out重傳算法。
對于數(shù)據(jù)包丟失發(fā)現(xiàn),SCTP和TCP采用截然不同的機制:當TCP發(fā)現(xiàn)接收序號有缺口時,會等到該缺口被填上后,才發(fā)送序列號高于丟失數(shù)據(jù)包的數(shù)據(jù)。然而,SCTP即使發(fā)現(xiàn)接收序號有缺口或順序錯亂,仍會發(fā)送后面的數(shù)據(jù)。
4.3 SCTP關(guān)閉關(guān)聯(lián)
作為面向連接的傳輸協(xié)議,SCTP也運用三路握手來關(guān)閉一個關(guān)聯(lián),但與TCP有一點不同:一個TCP終端在“關(guān)聯(lián)關(guān)閉”的過程中能夠保持連接開啟,并從對端接收新的數(shù)據(jù),而SCTP不支持TCP的這種“半關(guān)閉”狀態(tài)。
1. 主機A發(fā)出“關(guān)閉”(SHUTDOWN)塊來終止與主機B的關(guān)聯(lián),主機A進入“SHUTDOWN-
PENDING”狀態(tài),對應(yīng)的動作是:不再接受上層應(yīng)用的數(shù)據(jù),只發(fā)送隊列中剩余的數(shù)據(jù),進入“SHUTDOWN-SENT”狀態(tài)。
2. 主機B一旦接收到“關(guān)閉”塊,就進入“SHUTDOWN-RECEIVED”狀態(tài),同主機A一樣,不再接受上層應(yīng)用的數(shù)據(jù),只發(fā)送隊列中剩余的數(shù)據(jù)。
3. 主機A再次發(fā)送“關(guān)閉”塊,通知主機 B所發(fā)送的剩余數(shù)據(jù)已到達,并且重申了關(guān)聯(lián)正在關(guān)閉。
4. 當?shù)诙问盏健瓣P(guān)閉”塊時,主機B發(fā)送“確認關(guān)閉”塊。
5. 主機A隨后發(fā)送“關(guān)閉結(jié)束”塊,完成本次關(guān)聯(lián)的關(guān)閉。
5 結(jié)束語
SCTP是為傳輸信令業(yè)務(wù)流而開發(fā)的,但它所具有的一些優(yōu)于TCP的先進協(xié)議機制,如選擇性確認、快速重傳、無序遞交等,使它又滿足高性能傳輸?shù)男枨,這會給它帶來更為寬廣的應(yīng)用需求。目前,已有各種操作系統(tǒng)支持SCTP, 如Linux、AIX、Solaris、Windows、FressBSD。在不同協(xié)議實現(xiàn)間的互操作性測試的成功,揭示著SCTP正走向商業(yè)產(chǎn)品之路。
IEFT正在致力于SCTP進一步的修改,使其更能滿足下一代應(yīng)用的需求,例如支持IPv6地址,解決對端對于IPv6的site-local、link-local地址無連通性的問題,以及在已存在的關(guān)聯(lián)中動態(tài)地增加或刪除IP地址而無需重啟該關(guān)聯(lián)。
此外,在第三代移動通信中,SCTP可作為信令承載層的備選方案之一,它的應(yīng)用及其性能評估也有待研究。
參 考 文 獻
[1] Stewart R等 . Transmission Control Protocol,IETF RFC 2960
[2] Allman M,Paxson V, Stevens W . TCP Congestion Control,IETF RFC 2581
[3] Mathis M等 . TCP Selective Acknowledgment Option, IETF RFC 2018
[4] Krawczyk H等 . HMAC: Keyed-Hashing for Message Authentication,IETF RFC 2104
[5] Stevens W R . TCP/IP Illustrated, Volume 1: The Protocols . Addison-Wesley
----《中國數(shù)據(jù)通信》