本文檔描述如何將可擴展配置協議(EPP)會話映射到單個傳輸控制協議(TCP)連接。這種映射需要使用傳輸層安全性(
TLS)協議來保護EPP客戶機和EPP服務器之間交換的信息。本文件廢止RFC 4934。
2. 會話管理
- 創建TCP連接
客戶端必鬚髮出一個活動的OPEN呼叫，服務器必須在IANA分配的標準TCP端口(700)上偵聽TCP連接請求。
在TCP會話建立後，EPP服務器必須向客戶端返回EPP <greeting> - 關閉TCP連接
- 客戶端發出EPP <logout>命令結束EPP會話。 接收EPP <logout>命令的服務器必須結束EPP會話並通過CLOSE呼叫關閉TCP連接。
- 客戶端發出CLOSE呼叫結束EPP會話。
- 服務器發出CLOSE call終止TCP連接：EPP會話在服務器定義的時間段內一直處於非活動狀態。
- 服務器終止TCP連接：關閉打開和活動時間超過服務器定義的時間段。
3. 消息交換
Client Server
| |
| Connect |
| >>------------------------------->> |
| |
| Send Greeting |
| <<-------------------------------<< |
| |
| Send <login> |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command |
| >>------------------------------->> |
| |
| Send Response |
| <<-------------------------------<< |
| |
| Send Command X |
| >>------------------------------->> |
| |
| Send Command Y |
| >>---------------+ |
| | |
| | |
| Send Response X |
| <<---------------(---------------<< |
| | |
| | |
| +--------------->> |
| |
| Send Response Y |
| <<-------------------------------<< |
| |
| Send <logout> |
| >>------------------------------->> |
| |
| Send Response & Disconnect |
| <<-------------------------------<< |
| |
Figure 1: TCP Client-Server Message Exchange
- 除了EPP服務器greeting之外，EPP消息由
EPP客戶機以EPP命令的形式發起。 - EPP服務器必須在承載該命令的
同一TCP連接上向EPP命令返回EPP響應。 - 如果TCP連接中斷時，服務器的響應未返回給客戶機，服務器可能嘗試撤銷命令的效果，以確保客戶機和服務器之間的狀態一致。
- EPP命令是冪等的，因此多次處理命令會對存儲庫產生與成功處理命令一次相同的淨效果。
- EPP客戶端在已建立的TCP連接上將EPP命令流式傳輸到EPP服務器。 客戶端不得通過多個TCP連接從單個EPP會話分發命令。
客戶端可以建立多個TCP連接以支持多個EPP會話，每個會話映射到單個連接。 服務器應該根據服務器功能和操作負載將客戶端限制爲最大TCP連接數。 - EPP將客戶端 - 服務器交互描述爲命令 - 響應交換，其中客戶端向服務器發送一個命令，並且服務器向客戶端返回一個響應。
- 客戶端可能能夠通過流水線技術（
在收到第一個命令的響應之前發送多個命令）通過TCP傳輸實現輕微的性能提升，但此功能不會更改基本的單個命令、單個響應操作模式核心協議。 - 每個EPP數據單元必須包含
單個EPP消息。 命令必須獨立處理，處理順序與客戶端發送的順序相同。 - 服務器應該對客戶端發出格式良好的EPP命令所需的時間量施加限制。 如果在時間限制內沒有收到格式正確的命令，服務器應該結束EPP會話並關閉打開的TCP連接。
4. 數據單元格式
EPP數據單元總長度，包含兩個字段：
-
頭：
32位，描述數據單元總長度。
EPP數據單元的總長度以網絡(大端)字節順序測量。該字段也包含在總長度計算中。 -
EPP XML實例：
長度可變，數據單元中攜帶的EPP XML實例。
EPP XML實例的長度是通過從數據單元的總長度中減去四個字節來確定的。在處理EPP消息之前，接收方必須成功讀取那麼多字節才能檢索完整的EPP XML實例。EPP數據單元格式(一個刻度表示一個位的位置)：
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EPP XML Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. 傳輸安全
EPP as-is僅使用標識符和純文本密碼提供簡單的客戶端身份驗證服務。 被動攻擊足以恢復客戶端標識符和密碼，允許瑣碎的命令僞造。 防止大多數其他常見攻擊必須由其他分層協議提供。
當通過TCP分層時，傳輸層安全性（TLS）協議版本1.0 [RFC2246]或其後續版本（如TLS 1.2 [RFC5246] ），使用雙方支持的最新版本，必須用於提供完整性，機密性和相互強大的客戶端 - 服務器認證 TLS的實現通常包含弱加密模式，不應該用於保護EPP。 希望高安全性的客戶端和服務器應該使用TLS和不易受損害的加密算法。
使用TLS握手協議進行身份驗證可確認客戶端和服務器計算機的身份。 EPP使用額外的客戶端標識符和密碼來識別和驗證客戶端對服務器的用戶身份，補充TLS提供的機器身份驗證。 客戶端證書中描述的身份和EPP客戶端標識符中描述的身份可以不同，因爲服務器可以分配多個用戶身份以供任何特定客戶端計算機使用。 必須使用帶外機制在客戶端操作員和服務器操作員之間協商可接受的證書身份。 在授予EPP服務之前，提供的證書身份必須與協商的身份相匹配。
如果客戶端在嘗試建立EPP會話之前未正確識別服務器，則存在登錄憑證受損的風險。 在將登錄憑據發送到服務器之前，客戶端需要確認在TLS握手中收到的服務器證書是服務器的預期證書。 客戶端還需要確認從服務器接收的問候語包含預期的標識信息。 在建立TLS會話並在受保護的TCP連接上接收EPP問候語後，客戶端必須將證書主題和/或subjectAltName與預期的服務器標識信息進行比較，並在檢測到不匹配時進行中止處理。 如果證書驗證成功，則客戶端需要確保收到的證書和問候語中包含的信息是一致且適當的。 如上所述，兩個檢查通常需要在客戶端和服務器之間進行帶外信息交換，以在嘗試帶內連接之前識別期望值。
EPP TCP服務器容易受到常見的TCP拒絕服務攻擊，包括TCP SYN泛洪。 服務器應該採取措施，使用易於實施的解決方案的組合來最小化拒絕服務攻擊的影響，例如部署防火牆技術和邊界路由器過濾器，以限制對已知的可信客戶端的入站服務器訪問。