CN100596062C - 分布式报文传输安全保护装置和方法 - Google Patents
分布式报文传输安全保护装置和方法 Download PDFInfo
- Publication number
- CN100596062C CN100596062C CN200710120365A CN200710120365A CN100596062C CN 100596062 C CN100596062 C CN 100596062C CN 200710120365 A CN200710120365 A CN 200710120365A CN 200710120365 A CN200710120365 A CN 200710120365A CN 100596062 C CN100596062 C CN 100596062C
- Authority
- CN
- China
- Prior art keywords
- inbound
- message
- information
- disposable plates
- outgoing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/101—Access control lists [ACL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/164—Implementing security features at a particular protocol layer at the network layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
- H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/12—Details relating to cryptographic hardware or logic circuitry
- H04L2209/125—Parallelization or pipelining, e.g. for accelerating processing of cryptographic operations
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种分布式报文传输安全保护装置和方法。本发明中,主控板按照预设规则,将各SA信息分配给多个处理板,从而使得接收并存储SA信息的各处理板均可实现IPSec处理,从而实现了将IPSec处理分担到多个处理板,因此,当在同一个接口上有大量的IPSec隧道存在时,对经过所有IPSec隧道的报文进行IPSec处理不会只依靠该接口所在的一块处理板,而是分配给不同的处理板来完成,使得多块处理板有效地分担了与多个SA对应的IPSec处理,从而提高了IPSec处理的效率。
Description
技术领域
本发明涉及网络安全技术,特别涉及基于IP安全(IP Security,IPSec)的一种分布式报文传输安全保护装置和方法。
背景技术
IPSec是一种三层隧道加密协议,用于为两个端点之间传输的报文提供高质量的、可互操作的、基于密码学的安全保护。
其中,进行报文传输的两个端点称为IPSec对等体,IPSec对等体之间的连接可以称为IPSec隧道。
具体来说,IPSec对等体之间传输报文的安全保护是基于安全联盟(Security Association,SA)来实现的。SA为IPSec对等体间对某些要素的约定,例如,IPSec对等体间使用哪种安全协议、协议的封装模式、加密算法、特定流中受保护报文的共享密钥以及密钥的生存周期等。SA是单向的,如果在两个IPSec对等体之间通过一个IPSec隧道实现双向报文传输,则需要在IPSec对等体的每个端点上均建立两个相互关联的SA,一个入方向SA用于对入方向的报文加密,一个出方向SA用于对出方向的报文解密。其中,入方向是指进入IPSec隧道的方向,而出方向是指从IPSec隧道输出的方向。
实际应用中,SA的建立可以通过两种协商方式实现,一种是手工配置方式,一种是互联网密钥交换协议(Internet Key Exchange,IKE)。
图1为现有IPSec隧道组网模型示意图。如图1所示,以IPSec对等体为两个网关R1和R2为例,R1和R2分别作为IPSec隧道的起点和终点,R1和R2之间通过手工配置或IKE协商建立SA。主机A将需要发送给主机B的入方向报文发送给R1;R1作为发送方,先利用入方向SA的SA信息对来自主机A的入方向报文进行加密等入方向IPSec处理,再将处理后的报文通过IPSec隧道传输给R2;R2作为接收方,从IPSec隧道接收到加密后的报文后,利用出方向SA的SA信息对该报文进行解密、完整性验证等出方向IPSec处理,同时,还可以进行发送方是否合法、防重放等出方向IPSec处理,并将处理后的出方向报文发送给主机B。这样,R1和R2即作为报文传输安全保护装置,实现了对报文传输的安全保护。
现有报文传输安全保护装置通常包括多个接口单元,IPSec处理是由接口单元所在的处理板来完成的,其中,接口单元所在的处理板通常称为接口板,接口板设置有能够实现IPSec处理的功能单元。不同的接口单元对应不同的IPSec隧道,通过不同IPSec隧道传输的报文则分别在不同的接口板上进行IPSec处理,即实现分布式安全保护。
图2为现有IPSec隧道组网模型中分布式报文传输安全保护装置的结构示意图。如图2所示,以如图1所示的IPSec隧道组网模型为例,作为分布式报文传输安全保护装置的网关R1至少包括:主控板1、接口板A和接口板B。接口板A和接口板B上分别设置了两个接口单元A1和A2、B1和B2,主控板1与接口板A和接口板B通过交换网连接;作为分布式报文传输安全保护装置的网关R2至少包括:主控板2、接口板C和接口板D。接口板C和接口板D上分别设置了两个接口单元C1和C2、D1和D2,主控板2与接口板C和接口板D通过交换网连接。
以下举例说明网关R1和R2的内部工作原理:
对于入方向,假设网关R1的接口板A上的接口单元A1接收到一个入方向报文,则接口板A查找转发表;如果判断出该入方向报文需要从接口板B的接口单元B1发送,则接口板A将该入方向报文转发给接口板B。
此时,如果网关R1上尚未建立SA,则接口板B丢弃来自接口板A的入方向报文,并请求主控板创建SA;主控板在发起IKE协商建立SA后,将对应的入方向SA的SA信息发送给接口板B,以供接口板B下一次接收到入方向报文后能够进行入方向IPSec处理。如果网关R1上已建立了SA,则接口板B利用其存储的入方向SA的SA信息对来自接口板A的入方向报文进行加密等入方向IPSec处理,并通过接口单元B1发送到该接口单元对应的IPSec隧道。
对于出方向,假设网关R2的接口板D上的接口单元D1接收到来自IPSec隧道的出方向报文,即网关R1通过接口单元B1和该接口单元对应的IPSec隧道发送的报文,如果网关R2上尚未建立SA,则接口板D丢弃该报文,并请求主控板2创建SA,主控板2在发起IKE协商建立SA后,将对应的出方向SA的SA信息发送给接口板D;如果网关R2上已建立了SA,则接口板D利用其存储的出方向SA的SA信息对来自IPSec隧道的报文进行解密等出方向IPSec处理。
同理,网关R1和R2中的其它接口单元对应其他IPSec隧道,也可以按照上述原理对入方向或出方向报文进行IPSec处理。
由上述分布式报文传输安全保护装置可见,当需要通过某个接口单元所对应的IPSec隧道进行入方向或出方向的报文传输时,只能由该接口单元所在的接口板进行对应的IPSec处理。这样,实现了按接口分担IPSec处理。
然而,在某些组网环境下,当同一个接口单元上有大量的IPSec隧道存在时,对经过所有这些IPSec隧道的报文进行IPSec处理都只能依靠一块接口板,会使得IPSec处理的效率大大降低。
以如图2所示的现有IPSec隧道组网模型中分布式报文传输安全保护装置为例,网关R1的接口板A上的接口单元A1连续接收到多个入方向报文,则接口板A查找转发表;如果判断出接收到的每个入方向报文均需要从接口板B的接口单元B 1发送,则接口板A将连续接收到的多个入方向报文转发给接口板B,在网关R1上已建立了SA的情况下,由接口板B对接收到的多个报文进行入方向IPSec处理。而此时,接口板A却可能处于空闲状态。
接口板B通过接口单元B1将入方向IPSec处理后的报文发送到IPSec隧道,该IPSec隧道的对端接口为网关R2的接口板D上的接口单元D1。网关R2的接口板D上的接口单元D1接收到来自IPSec隧道的出方向报文,在网关R2上已建立了SA的情况下,接口板D利用其存储的出方向SA的SA信息对来自IPSec隧道的报文进行出方向IPSec处理。而此时,接口板C却可能处于空闲状态。
可见,现有分布式报文传输安全处理装置不能有效分担IPSec处理,从而造成了IPSec处理效率不高。
发明内容
有鉴于此,本发明提供了一种分布式报文传输安全保护装置和方法,能够有效分担IPSec处理,从而提高IPSec处理效率。
本发明提供的一种分布式报文传输安全保护装置,包括:主控板、与主控板相连的多个接口单元、以及与主控板相连的多个处理板,其中,
所述主控板,针对各接口单元上的互联网安全IPSec隧道建立对应的安全联盟SA,并按照均衡分担的原则将建立SA得到的SA信息发送给各处理板、且同一个SA的SA信息只发送给同一个处理板,处理板存储接收到的SA信息;
所述主控板还根据入方向SA的SA信息建立入方向重定向表、根据出方向SA的SA信息建立出方向重定向表;如果所述主控板通过接口单元接收到的需要进行IPSec处理的报文为入方向报文,则依据查找由对应入方向SA的SA信息建立的入方向重定向表的结果,将该报文发送给存储着与该报文的报文特性所匹配的SA信息的处理板;如果所述主控板通过接口单元接收到的需要进行IPSec处理的报文为出方向报文,则依据查找由对应出方向SA的SA信息建立的出方向重定向表的结果,将该报文发送给存储着与该报文的报文特性匹配的SA信息的处理板;
所述处理板,利用存储的SA信息,对来自主控板的报文进行IPSec处理。
所述入方向重定向表中包括入方向报文特性与处理板标识的映射关系;查找由对应入方向SA的SA信息建立的入方向重定向表的结果为入方向报文特性对应的处理板标识;
或者包括:根据入方向SA的SA信息中的访问控制列表ACL规则号,从预设ACL表中查找得到的五元组,以及该入方向SA的SA信息中的接口索引;
或者包括:入方向SA的SA信息中的接口索引;
或者包括:入方向SA的SA信息中的隧道对端IP和接口索引;
其中,接口索引和隧道对端IP是根据所述接收到的入方向报文中的目的IP查找预设转发表得到的。
所述入方向报文特性包括:入方向SA信息中的SA保护流五元组和接口索引;
其中,接口索引是根据所述接收到的入方向报文中的目的IP查找预设转发表得到的。
所述出方向重定向表中包括出方向报文特性与处理板标识的映射关系;查找由对应出方向SA的SA信息建立的出方向重定向表的结果为出方向报文特性对应的处理板标识;
所述出方向重定向表中的出方向报文特性,是根据出方向SA的SA信息确定的。
所述出方向的报文特性包括:对应的出方向SA信息中的安全参数索引、隧道本端IP、安全协议类型。
所述处理板标识为处理板板号;
所述入方向重定向表中的处理板板号,是根据所述入方向重定向表的数量对所述处理板的数量取模后的结果确定的;
所述出方向重定向表中的处理板板号,为对应的入方向重定向表中的处理板板号;其中,该出方向重定向表对应的出方向SA,与所述对应的入方向重定向表对应的入方向SA相关联。
所述接口单元为所述主控板上的物理接口,或者为独立于所述主控板的功能单元。
所述主控板、处理板和接口单元位于同一物理实体内部;
或者,所述主控板、处理板和接口单元中的任意两者分别位于不同物理实体内部。
该报文传输安全保护装置为网关。
本发明提供的一种分布式报文传输安全保护方法,包括:
主控板针对各接口单元上的互联网安全IPSec隧道建立对应的安全联盟SA,并按照均衡分担的原则将建立SA得到的SA信息发送给各处理板、且同一个SA的SA信息只发送给同一个处理板,处理板存储接收到的SA信息;
主控板根据入方向SA的SA信息建立入方向重定向表、根据出方向SA的SA信息建立出方向重定向表;如果主控板通过接口单元接收到的需要进行IPSec处理的报文为入方向报文,则依据查找由对应入方向SA的SA信息建立的入方向重定向表的结果,将该报文发送给存储着与该报文的报文特性所匹配的SA信息的处理板;如果主控板通过接口单元接收到的需要进行IPSec处理的报文为出方向报文,则依据查找由对应出方向SA的SA信息建立的出方向重定向表的结果,将该报文发送给存储着与该报文的报文特性匹配的SA信息的处理板;
处理板利用其存储的SA信息,对来自主控板的报文进行互联网安全IPSec处理。
所述根据入方向SA的SA信息建立入方向重定向表为:根据入方向SA的SA信息确定入方向报文特性,建立入方向报文特性与处理板标识的映射关系;
所述查找由对应入方向SA的SA信息建立的入方向重定向表的结果为入方向报文特性对应的处理板标识。
所述建立入方向报文特性与处理板标识的映射关系为:根据入方向SA的SA信息中的访问控制列表ACL规则号,从预设ACL表中查找得到五元组;建立查找得到的五元组和该入方向SA的SA信息中的接口索引,与处理板标识的映射关系;
所述查找由对应入方向SA的SA信息建立的入方向重定向表为:根据接收到的入方向报文中的目的IP查找预设转发表,确定该入方向报文对应的接口索引;根据接收到的入方向报文中的五元组的全部或部分元素,以及该报文对应的接口索引查找所述入方向重定向表。
所述建立入方向报文特性与处理板标识的映射关系为:建立入方向SA的SA信息中的接口索引与处理板标识的映射关系;
所述查找由对应入方向SA的SA信息建立的入方向重定向表为:根据接收到的入方向报文中的目的IP查找预设转发表,确定该入方向报文对应的接口索引;根据该报文对应的接口索引查找所述入方向重定向表。
所述建立入方向报文特性与处理板标识的映射关系为:建立对应的入方向SA的SA信息中的隧道对端IP和接口索引与处理板标识的映射关系;
所述查找由对应入方向SA的SA信息建立的入方向重定向表为:根据接收到的入方向报文中的目的IP查找预设转发表,确定该入方向报文对应的接口索引和隧道对端IP;根据该报文对应的接口索引和隧道对端IP查找所述入方向重定向表。
所述建立入方向报文特性与处理板标识的映射关系为:建立入方向SA信息中的SA保护流五元组和接口索引与处理板标识的映射关系;
所述查找由对应入方向SA的SA信息建立的入方向重定向表为:根据接收到的入方向报文中的目的IP查找预设转发表,确定该入方向报文对应的接口索引;根据接收到的入方向报文中的五元组的全部或部分元素,以及该报文对应的接口索引查找所述入方向重定向表。
所述根据出方向SA的SA信息建立出方向重定向表为:根据出方向SA的SA信息确定出方向报文特性,建立出方向报文特性与处理板标识的映射关系;
所述查找由对应出方向SA的SA信息建立的出方向重定向表的结果为出方向报文特性对应的处理板标识。
所述建立出方向报文特性与处理板标识的映射关系为:建立对应的出方向SA信息中的安全参数索引、隧道本端IP、安全协议类型与处理板标识的映射关系;
所述查找由对应出方向SA的SA信息建立的出方向重定向表为:据接收到的出方向报文中的安全参数索引、隧道本端IP、安全协议类型,查找出方向重定向表。
所述处理板标识为处理板板号;
所述入方向重定向表中的处理板板号,是根据所述入方向重定向表的数量对所述处理板的数量取模后的结果确定的;
所述出方向重定向表中的处理板板号,为对应的入方向重定向表中的处理板板号;其中,该出方向重定向表对应的出方向SA,与所述对应的入方向重定向表对应的入方向SA相关联。
由上述技术方案可见,主控板按照预设规则,将各SA信息分配给多个处理板,从而使得接收并存储SA信息的各处理板均可实现IPSec处理,从而实现了将IPSec处理分担到多个处理板,因此,当在同一个接口上有大量的IPSec隧道存在时,对经过所有IPSec隧道的报文进行IPSec处理不会只依靠该接口所在的一块处理板,而是分配给不同的处理板来完成,使得多块处理板有效地分担了与多个SA对应的IPSec处理,从而提高了IPSec处理的效率。
附图说明
图1为现有IPSec隧道组网模型示意图。
图2为现有IPSec隧道组网模型中分布式报文传输安全保护装置的结构示意图。
图3为本发明实施例中分布式报文传输安全保护装置的示例性结构图。
图4为本发明实施例中分布式报文传输安全保护方法的示例性流程图。
图5为本发明实施例中创建入方向重定向表的示意图。
图6为本发明实施例中入方向重定向过程的示意图。
图7为本发明实施例中创建出方向重定向表的示意图。
图8为本发明实施例中出方向重定向过程的示意图。
图9为本发明实施例中分布式报文传输安全保护过程1的流程图。
图10为本发明实施例中分布式报文传输安全保护过程2的流程图。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚明白,以下参照附图并举实施例,对本发明进一步详细说明。
本发明中,主控板并不总是将各接口单元上的IPSec隧道所对应的SA信息发送给该接口单元所在的处理板,而是按照均衡分担的原则,将针对各接口单元上的IPSec隧道所建立的SA的SA信息,根据各处理板当时业务处理情况,分别发送给比较空闲的各处理板;具体实现为:各接口单元首先将接收到的报文发送给主控板,由主控板在判断出该报文需要进行IPSec处理后,将该报文对应的SA信息发送给当时比较空闲的处理板,由该处理板对后续发送过来的报文进行IPSec相应的处理。
这样,当在同一个接口单元上有大量的IPSec隧道存在时,对经过所有这些IPSec隧道的报文进行IPSec处理不会只依靠该接口单元所在的一块处理板,而是根据各处理板当时业务的处理情况,分配给不同的处理板来完成,使得各处理板有效地分担了IPSec处理,从而提高了IPSec处理的效率。
上述处理板可以为接口单元所在的处理板,即接口板;由于分布式报文传输安全保护装置中,通常还包括用于会话业务处理等业务处理的业务板,因此,上述处理板也可以为业务板。实际应用中,只需在业务板上增加一个现有能够实现IPSec处理的功能单元即可。
图3为本发明实施例中分布式报文传输安全保护装置的示例性结构图。如图3所示,本实施例中的分布式报文传输安全保护装置可以包括:主控板、接口单元和处理板。
主控板,针对各接口单元上的IPSec隧道建立SA,并按照预设规则将建立SA得到的SA信息发送给各处理板,例如可以按照轮询、哈希(Hash)运算等基于均蘅原则的方式将SA信息分配给各处理板,处理板存储接收到的SA信息。
接口单元将接收到的报文发送给主控板,主控板将需要进行IPSec处理的报文,发送给存储着与该报文的报文特性所匹配的SA信息的处理板。
通常情况下,SA信息中包括:访问控制列表(Access Control List,ACL)规则号、接口索引、隧道对端IP、SA保护流五元组。因此,主控板可以从报文中提取相应的报文特性,并根据上述信息,判断出与接收到的报文的报文特性匹配的SA信息。
实际应用中,主控板中还存储着预先设置的安全策略。其中,安全策略规定不同报文对应的安全服务(包括安全协议类型、加密/认证算法以及封装模式);安全策略中还包括用于描述报文特性的访问控制列表ACL规则表。ACL规则表中包含了该安全策略保护的报文流的五元组信息(包括源/目的IP、源/目的端口号以及IP层承载的协议类型)以及对该报文进行何种动作(是应用IPSec保护还是丢弃)。主控板在接收到报文后,根据存储的预设安全策略判断是否应当对接收到的报文应用IPSec保护,如果根据报文的目的IP地址查找转发表所确定的接口单元绑定了预设的安全策略,则判断需要对该报文进行IPSec处理,并将该报文发送给存储着对应SA信息的处理板。相同或不同设置的安全策略可以与不同的接口单元绑定。
处理板利用所存储的SA信息,对来自主控板的报文进行IPSec处理。
其中,对于需要通过IPSec隧道发送的报文,IPSec处理为加密、封装等处理;对于从IPSec隧道接收到的报文,IPSec处理为解密、解封装等处理。如果处理板中存储着多个SA信息,则处理板也可以根据报文的报文特性选择出匹配的SA信息,并利用匹配的SA信息对报文进行IPSec处理。
由上述装置可见,主控板按照预设规则,将各SA信息分配给多个处理板,从而使得接收并存储SA信息的各处理板均可实现IPSec处理,从而实现了将IPSec处理分担到多个处理板,因此,当在同一个接口上有大量的IPSec隧道存在时,对经过所有IPSec隧道的报文进行IPSec处理不会只依靠该接口所在的一块处理板,而是分配给不同的处理板来完成,使得多块处理板有效地分担了与多个SA对应的IPSec处理,从而提高了IPSec处理的效率。
实际应用中,主控板和处理板可以通过交换网相连;接口单元可以为主控板上的物理接口,也可以为处理板上的物理接口、还可以为独立于主控板或独立于处理板的功能单元;如果接口单元为独立于主控板或独立于处理板的功能单元,则接口单元也可以通过交换网与主控板相连;如果接口单元为独立于主控板的功能单元,则接口单元还可以通过交换网与处理板相连,再由处理板通过另一个交换网与主控板相连。
在本发明实施例中的分布式报文传输安全保护装置中,主控板、处理板和接口单元可以位于同一物理实体内;或者,主控板、处理板和接口单元中的任意两者分别位于不同的物理实体内。
在完成对应的IPSec处理之后,处理板可以将处理后的报文发送给主控板,由主控板将来自处理板的报文通过对应的接口单元发送,实现了报文的传输。
如图3所示的报文传输安全保护装置可以为网关。
图4为本发明实施例中分布式报文传输安全保护方法的示例性流程图。如图4所示,本实施例中的分布式报文传输安全保护方法包括:
步骤401,主控板针对各接口单元上的IPSec隧道建立对应的SA,并根据预设规则将建立SA得到的SA信息发送给各处理板。
步骤402,处理板存储主控板发送的SA信息。
步骤403,接口单元将接收到的报文发送给主控板,主控板将需要进行IPSec处理的报文,发送给存储着与该报文的报文特性所匹配的SA信息的处理板。
本步骤中,主控板可先根据存储的预设安全策略,判断是否应对接收到的报文进行IPSec处理,如果应对该报文进行IPSec处理,才继续执行本步骤,否则,结束本流程,丢弃接收到的报文或通过其他路由转发方式转发接收到的报文。
步骤404,处理板利用存储的SA信息,对主控板发送的报文进行IPSec处理。
本步骤中,对于需要通过IPSec隧道发送的报文,IPSec处理为加密、封装等处理;对于从IPSec隧道接收到的报文,IPSec处理为解密、解封装等处理。如果处理板中存储着多个SA信息,则处理板也可以根据报文的报文特性选择出匹配的SA信息,并利用匹配的SA信息对报文进行IPSec处理。
由上述流程可见,主控板按照预设规则,将各SA信息分配给多个处理板,从而使得接收并存储SA信息的各处理板均可实现IPSec处理,从而实现了将IPSec处理分担到多个处理板,因此,当在同一个接口上有大量的IPSec隧道存在时,对经过所有IPSec隧道的报文进行IPSec处理不会只依靠该接口所在的同一块处理板,而是分配给不同的处理板来完成,使得多块处理板有效地分担了与多个SA对应的IPSec处理,从而提高了IPSec处理的效率。
在步骤404之后,处理板可以将处理后的报文发送给主控板,由主控板将来自处理板的报文通过对应的接口单元发送,实现了报文的传输。
本发明实施例中,考虑到IPSec的防重放特性,较佳地应保证同一个入方向SA或一个出方向SA对应的所有IPSec处理分配给同一个处理板。
例如,在入方向上,如果同一个SA对应的IPSec处理分布在不同的处理板上进行,就有可能由于序列号的不同步,使得两块处理板进行IPSec处理后的报文具有相同的序列号,违背了同一个SA对应的报文序列号为单调递增的特性;而且,在出方向上,如果同一个SA对应的IPSec处理分布在不同的处理板上,就有可能会造成两块处理板上同一SA对应的防重放窗口位置不一样,导致在出方向上接收的报文被错误丢弃。
因此,本实施例在主控板将同一个SA的SA信息只发送给一块处理板,而不会将同一个SA的SA信息发送给多块处理板,并在将不同SA的SA信息分配给各处理板之前,先根据不同SA的SA信息建立并存储对应的重定向表,再根据建立并存储的重定向表,将后续接收到的需要IPSec处理、且报文特性与同一SA信息匹配的所有报文,发送给同一块处理板进行相应的IPSec处理。
下面,对本实施例中的重定向表进行详细说明。
本实施例中,建立的重定向表包括:根据不同入方向SA的SA信息建立的入方向重定向表、和根据不同出方向SA的SA信息建立的出方向重定向表。
如果主控板通过至少一个接口单元接收到的报文为入方向报文,则主控板查找对应入方向SA的SA信息建立的重定向表,将查找重定向表的结果,发送给存储着该SA信息的处理板;
如果主控板通过至少一个接口单元接收到的报文为出方向报文,则主控板查找对应出方向SA的SA信息建立的重定向表,将查找重定向表的结果,发送给存储着该SA信息的处理板。
其中,入方向的重定向表的结构可以如表1所示。
表1
如表1所示的入方向重定向表中,将入方向报文特性作为关键字,包括:五元组信息(源IP、目的IP、源端口、目的端口、协议类型)、以及应用了IPSec处理的接口索引,其中,目的IP可替换为隧道对端IP;查表结果即为入方向报文特性对应的处理板板号等标识。
通常情况下,SA信息中包括:ACL规则号、接口索引、隧道对端IP、SA保护流五元组。因此,主控板可从上述信息中获取对应的关键字。
实际应用中,关键字也可以不全包括五元组中的所有信息和接口索引,而是只包括五元组中所有信息与接口索引中的一个或多个的组合。
在建立了入方向SA之后,主控板能够从入方向SA的SA信息中获取对应的入方向报文特性,将获取的入方向报文特性作为关键字,并确定该关键字对应的处理板标识,即可建立类似于表1所示的重定向表,并将建立重定向表对应的入方向SA信息发送给与处理板标识对应的处理板。
其中,如果处理板标识为处理板板号,则较佳地,可以将当前已建立的入方向重定向表的数量对所述处理板的数量取模,根据取模后的结果确定每个入方向重定向表中的处理板板号,即与不同入方向SA对应的处理板板号,从而能够将不同SA对应的IPSec处理较为均匀地分配给所有的处理板。
例如,假设处理板的数量为10,当前建立的重定向表为已建立的第1个重定向表,即重定向表的总数为1,则1对10取模的结果(即1除以10的余数)为1,根据取模后的结果确定第1个重定向表中的处理板板号为1。
依此类推,每建立一个重定向表,均按照上述方式确定该重定向表中的处理板板号,假设当前建立的重定向表为已建立的第53个重定向表,即重定向表的总数为53,则53对10取模的结果(即53除以10的余数)为3,根据取模后的结果确定第53个重定向表中的处理板板号为3。
可见,在处理板的数量为10的情况下,建立的第i个重定向表中的处理板板号为i的个位,从而实现了将不同SA对应的IPSec处理均匀地分配给所有的处理板。
实际应用中,也可以采用例如随机分配等其他方式,确定每个入方向重定向表中的处理板标识,以尽可能地将所有入方向SA对应的IPSec处理平均分配给所有处理板。
这样,在后续通过接口单元接收到入方向报文后,从入方向报文中直接或者间接获取对应的入方向报文特性,并根据获取的入方向报文特性查找入方向重定向表,获得对应的处理板标识,再将该报文发送给与该处理板标识对应的处理板即可。
实际应用中,可选择不同的入方向报文特性作为关键字建立入方向重定向表,并从接收到的入方向报文中获取对应的入方向报文特性,查找对应的入方向重定向表,再将入方向报文发送到存储着对应SA信息的处理板。也就是说,本发明实施例中,可以基于不同方式将不同SA对应的IPSec处理分配给不同的处理板。
以下,对基于不同方式分配IPSec处理、及对应的入方向重定向表的建立过程举例说明。
本实施例中可以基于如下四种方式重定向分配IPSec处理:按照ACL规则分配、按照接口索引分配、按照隧道对端IP分配、按照SA保护流五元组分配。
图5为本发明实施例中创建入方向重定向表的示意图。
如图5所示,如果按照ACL规则分配,即主控板根据IPSec安全策略中引用的ACL规则,将不同SA对应的IPSec处理分配给不同的处理板,则主控板提取入方向SA的SA信息中的ACL规则号,依此查找ACL表,获得该ACL规则保护的五元组信息,然后提取该五元组和SA信息中的接口索引,作为入方向重定向表的关键字。而作为查表结果的处理板标识,以处理板标识为处理板板号为例,则可以根据入方向重定向表的个数对处理板总数取模的结果来确定处理板板号;也可以随机确定。
这样,建立的入方向重定向表中,作为关键字的入方向报文特性包括:根据对应的入方向SA的SA信息中的ACL规则号,从预设ACL表中查找得到的五元组,以及该入方向SA的SA信息中的接口索引。
如图5所示,如果按照接口索引分配,即主控板根据不同的接口索引,将不同SA对应的IPSec处理分配给不同的处理板,则主控板提取入方向SA的SA信息中的接口索引,作为入方向重定向表的关键字。而作为查表结果的处理板标识,以处理板标识为处理板板号为例,则可以根据入方向重定向表的个数对处理板总数取模的结果来确定处理板板号;也可以随机确定。
这样,建立的入方向重定向表中,作为关键字的入方向报文特性包括:对应的入方向SA的SA信息中的接口索引。
如图5所示,如果按照隧道对端IP分配,即主控板将具有相同隧道对端IP的所有入方向报文分配给同一块处理板,则主控板提取入方向SA的SA信息中的隧道对端IP和接口索引,作为入方向重定向表的关键字。而作为查表结果的处理板标识,以处理板标识为处理板板号为例,则可以根据入方向重定向表的个数对处理板总数取模的结果来确定处理板板号;也可以随机确定。
对于按照隧道对端IP分配方式,如果本端和对端之间有多条IPSec隧道,则需要通过这些IPSec隧道传输的所有入方向报文都由同一块处理板处理。如果本端和多个对端之间有各自的IPSec隧道,则需要通过这些IPSec隧道传输的所有入方向报文将分担到多块处理板处理。
这样,建立的入方向重定向表中,作为关键字的入方向报文特性包括:对应的入方向SA的SA信息中的隧道对端IP和接口索引。
如图5所示,如果按照SA保护流五元组分配,即同一个SA仅对应一条数据流中的所有报文,则主控板提取入方向SA的SA信息中的SA保护流五元组和接口索引,作为入方向重定向表的关键字。而作为查表结果的处理板标识,以处理板标识为处理板板号为例,则可以根据入方向重定向表的个数对处理板总数取模的结果来确定处理板板号;也可以随机确定。
这样,建立的入方向重定向表中,作为关键字的入方向报文特性包括:对应的入方向SA信息中的SA保护流五元组和接口索引。
实际应用中,可以根据需要的负载分担粒度,选择不同的分配方式并建立对应的入方向重定向表。其中,由于按照接口索引分配IPSec处理,是将同一接口上需要进行的所有入方向报文的入方向IPSec处理分配给同一块处理板,因而该方式的分担粒度是最粗的;而由于按照SA保护流五元组分配,只将一条数据流对应的所有入方向报文的入方向IPSec处理分配给一块处理板,因而该方式的分担粒度是最细的。
对于上述各种分配IPSec处理的方式、及建立的对应入方向重定向表,主控板均可从接收到的入方向报文中直接或间接获取对应的入方向报文特性,并作为关键字从重定向表中查找到对应的处理板标识。
图6为本发明实施例中入方向重定向过程的示意图。
如图6所示,如果建立的入方向重定向表对应的IPSec处理的分配方式为按照ACL规则分配,则主控板先根据接口单元接收到的入方向报文中的目的IP,查找预设转发表确定该入方向报文对应的接口索引,再根据接收到的入方向报文中的五元组和该入方向报文对应的接口索引查找入方向重定向表,从而获得对应的处理板标识,并将该入方向报文发送给与该处理板标识对应的处理板。
实际应用中,主控板也可以不提取入方向报文的五元组中的所有元素,而是只提取任意一个或部分元素,并根据提取出的一个或部分元素、以及入方向报文对应的接口索引来查找入方向重定向表,也能够获得对应的处理板标识。
如图6所示,如果建立的入方向重定向表对应的IPSec处理的分配方式为按照接口索引分配,则主控板先根据通过接口单元接收到的入方向报文中的目的IP,查找预设转发表确定该入方向报文对应的接口索引,再根据接收到的入方向报文对应的接口索引查找所述入方向重定向表,从而获得对应的处理板标识,并将该入方向报文发送给与该处理板标识对应的处理板。
如图6所示,如果建立的入方向重定向表对应的IPSec处理的分配方式为按照隧道对端IP分配,则主控板先根据接口单元接收到的入方向报文中的目的IP,查找预设转发表确定该入方向报文对应的接口索引和该入方向报文的下一跳IP,再根据接收到的入方向报文对应的接口索引和下一跳IP查找入方向重定向表,从而获得对应的处理板标识,并将该入方向报文发送给与该处理板标识对应的处理板。
其中,入方向报文对应的下一跳IP可相当于IPSec隧道的对端IP。以如图1所示的IPSec隧道组网模型为例,入方向报文从主机A发往主机B,该入方向报文的目的IP为主机B的IP地址,而对于R1来说,隧道对端IP为R2的IP地址,因此,R1查找转发表中的下一跳IP为R2的IP地址。
如图6所示,如果建立的入方向重定向表对应的IPSec处理的分配方式为按照SA保护流五元组分配,则主控板先根据接口单元接收到的入方向报文中的目的IP,查找预设转发表确定该入方向报文对应的接口索引,再根据接收到的入方向报文中的五元组和该报文对应的接口索引查找所述入方向重定向表,从而获得对应的处理板标识,并将该入方向报文发送给与该处理板标识对应的处理板。其中,入方向报文中的五元组可对应SA保护流五元组。
实际应用中,主控板也可以不提取入方向报文的五元组中的所有元素,而是只提取任意一个或部分元素,并根据提取出的一个或部分元素、以及入方向报文对应的接口索引来查找入方向重定向表,也能够获得对应的处理板标识。
可见,本发明实施例中可根据所需的负载分担粒度,选择多种方式建立入方向重定向表,并根据建立的入方向重定向表,将入方向报文分配给不同处理板进行对应的入方向IPSec处理,从而实现多种IPSec处理的分配方式,进而提高了本发明技术方案的灵活性和通用性。
在建立入方向重定向表的同时,还建立出方向重定向表。本实施例中,出方向的重定向表结构可以如表2所示。
表2
如表2所示的出方向重定向表中,作为关键字的出方向报文特性可以包括:安全参数索引、隧道本端IP和安全协议类型。
通常情况下,SA由一个三元组来唯一标识,这个三元组包括:安全参数索引(Security Parameter Index,SPI)、目的IP和安全协议类型。因此,主控板可从上述信息中获取安全参数索引、安全协议类型、以及相当于隧道本端IP的目的IP。
在建立了出方向SA之后,主控板能够从出方向SA的SA信息中获取对应的出方向报文特性,将获取的出方向报文特性作为关键字,并确定该关键字对应的处理板标识,即可建立类似表2所示的重定向表,并将建立重定向表对应的出方向SA信息发送给处理板标识对应的处理板。
其中,如果处理板标识为处理板板号,则可以根据出方向重定向表的数量对所述处理板的数量取模,根据取模后的结果确定每个出方向重定向表中的处理板板号,或者按照例如随机分配等其他方式,确定每个出方向重定向表中的处理板标识,以尽可能地将所有出方向SA对应的IPSec处理平均分配给所有处理板。
但是,由于例如会话等数据流为双向数据流,因此,为了避免在处理IPSec隧道承载会话双向数据流时存在的状态同步复杂、系统带宽消耗量大等问题出现,本实施例中,较佳地,将相互关联的入方向SA和出方向SA对应的IPSec处理分配给一块处理板。
也就是说,可以先根据入方向SA的SA信息建立入方向重定向表,再将该入方向重定向表中的处理板标识作为对应的出方向重定向表中的处理板标识,其中,该出方向重定向表对应的出方向SA,与对应的入方向重定向表对应的入方向SA相关联。
这样,在后续通过接口单元接收到出方向报文后,从出方向报文中获取对应的出方向报文特性,并根据获取的出方向报文特性查找出方向重定向表,获得对应的处理板标识,再将该报文发送给与该处理板标识对应的处理板即可。而且,如果相互关联的入方向SA和出方向SA在入方向重定向表和出方向重定向表中,处理板标识相同,则可以保证将相互关联的入方向SA和出方向SA对应的IPSec处理分配给一块处理板,从而能够解决在处理IPSec隧道承载双向数据流时存在的状态同步复杂、系统带宽消耗量大等问题。
图7为本发明实施例中创建出方向重定向表的示意图。如图7所示,从出方向SA的SA信息中提取出安全索引、隧道本端IP和安全协议类型作为出方向重定向表中的关键字,并将对应的入方向重定向表中的处理板标识作为该出方向重定向表中的处理板标识即可。
图8为本发明实施例中出方向重定向过程的示意图。如图8所示,主控板从接口单元接收到的出方向报文中,提取出安全索引、目的IP和安全协议类型,并将提取出的出方向报文特性作为关键字,查找出方向重定向表,即可确定对应的处理板标识,并将该出方向报文发送给与该处理板标识对应的处理板。
这样,由于入方向重定向表已经保证了同一个入方向SA对应的入方向IPSec处理分配在一块处理板上,因此将入方向重定向表中作为查表结果的处理板标识复制到相应出方向重定向表中,即可保证出方向上同一个出方向SA对应的出方向IPSec处理也分配在该处理板上。
实际应用中,由于出方向SA的SA信息中,也包含了与入方向SA的SA信息中相同的接口索引、ACL规则号、隧道对端IP、SA保护流五元组信息。因此,本实施例中,也可根据不同的负载分担粒度,从出方向SA的SA信息中提取接口索引、ACL规则号、隧道对端IP、SA保护流五元组信息中的一个或多个的任意组合,作为入方向重定向表中的关键字。
可见,上述实施例中可根据所需的负载分担粒度,选择多种方式建立重定向表,并根据建立的重定向表将报文分配给不同业务板进行对应的IPSec处理,从而实现多种IPSec处理的分配方式,进而提高了本发明技术方案的灵活性和通用性。
而且,上述实施例还能够保证相互关联的入方向SA和出方向SA分别对应的入方向重定向表和出方向重定向表中,业务板标识相同,从而保证将相互关联的入方向SA和出方向SA对应的IPSec处理分配给一块业务板,进而能够解决在处理IPSec隧道承载双向数据流时存在的状态同步复杂、系统带宽消耗量大等问题。
以上是分别对本发明实施例中的报文传输安全装置和方法、以及重定向表的建立过程和报文重定向过程的详细说明。下面,结合报文传输过程的实例,对上述技术方案进行整体说明。
图9为本发明实施例中分布式报文传输安全保护过程1的流程图。如图9所示,以入方向IPSec处理的过程为例,本实施例中对于入方向的分布式报文传输安全保护过程包括:
步骤901,主控板通过接口单元1接收到入方向报文。
步骤902,主控板查找转发表,确定该入方向报文对应的出接口为接口单元2。
本步骤中,入方向报文对应的出接口是根据查找转发表得到的接口索引确定的;如果建立的入方向重定向表对应的IPSec处理的分配方式为按照隧道对端IP分配,则查找转发表的结果中除了对应的接口索引之外,进一步包括该入方向报文的下一跳IP。
本步骤中,在确定该入方向报文对应的出接口为接口单元2之后,主控板可根据多种方式判断该入方向报文是否需要进行IPSec处理,如果判断出该入方向报文需要进行IPSec处理才执行步骤903,否则,丢弃报文、或通过其他方法重定向到对应的处理板进行相应的业务处理,并结束本流程。
步骤903,主控板查找已建立并存储的入方向重定向表,如果未得到任何匹配的查表结果,则执行步骤904,如果得到匹配的查表结果,则执行步骤907。
本步骤中,未得到任何匹配的查表结果即为从入方向报文中提取的关键字,与所有已建立的入方向重定向表中的关键字均不匹配。
步骤904,丢弃该入方向报文,并发起IKE协商建立对应的SA。
步骤905,根据建立的对应SA的SA信息建立入方向重定向表和出方向重定向表,并将该SA信息发送给对应的处理板。
本步骤中,可以按照如前所述的任何一种方式建立重定向表。
步骤906,接收到SA信息的处理板保存该SA信息,用于后续的IPSec处理,并结束本流程。
步骤907,将该入方向报文发送给与查找入方向重定向表的结果对应的处理板。
步骤908,接收到入方向报文的处理板利用存储的入方向SA的SA信息,对该入方向报文进行入方向IPSec处理。
步骤909,处理板将入方向IPSec处理后的入方向报文发送给主控板。
步骤910,主控板将入方向IPSec处理后的入方向报文通过接口单元2发送,并结束本流程。
可见,对于入方向的报文传输安全保护,本发明能够将不同入方向SA对应的入方向IPSec处理分配给不同的处理板,且分配给不同处理板的入方向IPSec处理不受接口限制,当在同一个接口上有大量的IPSec隧道存在时,对经过所有IPSec隧道的报文进行的入方向IPSec处理不会只依靠一块接口板,而是分配给不同的处理板来完成,使得多块处理板有效地分担了与多个入方向SA对应的入方向IPSec处理,从而提高了IPSec处理的效率。
图10为本发明实施例中分布式报文传输安全保护过程2的流程图。如图10所示,以出方向IPSec处理的过程为例,本实施例中对于出方向的分布式报文传输安全保护过程包括:
步骤1001,主控板通过接口单元1接收到出方向报文。
步骤1002,主控板提取出方向报文中的出方向报文特性。
本步骤中,主控板在提取出方向报文中的出方向报文特性之前,先判断该出方向报文目的IP是否为隧道本端IP,如果是,则提取出方向报文中的出方向报文特性然后执行步骤1003,否则,直接丢弃报文、或通过其他方法重定向到对应的处理板进行相应的业务处理,并结束本流程。
步骤1003,主控板查找已建立并存储的出方向重定向表,如果未查找到任何匹配的查表结果,则执行步骤1004,如果查找到匹配的查表结果,则执行步骤1007。
本步骤中,未查找到任何匹配的查表结果即为从出方向报文中提取的关键字,与所有已建立的出方向重定向表中的关键字均不匹配。
步骤1004,丢弃该出方向报文,并发起IKE协商建立对应的SA。
步骤1005,根据建立的对应SA的SA信息建立入方向重定向表和出方向重定向表,并将该SA信息发送给对应的处理板。
本步骤中,可以按照如前所述的任何一种方式建立重定向表。
步骤1006,接收到SA信息的处理板保存该SA信息,用于后续的IPSec处理,并结束本流程。
步骤1007,将该出方向报文发送给与查找出方向重定向表的结果对应的处理板。
步骤1008,接收到出方向报文的处理板利用存储的出方向SA的SA信息,对该出方向报文进行出方向IPSec处理。
步骤1009,处理板根据出方向IPSec处理后的报文的目的IP,查找转发表,确定该报文的出接口为接口单元2。
步骤1010,处理板将出方向IPSec处理后的出方向报文发送给主控板,并通知主控板该报文的出接口为接口单元2。
步骤1011,主控板将出方向IPSec处理后的出方向报文通过接口单元2发送,并结束本流程。
可见,对于出方向的报文传输安全保护,本发明能够将不同出方向SA对应的出方向IPSec处理分配给不同的处理板,且分配给不同处理板的出方向IPSec处理不受接口限制,当在同一个接口上有大量的IPSec隧道存在时,对经过所有IPSec隧道的报文进行的出方向IPSec处理不会只依靠一块接口板,而是分配给不同的处理板来完成,使得多块处理板有效地分担了与多个出方向SA对应的出方向IPSec处理,从而提高了IPSec处理的效率。
以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换以及改进等,均应包含在本发明的保护范围之内。
Claims (15)
1、一种报文传输安全保护装置,其特征在于,包括:主控板、与主控板相连的多个接口单元、以及与主控板相连的多个处理板,其中,
所述主控板,针对各接口单元上的互联网安全IPSec隧道建立对应的安全联盟SA,并按照均衡分担的原则将建立SA得到的SA信息发送给各处理板、且同一个SA的SA信息只发送给同一个处理板,处理板存储接收到的SA信息;
所述主控板还根据入方向SA的SA信息建立入方向重定向表、根据出方向SA的SA信息建立出方向重定向表;如果所述主控板通过接口单元接收到的需要进行IPSec处理的报文为入方向报文,则依据查找由对应入方向SA的SA信息建立的入方向重定向表的结果,将该报文发送给存储着与该报文的报文特性所匹配的SA信息的处理板;如果所述主控板通过接口单元接收到的需要进行IPSec处理的报文为出方向报文,则依据查找由对应出方向SA的SA信息建立的出方向重定向表的结果,将该报文发送给存储着与该报文的报文特性匹配的SA信息的处理板;
所述处理板,利用存储的SA信息,对来自主控板的报文进行IPSec处理。
2、如权利要求1所述的装置,其特征在于,
所述入方向重定向表中包括入方向报文特性与处理板标识的映射关系;查找由对应入方向SA的SA信息建立的入方向重定向表的结果为入方向报文特性对应的处理板标识;
其中,所述入方向重定向表中的入方向报文特性是根据入方向SA的SA信息确定的。
3、如权利要求2所述的装置,其特征在于,所述入方向报文特性包括:
根据入方向SA的SA信息中的访问控制列表ACL规则号,从预设ACL表中查找得到的五元组,以及该入方向SA的SA信息中的接口索引;
或者包括:入方向SA的SA信息中的接口索引;
或者包括:入方向SA的SA信息中的隧道对端IP和接口索引;
或者包括:入方向SA信息中的SA保护流五元组和接口索引;
其中,接口索引是根据所述接收到的入方向报文中的目的IP查找预设转发表得到的。
4、如权利要求1所述的装置,其特征在于,
所述出方向重定向表中包括出方向报文特性与处理板标识的映射关系;查找由对应出方向SA的SA信息建立的出方向重定向表的结果为出方向报文特性对应的处理板标识;
所述出方向重定向表中的出方向报文特性,是根据出方向SA的SA信息确定的。
5、如权利要求4所述的装置,其特征在于,
所述出方向的报文特性包括:对应的出方向SA信息中的安全参数索引、隧道本端IP、安全协议类型。
6、如权利要求2至5中任意一项所述的装置,其特征在于,所述处理板标识为处理板板号;
所述入方向重定向表中的处理板板号,是根据所述入方向重定向表的数量对所述处理板的数量取模后的结果确定的;
所述出方向重定向表中的处理板板号,为对应的入方向重定向表中的处理板板号;其中,该出方向重定向表对应的出方向SA,与所述对应的入方向重定向表对应的入方向SA相关联。
7、如权利要求1所述的装置,其特征在于,所述接口单元为所述主控板上的物理接口,或者为独立于所述主控板的功能单元。
8、如权利要求1所述的装置,其特征在于,所述主控板、处理板和接口单元位于同一物理实体内部;
或者,所述主控板、处理板和接口单元中的任意两者分别位于不同物理实体内部。
9、如权利要求1所述的装置,其特征在于,该报文传输安全保护装置为网关。
10、一种报文传输安全保护方法,其特征在于,包括:
主控板针对各接口单元上的互联网安全IPSec隧道建立对应的安全联盟SA,并按照均衡分担的原则将建立SA得到的SA信息发送给各处理板、且同一个SA的SA信息只发送给同一个处理板,处理板存储接收到的SA信息;
主控板根据入方向SA的SA信息建立入方向重定向表、根据出方向SA的SA信息建立出方向重定向表;如果主控板通过接口单元接收到的需要进行IPSec处理的报文为入方向报文,则依据查找由对应入方向SA的SA信息建立的入方向重定向表的结果,将该报文发送给存储着与该报文的报文特性所匹配的SA信息的处理板;如果主控板通过接口单元接收到的需要进行IPSec处理的报文为出方向报文,则依据查找由对应出方向SA的SA信息建立的出方向重定向表的结果,将该报文发送给存储着与该报文的报文特性匹配的SA信息的处理板;
处理板利用其存储的SA信息,对来自主控板的报文进行互联网安全IPSec处理。
11、如权利要求10所述的方法,其特征在于,所述根据入方向SA的SA信息建立入方向重定向表为:根据入方向SA的SA信息确定入方向报文特性,建立入方向报文特性与处理板标识的映射关系;
所述查找由对应入方向SA的SA信息建立的入方向重定向表的结果为入方向报文特性对应的处理板标识。
12、如权利要求11所述的方法,其特征在于,
所述建立入方向报文特性与处理板标识的映射关系为:根据入方向SA的SA信息中的访问控制列表ACL规则号,从预设ACL表中查找得到五元组;建立查找得到的五元组和该入方向SA的SA信息中的接口索引与处理板标识的映射关系;
所述查找由对应入方向SA的SA信息建立的入方向重定向表为:根据接收到的入方向报文中的目的IP查找预设转发表,确定该入方向报文对应的接口索引;根据接收到的入方向报文中的五元组的全部或部分元素,以及该报文对应的接口索引查找所述入方向重定向表;
或者,所述建立入方向报文特性与处理板标识的映射关系为:建立入方向SA的SA信息中的接口索引与处理板标识的映射关系;
所述查找由对应入方向SA的SA信息建立的入方向重定向表为:根据接收到的入方向报文中的目的IP查找预设转发表,确定该入方向报文对应的接口索引;根据该报文对应的接口索引查找所述入方向重定向表;
或者,所述建立入方向报文特性与处理板标识的映射关系为:建立对应的入方向SA的SA信息中的隧道对端IP和接口索引与处理板标识的映射关系;
所述查找由对应入方向SA的SA信息建立的入方向重定向表为:根据接收到的入方向报文中的目的IP查找预设转发表,确定该入方向报文对应的接口索引和隧道对端IP;根据该报文对应的接口索引和隧道对端IP查找所述入方向重定向表;
或者,所述建立入方向报文特性与处理板标识的映射关系为:建立入方向SA信息中的SA保护流五元组和接口索引,与处理板标识的映射关系;
所述查找由对应入方向SA的SA信息建立的入方向重定向表为:根据接收到的入方向报文中的目的IP查找预设转发表,确定该入方向报文对应的接口索引;根据接收到的入方向报文中的五元组的全部或部分元素,以及该报文对应的接口索引查找所述入方向重定向表。
13、如权利要求10所述的方法,其特征在于,
所述根据出方向SA的SA信息建立出方向重定向表为:根据出方向SA的SA信息确定出方向报文特性,建立出方向报文特性与处理板标识的映射关系;
所述查找由对应出方向SA的SA信息建立的出方向重定向表的结果为出方向报文特性对应的处理板标识。
14、如权利要求13所述的方法,其特征在于,
所述建立出方向报文特性与处理板标识的映射关系为:建立对应的出方向SA信息中的安全参数索引、隧道本端IP、安全协议类型与处理板标识的映射关系;
所述查找由对应出方向SA的SA信息建立的出方向重定向表为:据接收到的出方向报文中的安全参数索引、隧道本端IP、安全协议类型,查找出方向重定向表。
15、如权利要求11至14中任意一项所述的方法,其特征在于,所述处理板标识为处理板板号;
所述入方向重定向表中的处理板板号,是根据所述入方向重定向表的数量对所述处理板的数量取模后的结果确定的;
所述出方向重定向表中的处理板板号,为对应的入方向重定向表中的处理板板号;其中,该出方向重定向表对应的出方向SA,与所述对应的入方向重定向表对应的入方向SA相关联。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200710120365A CN100596062C (zh) | 2007-08-16 | 2007-08-16 | 分布式报文传输安全保护装置和方法 |
PCT/CN2008/071723 WO2009021428A1 (fr) | 2007-08-16 | 2008-07-22 | Dispositif de protection sécurisé et procédé permettant le transfert de messages |
US12/672,178 US8392701B2 (en) | 2007-08-16 | 2008-07-22 | Method and apparatus for ensuring packet transmission security |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200710120365A CN100596062C (zh) | 2007-08-16 | 2007-08-16 | 分布式报文传输安全保护装置和方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101106450A CN101106450A (zh) | 2008-01-16 |
CN100596062C true CN100596062C (zh) | 2010-03-24 |
Family
ID=39000155
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200710120365A Active CN100596062C (zh) | 2007-08-16 | 2007-08-16 | 分布式报文传输安全保护装置和方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US8392701B2 (zh) |
CN (1) | CN100596062C (zh) |
WO (1) | WO2009021428A1 (zh) |
Families Citing this family (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100596062C (zh) | 2007-08-16 | 2010-03-24 | 杭州华三通信技术有限公司 | 分布式报文传输安全保护装置和方法 |
CN101345689B (zh) * | 2008-09-10 | 2011-07-06 | 成都市华为赛门铁克科技有限公司 | 一种ip安全业务的实现方法、装置和通信设备 |
WO2010020151A1 (zh) | 2008-08-18 | 2010-02-25 | 成都市华为赛门铁克科技有限公司 | 报文处理方法、装置和系统 |
US8468220B2 (en) * | 2009-04-21 | 2013-06-18 | Techguard Security Llc | Methods of structuring data, pre-compiled exception list engines, and network appliances |
US9894093B2 (en) | 2009-04-21 | 2018-02-13 | Bandura, Llc | Structuring data and pre-compiled exception list engines and internet protocol threat prevention |
CN103546497B (zh) * | 2012-07-09 | 2016-12-21 | 杭州华三通信技术有限公司 | 一种分布式防火墙IPSec业务负载分担的方法及装置 |
CN102868629B (zh) * | 2012-08-30 | 2016-01-06 | 汉柏科技有限公司 | 利用ipsec实现负载分担的方法及系统 |
CN102891766B (zh) * | 2012-09-25 | 2015-04-22 | 汉柏科技有限公司 | 一种ipsec状态恢复方法 |
CN102868631B (zh) * | 2012-09-28 | 2016-09-21 | 华为技术有限公司 | 负载分担方法和装置 |
CN102938741B (zh) * | 2012-10-30 | 2015-08-19 | 汉柏科技有限公司 | 通过流量控制ipsec负载分担的方法及系统 |
CN102938740B (zh) * | 2012-10-30 | 2015-06-03 | 汉柏科技有限公司 | 通过用户数控制ipsec负载分担的方法及设备 |
CN102970191B (zh) * | 2012-12-12 | 2018-08-14 | 中兴通讯股份有限公司 | 一种分布式系统中检测协议的实现方法和装置 |
CN103200194A (zh) * | 2013-03-28 | 2013-07-10 | 汉柏科技有限公司 | 一种ipsec隧道加密报文的流程优化装置及方法 |
CN104375479B (zh) * | 2014-09-24 | 2017-12-29 | 惠州市亿能电子有限公司 | 一种可更换从控单元的设备及其主从匹配方法 |
CN104333554B (zh) * | 2014-11-12 | 2018-06-15 | 新华三技术有限公司 | 一种因特网协议安全安全联盟协商方法和装置 |
CN104579939B (zh) * | 2014-12-29 | 2021-02-12 | 网神信息技术(北京)股份有限公司 | 网关的保护方法和装置 |
US10051000B2 (en) * | 2015-07-28 | 2018-08-14 | Citrix Systems, Inc. | Efficient use of IPsec tunnels in multi-path environment |
CN105099364A (zh) * | 2015-07-30 | 2015-11-25 | 北京京东方能源科技有限公司 | 光伏电站远程监控系统 |
CN106533947B (zh) * | 2015-09-11 | 2019-10-08 | 新华三技术有限公司 | 报文处理方法及装置 |
US9912699B1 (en) * | 2015-12-30 | 2018-03-06 | Juniper Networks, Inc. | Selectively applying internet protocol security (IPSEC) encryption based on application layer information |
CN107181605B (zh) * | 2016-03-09 | 2020-06-23 | 阿里巴巴集团控股有限公司 | 报文检测方法及系统、内容提取装置、流量匹配装置 |
CN105763557B (zh) * | 2016-04-07 | 2019-01-22 | 烽火通信科技股份有限公司 | 交换芯片或np与cpu协同完成报文ipsec加密的方法与系统 |
CN107547479A (zh) * | 2016-06-29 | 2018-01-05 | 迈普通信技术股份有限公司 | IPsec的实现方法及装置 |
CN106899606B (zh) * | 2017-03-16 | 2020-02-11 | 新华三技术有限公司 | 一种报文处理方法和装置 |
US20210092103A1 (en) * | 2018-10-02 | 2021-03-25 | Arista Networks, Inc. | In-line encryption of network data |
CN111355698B (zh) * | 2018-12-24 | 2022-05-20 | 中兴通讯股份有限公司 | 一种传输方法、装置、报文发送端和接收端 |
CN109379391B (zh) * | 2018-12-25 | 2021-06-01 | 北京物芯科技有限责任公司 | 一种基于IPSec的通信方法、装置、设备和储存介质 |
CN109600270B (zh) * | 2019-01-25 | 2021-08-06 | 新华三技术有限公司 | 网络设备控制方法及网络设备 |
CN110166373B (zh) * | 2019-05-21 | 2022-12-27 | 优刻得科技股份有限公司 | 源物理机向目的物理机发数据的方法、装置、介质和系统 |
CN114301735B (zh) * | 2021-12-10 | 2023-05-02 | 北京天融信网络安全技术有限公司 | 管控ipsec隧道数据按需分配的方法、系统、终端及存储介质 |
CN114866527B (zh) * | 2022-04-29 | 2023-09-15 | 中国科学院信息工程研究所 | 数据处理方法、装置及系统 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020184487A1 (en) * | 2001-03-23 | 2002-12-05 | Badamo Michael J. | System and method for distributing security processing functions for network applications |
US7159242B2 (en) * | 2002-05-09 | 2007-01-02 | International Business Machines Corporation | Secure IPsec tunnels with a background system accessible via a gateway implementing NAT |
CN100502348C (zh) | 2003-07-23 | 2009-06-17 | 华为技术有限公司 | 网络安全处理装置及其方法 |
CN100463427C (zh) | 2003-10-17 | 2009-02-18 | 中兴通讯股份有限公司 | 实现IPsec标准中不同安全终点的安全联盟嵌套方法 |
TWI271076B (en) | 2004-07-02 | 2007-01-11 | Icp Electronics Inc | Security gateway with SSL protection and method for the same |
CN100512296C (zh) | 2005-11-10 | 2009-07-08 | 华为技术有限公司 | 一种提高安全联盟访问效率的方法 |
CN1984131A (zh) | 2005-12-14 | 2007-06-20 | 北京三星通信技术研究有限公司 | 分布式IPSec处理的方法 |
CN100596062C (zh) | 2007-08-16 | 2010-03-24 | 杭州华三通信技术有限公司 | 分布式报文传输安全保护装置和方法 |
-
2007
- 2007-08-16 CN CN200710120365A patent/CN100596062C/zh active Active
-
2008
- 2008-07-22 US US12/672,178 patent/US8392701B2/en not_active Expired - Fee Related
- 2008-07-22 WO PCT/CN2008/071723 patent/WO2009021428A1/zh active Application Filing
Also Published As
Publication number | Publication date |
---|---|
US8392701B2 (en) | 2013-03-05 |
US20110252228A1 (en) | 2011-10-13 |
CN101106450A (zh) | 2008-01-16 |
WO2009021428A1 (fr) | 2009-02-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100596062C (zh) | 分布式报文传输安全保护装置和方法 | |
JP6651096B1 (ja) | データ処理方法、装置、端末及びアクセスポイントコンピュータ | |
CN105763557B (zh) | 交换芯片或np与cpu协同完成报文ipsec加密的方法与系统 | |
US7735129B2 (en) | Firewall device | |
WO2019128753A1 (zh) | 一种低延迟的量子密钥移动服务方法 | |
JP3599552B2 (ja) | パケットフィルタ装置、認証サーバ、パケットフィルタリング方法及び記憶媒体 | |
WO2011021835A2 (en) | Techniques for providing secure communications among clients with efficient credentials management | |
JP2005509977A5 (zh) | ||
JP2006121510A (ja) | 暗号化通信システム | |
WO2009082889A1 (fr) | Procédé de négociation pour échange de clés internet et dispositif et système associés | |
KR20130098368A (ko) | 공유 비밀 확립 및 분배 | |
WO2020138525A1 (ko) | 사물인터넷 블록체인 환경에서의 디바이스 분산 인증 방법 및 이를 이용한 디바이스 분산 인증 시스템 | |
CN111935213B (zh) | 一种基于分布式的可信认证虚拟组网系统及方法 | |
CN102546428A (zh) | 基于DHCPv6侦听的IPv6报文交换系统及方法 | |
CN102761494A (zh) | 一种ike协商处理方法及装置 | |
EP3529950A1 (en) | Method for managing data traffic within a network | |
CN101442470B (zh) | 一种建立隧道的方法、系统和设备 | |
CN102437966A (zh) | 基于二层dhcp snooping三层交换系统及方法 | |
CN106533894A (zh) | 一种全新的安全的即时通信体系 | |
CN101471839A (zh) | 多核异步实现IPSec vpn的方法 | |
CN110166410B (zh) | 一种安全传输数据的方法、终端及多模通信终端 | |
CN106161340B (zh) | 业务分流方法和系统 | |
CN201252570Y (zh) | 一种安全网关客户端装置 | |
CN100499649C (zh) | 一种实现安全联盟备份和切换的方法 | |
CN109450849B (zh) | 一种基于区块链的云服务器组网方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Patentee before: Huasan Communication Technology Co., Ltd. |
|
CP03 | Change of name, title or address |