[發明專利]保護動態主機配置協議的方法、發送方和接收方

在審

• 申請號: 201210113942.1
• 申請日: 2012-04-18
• 公開（公告）號: CN103379094A
• 公開（公告）日: 2013-10-30
• 發明（設計）人: 周蘇靜;苗忠明
• 申請（專利權）人: 中興通訊股份有限公司
• 主分類號: H04L29/06
• 分類號: H04L29/06;H04L29/12
• 代理公司: 北京安信方達知識產權代理有限公司 11262
• 代理人: 李健;龍洪

技術領域

本發明涉及互聯網絡領域，尤其涉及保護動態主機配置協議的方法、發送方和接收方。

背景技術

動態主機配置協議(Dynamic?Host?Configuration?Protocol，DHCP)是一種基于客戶端/服務器端的網絡協議，其目的是使客戶端從服務器端獲得一些網絡配置參數，例如IP(Internet?Protocol，互聯網協議)地址、DNS(Domain?Name?Server，域名服務器)地址等。根據互聯網協議的版本不同，動態主機配置協議的版本也不同，包括IETF(互聯網工程任務組，Internet?Engineering?Task?Force)在RFC(請求意見文檔，Request?For?Comments)2131中發布的第四版DHCPv4和RFC?3315中發布的第六版DHCPv6。

DHCPv4的消息類型主要包括發現DHCPDISCOVER、提供DHCPOFFER、請求DHCPREQUEST、確認DHCPACK。客戶端發送發現消息到廣播地址，用于發現提供DHCP服務的服務器端；服務器端收到來自客戶端的發現消息時，為客戶端保留一個IP地址，然后發送提供消息給客戶端；客戶端收到提供消息后，選擇一個服務器端提供的IP地址，發送請求消息給廣播地址，其中包含選擇的服務器端的IP；服務器端收到來自客戶端的請求消息后，發送一個確認消息給客戶端，包含分配IP地址的租期和客戶端可能請求的其他所有配置信息。

DHCPv6和第四版的區別比較大，下面是對DHCPv6的介紹：

根據配置信息的類型和場景，DHCPv6的消息交換次數可以是四次、兩次或一次。

其中交換四次消息的消息流主要用于客戶端希望從服務器獲得IP地址的場景。這時客戶端首先發送初始請求消息SOLICIT給一個固定的本地鏈路多播地址，初始請求消息中包含一些條件；符合條件的服務器端發送一個廣告消息ADVERTISE，其中包含給客戶端分配的IP地址；客戶端從收到的服務器端廣告消息中選擇一個IP地址及其他配置信息，發送地址請求消息REQUEST給該服務器端；服務器端發送一個回復消息REPLY，確認客戶端選擇的IP地址和其他配置信息。

其中交換兩次消息的消息流主要用于如下場景：客戶端已經被分配IP地址，希望延長使用、釋放該IP地址或者獲得其他配置信息；客戶端檢測到該IP地址和別的客戶端的IP地址沖突，拒絕使用該IP地址；服務器端的配置信息已經更新，希望客戶端發起請求獲得最新的配置信息。這些場景下，客戶端首先發送非地址請求消息，非地址請求消息的類型包括配置請求INFORMATION-REQUEST、第一次續租請求RENEW、第二次續租請求REBIND、確認請求CONFIRM、拒絕請求DECLINE、釋放請求RELEASE。如果客戶端知道服務器端的IP地址，上述請求消息直接發送給該服務器端，否則發送給一個固定的本地鏈路多播地址。服務器端發送一個回復消息REPLY，其中包含給客戶端分配的配置信息。

其中交換一次消息的場景是服務器端的配置信息已經更新，希望客戶端發起請求獲得最新的配置信息，于是服務器端給客戶端發送一條更新配置觸發消息RECONFIGURE。該觸發消息后通常跟著交換兩次消息的消息流，如第一次續租請求/回復、配置請求/回復。

在實際應用中，動態主機配置協議還可能涉及中轉服務器端Relay，其作用是中轉客戶端和服務器端之間的消息，在此不詳細介紹。

動態主機配置協議中每個由客戶端發出的消息都包含一個事務標識，用于標識該消息，服務器端收到來自客戶端的消息后，如果要發送回復消息或廣告消息，將客戶端消息中包含的事務標識拷貝到回復消息或廣告消息中，以供客戶端將回復消息或廣告消息和發送消息聯系起來。擁有同一個事務標識的請求消息和應答消息組成一對消息，動態主機配置協議就是由多對消息組成的。一個例外是服務器端發送的更新配置觸發消息，其中包含的事務標識為零，且沒有和它共享一個事務標識的消息。

無論哪個版本，動態主機配置協議在實際應用中主要面對兩種安全威脅：服務器端發送的消息被偽造、客戶端發送的消息被偽造。為了抵御上述安全威脅，動態主機配置協議的標準(RFC3118、RFC3315)說明每個客戶端和服務器端之間共享一個密鑰，它們之間發送和接收的消息附帶一個根據共享密鑰計算的針對消息內容的消息認證碼，以此保證消息內容和消息發送者的真實可信性。但是該標準并沒有規范共享密鑰的分配機制，通常的做法是在客戶端和服務器端手工配置共享密鑰，其缺點是靈活性、可擴展性比較差。