CAPWAP介紹

--wendynie

CAPWAP介紹

AC發(fā)現(xiàn)機(jī)制WTP使用AC發(fā)現(xiàn)機(jī)制來(lái)得知哪些AC是可用的，決定最佳的AC來(lái)建立CAPWAP連接。WTP的發(fā)現(xiàn)過(guò)程是可選的。如果在WTP上靜態(tài)配置了AC，那么WTP并不需要完成AC的發(fā)現(xiàn)過(guò)程。

WTP首先發(fā)送一個(gè)DiscoveryRequestmessage給受限的廣播地址，或者CAPWAP的多播地址(224.0.1.140)，或者是預(yù)配置的AC的單播地址。在IPV6網(wǎng)絡(luò)中，由于廣播并不存在，因此使用"AllACsmulticastaddress"(FF0X:0:0:0:0:0:0:18C)來(lái)代替。當(dāng)接收到DiscoveryRequestmessage消息，AC發(fā)送一個(gè)單播DiscoveryResponsemessage給WTP。WTP可以通過(guò)DiscoveryResponsemessage中所帶的AC優(yōu)先級(jí)，支持的CAPWAPbinding來(lái)選擇與哪個(gè)AC建立會(huì)話(huà)。除了上面的發(fā)現(xiàn)機(jī)制，WTP還可以使用DNS或者DHCP來(lái)發(fā)現(xiàn)AC.

返回AC發(fā)現(xiàn)機(jī)制WTP使用AC發(fā)現(xiàn)機(jī)制來(lái)得知哪些AC是可用的DTLS握手DTLS握手DTLS認(rèn)證和授權(quán)DTLS支持終端認(rèn)證方式為：證書(shū)（CERTIFICATE）和預(yù)共享密鑰（PRE-SHAREDKEY）。

CAPWAP認(rèn)證中使用證書(shū)支持的算法是TLS_RSA_WITH_AES_128_CBC_SHA[RFC5246]（MUSTSUPPORT）TLS_DHE_RSA_WITH_AES_128_CBC_SHA[RFC5246](SHOULDSUPPORT)TLS_RSA_WITH_AES_256_CBC_SHA[RFC5246](MAYSUPPORT)TLS_DHE_RSA_WITH_AES_256_CBC_SHA[RFC5246]](MAYSUPPORT)

DTLS認(rèn)證和授權(quán)DTLS支持終端認(rèn)證方式為：證書(shū)（DTLS認(rèn)證和授權(quán)

在RFC4279中定義了多種預(yù)共享密鑰的認(rèn)證方式，CAPWAP中主要關(guān)心下面兩種：Pre-SharedKey(PSK)keyexchangealgorithmDHE_PSKkeyexchangealgorithm同樣，CAPWAP定義了預(yù)共享密鑰支持的算法TLS_PSK_WITH_AES_128_CBC_SHA[RFC5246]（MUSTSUPPORT）TLS_DHE_PSK_WITH_AES_128_CBC_SHA[RFC5246]（MUSTSUPPORT）TLS_PSK_WITH_AES_256_CBC_SHA[RFC5246]](MAYSUPPORT)TLS_DHE_PSK_WITH_AES_256_CBC_SHA[RFC5246]](MAYSUPPORT)

DTLS認(rèn)證和授權(quán)在RFC4279中定義了多種預(yù)共CAPWAPPre-Provisioning由此可以看出，WTP和AC之間要建立安全的連接，必須預(yù)先配置一些數(shù)據(jù)。當(dāng)使用預(yù)共享密鑰，那么就需要在AC與WTP上面配置下面的數(shù)據(jù)：標(biāo)識(shí)符（Identity）:對(duì)端AC或者WTP的標(biāo)識(shí)符。標(biāo)識(shí)符可能就是一個(gè)IP地址或者主機(jī)名（DNS）。密鑰（Key）:建立DTLS會(huì)話(huà)所需要的預(yù)共享密鑰PSK標(biāo)識(shí)符（PSKIdentity）:與密鑰相關(guān)的身份標(biāo)識(shí)（Identityhint）。

當(dāng)使用證書(shū)的時(shí)候，需要配置：設(shè)備證書(shū)（DeviceCertificate）:本地設(shè)備的證書(shū)信任錨（TrustAnchor）:被信任的根證書(shū)鏈（rootcertificatechain），用于驗(yàn)證從CAPWAP對(duì)端收到的證書(shū)。CAPWAPPre-Provisioning由此可CAPWAPPre-Provisioning

除了為認(rèn)證而需要預(yù)先提供的數(shù)據(jù)，CAPWAP還需要配置控制訪(fǎng)問(wèn)列表（AccessControlList）:控制訪(fǎng)問(wèn)列表包括了一個(gè)或者多個(gè)CAPWAP對(duì)端的標(biāo)識(shí)符，并提供其相關(guān)的規(guī)則。這些規(guī)則用于決定與那些對(duì)端建立連接。

返回

CAPWAPPre-Provisioning除了為認(rèn)證TLS（TransportLayerSecurity）協(xié)議的局限性

TLS是最為廣泛部署的協(xié)議，它用來(lái)保障網(wǎng)絡(luò)安全通信。TLS用來(lái)保護(hù)Web通信和email協(xié)議（諸如IMAP，POP）。TLS的主要優(yōu)勢(shì)是它通過(guò)向應(yīng)用層和網(wǎng)絡(luò)層之間（即OSI模型中的會(huì)話(huà)層）插入TLS來(lái)保證應(yīng)用的安全。然而，TLS要求一個(gè)可靠的傳輸信道—典型的是TCP—因此不能用來(lái)保證數(shù)據(jù)報(bào)通信的安全。當(dāng)部署TLS的時(shí)候，大家還沒(méi)有充分認(rèn)識(shí)到這個(gè)局限性的嚴(yán)重程度，因?yàn)楫?dāng)時(shí)大多數(shù)應(yīng)用運(yùn)行在TCP之上。即使今天也是這樣。然而情況正在改變。

TLS（TransportLayerSecurity）協(xié)DTLS協(xié)議的出現(xiàn)

在過(guò)去幾年中，不斷增長(zhǎng)的應(yīng)用層協(xié)議，比如SIP(sessioninitialprotocol)，RTP(realtimeprotocol),MGCP(theMediaGatewayControlProtocol)，還有許多游戲協(xié)議都基于UDP傳輸而設(shè)計(jì)。這些應(yīng)用的設(shè)計(jì)者面對(duì)著許多用來(lái)保證安全性的選擇，但卻無(wú)法令人滿(mǎn)意。

首先，他們可以使用IPsec。然而，IPsec不適合于Client-Server應(yīng)用模型，且難以同應(yīng)用程序結(jié)合，因?yàn)镮Psec運(yùn)行在系統(tǒng)內(nèi)核。有很多文獻(xiàn)詳細(xì)討論了為什么IPsec為什么不是一個(gè)令人滿(mǎn)意的選擇。

其次，他們自己設(shè)計(jì)一個(gè)特有的應(yīng)用層安全協(xié)議。例如，SIP使用了S/MIME的一個(gè)變體來(lái)保證安全通信。將S/MIME嫁接到SIP中比使用TLS上的TCP版本的SIP變體更費(fèi)盡。

第三，可以把應(yīng)用移植到TCP之上，然后使用TLS。不幸的是，許多這樣的應(yīng)用依賴(lài)于UDP語(yǔ)義，當(dāng)運(yùn)行在諸如TCP之類(lèi)的流協(xié)議上性能將無(wú)法令人接受。DTLS協(xié)議的出現(xiàn)在過(guò)去幾年中，不斷增長(zhǎng)的應(yīng)用層DTLS協(xié)議的出現(xiàn)

最為明顯的選擇是設(shè)計(jì)一個(gè)通用的信道安全協(xié)議，它可以使用數(shù)據(jù)報(bào)傳輸，就像TCP上的TLS。這樣一個(gè)協(xié)議可以在用戶(hù)空間中實(shí)現(xiàn)，這樣便于安裝，但是要足夠靈活和通用，能夠許多面向數(shù)據(jù)報(bào)的應(yīng)用程序提供安全。盡管認(rèn)為這個(gè)方案將是一個(gè)巨大和困難的規(guī)劃項(xiàng)目。但是構(gòu)造一個(gè)可以工作的協(xié)議相當(dāng)直接，尤其是有了TLS的起點(diǎn)和IPsec的參考。因此設(shè)計(jì)出了這個(gè)新的協(xié)議，我們稱(chēng)為“DatagramTLS“,DTLS是TLS的一個(gè)修改版本，這樣函數(shù)能夠運(yùn)行在數(shù)據(jù)報(bào)通信上。相對(duì)于上面的方案，該方法有兩個(gè)主要優(yōu)勢(shì)：

首先，既然DTLS非常類(lèi)似于TLS，可以重用以前的協(xié)議架構(gòu)和實(shí)現(xiàn)方法。

其次，既然DTLS向通用安全層提供了相似的接口，就易于調(diào)整協(xié)議來(lái)使用它。TLS的經(jīng)驗(yàn)顯示，這種易于調(diào)整性是擴(kuò)大部署的關(guān)鍵。DTLS協(xié)議的出現(xiàn)最為明顯的選擇是設(shè)計(jì)一個(gè)通用的信道DTLS的特點(diǎn)可靠會(huì)話(huà)建立DTLS必須提供一個(gè)機(jī)制來(lái)認(rèn)證對(duì)端，進(jìn)行可靠密鑰建立、算法協(xié)商合參數(shù)傳遞。既然DTLS完全運(yùn)行在不可靠的數(shù)據(jù)報(bào)通信之上，必須實(shí)現(xiàn)重傳機(jī)制來(lái)保證握手信息的可靠傳遞。然而，重傳機(jī)制必須簡(jiǎn)單和輕量，能夠盡量使得DTLS的可移植。注意，要求創(chuàng)建一個(gè)會(huì)話(huà)意思是DTLS是適合于長(zhǎng)期的“面向連接的“協(xié)議，而不是類(lèi)似于DNS的完全無(wú)連接。無(wú)連接協(xié)議最好應(yīng)用層的對(duì)象安全協(xié)議提供。安全服務(wù)DTLS必須保證數(shù)據(jù)傳輸?shù)臋C(jī)密性和完整性，能夠檢測(cè)出被替代的數(shù)據(jù)包。易于部署在用戶(hù)空間中實(shí)現(xiàn)，不依賴(lài)于操作系統(tǒng)。語(yǔ)義借鑒TLS的優(yōu)點(diǎn)，DTLS的語(yǔ)義應(yīng)該模仿UDP語(yǔ)義，其借口模仿UDPAPI。最小的改動(dòng)由于TLS已經(jīng)非常成熟，最小化改動(dòng)能夠減少引入未知脆弱性的可能性。返回DTLS的特點(diǎn)可靠會(huì)話(huà)建立DTLS必須提供一個(gè)機(jī)制來(lái)認(rèn)證CAPWAP狀態(tài)機(jī)

CAPWAP狀態(tài)機(jī)，是被AC和WTP同時(shí)使用的。對(duì)于每個(gè)定義的狀態(tài)，只有特定的消息才被允許收發(fā)。因?yàn)閃TP只會(huì)和單個(gè)AC通訊，因此只會(huì)有一個(gè)CAPWAP的狀態(tài)機(jī)。而AC與WTP有很大差別，因?yàn)锳C同時(shí)和許多WTP通訊。DTLS和CAPWAP的狀態(tài)機(jī)由命令和通告的API接口聯(lián)系起來(lái)。DTLS狀態(tài)機(jī)的變遷由CAPWAP狀態(tài)機(jī)的命令觸發(fā)

CAPWAP狀態(tài)機(jī)的變遷由DTLS狀態(tài)機(jī)的通告觸發(fā)

CAPWAP狀態(tài)機(jī)Sulking

StartIdlediscoveryAuthorizeDeadDTLSSetupDTLSConnectDTLSTDJoinConfigureImageDataDataCheckRunReset返回SulkingStartIdlediscoveryAuth

StartIdleDTLSSetupdiscoveryAuthorizeSulkingDTLSConnectDTLSTDDeadJoinConfigureImageDataDataCheckRunResetStartIdleDTLSSetupdiscoveryAAC線(xiàn)程

AC使用了三個(gè)“線(xiàn)程”（thread）的概念。監(jiān)聽(tīng)線(xiàn)程：

通過(guò)DTLSlisten命令，AC監(jiān)聽(tīng)線(xiàn)程處理DTLS會(huì)話(huà)建立請(qǐng)求。創(chuàng)建的時(shí)候,監(jiān)聽(tīng)線(xiàn)程開(kāi)啟DTLSSetup狀態(tài)。當(dāng)狀態(tài)機(jī)進(jìn)入Authorize狀態(tài)，且DTLS會(huì)話(huà)生效之后，監(jiān)聽(tīng)線(xiàn)程創(chuàng)建一個(gè)指定的WTP指定會(huì)話(huà)服務(wù)線(xiàn)程和狀態(tài)空間。發(fā)現(xiàn)線(xiàn)程：

AC的發(fā)現(xiàn)線(xiàn)程負(fù)責(zé)接收和響應(yīng)發(fā)現(xiàn)請(qǐng)求消息。服務(wù)線(xiàn)程：

AC的服務(wù)進(jìn)程處理每個(gè)WTP的狀態(tài)和每個(gè)WTP連接的線(xiàn)程。這個(gè)線(xiàn)程在認(rèn)證后被監(jiān)聽(tīng)線(xiàn)程創(chuàng)建。一旦創(chuàng)建，服務(wù)線(xiàn)程會(huì)繼承監(jiān)聽(tīng)線(xiàn)程的一份狀態(tài)機(jī)空間的拷貝。當(dāng)與WTP之間的通訊完成后，服務(wù)線(xiàn)程關(guān)閉，所有的資源都會(huì)被釋放。

注意，在這里使用了線(xiàn)程這個(gè)術(shù)語(yǔ)，但是并不代表實(shí)現(xiàn)者就必須使用線(xiàn)程。這只是一個(gè)實(shí)現(xiàn)AC狀態(tài)機(jī)的可用的方法。AC線(xiàn)程AC使用了三個(gè)“線(xiàn)程”（thread）的概念StarttoIdle這個(gè)狀態(tài)變遷發(fā)生在設(shè)備初始化完成。WTP:開(kāi)啟CAPWAP狀態(tài)機(jī)。AC:開(kāi)啟CAPWAP狀態(tài)機(jī)。

返回StarttoIdleIdletoDiscovery

這個(gè)狀態(tài)變遷發(fā)生是為了支持CAPWAP發(fā)現(xiàn)進(jìn)程。

WTP:

WTP進(jìn)入發(fā)現(xiàn)狀態(tài)是為了優(yōu)先去傳輸?shù)谝粋€(gè)DiscoveryRequestmessage。在進(jìn)入這個(gè)狀態(tài)之前，WTP設(shè)置發(fā)現(xiàn)DiscoveryIntervaltimer，將DiscoveryCountcounter為0.同時(shí)清理以前的發(fā)現(xiàn)過(guò)程中可能會(huì)從AC收到的所有信息。

AC：

由發(fā)現(xiàn)線(xiàn)程執(zhí)行，且發(fā)生在收到一個(gè)發(fā)現(xiàn)請(qǐng)求報(bào)文的時(shí)候。此時(shí)，AC需要給這個(gè)報(bào)文響應(yīng)一個(gè)DiscoveryResponsemessage。

返回IdletoDiscovery這個(gè)狀態(tài)變遷發(fā)生是為DiscoverytoDiscovery

在這個(gè)發(fā)現(xiàn)狀態(tài)，WTP決定連接哪個(gè)AC。

WTP：

這個(gè)狀態(tài)變遷發(fā)生在發(fā)現(xiàn)DiscoveryIntervaltimer觸發(fā)的時(shí)候。對(duì)于這個(gè)事件的每次變遷，DiscoveryCountcounter會(huì)遞增。一旦WTP發(fā)送了DiscoveryRequestmessage，WTP重啟DiscoveryIntervaltimer。AC:

對(duì)于AC來(lái)說(shuō)，這個(gè)狀態(tài)變遷是無(wú)效的。

返回DiscoverytoDiscovery在這個(gè)發(fā)現(xiàn)DiscoverytoIdle

當(dāng)發(fā)現(xiàn)過(guò)程完畢的時(shí)候，AC的發(fā)現(xiàn)線(xiàn)程將會(huì)觸發(fā)這個(gè)變遷。WTP:

對(duì)于WTP來(lái)說(shuō)，這個(gè)狀態(tài)變遷是無(wú)效的。AC:

這個(gè)狀態(tài)變遷由AC發(fā)現(xiàn)線(xiàn)程執(zhí)行，當(dāng)發(fā)現(xiàn)線(xiàn)程傳輸了一個(gè)給DiscoveryRequest回送了一個(gè)DiscoveryResponse的時(shí)候，就會(huì)觸發(fā)這個(gè)過(guò)程。