SIP協議詳解(中文)-6
阿新 • • 發佈：2019-01-27
這些展示的問題需要定義一個架構來把拒絕服務攻擊造成的影響最小化，並且需要在安全機制中對這類攻擊特別留意。
26.2 安全機制
從上邊講述的威脅來看，我們得到了SIP協議所需要的基本安全服務，他們是：保護訊息的隱私性和完整性，保護重現（replay）攻擊或者訊息欺騙，提供會話參與者的身份認證和隱私保護，保護拒絕服務攻擊。SIP訊息中的包體分別要求機密性，完整性和身份認證。
比為SIP重新定義新的安全機制更好的是，SIP可以重用已經存在的HTTP或者SMTP的安全機制。
全加密的訊息提供了最好的機密保護－它也可以保證訊息不被噁心的中間節點更改。不過SIP請求和應答不能簡單的進行端到端的加密，因為在大多數網路架構下，訊息的頭域比如Request-URI,Route,Via在中間經過的proxy中需要可見，這樣SIP請求才能被正確路由。注意，proxy伺服器需要修改一些訊息的特定屬性（比如增加Via頭域），這樣才能保證SIP正常工作。那麼proxy伺服器就必須被UA信任，至少在某種程度上信任。為了這個目標，我們建議為SIP提供低層次的安全機制，他們是基於節點到節點的整個SIP請求和應答的線上加密，並且語序終端節點校驗他們發出請求的proxy伺服器的身份。
SIP實體也可以為安全保證，需要驗證對方的身份。當SIP終端向對方UA或者proxy伺服器，宣告它的使用者的身份時，這個身份應當是可以通過某種方法驗證的。SIP中的數字簽名機制就是為了這個需要的。
SIP訊息體的一個獨立的安全（加密）機制提供了另一個端到端的相互認證方式，也降低了UA必須信任中間節點的程度。
26.2.1 通訊和網路層的安全
通訊或者網路層的安全機制是加密訊號通訊，保證訊息機密的和完整的傳送。
很多情況下，低層次的安全是通過證書實現的，這些證書可以在很多架構下用於提供身份認證使用。
兩個通常使用的方法，提供了通訊層和網路層的安全，他們是TLS[25]和IPSec[26]。
IPSec是一組網路層的協議工具，他們可以一起使用來作為傳統IP通訊的安全替代。IPSec最常用於一組主機或者管理的域有一個現存的互相信任關係的架構下。Ipsec通常由主機的作業系統級別實現，或者在一個提供機密通訊和完整性保證的通訊安全閘道器上實現（比如VPN接面構），IPSec也可以用於點到點的結構。
在很多結構下，IPSec並不要求和SIP應用一起使用；IPSec可能是最適合於部屬在那種難於直接在SIP伺服器上增加安全性的情況。具有預先共享金鑰關係的UA和他們的第一個節點的proxy伺服器很適合使用IPSec。為SIP部屬的IPSec要求一個IPSec 描述了協議工具的profile。這個profile在本文件中沒有提供。
TLS提供了通訊層的安全性，基於連線相關的協議（TCP）。可以通過在Via頭域或者在一個SIP URI中列明”tls” (表示基於TCP的TLS)指定通訊協議為TLS。TLS最適合沒有事先定義的信任關係的點到點的結構。例如Alice 信任她的本地proxy伺服器，這個伺服器在進行證書交換後信任Bob的本地proxy伺服器，這個Bob的本地proxy伺服器是Bob信任的，因此Bob可以和Alice安全的通訊。
TLS必須和SIP應用緊緊聯絡在一起。注意在SIP中的通訊機制是點到點的，因此一個基於TLS傳送請求到proxy伺服器的UA並不能保證這個TLS會在端到端的應用。
當實現者在SIP應用中使用TLS的時候，實現者必須支援最小集合的TLS_RSA_WITH_AES_128_CBC_SHA密碼套件[6]。並且為了向後相容，proxy伺服器，重定向伺服器和註冊伺服器應當支援TLS_RSA_WITH3DES_EDE_CBC_SHA。實現者也可以支援其他密碼套件。
26.2.2 SIPS URI方案
SIPS URI方案是SIP URI（19節）語法的一個附加，雖然這個方案串是”sips”不同於”sip”。SIPS的語義和SIP URI的語義十分不同。SIPS 允許指定希望通過安全訪問的資源。SIPS URI可以當作一個特定使用者的address-of-record使用－這個使用者是已知的（根據他們的名片，在他盟請求的From頭域，在REGISTER請求的To頭域）。當在請求中使用Request-URI，SIPS 方案指出請求經過的每一個節點，知道請求到達目的這個Request-URI指明的SIP元素，必須通過TLS進行加密；當請求抵達目標的域，他會根據目標域的本地安全策略和轉發策略，很有可能最後一部也是用TLS到達UAS。當用在請求的發起方（就像這種情況，當他們使用SIPS URI當作目標的address-of-record一樣），SIPS只是這個實體請求，到目的主機的所有路徑都應當加密。
SIPS方案適用於很多在SIP中應用的SIP URI，比如附加域Request-Uri,包含在address-of-record,聯絡地址（Contact的內容，包含REGISTER方法的頭域等等），還有Route頭域等等。在每個用法中，SIPS URI方案允許這些存在的URI來指明需要安全訪問的資源。這些由SIPS URI所替換的東西，有他們自己的安全屬性（[4]中詳細介紹）。
對SIPS的使用在細節上要求必須具備TLS互相的認證，並且要求支援密碼套件TLS_RSA_WITH_AES_128_CBC_SHA。在認證過程中接收到的信任書應當從客戶端持有的信任書跟節點開始驗證；對信任書驗證失敗應當導致請求的失敗。
注意在SIPS URI方案中，通訊層是和TLS沒有依賴關係的，並且因此”sips:
將address-of-record用SIPS URI發出的使用者，如果在非可靠通訊協議上收到的請求，可以操作裝置來拒絕這個請求。
26.2.3 HTTP Authentication
SIP提供了認證機制，基於HTTP認證的身份認證機制，他們依賴於401倒407應答碼和相關頭域來提供拒絕不信任的信任書。對於SIP使用的HTTP Digest認證機制，並沒有做重大的修改，它提供了replay攻擊的保護和單向認證關係。
對SIP的Digest 認證使用在22節有描述。
26.2.4 S/MIME
就像上邊講述的，在端到端的過程中加密整個SIP訊息體，可以提供機密性的保護，但是並非所有的欄位都能使用這個機制進行保護，因為中間的網路節點（比如proxy伺服器），需要根據讀取適當的頭域然後決定這個訊息應當轉發倒哪裡，並且如果這些中間節點由於安全原因被排出在外，那麼SIP訊息從本質上就是不能路由的。
不過，S/MIME允許SIP 的UA在SIP中加密MIME包體，在不影響訊息頭的情況下，在端到端的通訊中加密這些MIME包體。S/MIME可以提供訊息體的端到端的完整性和機密性，同樣也提供了雙向的認證機制。使用S/MIME也可以通過SIP訊息隧道，為SIP頭域提供一個完整性和機密性的方案。
對SIP的S/MIME使用在23節講述。
26.3 安全機制的實現
26.3.1 對SIP實現者的要求
proxy伺服器，重定向伺服器，和註冊伺服器必須實現TLS，並且必須支援雙向的和單向的認證關係。強烈建議UA可以初始化TLS；UA同樣可以作為一個TLS伺服器。proxy伺服器，重定向伺服器和註冊伺服器應當有一個站點信任書，這個信任書的主題和他們的規範主機名相關。對於TLS的雙向認證，UA可以有他們自己的信任書，但是本文件中，沒有規定他們的具體用法。所有的支援TLS的SIP元素必須具備在TLS協商中，驗證信任書的機制；這個使得證書機關（可能是有名的類似web瀏覽器證書發行機構的發行機構）釋出的一個或者多個根信任書成為必須。所有支援TLS的SIP元素必須同樣支援SIPS URI方案。
Proxy伺服器，重定向伺服器，註冊伺服器，和UA可以實現IPSec或者其他底層的安全協議。
當UA試圖聯絡一個proxy伺服器，重定向伺服器或者主阿伺服器，UAC應當初始化一個TLS連線，在這個連線上發起SIP訊息。在某些結構嚇，UAS可以同樣在這些TLS接收請求
Proxy伺服器，重定向伺服器，註冊伺服器，和UA必須實現Digest身份認證，包括所有的22節要求的要點。Proxy伺服器，重定向伺服器，註冊伺服器應當配置成為至少有一個Digest realm,並且對於給定伺服器來說，必須支援至少有一個”realm”字串和這個伺服器的主機名或者hostname相關聯。
UA可以支援MIME包體的加密，並且通過23節描述的那樣使用S/MIME傳送信任書。如果UA具有一個或者多個根身份認證的信任書，用來鑑定TLS或者IPSec的信任書，它應當適當的可以用這些來鑑定S/MIME的信任書。UA可以為S/MIME身份認證而具有特定的根信任書。
注意，隨著S/MIME實現，將來會有安全擴充套件，來提高S/MIME的強度。
26.3.2 安全解決方案
這些安全機制的操作，可以在某種程度上和現存的WEB和EMAIL安全模式一致。在高一點的級別來看，UA通過Digest 使用者名稱和口令把他們自己的身份向伺服器（proxy伺服器，重定向伺服器，註冊伺服器）認證；伺服器把他們自己向UA單節點認證，或者向另外一個伺服器進行單節點（one hop）認證（反之亦然），並且是通過TLS來傳送伺服器節點信任書。
在點對點的級別，UA一般信任網路來進行對方身份的鑑別；不過,如果網路不能夠鑑定對方身份，或者網路本身不被信任的情況下，也可以使用S/MIME來提供直接的身份認證。
接下來是一個例子，在這個例子中，不同的UA和伺服器使用這些安全機制防止26.1節描述的攻擊威脅。實現者和網路管理員可以遵循本節末尾給出的指示來防止攻擊威脅，這些指示是作為實現例子提供的。
26.3.2.1 註冊
當UA上線，並且註冊到它自己的域上，它應當和它的註冊伺服器建立一個TLS連線（10節描述了UA怎樣找到它的註冊伺服器）。註冊伺服器應當提供一個信任書給UA，並且這個信任書的節點必須是這個UA想要註冊的域相關的信任書節點；例如，如果UA向註冊
當UA收到註冊伺服器提供的一個有效的信任書，UA知道註冊伺服器並非一個攻擊者（可能重定向、竊取口令、或者試圖做類似攻擊的攻擊者）。
於是UA建立了一個REGISTER請求，並且Request-URI應當指向從註冊伺服器所接收到的信任書站點。當UA通過剛才建立的TLS連線傳送REGISTER請求，註冊伺服器應當給出一個401（Proxy Authentication Required）應答。在這個應答中，Proxy-Authenticate頭域的”realm”引數，應當和前邊給出的信任書節點的域相同。當UAC收到這個拒絕，它應當提示給使用者要求信任書，或者根據應答中的”realm”引數，從現有的金鑰組中查詢對應的信任書。這個信任書的使用者名稱應當和REGISTER請求的To頭域的URI的”userinfo”部分相關。當在一個合適的Proxy-Authorization頭域中插入和這個信任書，REGISTER應當重新發送到註冊伺服器。
由於註冊伺服器要求UA認證它自己，對於攻擊者來說，偽造一個使用者的address-of-record的REGISTER請求是很困難的。同樣注意到由於REGISTER是通過機密的TLS連線傳送的，攻擊者不能通過擷取REGISTER來記錄信任書來進行重放攻擊。
當註冊請求被註冊伺服器接收，UA應當繼續保持TLS連線，這樣使得註冊伺服器可以既當作proxy伺服器，這個proxy伺服器可以作為管理這個域的proxy伺服器。剛完成註冊的TLS連線會繼續保留用於接收UA後續發起的請求。
由於UA已經通過在TLS連線的對方的伺服器的認證，所有在這個連線上的請求都是經過proxy 伺服器的（由於保留了TLS連線，也就是說，剛才的註冊伺服器更換了角色，變成一個proxy伺服器）－－攻擊者不能偽造好像是剛才從這個proxy伺服器傳送的請求。
26.3.2.2 在域之間的請求
現在我們說，Alice的UA希望和遠端管理的域的一個使用者，這個使用者叫做”
對於一個管理域的Proxy伺服器處理那發請求，可以同樣作為本地的外發proxy；基於簡單的原則，我們假定這就是atlanta.com（否則這時候UA將要初始化一個新的TLS連線到一個獨立的伺服器）。假定這時候，這個客戶端已經完成了註冊（參見前邊的步驟），當它發出INVITE請求邀請另外一個使用者的時候，它將重用這個TLS連線到本地proxy伺服器（剛才的註冊伺服器）。這個UA在INVITE請求中，將會重用剛才cache的信任書，這樣可以避免不必要的要求使用者輸入信任書。
當本地的發外伺服器驗證了這個UA在INVITE請求中的信任書，它應當檢查Request-URI來決定這個訊息應當如何路由（參見[4]）。如果這個Request-URI的”domainname”部分和一個本地域相關聯（atlanta.com）而不是和biloxi.com相關，那麼proxy伺服器會向本地服務查詢來決定怎樣最好的訪問到被呼叫的使用者。
“[email protected]”正在嘗試聯絡呼叫”[email protected]”,本地proxy將會轉發這個請求到Alex和它的註冊伺服器所建立的TLS連線上。由於Alex將會通過它的已經通過認證的連線上收到這個請求，它就確定這個Alice的請求是通過了本地管理域的proxy的身份驗證的。
不過，在這個例子中，Request-URI指向的是一個遠端域。在atlanta.com的本地外發伺服器應當因此而建立一個和在biloxi.com的遠端proxy伺服器的TLS連線。由於這個TLS連線的兩端都是伺服器，並且都有伺服器的信任書，那麼應當使用雙向的TLS身份認證。連線的雙方應當驗證和檢查對方的信任書，把在信任書中的域名同SIP訊息中的頭域做比較。例如，atlanta.com 這個proxy伺服器，在這步，應當檢查從對方接收到的關於biloxi.com域的信任書。當檢查完畢，並且TLS協商完成，就建立了基於兩個proxy的安全通道，atlanta.com proxy於是可以把INVITE請求轉發給biloxi.com了。
在biloxi.com的proxy伺服器應當檢查atlanta.com的信任書，並且比較信任書提供的域名和INVITE請求的From頭域的”domainname”部分。這個biloxi proxy可以執行嚴格的安全機制，拒絕那些他們被轉發的域和本proxy所管理的域不匹配的請求（這個不太明白）。
這些安全機制可以用來防止SIP和SMTP ‘open relays’一樣經常被用於產生垃圾郵件一樣的資訊。
這個政策，只是保證了請求宣告的來源確實是它自己；他並不允許biloxi.com確知如何atlanta.com認證的Alice。只有當biloxi.com由其他方法知道atlanta.com的身份認證機制，他才可能確知Alice如何證明她的身份的。biloxi.com可以接著使用更嚴格的方法，禁止來自未確定和biloxi.com相同的認證策略的域的請求（就是說所有biloxi.com接受的請求，都必須來自biloxi.com所知道身份認證方式的域）。
當INVITE請求被biloxi.com核准，proxy伺服器應當鑑別現存的TLS通道，如果存在現存的TLS通道，並且是和這個請求中的被叫使用者（在這個例子中是[email protected]）相關聯的。那麼這個INVITE請求應當通過這個TLS通道傳送給Bob。由於通過這個TLS連線收到的請求，這個TLS連線是剛才已經在biloxi proxy上通過了身份認證，Bob於是知道From頭域沒有被篡改，並且atlanta.com已經認證了Alice，所以就沒有必要猶豫是否信任Alice的身份。
在他們轉發請求錢，兩個proxy伺服器應當在請求中增加Record-Route頭域，這樣所有在這個對話中的後續的請求講過通過這兩個proxy伺服器。proxy伺服器因此可以在對話生存週期中，繼續提供安全服務。如果proxy伺服器並不在Record-Route頭域增加他們自己，以後的訊息將會直接端到端的在Alice和Bob中傳送，而沒有任何安全措施（除非兩個端點使用了某種獨立的端到端的安全措施，比如S/MIME）。在這個考慮上，SIP梯形模式可以提供一個精美的結構來在proxy伺服器節點之間進行磋商，以提供一個Alice和Bob之間的有道理的安全通道。
例如，一個攻擊這個結構的攻擊者將會不能偽造BYE請求並且把他插入Bob和Alice的信令流，因為攻擊者無從探聽會話的引數，這也是由於通訊的完整性機制保證了Alice和Bob之間的通訊是機密的完整的。
26.3.2.3 點對點請求
另外，考慮這樣一個情況，UA聲稱[email protected]沒有一個本地外發proxy。當Carol希望傳送INVITE到[email protected],她的UA應當直接初始化一個TLS連線到biloxi proxy（使用附件[4]中描述的機制來檢查怎樣到達指定的Request-URI）。當她的UA收到一個biloxi proxy傳送的信任書，她應當在通過TLS連線傳送她的INVITE請求前，正常校驗這個信任書。不過，Carol並沒有義務相biloxi proxy提供她自己的身份，但是她在INVITE請求的”message/sip”包體中，有一個CMS-detached(分離的)簽名。如果Carol在biloxi.com realm有其他信任書的話，就不一定提供這個簽名，但是她在biloxi.com上沒有正式關係，所以她沒有信任書，也就必須提供這個簽名。biloxi proxy可以有嚴格的機制直接把這個請求踢掉，甚至不用麻煩被叫方來驗證這個請求，因為在From頭域的”domainname”部分，並沒有biloxi.com－它可以被當作這個使用者是未認證的。
biloxi proxy對於Bob使用者有一個政策，就是所有未認證的請求都應當轉發到一個適當的地址，對於[email protected],就是<sipo:[email protected]>。Carol在和biloxi proxy建立的TLS連線上，收到這個轉發請求的應答，於是它信任這個轉發地址的真實性。
Carol應當和目標地址建立一個TCP連線，並且傳送一個新的INVITE請求，在這個請求中，Request-URI包含剛才接收到的聯絡地址（需要重新計算包體中的簽名，因為請求重新構造了）。Bob從不安全的介面上接收到這個INVITE請求，但是這個UA是特意預留一個不安全的介面，在這個情況下，認可請求中的From頭域並且隨後把INVITE包體中的簽名和一個本地cache的信任書進行匹配。Bob用類似的方法應答,把他自己相Carol進行認證，這樣一個安全的對話就開始了。
某些情況下，在一個域的NAT或者防火牆會阻止UA之間直接建立TCP連線。在這個情況下，如果本地策略許可，proxy伺服器可以隱含的做UA之間的請求轉發，並且這個轉發是基於沒有信任關係的（比如不用現存的TLS連線，而是通過TCP明碼的請求轉發）
26.3.2.4 DoS 防護
基於這些安全解決方案，為了使得拒絕服務(DoS)攻擊造成的影響最小，實現者應當注意如下的指引：
當SIP proxy伺服器所在的主機是基於公共internte做路由的，他應當部署在一個具有防護操作策略的管理域中（比如block源路由，過濾ping包等等）。TLS和IPSec都可以在管理域的邊界的防護主機，一起參與安全系統的構家，來提高安全性。這些防護主機可以防護拒絕服務攻擊，確保在管理域中的SIP主機不會被大量的訊息阻塞。
不管使用什麼樣的安全措施，對proxy伺服器的洪水訊息攻擊可以耗盡proxy伺服器的資源，並且阻止傳送到目的地的正確的請求。對於proxy伺服器來說，每一個SIP事務都會好用一定的資源，對於有狀態的伺服器來說這個消耗會更大。因此，有狀態的proxy比無狀態的proxy更容易受到洪水攻擊的影響。
UA和proxy伺服器應當用一個401（Unauthorized）或者407（Proxy Authentication Required）拒絕有問題的請求，並且對這些有問題的請求不使用正常的應答重發機制，並且對這些未認證的請求把自己當作無狀態的伺服器使用。如果攻擊者使用假的頭域值(例如Via)指向一個第三方的被攻擊的伺服器，那麼對於401(Unauthorized)或者407（Proxy Authentication Required）應答的重發可能正中攻擊者的下懷。
總得來說，基於TLS簽名的proxy伺服器之間的雙向認證機制，降低了中間節點潛在的風險，並且減少了可以用作拒絕服務攻擊的偽造的請求或者應答。這也同樣提高了攻擊者利用無知的SIP節點進行放大攻擊的難度。
26.4 限制
雖然有這些安全機制，在正確應用的時候，可以阻止很多攻擊，但是對於網路管理者和開發者來說，也必須明白他們也會有很多限制的地方。
26.4.1 HTTP Digest
在SIP中對於HTTP Digest一個限制是Digest的完整性機制在SIP下運作的不是很完美。尤其是，他們提供了對訊息中的Request-URI和方法的保護，但是並沒有對UA希望提供加密的所有頭域進行了保護。
RFC2617所提供的回放攻擊保護對於SIP來說也有一些限制。例如，next-nonce機制，並不支援通過管道傳送的請求。防止回放攻擊應當使用nonce-count機制。
另一個HTTP Digest限制是realm的範圍。當用戶希望把他們自己的身份向一個資源（這個資源和他們有著預先存在的關係）進行認證的時候，Digest是有用的，它就像一個服務提供者，使用者是一個客戶端（這是十分常見的場景，因此Digest提供了一個十分有用的功能）。與之對應的，TLS的範圍是基於域之間的，或者multirealm的，因為信任書通常是全域性可驗證的，所以UA可以在不需要預先存在關係的伺服器上進行身份驗證。
26.4.2 S/MIME
對於S/MIME的一個最大的限制是對終端使用者來說，缺少廣泛的公共金鑰機構。如果使用的是自簽名（selfsigned）信任書（或者信任書不能被對話的對方所驗證），23.2節描述的基於SIP的金鑰交換機制就容易遭受中間人攻擊（man-in-the-middle），在這個中間人攻擊中，攻擊者可以悄悄檢查和修改S/MIME包體。攻擊者需要擷取對話中，雙方的第一個金鑰交換，在請求和應答中移去現有的CMS-detached簽名，並且插入另外的包含攻擊者提供的信任書（但是看起來像是正確地address-of-record的信任書）的CMS-detached 簽名。通訊的雙方都回以為他們和對方交換了金鑰，實際上他們互相有的只是攻擊者的公鑰。
必須明確注意到攻擊者只能攻擊雙方的第一次的金鑰交換－在後續的情況，金鑰的變更對於UA來說就是不可見的了。同樣使得攻擊者難以竊聽對話雙方的以後的對話中（比如一天內的對話，周內的，或者一年的對話）。
SSH在第一次金鑰交換的時候，也同樣容易受到這個中間人攻擊；但是，雖然眾所周知SSH不完美，但是它確實提高了連線的安全性。對於SIP來說，使用金鑰的指紋可以有些幫助，就像在SSH中一樣。例如，如果SIP的雙方建立了一個語音通訊會話，每一個都可以讀取對方傳送的金鑰指紋，並且可以根據這個指紋和原始指紋做比較。這使得中間人更加難以在語音中模擬通話雙方的金鑰指紋（實際上這個在Clipper 基於晶片的保密電話中使用）。
在S/MIME機制下，如果UA在他們的金鑰組中持有對方address-of-record的信任書，允許UA不用導言來發送加密的請求。不過，存在這個樣的情況，如果某個設備註冊了這個address-of-record，並且沒有持有持有裝置當前使用者先前使用的信任書。並且它將因此不能正常處理加密的請求，於是可能會導致某些原本可以避免的錯誤訊號。這很像加密的請求被分支的情況。
S/MIME相關的金鑰通常用於和特定使用者（一個address-of-record）關聯起來使用,而不是和一個裝置（UA）一起使用。當用戶在裝置之間移動，很難把私鑰安全的在UA之間傳遞；一個裝置如何獲得這些金鑰不在本文討論。
另外，使用S/MIME更常見的困難是，它可以導致很大的訊息，特別是當採用23.4節的SIP隧道戒指的時候。基於這個原因，當使用S/MIME隧道機制的時候，一定要使用TCP通訊協議。
26.4.3 TLS
TLS最大的問題是，它不能基於UDP；TLS要求面向連線的底層通訊協議，對於本文來說，就是TCP。
對於TLS來說，在本地外發proxy伺服器和/或者主車伺服器上和大量UA，維持很多併發TLS長連線，是一件費力的事情。這導致某些容量問題，特別是在使用加強金鑰套件的時候更容易出現容量問題。維持冗餘的TLS長連線，特別是當UA獨立負責他們的連線，會很耗資源。
TLS只允許SIP實體到他們臨近的認證伺服器的連線；TLS提供了嚴格的節點到節點的安全性（hop-by-hop）。無論TLS,還是其他本文件規定的安全機制，當不能直接建立TCP連線的情況下，都允許客戶通過驗證自己到proxy伺服器來到達目的地。
26.4.4 SIPS URI
實際上在請求經過的每一段都使用TLS，要求了最終的UAS必須能夠通過TLS到達（也許是通過SIPS URI作為一個聯絡地址註冊的）。通常這個目的地是用SIPS描述的。在很多結構下，使用TLS保護一部分請求路徑，最後一部確實依賴於其他的安全機制到UAS。因此SIPS不能保證TLS是真正的端到端的使用。注意，這是由於許多UA不接受進來的TLS連線，甚至那些支援TLS的UA也可能要求要維持一個永久的TLS連線（就像前邊的TLS限制節講述的一樣），目的是為了作為UAS從TLS上接收請求。
位置服務，對於SIPS Request-URI來說，是不要求提供SIPS繫結的。雖然位置服務通常由使用者註冊（10.2.1節描述）組成，但是對於一個address-of-record來說，可以由不同的協議和介面都可以提供聯絡地址，並且這些工具都可以用來對映SIPS URI到適當的SIP URI。當對繫結資訊查詢的時候，位置服務返回它的聯絡地址，而不關心這個是否是從一個SIPS的Request-URI上收到的請求。如果是轉發伺服器訪問位置服務，那就是說取決於處理轉發的Contact頭域的SIP實體來決定聯絡地址的屬性。
如果要求請求經過的全部路徑都使用TLS通訊，那麼對目的域來說稍稍有點麻煩。如果實現困難，也允許在請求傳送節點中的基於密碼認證的proxy伺服器，不相容或者選擇一個折中方案來略過SIPS的轉發機制（在16.6節定義的通常轉發規則）。但是，惡意的中間節點就有可能把一個基於SIPS URI的請求，重新降級成為SIP URI。
另外，中間節點也可以正常的把一個基於SIP的請求更改成基於SIPS URI的請求。請求的接受方發現請求的Request-URI是基於SIPS URI方案的並不能假設原始請求的Request-URI也是基於SIPS通過中間節點傳送的（從客戶端往後）。
為了解決這個問題，我們建議請求的收件人,在請求的Request-URI包含一個SIP或者SIPS URI的情況下，檢查To頭域值，看看是否包含一個SIPS URI（雖然注意到Request-URI可以和To頭域URI有相同的URI方案，但是他們不相等並不意味者是一個安全隱患）。雖然客戶端可以在一個請求中把Request-URI和To頭域做成不一樣的，但是當兩個欄位的SIPS不一樣的話，那就是可能的安全隱患，並且請求因此應當被接受方拒絕。接受方也可以檢查Via頭域鏈來雙重檢查是否TLS在整個請求路徑中被使用，一直到最近的本地管理域。源UAC也可以用S/MIME來幫助確保原始格式的To頭域被端到端的傳送。
如果UAS有原因來相信Request-URI的URI方案在通訊中被非法修改，UA應當提示使用者這個潛在的安全隱患。
作為更深遠的考量，為了防止底層的攻擊，如果SIP實體只接受SIPS請求，那麼可以拒絕在非安全埠的連線。
終端使用者應當完全清楚SIPS和SIP URI的區別，他們可以在應答中手工更改這個URI方案。這可以增加或者降低安全性。例如，如果一個攻擊者攻陷了一個DNS的cache，插入了一個假的記錄集，這個記錄集有效刪去了一個proxy伺服器的所有SIPS記錄，接著經過這個proxy伺服器的SIPS請求就會失效。這時候，一個使用者，看見這個SIPS address-of-record總是失敗，他可以手工改掉URI從SIPS改成SIP，並且重試。當然，這也有一些安全機制防止這類事情發生（如果目標UA真是有神經病拒絕所有非SIPS請求的話）。但是這個限制毫無價值。往好了想，使用者也可以把SIP URI變成SIPS URI。
26.5 Privacy(隱私)
SIP訊息經常包含傳送者的敏感資訊－不只是他們將說些什麼，也包括了他們和誰在通訊，以及他們通訊了多久，以及從那裡到哪裡的通訊等等。很多應用和他們的使用者都要求這類隱私資訊對於沒有必要知道的方面來說都必須保持隱祕。
注意，也有隱私資訊也有少數直接洩漏的方式。如果使用者或者服務，位於一個容易猜到的地址，比如通過使用者的名字或者機構的聯絡（這是構成Address-of-record的最經常的情形），傳統保證隱私性的方式是通過一個未列出的”電話號碼錶”來實現的。在呼叫方發起的會話邀請中，使用者位置服務可以提供精確的被叫方的位置從而破壞了隱私；在實現上因此應當更嚴格，基於每使用者的原則，根據不同的呼叫方給出不同的位置資訊和可用性的資訊。這是一個SIP需要解決的完整的問題。
在某些情況下，使用者可能希望在通過身份驗證時，在頭域中隱藏個人資訊。這可以應用於不僅是From和相關表現請求發起方資訊的頭域，也應用於To頭域－他可能不能由快速撥號的nick-name轉換成為最終的目的地資訊，或者一個為擴充套件的一組目標的標誌，當請求被路由的時候，每一個都可以從Request-URI上被移去，但是如果和To頭域初始值相等的時候，不能更改To頭域。因此，他可能由於隱私的原因建立和Request-URI不同的To頭域。
27 IANA 認證
SIP應用中的所有的方法名字，頭域名字，狀態碼，和option tags，都是通過RFC中關於IANA認證節的說明在IANA註冊的。
本規範指示IANA建立了4個新的子註冊專案在：http://www.iana.org/assignments/sip-parameters: Option Tags,Warning Codes(warn-codes),Methods和Response Codes,頭域的子項也在那裡。
27.1 Option Tags
這個規範在http://www.iana.org/assignments/sip-parameters建立了Option Tags註冊項.
Option tags用於類似Require,Supported,Proxy-Require,Unsupoprted這類的頭域，用來支援SIP的擴充套件相容性機制（19.2節）。Option tag自身時一個字串，和特定的SIP選項相關（也就是和特定的SIP擴充套件相關）。它為SIP終端確定這個選項。Option tags當被標準的RFC軌跡擴充套件，它就在IANA註冊了。RFC的IANA認證節必須包含如下內容，這些內容與RFC出版號碼一起在IANA登錄檔登記。
o option tag的名字。名字可以是任意長度的，但是應當不要超過20個字母。丙子必須是alphanum(25節)字元。
o 描述擴充套件的描述資訊
27.2 Warn-Codes
本規範在http://www.iana.org/assignments/sip-parameters建立了Warn-Codes註冊項。並且初始釋出的warn-codes值在20.43節列出。附加的warn-codes通過RFC出版物註冊發表。
對於warn-codes表的描述資訊如下：
當一個會話描述協議（SDP）（RFC 2327[1]）出現問題導致事務失敗的時候，Warning codes在SIP應答資訊中提供了對狀態碼的補充資訊。
“warn-code”包含了3位數字。第一個數字”3”表示warning是SIP的警告資訊。除非以後另有描述，只有3xx警告資訊可以被註冊。
300到329的警告資訊為會話描述保留字錯誤保留，330到339為會話要求基本網路服務錯誤保留，370到379是為會話描述要求的QoS引數數量錯誤保留，390到399是無法歸類的雜項警告資訊。
27.3 頭域名
本規範在http://www.iana.org/assignments/sip-parameters建立了頭域的註冊項。
為了註冊一個新的頭域名，下列資訊需要在RFC出版物中提供，
o 頭域註冊的RFC號碼
o 註冊的頭域名
o 如果有縮寫，頭域的縮寫版本。
部分常用的頭域可以縮寫成1個字母的簡寫形式（7.3.3節）。簡寫形式只能在SIP工作組複查的時候被登記在RFC出版物上。
27.4 方法和應答碼
本規範在http://www.iana.org/assignments/sip-parameters建立了Method和Response-code的註冊項。並且下邊列出了他們的初始值。初始的方法表如下：
INVITE [RFC3261]
ACK [RFC3261]
BYE [RFC3261]
CANCEL [RFC3261]
REGISTER [RFC3261]
OPTIONS [RFC3261]
INFO [RFC2976]
應答碼的初始值在21節列出，分為資訊部分(Informational)，成功(Success)，轉發(Redirection)，客戶端錯誤(Client-Error)，服務端錯誤(Server-Error)，全域性錯誤(Global-Failure)幾個部分。這個表格有如下格式：
型別（Type，就是Informational）, Number, Default Reason Phrase [RFC3261]
如下資訊需要提供給RFC出版機構來註冊新的應答碼或者方法：
o 應答碼和方法需要註冊的RFC號碼
o 應答碼號碼或者方法名
o 預設應答碼的原因說明
27.5 “message/sip” MIME型別
本文件註冊了”message/sip”MIME媒體型別，目的是允許SIP可以通過SIP包體隧道，首要用於端到端的安全保障。這個媒體型別由如下部分組成：
媒體型別名字： message
媒體子型別： sip
要求的引數： none
可選的引數： version/Encoding scheme/Security considerations
version: 這個打包的訊息的SIP-version號碼（比如”2.0”）。如果沒有提供，version的預設值就是”2.0”。
Encoding scheme: SIP訊息包含一個8位的頭，在二進位制的MIME資料物件後邊可選。同樣的，SIP訊息必須把這個當作一個二進位制值。在通常情況下，SIP訊息通過二進位制相容的通訊協議傳送，不需要特別的編碼方式。
Security considerations: 本引數用於同23.4給出的S/MIME安全機制一致，請參見下邊的例子和說明。
27.6 新Content-Disposition 引數註冊
本文件也註冊了4個新的Content-Disposition頭”disposition-types”: altert,icon,session和render。作者要求這些值在IANA中為Content-Disposition登記。
對於”disposition-types”的描述，包括例子和說明，在20.11中說明。
在IANA註冊中的簡單描述是：
alter 包體是一個客戶定義的鈴聲用於提醒使用者。
icon 包體是一個顯示給使用者的icon
render 包體應當顯示給使用者
session 包體描述了一個通訊會話，例如RFC2327 SDP包體
28 同RFC 2543的改變
這個RFC修訂了RFC 2543。它主要和RFC2543向後相容。這裡描述的變更主要修訂了RFC2543中發現的錯誤，並且提供了在RFC2543中沒有提及的相關情節資訊。在本文中，協議以更清晰的層次結構描述。
我們把和RFC2543的永久改變，分成按功能行為劃分這些區別。比如在互操作上不相容，或者修正了某些情況下的錯誤操作，以及和RFC2543功能行為不同但是不是一個潛在的相容性問題。以及有數不清楚的澄清，在本文中沒有提及。
28.1 主要的功能改變
o 在UAC還沒有給出應答之前，UAC希望終止一個會話，它傳送CANCEL來終止。如果原始INVITE依舊給出2xx應答，那麼UAC接著傳送BYE。BYE只能發給現存的呼叫對話（leg）中（在這個RFC中成為對話(dialog)），但是在RFC2543中可以在任何時間傳送BYE。
o SIP的BNF改成RFC2234相容的了。
o SIP URL的BNF更改的更加通用，在user部分，允許一個很大的字符集。此外，比較規則也簡化為首先大小寫不敏感，接著詳細比較各個引數。最主要的變化是帶引數的URI和不帶這個引數（但是預設值相等）的URI 判定是不相等的。
o 刪除了隱藏的Via。這要求發出絕對的信任，由於它依賴於下一個節點來執行這個不明確的操作。作為替代，Via隱藏可以通過在proxy伺服器上的本地實現選擇完成，於是在這裡不在說明。
o 在RFC2543,CANCEL和INVITE請求是混和的。他們現在分開了。當用戶發出一個INVITE請求接著CANCEL掉，INVITE事務將正常終結。UAS應當對原始INVITE請求給出一個487應答。
o類似的，CANCEL和BYE事務也是混和的；RFC2543允許UAS在收到BYE的時候，不給INVTE請求傳送應答。本文件不允許這種情況出現。原始的INVITE請求需要一個應答。
o 在RFC2543中,UA需要支援只有UDP的情況。在這個RFC中，UA應當支援UDP和TCP。
o 在RFC2543中，forking 分支proxy在收到多個拒絕應答的時候，只向下行元素髮出一個拒絕身份認證應答，在這個RFC中，proxy應當蒐集所有的拒絕並且把他們放在應答中傳送。
o 在Digest信任書中，URI需要被引號引起來；這個在RFC2617和RFC2069是不一致的。
o SDP處理被分為獨立的規範[13]，並且更全面的描述了正式的通過SIP包體隧道進行的offer/answer交換過程。作為SIP實現基線，SIP允許在INVITE/200或者200/ACK中存在；RFC2543間接指出了在INVITE,200和ACK中的單個事務使用這個方法，但是這個在RFC2543中沒有很好的定義。在SIP擴充套件中允許使用更復雜的SDP。
o 增加了對URI中和在Via頭域中的IPV6的全面支援。Via頭域允許方括號和冒號的引數，要求對Via頭域的IPV6的支援。這些字元在先前是不允許的。在理論上，這顆一導致和舊規範實現上的相互操作的問題。不過，我們觀察到大部分實現在這個引數上，接受非控制ASCII字元。
o DNS SRV處理步驟現在使用了單獨的規範[4]。這個步驟使用了SRV和NAPTR資源記錄，並且不在合併從SRV記錄的資料（RFC2543）。
o 迴圈檢測變成可選的了，替代為強制使用Max-Forwards引數。這個迴圈檢測在RFC2543由嚴重bug，可能會在正常情況下把”螺旋”報告成為一個錯誤。在這裡，可選的迴圈檢測步驟是更加全面的和正確的。
o 由於他們現在在對話中是作為識別對話的基本要素存在，所以，對tag的使用是強制的（他們在RFC2543中是可選的）。
o 增加了Supported頭域，允許客戶端向伺服器表示它支援什麼樣的擴充套件，伺服器可以根據這個欄位決定給出包含什麼樣擴充套件的應答，並且把他們需要的擴充套件支援放在Require欄位裡邊。
o 幾個頭域的擴充套件引數的BNF描述在RFC2543中忽略了，這裡增加了。
o 處理Route和Record-Route的構在在RFC2543中是很不規範的，並且也不正確。它在本規範中更改成為規範正確的（並且大大簡化了）。這是很大的改變。對於沒有使用”預先載入路由的”部屬情況下（在預先載入路由的時候，初始的請求有一個Route路由集合，這個集合不是由Record-Route構造的），依舊提供了向後相容性。在預先載入路由的情況下，新舊機制是不能互相操作的。
o 在RFC2543中，訊息中的行是可以由CR/LF/或者CRLF終端的。本規範只允許CRLF。
o 在CANCLE和ACK請求中的Route的使用，在RFC2543中沒有精確定義，在本文件中定義了；如果請求有一個Route頭域，他的為一個給請求的非2xx應答的CANCEL或者ACK應當包含相同的Route頭域。為2xx應答的ACK請求使用2xx應答的Record-Route構造Route頭域值。
o RFC 2543允許一個UDP包中多個請求。這個使用方法在本文件中刪去了。
o 對於Expires頭域和引數中的絕對時間的使用方式被刪去了。當各個節點之間時間不同步的時候，他會帶來戶操作的問題。本文件使用相對時間。
o Via頭域中的branch引數現在是強制每一個元素都使用。它現在作為事務的唯一標誌。這避免了RFC2543容易出錯的事務鑑別規則的複雜性。我們在這個引數值使用一個亂數cookie來檢查上一個節點產生的這個引數是否全域性唯一的，如果不是，那麼舊採用舊的比較規則。因此，保證了互操作性。
o 在RFC2543，對TCP連線的關閉和CANCEL是相同的。當TCP連線在兩個proxy之間的時候，這在實現上是幾乎不可能的（也是錯誤的）。這個要求在這裡被刪去了，所以，TCP連線狀態和SIP處理之間沒有直接關係。
o RFC2543中，當UA到一個節點可以初始化一個新的事務，當對方正在進行事務處理的時候。在這裡被精確定義了。只允許初始化非INVITE請求，不允許INVITE請求。
o PGP被刪去了。它沒有很充分的定義，並且和更復雜的PGP MIME不相容。替換成為S/MIME。
o 增加了”sips” URI方案用於端到端的TLS通訊。這個方案是和RFC2543不能年個相容的。現有的節點如果接收到請求的Request-URI中包含SIPS URI方案，將拒絕這個請求。這實際上是一個特性；它保證了對SIPS URI只會在所有節點都是安全的情況下被傳送。
o 在TLS上附加了安全特性，並且這裡也更廣泛更完整的描述了安全考慮。
o 在RFC 2543中，並不要求proxy轉發101到199的臨時應答到上行佇列。這裡被更改成為必須轉發。這是非常重要的，因為很多後續的特性都依賴於傳送所有的101到199的臨時應答。
o RFC 2543提及了很少的503應答。它用於標誌proxy失敗或者過載的情況。這要求某些特別的處理。尤其是，接收到503的接受方應當觸發一個對於下一個節點在DNS SRV的重新查詢。同樣的，503應答只由proxy伺服器在特定情況下轉發到上行佇列。
o RFC2543定義了，但是沒有充分指出，對於UA認證一個伺服器的機制。這個已經刪去了。作為替代，允許使用RFC2617的雙向認證步驟。
o 對於UA來說，除非它收到了初始請求的ACK，不能傳送BYE到一個呼叫。這個在RFC2543是允許的，但是可能導致潛在的空轉可能。
o UA或者proxy不能傳送CANCEL到一個事務，直到它得到了一個臨時應答。這個在RFC2543中是允許的，但是可能導致空轉的可能。
o 在註冊中的action引數被禁止使用了。它不足以提供任何有用的服務，並且會導致在proxy上的應用程式處理上的衝突。
o RFC2543對於multicast有一堆特別的情況。例如某個應答被禁止了，定時器調整了，等等。multicast現在受到更多限制，並且同unicast相反，協議操作不影響對multicast的使用。
o 基本的認證整個被刪除了，不允許用基本的認證。
o proxy不再立刻收到就轉發6xx應答。他們立刻CANCEL相關等待的分支。這也避免了潛在的空轉，使得UAC再2xx之後收到一個6xx。在除了這個空轉的情況，結果都必須是相同的－6xx轉發到上行佇列。
o RFC2543並不對請求的合併認為是一個錯誤。這就導致在proxy上分支的請求稍後會在一個節點合併。只有在UA上能進行合併操作，並且處理步驟定義的是除了第一個請求都統統拒絕。
28.2 小功能性的變更
o 為給使用者展示可選的內容，增加了Alert-Info,Error-Info,Call-Info頭域。
o 增加了Content-Language,Content-Disposition和MIME-Verison頭域。
o 增加了一個”glare hanling”機制來處理雙方同時都向對方提出一個re-INVITE。它使用信的491（Request Pending）錯誤碼。
o 增加了 In-Reply_To和Reply-To頭域來支援稍後對未接呼叫/訊息的返回。
o 在SIP通訊協議中增加了TLS和SCTP。
o 描寫了很多機制來處理呼叫中的發生的錯誤；現在做了統一的處理。BYE用來發送會話終結。
o RFC2543要求INVITE應答通過TCP重新傳送，但是注意到實際上只對2xx應答是需要的。這就導致了人為的協議不足。通過定義了一個一致的事務層，這就不在需要了。只有給INVITE的2xx應答需要基於TCP重傳。
o 客戶端和服務端事務機器現在基於超時機制，而不是基於重傳次數。這允許狀態機能夠更好的適應TCP和UDP。
o Date頭域在REGISTER應答中使用，提供一個簡單的自動配置UA的日期的機制。
o 允許註冊伺服器拒絕過小的超時時間的註冊。並且為此定義了423應答碼和Min-Expires頭域。
29 標準索引
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers",RFC 3263, June 2002.
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002.
[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[15] Postel, J., "DoD Standard Transmission Control Protocol", RFC 761, January 1980.
[16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,"Stream Control Transmission Protocol", RFC 2960, October 2000.
[17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication:Basic and Digest Access Authentication", RFC 2617, June 1999.
[18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[20] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[21] Alvestrand, H., "IETF Policy on Character Sets and Languages",BCP 18, RFC 2277, January 1998.
[22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[26] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.30
30 資訊索引：
[27] R. Pandya, "Emerging mobile and personal communication systems," IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995.
[28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.
[31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[33] E. M. Schooler, "A multicast user directory service for synchronous rendezvous," Master’s Thesis CS-TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, Aug. 1996.
[34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[37] Good, G., "The LDAP Data Interchange Format (LDIF) – Technical Specification", RFC 2849, June 2000.
[38] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
[40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call Flow Examples", Work in Progress.
[41] E. M. Schooler, "Case study: multimedia conference control in a packet-switched teleconferencing system," Journal of Internetworking: Research and Experience, Vol. 4, pp. 99--120, June 1993. ISI reprint series ISI/RS-93-359.
[42] H. Schulzrinne, "Personal mobility for multimedia services inthe Internet," in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. 1996.
[43] Floyd, S., "Congestion Control Principles", RFC 2914, September 2000.
定時器值的表格：
表4：本規範使用的定時器意義機器預設值：
定時器 值 章節 意義
T1 500 ms 預設 17.1.1.1 預估的RTT時間
T2 4s 17.1.2.2 給非INVITE請求和INVITE應答的最大重傳時間間隔
T4 5s 17.1.2.2 最大網路傳送訊息時間
定時器A 初始值T1 17.1.1.2 INVITE請求重傳間隔,UDP only
定時器B 64×T1 17.1.1.2 INVITE請求超時時間
定時器C >3分鐘 16.6/11 proxyINVITE請求超時時間
定時器D >32秒 UDP0 TCP/SCTP 17.1.1.2 應答重發的等待時間
定時器E 初始值T1 17.1.2.2 非INVITE請求重傳間隔，UDP only
定時器F 64×T1 17.1.2.2 非INVITE請求事務超時時間
定時器G 初始值T1 17.2.1 INVITE應答重傳間隔
定時器H 64×T1 17.2.1 等待ACK的時間
定時器I T4 UDP0 TCP/SCTP 17.2.1 ACK重傳的等待時間
定時器J 64×T1 UDP0 TCP/SCTP 17.2.2 非INVITE請求重傳的等待時間
定時器K T4 UDP0 TCP/SCP 17.1.2.2 應答重傳的等待時間
感謝書
我們感謝IETF MMUSIC和SIP WGs的意見和建議。Ofir Arkin,Brian Bidulock,Jim Buller,Neil Deason,Dave Devanathan,Keith Drage,Bill Fenner, Cedric Fluckiger, Yaron Goland, John Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders Kristensen, Joanthan Lennox, Gethin Liddell, Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe J. Sambol, Chip Sharp, igor Slepchin, Eric Tremblay, Rick Workman 提供了詳細的註釋
Brian Rosen 提供了完整的BNF
Jean Mahoney 提供了技術寫作協助
這個工作是基於 inter alia [41,42]
作者地址
這裡作者的地址是按照字母順序的，首先是作者，接著是RFC2543原著。所有列出的作者都對本文有著巨大貢獻：
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Ave
East Hanover, NJ 07936
USA
EMail: [email protected]
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: [email protected]
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
EMail: [email protected]
Alan Johnston
WorldCom
100 South 4th Street
St. Louis, MO 63102
USA
EMail: [email protected]
Jon Peterson
NeuStar, Inc
1800 Sutter Street, Suite 570
Concord, CA 94520
USA
EMail: [email protected]
Robert Sparks
dynamicsoft, Inc.
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
USA
EMail: [email protected]
Mark Handley
International Computer Science Institute
1947 Center St, Suite 600
Berkeley, CA 94704
USA
EMail: [email protected]
Eve Schooler
AT&T Labs-Research
75 Willow Road
Menlo Park, CA 94025
USA
EMail: [email protected]
版權宣告
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
譯者：崮山路上走9遍 2004-9-23於深圳完稿。
BLOG: sharp838.mblogger.cn
EMAIL: [email protected]；[email protected]
所有的版權歸於原作者。
26.2 安全機制
從上邊講述的威脅來看，我們得到了SIP協議所需要的基本安全服務，他們是：保護訊息的隱私性和完整性，保護重現（replay）攻擊或者訊息欺騙，提供會話參與者的身份認證和隱私保護，保護拒絕服務攻擊。SIP訊息中的包體分別要求機密性，完整性和身份認證。
比為SIP重新定義新的安全機制更好的是，SIP可以重用已經存在的HTTP或者SMTP的安全機制。
全加密的訊息提供了最好的機密保護－它也可以保證訊息不被噁心的中間節點更改。不過SIP請求和應答不能簡單的進行端到端的加密，因為在大多數網路架構下，訊息的頭域比如Request-URI,Route,Via在中間經過的proxy中需要可見，這樣SIP請求才能被正確路由。注意，proxy伺服器需要修改一些訊息的特定屬性（比如增加Via頭域），這樣才能保證SIP正常工作。那麼proxy伺服器就必須被UA信任，至少在某種程度上信任。為了這個目標，我們建議為SIP提供低層次的安全機制，他們是基於節點到節點的整個SIP請求和應答的線上加密，並且語序終端節點校驗他們發出請求的proxy伺服器的身份。
SIP實體也可以為安全保證，需要驗證對方的身份。當SIP終端向對方UA或者proxy伺服器，宣告它的使用者的身份時，這個身份應當是可以通過某種方法驗證的。SIP中的數字簽名機制就是為了這個需要的。
SIP訊息體的一個獨立的安全（加密）機制提供了另一個端到端的相互認證方式，也降低了UA必須信任中間節點的程度。
26.2.1 通訊和網路層的安全
通訊或者網路層的安全機制是加密訊號通訊，保證訊息機密的和完整的傳送。
很多情況下，低層次的安全是通過證書實現的，這些證書可以在很多架構下用於提供身份認證使用。
兩個通常使用的方法，提供了通訊層和網路層的安全，他們是TLS[25]和IPSec[26]。
IPSec是一組網路層的協議工具，他們可以一起使用來作為傳統IP通訊的安全替代。IPSec最常用於一組主機或者管理的域有一個現存的互相信任關係的架構下。Ipsec通常由主機的作業系統級別實現，或者在一個提供機密通訊和完整性保證的通訊安全閘道器上實現（比如VPN接面構），IPSec也可以用於點到點的結構。
在很多結構下，IPSec並不要求和SIP應用一起使用；IPSec可能是最適合於部屬在那種難於直接在SIP伺服器上增加安全性的情況。具有預先共享金鑰關係的UA和他們的第一個節點的proxy伺服器很適合使用IPSec。為SIP部屬的IPSec要求一個IPSec 描述了協議工具的profile。這個profile在本文件中沒有提供。
TLS提供了通訊層的安全性，基於連線相關的協議（TCP）。可以通過在Via頭域或者在一個SIP URI中列明”tls” (表示基於TCP的TLS)指定通訊協議為TLS。TLS最適合沒有事先定義的信任關係的點到點的結構。例如Alice 信任她的本地proxy伺服器，這個伺服器在進行證書交換後信任Bob的本地proxy伺服器，這個Bob的本地proxy伺服器是Bob信任的，因此Bob可以和Alice安全的通訊。
TLS必須和SIP應用緊緊聯絡在一起。注意在SIP中的通訊機制是點到點的，因此一個基於TLS傳送請求到proxy伺服器的UA並不能保證這個TLS會在端到端的應用。
當實現者在SIP應用中使用TLS的時候，實現者必須支援最小集合的TLS_RSA_WITH_AES_128_CBC_SHA密碼套件[6]。並且為了向後相容，proxy伺服器，重定向伺服器和註冊伺服器應當支援TLS_RSA_WITH3DES_EDE_CBC_SHA。實現者也可以支援其他密碼套件。
26.2.2 SIPS URI方案
SIPS URI方案是SIP URI（19節）語法的一個附加，雖然這個方案串是”sips”不同於”sip”。SIPS的語義和SIP URI的語義十分不同。SIPS 允許指定希望通過安全訪問的資源。SIPS URI可以當作一個特定使用者的address-of-record使用－這個使用者是已知的（根據他們的名片，在他盟請求的From頭域，在REGISTER請求的To頭域）。當在請求中使用Request-URI，SIPS 方案指出請求經過的每一個節點，知道請求到達目的這個Request-URI指明的SIP元素，必須通過TLS進行加密；當請求抵達目標的域，他會根據目標域的本地安全策略和轉發策略，很有可能最後一部也是用TLS到達UAS。當用在請求的發起方（就像這種情況，當他們使用SIPS URI當作目標的address-of-record一樣），SIPS只是這個實體請求，到目的主機的所有路徑都應當加密。
SIPS方案適用於很多在SIP中應用的SIP URI，比如附加域Request-Uri,包含在address-of-record,聯絡地址（Contact的內容，包含REGISTER方法的頭域等等），還有Route頭域等等。在每個用法中，SIPS URI方案允許這些存在的URI來指明需要安全訪問的資源。這些由SIPS URI所替換的東西，有他們自己的安全屬性（[4]中詳細介紹）。
對SIPS的使用在細節上要求必須具備TLS互相的認證，並且要求支援密碼套件TLS_RSA_WITH_AES_128_CBC_SHA。在認證過程中接收到的信任書應當從客戶端持有的信任書跟節點開始驗證；對信任書驗證失敗應當導致請求的失敗。
注意在SIPS URI方案中，通訊層是和TLS沒有依賴關係的，並且因此”sips:
將address-of-record用SIPS URI發出的使用者，如果在非可靠通訊協議上收到的請求，可以操作裝置來拒絕這個請求。
26.2.3 HTTP Authentication
SIP提供了認證機制，基於HTTP認證的身份認證機制，他們依賴於401倒407應答碼和相關頭域來提供拒絕不信任的信任書。對於SIP使用的HTTP Digest認證機制，並沒有做重大的修改，它提供了replay攻擊的保護和單向認證關係。
對SIP的Digest 認證使用在22節有描述。
26.2.4 S/MIME
就像上邊講述的，在端到端的過程中加密整個SIP訊息體，可以提供機密性的保護，但是並非所有的欄位都能使用這個機制進行保護，因為中間的網路節點（比如proxy伺服器），需要根據讀取適當的頭域然後決定這個訊息應當轉發倒哪裡，並且如果這些中間節點由於安全原因被排出在外，那麼SIP訊息從本質上就是不能路由的。
不過，S/MIME允許SIP 的UA在SIP中加密MIME包體，在不影響訊息頭的情況下，在端到端的通訊中加密這些MIME包體。S/MIME可以提供訊息體的端到端的完整性和機密性，同樣也提供了雙向的認證機制。使用S/MIME也可以通過SIP訊息隧道，為SIP頭域提供一個完整性和機密性的方案。
對SIP的S/MIME使用在23節講述。
26.3 安全機制的實現
26.3.1 對SIP實現者的要求
proxy伺服器，重定向伺服器，和註冊伺服器必須實現TLS，並且必須支援雙向的和單向的認證關係。強烈建議UA可以初始化TLS；UA同樣可以作為一個TLS伺服器。proxy伺服器，重定向伺服器和註冊伺服器應當有一個站點信任書，這個信任書的主題和他們的規範主機名相關。對於TLS的雙向認證，UA可以有他們自己的信任書，但是本文件中，沒有規定他們的具體用法。所有的支援TLS的SIP元素必須具備在TLS協商中，驗證信任書的機制；這個使得證書機關（可能是有名的類似web瀏覽器證書發行機構的發行機構）釋出的一個或者多個根信任書成為必須。所有支援TLS的SIP元素必須同樣支援SIPS URI方案。
Proxy伺服器，重定向伺服器，註冊伺服器，和UA可以實現IPSec或者其他底層的安全協議。
當UA試圖聯絡一個proxy伺服器，重定向伺服器或者主阿伺服器，UAC應當初始化一個TLS連線，在這個連線上發起SIP訊息。在某些結構嚇，UAS可以同樣在這些TLS接收請求
Proxy伺服器，重定向伺服器，註冊伺服器，和UA必須實現Digest身份認證，包括所有的22節要求的要點。Proxy伺服器，重定向伺服器，註冊伺服器應當配置成為至少有一個Digest realm,並且對於給定伺服器來說，必須支援至少有一個”realm”字串和這個伺服器的主機名或者hostname相關聯。
UA可以支援MIME包體的加密，並且通過23節描述的那樣使用S/MIME傳送信任書。如果UA具有一個或者多個根身份認證的信任書，用來鑑定TLS或者IPSec的信任書，它應當適當的可以用這些來鑑定S/MIME的信任書。UA可以為S/MIME身份認證而具有特定的根信任書。
注意，隨著S/MIME實現，將來會有安全擴充套件，來提高S/MIME的強度。
26.3.2 安全解決方案
這些安全機制的操作，可以在某種程度上和現存的WEB和EMAIL安全模式一致。在高一點的級別來看，UA通過Digest 使用者名稱和口令把他們自己的身份向伺服器（proxy伺服器，重定向伺服器，註冊伺服器）認證；伺服器把他們自己向UA單節點認證，或者向另外一個伺服器進行單節點（one hop）認證（反之亦然），並且是通過TLS來傳送伺服器節點信任書。
在點對點的級別，UA一般信任網路來進行對方身份的鑑別；不過,如果網路不能夠鑑定對方身份，或者網路本身不被信任的情況下，也可以使用S/MIME來提供直接的身份認證。
接下來是一個例子，在這個例子中，不同的UA和伺服器使用這些安全機制防止26.1節描述的攻擊威脅。實現者和網路管理員可以遵循本節末尾給出的指示來防止攻擊威脅，這些指示是作為實現例子提供的。
26.3.2.1 註冊
當UA上線，並且註冊到它自己的域上，它應當和它的註冊伺服器建立一個TLS連線（10節描述了UA怎樣找到它的註冊伺服器）。註冊伺服器應當提供一個信任書給UA，並且這個信任書的節點必須是這個UA想要註冊的域相關的信任書節點；例如，如果UA向註冊
當UA收到註冊伺服器提供的一個有效的信任書，UA知道註冊伺服器並非一個攻擊者（可能重定向、竊取口令、或者試圖做類似攻擊的攻擊者）。
於是UA建立了一個REGISTER請求，並且Request-URI應當指向從註冊伺服器所接收到的信任書站點。當UA通過剛才建立的TLS連線傳送REGISTER請求，註冊伺服器應當給出一個401（Proxy Authentication Required）應答。在這個應答中，Proxy-Authenticate頭域的”realm”引數，應當和前邊給出的信任書節點的域相同。當UAC收到這個拒絕，它應當提示給使用者要求信任書，或者根據應答中的”realm”引數，從現有的金鑰組中查詢對應的信任書。這個信任書的使用者名稱應當和REGISTER請求的To頭域的URI的”userinfo”部分相關。當在一個合適的Proxy-Authorization頭域中插入和這個信任書，REGISTER應當重新發送到註冊伺服器。
由於註冊伺服器要求UA認證它自己，對於攻擊者來說，偽造一個使用者的address-of-record的REGISTER請求是很困難的。同樣注意到由於REGISTER是通過機密的TLS連線傳送的，攻擊者不能通過擷取REGISTER來記錄信任書來進行重放攻擊。
當註冊請求被註冊伺服器接收，UA應當繼續保持TLS連線，這樣使得註冊伺服器可以既當作proxy伺服器，這個proxy伺服器可以作為管理這個域的proxy伺服器。剛完成註冊的TLS連線會繼續保留用於接收UA後續發起的請求。
由於UA已經通過在TLS連線的對方的伺服器的認證，所有在這個連線上的請求都是經過proxy 伺服器的（由於保留了TLS連線，也就是說，剛才的註冊伺服器更換了角色，變成一個proxy伺服器）－－攻擊者不能偽造好像是剛才從這個proxy伺服器傳送的請求。
26.3.2.2 在域之間的請求
現在我們說，Alice的UA希望和遠端管理的域的一個使用者，這個使用者叫做”
對於一個管理域的Proxy伺服器處理那發請求，可以同樣作為本地的外發proxy；基於簡單的原則，我們假定這就是atlanta.com（否則這時候UA將要初始化一個新的TLS連線到一個獨立的伺服器）。假定這時候，這個客戶端已經完成了註冊（參見前邊的步驟），當它發出INVITE請求邀請另外一個使用者的時候，它將重用這個TLS連線到本地proxy伺服器（剛才的註冊伺服器）。這個UA在INVITE請求中，將會重用剛才cache的信任書，這樣可以避免不必要的要求使用者輸入信任書。
當本地的發外伺服器驗證了這個UA在INVITE請求中的信任書，它應當檢查Request-URI來決定這個訊息應當如何路由（參見[4]）。如果這個Request-URI的”domainname”部分和一個本地域相關聯（atlanta.com）而不是和biloxi.com相關，那麼proxy伺服器會向本地服務查詢來決定怎樣最好的訪問到被呼叫的使用者。
“[email protected]”正在嘗試聯絡呼叫”[email protected]”,本地proxy將會轉發這個請求到Alex和它的註冊伺服器所建立的TLS連線上。由於Alex將會通過它的已經通過認證的連線上收到這個請求，它就確定這個Alice的請求是通過了本地管理域的proxy的身份驗證的。
不過，在這個例子中，Request-URI指向的是一個遠端域。在atlanta.com的本地外發伺服器應當因此而建立一個和在biloxi.com的遠端proxy伺服器的TLS連線。由於這個TLS連線的兩端都是伺服器，並且都有伺服器的信任書，那麼應當使用雙向的TLS身份認證。連線的雙方應當驗證和檢查對方的信任書，把在信任書中的域名同SIP訊息中的頭域做比較。例如，atlanta.com 這個proxy伺服器，在這步，應當檢查從對方接收到的關於biloxi.com域的信任書。當檢查完畢，並且TLS協商完成，就建立了基於兩個proxy的安全通道，atlanta.com proxy於是可以把INVITE請求轉發給biloxi.com了。
在biloxi.com的proxy伺服器應當檢查atlanta.com的信任書，並且比較信任書提供的域名和INVITE請求的From頭域的”domainname”部分。這個biloxi proxy可以執行嚴格的安全機制，拒絕那些他們被轉發的域和本proxy所管理的域不匹配的請求（這個不太明白）。
這些安全機制可以用來防止SIP和SMTP ‘open relays’一樣經常被用於產生垃圾郵件一樣的資訊。
這個政策，只是保證了請求宣告的來源確實是它自己；他並不允許biloxi.com確知如何atlanta.com認證的Alice。只有當biloxi.com由其他方法知道atlanta.com的身份認證機制，他才可能確知Alice如何證明她的身份的。biloxi.com可以接著使用更嚴格的方法，禁止來自未確定和biloxi.com相同的認證策略的域的請求（就是說所有biloxi.com接受的請求，都必須來自biloxi.com所知道身份認證方式的域）。
當INVITE請求被biloxi.com核准，proxy伺服器應當鑑別現存的TLS通道，如果存在現存的TLS通道，並且是和這個請求中的被叫使用者（在這個例子中是[email protected]）相關聯的。那麼這個INVITE請求應當通過這個TLS通道傳送給Bob。由於通過這個TLS連線收到的請求，這個TLS連線是剛才已經在biloxi proxy上通過了身份認證，Bob於是知道From頭域沒有被篡改，並且atlanta.com已經認證了Alice，所以就沒有必要猶豫是否信任Alice的身份。
在他們轉發請求錢，兩個proxy伺服器應當在請求中增加Record-Route頭域，這樣所有在這個對話中的後續的請求講過通過這兩個proxy伺服器。proxy伺服器因此可以在對話生存週期中，繼續提供安全服務。如果proxy伺服器並不在Record-Route頭域增加他們自己，以後的訊息將會直接端到端的在Alice和Bob中傳送，而沒有任何安全措施（除非兩個端點使用了某種獨立的端到端的安全措施，比如S/MIME）。在這個考慮上，SIP梯形模式可以提供一個精美的結構來在proxy伺服器節點之間進行磋商，以提供一個Alice和Bob之間的有道理的安全通道。
例如，一個攻擊這個結構的攻擊者將會不能偽造BYE請求並且把他插入Bob和Alice的信令流，因為攻擊者無從探聽會話的引數，這也是由於通訊的完整性機制保證了Alice和Bob之間的通訊是機密的完整的。
26.3.2.3 點對點請求
另外，考慮這樣一個情況，UA聲稱[email protected]沒有一個本地外發proxy。當Carol希望傳送INVITE到[email protected],她的UA應當直接初始化一個TLS連線到biloxi proxy（使用附件[4]中描述的機制來檢查怎樣到達指定的Request-URI）。當她的UA收到一個biloxi proxy傳送的信任書，她應當在通過TLS連線傳送她的INVITE請求前，正常校驗這個信任書。不過，Carol並沒有義務相biloxi proxy提供她自己的身份，但是她在INVITE請求的”message/sip”包體中，有一個CMS-detached(分離的)簽名。如果Carol在biloxi.com realm有其他信任書的話，就不一定提供這個簽名，但是她在biloxi.com上沒有正式關係，所以她沒有信任書，也就必須提供這個簽名。biloxi proxy可以有嚴格的機制直接把這個請求踢掉，甚至不用麻煩被叫方來驗證這個請求，因為在From頭域的”domainname”部分，並沒有biloxi.com－它可以被當作這個使用者是未認證的。
biloxi proxy對於Bob使用者有一個政策，就是所有未認證的請求都應當轉發到一個適當的地址，對於[email protected],就是<sipo:[email protected]>。Carol在和biloxi proxy建立的TLS連線上，收到這個轉發請求的應答，於是它信任這個轉發地址的真實性。
Carol應當和目標地址建立一個TCP連線，並且傳送一個新的INVITE請求，在這個請求中，Request-URI包含剛才接收到的聯絡地址（需要重新計算包體中的簽名，因為請求重新構造了）。Bob從不安全的介面上接收到這個INVITE請求，但是這個UA是特意預留一個不安全的介面，在這個情況下，認可請求中的From頭域並且隨後把INVITE包體中的簽名和一個本地cache的信任書進行匹配。Bob用類似的方法應答,把他自己相Carol進行認證，這樣一個安全的對話就開始了。
某些情況下，在一個域的NAT或者防火牆會阻止UA之間直接建立TCP連線。在這個情況下，如果本地策略許可，proxy伺服器可以隱含的做UA之間的請求轉發，並且這個轉發是基於沒有信任關係的（比如不用現存的TLS連線，而是通過TCP明碼的請求轉發）
26.3.2.4 DoS 防護
基於這些安全解決方案，為了使得拒絕服務(DoS)攻擊造成的影響最小，實現者應當注意如下的指引：
當SIP proxy伺服器所在的主機是基於公共internte做路由的，他應當部署在一個具有防護操作策略的管理域中（比如block源路由，過濾ping包等等）。TLS和IPSec都可以在管理域的邊界的防護主機，一起參與安全系統的構家，來提高安全性。這些防護主機可以防護拒絕服務攻擊，確保在管理域中的SIP主機不會被大量的訊息阻塞。
不管使用什麼樣的安全措施，對proxy伺服器的洪水訊息攻擊可以耗盡proxy伺服器的資源，並且阻止傳送到目的地的正確的請求。對於proxy伺服器來說，每一個SIP事務都會好用一定的資源，對於有狀態的伺服器來說這個消耗會更大。因此，有狀態的proxy比無狀態的proxy更容易受到洪水攻擊的影響。
UA和proxy伺服器應當用一個401（Unauthorized）或者407（Proxy Authentication Required）拒絕有問題的請求，並且對這些有問題的請求不使用正常的應答重發機制，並且對這些未認證的請求把自己當作無狀態的伺服器使用。如果攻擊者使用假的頭域值(例如Via)指向一個第三方的被攻擊的伺服器，那麼對於401(Unauthorized)或者407（Proxy Authentication Required）應答的重發可能正中攻擊者的下懷。
總得來說，基於TLS簽名的proxy伺服器之間的雙向認證機制，降低了中間節點潛在的風險，並且減少了可以用作拒絕服務攻擊的偽造的請求或者應答。這也同樣提高了攻擊者利用無知的SIP節點進行放大攻擊的難度。
26.4 限制
雖然有這些安全機制，在正確應用的時候，可以阻止很多攻擊，但是對於網路管理者和開發者來說，也必須明白他們也會有很多限制的地方。
26.4.1 HTTP Digest
在SIP中對於HTTP Digest一個限制是Digest的完整性機制在SIP下運作的不是很完美。尤其是，他們提供了對訊息中的Request-URI和方法的保護，但是並沒有對UA希望提供加密的所有頭域進行了保護。
RFC2617所提供的回放攻擊保護對於SIP來說也有一些限制。例如，next-nonce機制，並不支援通過管道傳送的請求。防止回放攻擊應當使用nonce-count機制。
另一個HTTP Digest限制是realm的範圍。當用戶希望把他們自己的身份向一個資源（這個資源和他們有著預先存在的關係）進行認證的時候，Digest是有用的，它就像一個服務提供者，使用者是一個客戶端（這是十分常見的場景，因此Digest提供了一個十分有用的功能）。與之對應的，TLS的範圍是基於域之間的，或者multirealm的，因為信任書通常是全域性可驗證的，所以UA可以在不需要預先存在關係的伺服器上進行身份驗證。
26.4.2 S/MIME
對於S/MIME的一個最大的限制是對終端使用者來說，缺少廣泛的公共金鑰機構。如果使用的是自簽名（selfsigned）信任書（或者信任書不能被對話的對方所驗證），23.2節描述的基於SIP的金鑰交換機制就容易遭受中間人攻擊（man-in-the-middle），在這個中間人攻擊中，攻擊者可以悄悄檢查和修改S/MIME包體。攻擊者需要擷取對話中，雙方的第一個金鑰交換，在請求和應答中移去現有的CMS-detached簽名，並且插入另外的包含攻擊者提供的信任書（但是看起來像是正確地address-of-record的信任書）的CMS-detached 簽名。通訊的雙方都回以為他們和對方交換了金鑰，實際上他們互相有的只是攻擊者的公鑰。
必須明確注意到攻擊者只能攻擊雙方的第一次的金鑰交換－在後續的情況，金鑰的變更對於UA來說就是不可見的了。同樣使得攻擊者難以竊聽對話雙方的以後的對話中（比如一天內的對話，周內的，或者一年的對話）。
SSH在第一次金鑰交換的時候，也同樣容易受到這個中間人攻擊；但是，雖然眾所周知SSH不完美，但是它確實提高了連線的安全性。對於SIP來說，使用金鑰的指紋可以有些幫助，就像在SSH中一樣。例如，如果SIP的雙方建立了一個語音通訊會話，每一個都可以讀取對方傳送的金鑰指紋，並且可以根據這個指紋和原始指紋做比較。這使得中間人更加難以在語音中模擬通話雙方的金鑰指紋（實際上這個在Clipper 基於晶片的保密電話中使用）。
在S/MIME機制下，如果UA在他們的金鑰組中持有對方address-of-record的信任書，允許UA不用導言來發送加密的請求。不過，存在這個樣的情況，如果某個設備註冊了這個address-of-record，並且沒有持有持有裝置當前使用者先前使用的信任書。並且它將因此不能正常處理加密的請求，於是可能會導致某些原本可以避免的錯誤訊號。這很像加密的請求被分支的情況。
S/MIME相關的金鑰通常用於和特定使用者（一個address-of-record）關聯起來使用,而不是和一個裝置（UA）一起使用。當用戶在裝置之間移動，很難把私鑰安全的在UA之間傳遞；一個裝置如何獲得這些金鑰不在本文討論。
另外，使用S/MIME更常見的困難是，它可以導致很大的訊息，特別是當採用23.4節的SIP隧道戒指的時候。基於這個原因，當使用S/MIME隧道機制的時候，一定要使用TCP通訊協議。
26.4.3 TLS
TLS最大的問題是，它不能基於UDP；TLS要求面向連線的底層通訊協議，對於本文來說，就是TCP。
對於TLS來說，在本地外發proxy伺服器和/或者主車伺服器上和大量UA，維持很多併發TLS長連線，是一件費力的事情。這導致某些容量問題，特別是在使用加強金鑰套件的時候更容易出現容量問題。維持冗餘的TLS長連線，特別是當UA獨立負責他們的連線，會很耗資源。
TLS只允許SIP實體到他們臨近的認證伺服器的連線；TLS提供了嚴格的節點到節點的安全性（hop-by-hop）。無論TLS,還是其他本文件規定的安全機制，當不能直接建立TCP連線的情況下，都允許客戶通過驗證自己到proxy伺服器來到達目的地。
26.4.4 SIPS URI
實際上在請求經過的每一段都使用TLS，要求了最終的UAS必須能夠通過TLS到達（也許是通過SIPS URI作為一個聯絡地址註冊的）。通常這個目的地是用SIPS描述的。在很多結構下，使用TLS保護一部分請求路徑，最後一部確實依賴於其他的安全機制到UAS。因此SIPS不能保證TLS是真正的端到端的使用。注意，這是由於許多UA不接受進來的TLS連線，甚至那些支援TLS的UA也可能要求要維持一個永久的TLS連線（就像前邊的TLS限制節講述的一樣），目的是為了作為UAS從TLS上接收請求。
位置服務，對於SIPS Request-URI來說，是不要求提供SIPS繫結的。雖然位置服務通常由使用者註冊（10.2.1節描述）組成，但是對於一個address-of-record來說，可以由不同的協議和介面都可以提供聯絡地址，並且這些工具都可以用來對映SIPS URI到適當的SIP URI。當對繫結資訊查詢的時候，位置服務返回它的聯絡地址，而不關心這個是否是從一個SIPS的Request-URI上收到的請求。如果是轉發伺服器訪問位置服務，那就是說取決於處理轉發的Contact頭域的SIP實體來決定聯絡地址的屬性。
如果要求請求經過的全部路徑都使用TLS通訊，那麼對目的域來說稍稍有點麻煩。如果實現困難，也允許在請求傳送節點中的基於密碼認證的proxy伺服器，不相容或者選擇一個折中方案來略過SIPS的轉發機制（在16.6節定義的通常轉發規則）。但是，惡意的中間節點就有可能把一個基於SIPS URI的請求，重新降級成為SIP URI。
另外，中間節點也可以正常的把一個基於SIP的請求更改成基於SIPS URI的請求。請求的接受方發現請求的Request-URI是基於SIPS URI方案的並不能假設原始請求的Request-URI也是基於SIPS通過中間節點傳送的（從客戶端往後）。
為了解決這個問題，我們建議請求的收件人,在請求的Request-URI包含一個SIP或者SIPS URI的情況下，檢查To頭域值，看看是否包含一個SIPS URI（雖然注意到Request-URI可以和To頭域URI有相同的URI方案，但是他們不相等並不意味者是一個安全隱患）。雖然客戶端可以在一個請求中把Request-URI和To頭域做成不一樣的，但是當兩個欄位的SIPS不一樣的話，那就是可能的安全隱患，並且請求因此應當被接受方拒絕。接受方也可以檢查Via頭域鏈來雙重檢查是否TLS在整個請求路徑中被使用，一直到最近的本地管理域。源UAC也可以用S/MIME來幫助確保原始格式的To頭域被端到端的傳送。
如果UAS有原因來相信Request-URI的URI方案在通訊中被非法修改，UA應當提示使用者這個潛在的安全隱患。
作為更深遠的考量，為了防止底層的攻擊，如果SIP實體只接受SIPS請求，那麼可以拒絕在非安全埠的連線。
終端使用者應當完全清楚SIPS和SIP URI的區別，他們可以在應答中手工更改這個URI方案。這可以增加或者降低安全性。例如，如果一個攻擊者攻陷了一個DNS的cache，插入了一個假的記錄集，這個記錄集有效刪去了一個proxy伺服器的所有SIPS記錄，接著經過這個proxy伺服器的SIPS請求就會失效。這時候，一個使用者，看見這個SIPS address-of-record總是失敗，他可以手工改掉URI從SIPS改成SIP，並且重試。當然，這也有一些安全機制防止這類事情發生（如果目標UA真是有神經病拒絕所有非SIPS請求的話）。但是這個限制毫無價值。往好了想，使用者也可以把SIP URI變成SIPS URI。
26.5 Privacy(隱私)
SIP訊息經常包含傳送者的敏感資訊－不只是他們將說些什麼，也包括了他們和誰在通訊，以及他們通訊了多久，以及從那裡到哪裡的通訊等等。很多應用和他們的使用者都要求這類隱私資訊對於沒有必要知道的方面來說都必須保持隱祕。
注意，也有隱私資訊也有少數直接洩漏的方式。如果使用者或者服務，位於一個容易猜到的地址，比如通過使用者的名字或者機構的聯絡（這是構成Address-of-record的最經常的情形），傳統保證隱私性的方式是通過一個未列出的”電話號碼錶”來實現的。在呼叫方發起的會話邀請中，使用者位置服務可以提供精確的被叫方的位置從而破壞了隱私；在實現上因此應當更嚴格，基於每使用者的原則，根據不同的呼叫方給出不同的位置資訊和可用性的資訊。這是一個SIP需要解決的完整的問題。
在某些情況下，使用者可能希望在通過身份驗證時，在頭域中隱藏個人資訊。這可以應用於不僅是From和相關表現請求發起方資訊的頭域，也應用於To頭域－他可能不能由快速撥號的nick-name轉換成為最終的目的地資訊，或者一個為擴充套件的一組目標的標誌，當請求被路由的時候，每一個都可以從Request-URI上被移去，但是如果和To頭域初始值相等的時候，不能更改To頭域。因此，他可能由於隱私的原因建立和Request-URI不同的To頭域。
27 IANA 認證
SIP應用中的所有的方法名字，頭域名字，狀態碼，和option tags，都是通過RFC中關於IANA認證節的說明在IANA註冊的。
本規範指示IANA建立了4個新的子註冊專案在：http://www.iana.org/assignments/sip-parameters: Option Tags,Warning Codes(warn-codes),Methods和Response Codes,頭域的子項也在那裡。
27.1 Option Tags
這個規範在http://www.iana.org/assignments/sip-parameters建立了Option Tags註冊項.
Option tags用於類似Require,Supported,Proxy-Require,Unsupoprted這類的頭域，用來支援SIP的擴充套件相容性機制（19.2節）。Option tag自身時一個字串，和特定的SIP選項相關（也就是和特定的SIP擴充套件相關）。它為SIP終端確定這個選項。Option tags當被標準的RFC軌跡擴充套件，它就在IANA註冊了。RFC的IANA認證節必須包含如下內容，這些內容與RFC出版號碼一起在IANA登錄檔登記。
o option tag的名字。名字可以是任意長度的，但是應當不要超過20個字母。丙子必須是alphanum(25節)字元。
o 描述擴充套件的描述資訊
27.2 Warn-Codes
本規範在http://www.iana.org/assignments/sip-parameters建立了Warn-Codes註冊項。並且初始釋出的warn-codes值在20.43節列出。附加的warn-codes通過RFC出版物註冊發表。
對於warn-codes表的描述資訊如下：
當一個會話描述協議（SDP）（RFC 2327[1]）出現問題導致事務失敗的時候，Warning codes在SIP應答資訊中提供了對狀態碼的補充資訊。
“warn-code”包含了3位數字。第一個數字”3”表示warning是SIP的警告資訊。除非以後另有描述，只有3xx警告資訊可以被註冊。
300到329的警告資訊為會話描述保留字錯誤保留，330到339為會話要求基本網路服務錯誤保留，370到379是為會話描述要求的QoS引數數量錯誤保留，390到399是無法歸類的雜項警告資訊。
27.3 頭域名
本規範在http://www.iana.org/assignments/sip-parameters建立了頭域的註冊項。
為了註冊一個新的頭域名，下列資訊需要在RFC出版物中提供，
o 頭域註冊的RFC號碼
o 註冊的頭域名
o 如果有縮寫，頭域的縮寫版本。
部分常用的頭域可以縮寫成1個字母的簡寫形式（7.3.3節）。簡寫形式只能在SIP工作組複查的時候被登記在RFC出版物上。
27.4 方法和應答碼
本規範在http://www.iana.org/assignments/sip-parameters建立了Method和Response-code的註冊項。並且下邊列出了他們的初始值。初始的方法表如下：
INVITE [RFC3261]
ACK [RFC3261]
BYE [RFC3261]
CANCEL [RFC3261]
REGISTER [RFC3261]
OPTIONS [RFC3261]
INFO [RFC2976]
應答碼的初始值在21節列出，分為資訊部分(Informational)，成功(Success)，轉發(Redirection)，客戶端錯誤(Client-Error)，服務端錯誤(Server-Error)，全域性錯誤(Global-Failure)幾個部分。這個表格有如下格式：
型別（Type，就是Informational）, Number, Default Reason Phrase [RFC3261]
如下資訊需要提供給RFC出版機構來註冊新的應答碼或者方法：
o 應答碼和方法需要註冊的RFC號碼
o 應答碼號碼或者方法名
o 預設應答碼的原因說明
27.5 “message/sip” MIME型別
本文件註冊了”message/sip”MIME媒體型別，目的是允許SIP可以通過SIP包體隧道，首要用於端到端的安全保障。這個媒體型別由如下部分組成：
媒體型別名字： message
媒體子型別： sip
要求的引數： none
可選的引數： version/Encoding scheme/Security considerations
version: 這個打包的訊息的SIP-version號碼（比如”2.0”）。如果沒有提供，version的預設值就是”2.0”。
Encoding scheme: SIP訊息包含一個8位的頭，在二進位制的MIME資料物件後邊可選。同樣的，SIP訊息必須把這個當作一個二進位制值。在通常情況下，SIP訊息通過二進位制相容的通訊協議傳送，不需要特別的編碼方式。
Security considerations: 本引數用於同23.4給出的S/MIME安全機制一致，請參見下邊的例子和說明。
27.6 新Content-Disposition 引數註冊
本文件也註冊了4個新的Content-Disposition頭”disposition-types”: altert,icon,session和render。作者要求這些值在IANA中為Content-Disposition登記。
對於”disposition-types”的描述，包括例子和說明，在20.11中說明。
在IANA註冊中的簡單描述是：
alter 包體是一個客戶定義的鈴聲用於提醒使用者。
icon 包體是一個顯示給使用者的icon
render 包體應當顯示給使用者
session 包體描述了一個通訊會話，例如RFC2327 SDP包體
28 同RFC 2543的改變
這個RFC修訂了RFC 2543。它主要和RFC2543向後相容。這裡描述的變更主要修訂了RFC2543中發現的錯誤，並且提供了在RFC2543中沒有提及的相關情節資訊。在本文中，協議以更清晰的層次結構描述。
我們把和RFC2543的永久改變，分成按功能行為劃分這些區別。比如在互操作上不相容，或者修正了某些情況下的錯誤操作，以及和RFC2543功能行為不同但是不是一個潛在的相容性問題。以及有數不清楚的澄清，在本文中沒有提及。
28.1 主要的功能改變
o 在UAC還沒有給出應答之前，UAC希望終止一個會話，它傳送CANCEL來終止。如果原始INVITE依舊給出2xx應答，那麼UAC接著傳送BYE。BYE只能發給現存的呼叫對話（leg）中（在這個RFC中成為對話(dialog)），但是在RFC2543中可以在任何時間傳送BYE。
o SIP的BNF改成RFC2234相容的了。
o SIP URL的BNF更改的更加通用，在user部分，允許一個很大的字符集。此外，比較規則也簡化為首先大小寫不敏感，接著詳細比較各個引數。最主要的變化是帶引數的URI和不帶這個引數（但是預設值相等）的URI 判定是不相等的。
o 刪除了隱藏的Via。這要求發出絕對的信任，由於它依賴於下一個節點來執行這個不明確的操作。作為替代，Via隱藏可以通過在proxy伺服器上的本地實現選擇完成，於是在這裡不在說明。
o 在RFC2543,CANCEL和INVITE請求是混和的。他們現在分開了。當用戶發出一個INVITE請求接著CANCEL掉，INVITE事務將正常終結。UAS應當對原始INVITE請求給出一個487應答。
o類似的，CANCEL和BYE事務也是混和的；RFC2543允許UAS在收到BYE的時候，不給INVTE請求傳送應答。本文件不允許這種情況出現。原始的INVITE請求需要一個應答。
o 在RFC2543中,UA需要支援只有UDP的情況。在這個RFC中，UA應當支援UDP和TCP。
o 在RFC2543中，forking 分支proxy在收到多個拒絕應答的時候，只向下行元素髮出一個拒絕身份認證應答，在這個RFC中，proxy應當蒐集所有的拒絕並且把他們放在應答中傳送。
o 在Digest信任書中，URI需要被引號引起來；這個在RFC2617和RFC2069是不一致的。
o SDP處理被分為獨立的規範[13]，並且更全面的描述了正式的通過SIP包體隧道進行的offer/answer交換過程。作為SIP實現基線，SIP允許在INVITE/200或者200/ACK中存在；RFC2543間接指出了在INVITE,200和ACK中的單個事務使用這個方法，但是這個在RFC2543中沒有很好的定義。在SIP擴充套件中允許使用更復雜的SDP。
o 增加了對URI中和在Via頭域中的IPV6的全面支援。Via頭域允許方括號和冒號的引數，要求對Via頭域的IPV6的支援。這些字元在先前是不允許的。在理論上，這顆一導致和舊規範實現上的相互操作的問題。不過，我們觀察到大部分實現在這個引數上，接受非控制ASCII字元。
o DNS SRV處理步驟現在使用了單獨的規範[4]。這個步驟使用了SRV和NAPTR資源記錄，並且不在合併從SRV記錄的資料（RFC2543）。
o 迴圈檢測變成可選的了，替代為強制使用Max-Forwards引數。這個迴圈檢測在RFC2543由嚴重bug，可能會在正常情況下把”螺旋”報告成為一個錯誤。在這裡，可選的迴圈檢測步驟是更加全面的和正確的。
o 由於他們現在在對話中是作為識別對話的基本要素存在，所以，對tag的使用是強制的（他們在RFC2543中是可選的）。
o 增加了Supported頭域，允許客戶端向伺服器表示它支援什麼樣的擴充套件，伺服器可以根據這個欄位決定給出包含什麼樣擴充套件的應答，並且把他們需要的擴充套件支援放在Require欄位裡邊。
o 幾個頭域的擴充套件引數的BNF描述在RFC2543中忽略了，這裡增加了。
o 處理Route和Record-Route的構在在RFC2543中是很不規範的，並且也不正確。它在本規範中更改成為規範正確的（並且大大簡化了）。這是很大的改變。對於沒有使用”預先載入路由的”部屬情況下（在預先載入路由的時候，初始的請求有一個Route路由集合，這個集合不是由Record-Route構造的），依舊提供了向後相容性。在預先載入路由的情況下，新舊機制是不能互相操作的。
o 在RFC2543中，訊息中的行是可以由CR/LF/或者CRLF終端的。本規範只允許CRLF。
o 在CANCLE和ACK請求中的Route的使用，在RFC2543中沒有精確定義，在本文件中定義了；如果請求有一個Route頭域，他的為一個給請求的非2xx應答的CANCEL或者ACK應當包含相同的Route頭域。為2xx應答的ACK請求使用2xx應答的Record-Route構造Route頭域值。
o RFC 2543允許一個UDP包中多個請求。這個使用方法在本文件中刪去了。
o 對於Expires頭域和引數中的絕對時間的使用方式被刪去了。當各個節點之間時間不同步的時候，他會帶來戶操作的問題。本文件使用相對時間。
o Via頭域中的branch引數現在是強制每一個元素都使用。它現在作為事務的唯一標誌。這避免了RFC2543容易出錯的事務鑑別規則的複雜性。我們在這個引數值使用一個亂數cookie來檢查上一個節點產生的這個引數是否全域性唯一的，如果不是，那麼舊採用舊的比較規則。因此，保證了互操作性。
o 在RFC2543，對TCP連線的關閉和CANCEL是相同的。當TCP連線在兩個proxy之間的時候，這在實現上是幾乎不可能的（也是錯誤的）。這個要求在這裡被刪去了，所以，TCP連線狀態和SIP處理之間沒有直接關係。
o RFC2543中，當UA到一個節點可以初始化一個新的事務，當對方正在進行事務處理的時候。在這裡被精確定義了。只允許初始化非INVITE請求，不允許INVITE請求。
o PGP被刪去了。它沒有很充分的定義，並且和更復雜的PGP MIME不相容。替換成為S/MIME。
o 增加了”sips” URI方案用於端到端的TLS通訊。這個方案是和RFC2543不能年個相容的。現有的節點如果接收到請求的Request-URI中包含SIPS URI方案，將拒絕這個請求。這實際上是一個特性；它保證了對SIPS URI只會在所有節點都是安全的情況下被傳送。
o 在TLS上附加了安全特性，並且這裡也更廣泛更完整的描述了安全考慮。
o 在RFC 2543中，並不要求proxy轉發101到199的臨時應答到上行佇列。這裡被更改成為必須轉發。這是非常重要的，因為很多後續的特性都依賴於傳送所有的101到199的臨時應答。
o RFC 2543提及了很少的503應答。它用於標誌proxy失敗或者過載的情況。這要求某些特別的處理。尤其是，接收到503的接受方應當觸發一個對於下一個節點在DNS SRV的重新查詢。同樣的，503應答只由proxy伺服器在特定情況下轉發到上行佇列。
o RFC2543定義了，但是沒有充分指出，對於UA認證一個伺服器的機制。這個已經刪去了。作為替代，允許使用RFC2617的雙向認證步驟。
o 對於UA來說，除非它收到了初始請求的ACK，不能傳送BYE到一個呼叫。這個在RFC2543是允許的，但是可能導致潛在的空轉可能。
o UA或者proxy不能傳送CANCEL到一個事務，直到它得到了一個臨時應答。這個在RFC2543中是允許的，但是可能導致空轉的可能。
o 在註冊中的action引數被禁止使用了。它不足以提供任何有用的服務，並且會導致在proxy上的應用程式處理上的衝突。
o RFC2543對於multicast有一堆特別的情況。例如某個應答被禁止了，定時器調整了，等等。multicast現在受到更多限制，並且同unicast相反，協議操作不影響對multicast的使用。
o 基本的認證整個被刪除了，不允許用基本的認證。
o proxy不再立刻收到就轉發6xx應答。他們立刻CANCEL相關等待的分支。這也避免了潛在的空轉，使得UAC再2xx之後收到一個6xx。在除了這個空轉的情況，結果都必須是相同的－6xx轉發到上行佇列。
o RFC2543並不對請求的合併認為是一個錯誤。這就導致在proxy上分支的請求稍後會在一個節點合併。只有在UA上能進行合併操作，並且處理步驟定義的是除了第一個請求都統統拒絕。
28.2 小功能性的變更
o 為給使用者展示可選的內容，增加了Alert-Info,Error-Info,Call-Info頭域。
o 增加了Content-Language,Content-Disposition和MIME-Verison頭域。
o 增加了一個”glare hanling”機制來處理雙方同時都向對方提出一個re-INVITE。它使用信的491（Request Pending）錯誤碼。
o 增加了 In-Reply_To和Reply-To頭域來支援稍後對未接呼叫/訊息的返回。
o 在SIP通訊協議中增加了TLS和SCTP。
o 描寫了很多機制來處理呼叫中的發生的錯誤；現在做了統一的處理。BYE用來發送會話終結。
o RFC2543要求INVITE應答通過TCP重新傳送，但是注意到實際上只對2xx應答是需要的。這就導致了人為的協議不足。通過定義了一個一致的事務層，這就不在需要了。只有給INVITE的2xx應答需要基於TCP重傳。
o 客戶端和服務端事務機器現在基於超時機制，而不是基於重傳次數。這允許狀態機能夠更好的適應TCP和UDP。
o Date頭域在REGISTER應答中使用，提供一個簡單的自動配置UA的日期的機制。
o 允許註冊伺服器拒絕過小的超時時間的註冊。並且為此定義了423應答碼和Min-Expires頭域。
29 標準索引
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers",RFC 3263, June 2002.
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002.
[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[15] Postel, J., "DoD Standard Transmission Control Protocol", RFC 761, January 1980.
[16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,"Stream Control Transmission Protocol", RFC 2960, October 2000.
[17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication:Basic and Digest Access Authentication", RFC 2617, June 1999.
[18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[20] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[21] Alvestrand, H., "IETF Policy on Character Sets and Languages",BCP 18, RFC 2277, January 1998.
[22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[26] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.30
30 資訊索引：
[27] R. Pandya, "Emerging mobile and personal communication systems," IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995.
[28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.
[31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[33] E. M. Schooler, "A multicast user directory service for synchronous rendezvous," Master’s Thesis CS-TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, Aug. 1996.
[34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[37] Good, G., "The LDAP Data Interchange Format (LDIF) – Technical Specification", RFC 2849, June 2000.
[38] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
[40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call Flow Examples", Work in Progress.
[41] E. M. Schooler, "Case study: multimedia conference control in a packet-switched teleconferencing system," Journal of Internetworking: Research and Experience, Vol. 4, pp. 99--120, June 1993. ISI reprint series ISI/RS-93-359.
[42] H. Schulzrinne, "Personal mobility for multimedia services inthe Internet," in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. 1996.
[43] Floyd, S., "Congestion Control Principles", RFC 2914, September 2000.
定時器值的表格：
表4：本規範使用的定時器意義機器預設值：
定時器 值 章節 意義
T1 500 ms 預設 17.1.1.1 預估的RTT時間
T2 4s 17.1.2.2 給非INVITE請求和INVITE應答的最大重傳時間間隔
T4 5s 17.1.2.2 最大網路傳送訊息時間
定時器A 初始值T1 17.1.1.2 INVITE請求重傳間隔,UDP only
定時器B 64×T1 17.1.1.2 INVITE請求超時時間
定時器C >3分鐘 16.6/11 proxyINVITE請求超時時間
定時器D >32秒 UDP0 TCP/SCTP 17.1.1.2 應答重發的等待時間
定時器E 初始值T1 17.1.2.2 非INVITE請求重傳間隔，UDP only
定時器F 64×T1 17.1.2.2 非INVITE請求事務超時時間
定時器G 初始值T1 17.2.1 INVITE應答重傳間隔
定時器H 64×T1 17.2.1 等待ACK的時間
定時器I T4 UDP0 TCP/SCTP 17.2.1 ACK重傳的等待時間
定時器J 64×T1 UDP0 TCP/SCTP 17.2.2 非INVITE請求重傳的等待時間
定時器K T4 UDP0 TCP/SCP 17.1.2.2 應答重傳的等待時間
感謝書
我們感謝IETF MMUSIC和SIP WGs的意見和建議。Ofir Arkin,Brian Bidulock,Jim Buller,Neil Deason,Dave Devanathan,Keith Drage,Bill Fenner, Cedric Fluckiger, Yaron Goland, John Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders Kristensen, Joanthan Lennox, Gethin Liddell, Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe J. Sambol, Chip Sharp, igor Slepchin, Eric Tremblay, Rick Workman 提供了詳細的註釋
Brian Rosen 提供了完整的BNF
Jean Mahoney 提供了技術寫作協助
這個工作是基於 inter alia [41,42]
作者地址
這裡作者的地址是按照字母順序的，首先是作者，接著是RFC2543原著。所有列出的作者都對本文有著巨大貢獻：
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Ave
East Hanover, NJ 07936
USA
EMail: [email protected]
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: [email protected]
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
EMail: [email protected]
Alan Johnston
WorldCom
100 South 4th Street
St. Louis, MO 63102
USA
EMail: [email protected]
Jon Peterson
NeuStar, Inc
1800 Sutter Street, Suite 570
Concord, CA 94520
USA
EMail: [email protected]
Robert Sparks
dynamicsoft, Inc.
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
USA
EMail: [email protected]
Mark Handley
International Computer Science Institute
1947 Center St, Suite 600
Berkeley, CA 94704
USA
EMail: [email protected]
Eve Schooler
AT&T Labs-Research
75 Willow Road
Menlo Park, CA 94025
USA
EMail: [email protected]
版權宣告
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
譯者：崮山路上走9遍 2004-9-23於深圳完稿。
BLOG: sharp838.mblogger.cn
EMAIL: [email protected]；[email protected]
所有的版權歸於原作者。
相關推薦
SIP協議詳解(中文)-6
這些展示的問題需要定義一個架構來把拒絕服務攻擊造成的影響最小化，並且需要在安全機制中對這類攻擊特別留意。26.2 安全機制從上邊講述的威脅來看，我們得到了SIP協議所需要的基本安全服務，他們是：保護訊息的隱私性和完整性，保護重現（replay）攻擊或者訊息欺騙，提供會話參與者的身份認證和隱私保護，保護拒絕服務
sip協議詳解 系列（二）
Sip的核心請求訊息 INVITE、ACK、OPTIONS、BYE、CANCEL 和 REGISTER INVITE • INVITE可以在郵件正文中包含主叫方的媒體資訊。 • 如果INVITE已經接收到成功響應（2xx）或已經發送ACK，則會話被認為是建立的。 • 成功的INVIT
sip協議詳解 系列（一）
近期一直在研究視訊通話，裡面有sip或者xmpp，之前也不瞭解， 準備整體瞭解sip並整理相關內容。 Sip概述 SIP（Session Initiation Protocol，會話初始協議）是由IETF（Internet Engineering Task Force，因特網工程任務組）
SIP協議詳解&eXosip原始碼庫用法分析
1、概述 1.1 SIP概念 會話初始協議SIP（Session Initiation Protocol）是一個應用層的控制協議，可以建立、修改和結束多媒體的會話。它是由IETF提出並主持研究的一個在IP網路上進行多媒體通訊的應用層控制協議，它被用來建立、修改、
SIP 協議詳解
## SIP 協議詳解 2013年參與過一個“視訊通訊的App”專案，使用Sip協議通訊。當時通訊協議這塊不是自己負責，加上時間緊、任務重等方面的原因，一直未對Sip協議進行過深入的瞭解。 2020年春天疫情突發，宅在家裡終於有了空餘時間。這裡來詳細瞭解一下Sip協議。 以下內容大致分為以下幾個部分：
網絡協議詳解
網絡協議 test 未能 第一個 為什麽 體系 index 緩存 hyper 目錄：：：：：： 一、網絡協議 二、TCP（Transmission Control Protocol，傳輸控制協議） TCP頭格式 TCP協議中的三次握手和四次揮手
HTTP協議詳解（真的很經典）
cnp 運用 web應用 media 服務器端 所有 長度 request bad 轉載：http://e7kan.com/?p=264& 引言 HTTP是一個屬於應用層的面向對象的協議，由於其簡捷、快速的方式，適用於分布式超媒體信息系統。它於1990年提出，經過幾
http協議詳解
表單 pos 換行 none 必須掌握 通信 pow print expires HTTP是一個屬於應用層的面向對象的協議，由於其簡捷、快速的方式，適用於分布式超媒體信息系統。它於1990年提出，經過幾年的使用與發展，得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1
HTTP 協議詳解
範圍 文件傳輸 ext text 繼續 warn 分組 asi nsf 前言： 之前買過一本《圖解 HTTP》這本書，作者好像是個小日本，也繼承了小日本在動漫方面的天賦，30% 的內容都是 Q 版畫圖。 之後沒有引起我的重視，書一借出去，然後，之後 .. 之後，
Http 協議詳解筆記
code sps 網頁 提示 agent tor 指定 6.0 lec HTTP是一個屬於應用層的面向對象的協議，由於其簡捷、快速的方式，適用於分布式超媒體信息系統。它於1990年提出，經過幾年的使用與發展，得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六
HTTPS協議詳解(二)：TLS/SSL工作原理
-c 基本 公鑰加密 工作方式 通信 使用 sha2 公開 原理 HTTPS協議的主要功能基本都依賴於TLS/SSL協議，本節分析TLS/SSL協議工作原理。 TLS/SSL的功能實現主要依賴於三類基本算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實
HTTPS協議詳解(四)：TLS/SSL握手過程
其它 對數 hello 減少 受保護 改版 text gin 組裝 1、握手與密鑰協商過程 基於RSA握手和密鑰交換的客戶端驗證服務器為示例詳解TLS/SSL握手過程 再看一張手繪時序圖 (1).client_hello 客戶端發起請求，以明文傳輸請求信息，包
HTTPS協議詳解(三)：PKI 體系
客戶 判斷 節點 無法 三方 證書無效 進行 證書 roo 1、RSA身份驗證的隱患 身份驗證和密鑰協商是TLS的基礎功能，要求的前提是合法的服務器掌握著對應的私鑰。但RSA算法無法確保服務器身份的合法性，因為公鑰並不包含服務器的信息，存在安全隱患: 客戶端C和
FC協議詳解
fc標題索引本文出自 “一步一印，有印為證” 博客，謝絕轉載！FC協議詳解
RTSP協議詳解
5.1 handler 詳解 finally 運行 綁定 prot mage accepted RTSP簡介 RTSP（Real Time Streaming Protocol）是由Real Network和Netscape共同提出的如何有效地在IP網絡上傳輸流媒
（三）GET和POST協議詳解
str 打印 http 類別 多個 表現 pro 版本 prot 一、GET請求報文分析： 1、 請求行： a) GET（描述該請求采用了什麽請求方法），HTTP協議中包含8種請求方法： GET 請求獲取Request-URI 所標識的資源 POST
HTTP協議詳解以及URL具體訪問過程
標記語言 初始化 折疊 code 文件類型 scheme 缺少 gif 其他瀏覽器 1、簡介 1.1、HTTP協議是什麽？ 即超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最為廣泛的一種網絡協議，所有的WWW文件都必
(轉)RTSP協議詳解
定義 attach highlight not xtend prev desc 設備 代理服 轉自：https://www.cnblogs.com/lidabo/p/6553212.html RTSP簡介 RTSP（Real Time Streaming Prot
第二章、IP協議詳解
32位 匹配 重新 連續 檢測 tcp crc校驗 變化 同步傳輸 一、IP服務的的特點 IP協議是TCP/IP協議族的動力，他為上層協議提供的無狀態無連接，不可靠的服務。 無狀態是指IP通信雙方不同步傳輸數據的狀態信息，因此所有的ip數據報的發送，傳出和接受都是相互獨
# 中小型網絡構建-vrrp協議詳解
中小型網絡構建中小型網絡構建-vrrp協議詳解 什麽是VRRP？虛擬路由冗余協議(Virtual Router Redundancy Protocol，簡稱VRRP)是由IETF提出的解決局域網中配置靜態網關出現單點失效現象的路由協議，1998年已推出正式的RFC2338協議標準。VRRP廣泛應用在邊緣網絡中