CN105610790A - IPSec加密卡与CPU协同的用户面数据处理方法 - Google Patents
IPSec加密卡与CPU协同的用户面数据处理方法 Download PDFInfo
- Publication number
- CN105610790A CN105610790A CN201510954045.7A CN201510954045A CN105610790A CN 105610790 A CN105610790 A CN 105610790A CN 201510954045 A CN201510954045 A CN 201510954045A CN 105610790 A CN105610790 A CN 105610790A
- Authority
- CN
- China
- Prior art keywords
- cpu
- card
- message
- encrypted
- encrypted card
- 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.)
- Granted
Links
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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0485—Networking architectures for enhanced packet encryption processing, e.g. offloading of IPsec packet processing or efficient security association look-up
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/30—Peripheral units, e.g. input or output ports
- H04L49/3009—Header conversion, routing tables or routing tags
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/30—Peripheral units, e.g. input or output ports
- H04L49/3054—Auto-negotiation, e.g. access control between switch gigabit interface connector [GBIC] and link
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5046—Resolving address allocation conflicts; Testing of addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/12—Setup of transport tunnels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/622—Layer-2 addresses, e.g. medium access control [MAC] addresses
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明提出了一种IPSec加密卡与CPU协同的用户面数据处理方法,设置CPU、IPSec加密卡以及做数据分流的交换芯片;初始化过程中,CPU在交换芯片与加密卡连接的SGMII端口上禁止MAC地址学习,并进行IKE协商配置到加密卡中,配置ACL规则到交换芯片上,在交换芯片与PHY器件相连的接口上过滤IP协议字段为ESP的报文,强制转发到加密卡上;数据往返过程中,加密卡处理报文加解密。本发明技术方案能够在基站用户面加解密数据处理过程中,减少资源消耗、提高性能和通用性。由于实现了协议与数据处理分离,既保障了协议的灵活性,又提高了性能,同时避免CPU和IPSec加密卡的IP/MAC地址冲突。
Description
技术领域
本发明涉及移动通信领域,尤其是涉及为保密而安全的通讯提供一种IPSec加密卡与CPU协同工作的方法。
背景技术
随着无线通信技术的进步,无线网络设备的不断升级改造,对于LTE(3GPP长期演进技术)基站用户面数据处理要求越来越高。另一方面,网络威胁日益严重,LTE基站所承载的用户数据越来越重要,这就要求用户的数据能够经过加密后密文传输。Internet协议安全性(IPSec)是一种开放标准的框架结构,通过使用加密的安全服务以确保在Internet协议(IP)网络上进行保密而安全的通讯。目前通信领域比较成熟的加密方法是采用IPSec标准的加密技术,IPSec标准得到国际上几乎所有主流网络和安全供应商的鼎力支持,并且正在不断丰富完善。LTE基站用户面的数据主要是承载于UDP(用户数据报协议)之上的GTPU(隧道协议)业务,对于GTPU加密报文,传统的处理方式是在LTE控制信道建立完成时,使用开源的IPsec协议(openswan或者strongswan)来与IPSec网关建立一个IPSec隧道,当UE发送数据时,LTE基站先根据LTE协议将用户面数据构造成GTPU报文,GTPU报文再经过加密发送到网络上去。当有数据要发往UE时,LTE基站收到密文信息后,首先进行解密,解密出来的数据再交给LTE协议栈处理。从用户面数据的转发流程来看,涉及到GTPU报文的组装,IPSecIKE协议,用户面数据的加密。
目前可选的LTE数据面加密解决方案有以下几种:
1)纯软件实现:CPU
典型配置:
通用CPU
实现方法
软件实现LTE协议栈
软件实现IPSecIKE协议
软件实现IPSec加解密算法
优点:
低成本
协议扩展性强
问题:
CPU资源耗费大
数据吞吐量小
2)硬件辅助实现:CPU+协处理器
典型配置:
支持Sec协处理器的CPU(例如PowerPCP4080)
实现方法
软件实现LTE协议栈
软件实现IPSecIKE协议
协处理器实现IPSec加解密算法
优点:
低成本
处理灵活
问题:
接口可扩展性受限于PowerPC平台
协处理器的性能受限于PowerPC平台
3)硬件实现:加密卡+CPU
典型配置:
通用CPU,加密卡
实现方法
软件实现LTE协议栈
加密卡实现IPSecIKE协议
加密卡实现IPSec加解密算法
优点:
CPU资源消耗少
数据吞吐量大
问题:
支持IKE协议的加密卡成本高
IKE协议可扩展性受限于加密卡
由于基站设备处在LTE网络的末端节点,从空口上来的单用户数据量理论上能到达到100M,这就要求基站上行到核心网的业务端口至少千兆网口,LTE基站同时做上下行业务时,如果使用CPU进行软件加解密,即达不到千兆流量的加解密性能,又会影响LTE协议的实时处理,因此纯软件实现的方案1不可行,
方案2中,CPU自带IPSec的协处理器的方案,其灵活程度低,且IPSec协处理器的性能与CPU相关,以P4080为例,协处理器的性能为400Mbps,还达不到千兆线速的能力,另外,其协处理器的配置、使用与CPU紧密相关,其通用性不高,因此方案2不可行。
如果选择带专门的加密卡的方案,由于加密卡需要能够与对端的IPSec网关进行IKE协商,需要单独设置一个IP,而基站CPU本身也需要一个对外的IP,但是运营商建网设计中,一个基站只能够配置一个IP地址,所以加密卡和CPU之间会存在IP冲突,且带有IKE功能的加密卡成本高,不适合基站这种部署众多的末端设备,因此方案3不可行。
发明内容
本发明针对现有技术存在的问题,提出了一种基于通用CPU和通用IPSec加密卡的高带宽的数据加解密设计方法,其目的是在LTE基站用户面加密数据处理过程中,解决CPU消耗高,加解密性能低和设计的通用性问题。
本发明的技术方案提供一种IPSec加密卡与CPU协同的用户面数据处理方法,用于LTE基站用户面数据处理,设置CPU、加密卡以及做数据分流的交换芯片,所述加密卡为IPSec加密卡;
CPU通过SMI总线控制交换芯片,通过I2C总线控制和配置加密卡,CPU和加密卡之间通过PCIE接口传递数据,交换芯片与CPU和加密卡之间分别采用SGMII接口传递数据,交换芯片通过RGMII接口连接到PHY器件;
初始化过程包括以下子步骤,
步骤1.1,LTE系统启动时,CPU通过SMI总线控制交换芯片,在交换芯片与加密卡连接的SGMII端口上禁止MAC地址学习,使得加密卡发出来的IP报文,其MAC地址不会被记录到交换芯片中;
步骤1.2,LTE系统获取到IP地址后,CPU通过I2C总线控制加密卡,将CPU上的网口IP地址和MAC地址配置到加密卡的网口上;
步骤1.3,LTE系统与安全网关建立IPSec隧道时,CPU与安全网关进行IKE协商;
步骤1.4,CPU将步骤1.3协商出来的密钥、SA和加解密算法通过I2C总线配置到加密卡中;
步骤1.5,CPU通过SMI总线控制交换芯片,配置ACL规则到交换芯片上,ACL规则包括在交换芯片与PHY器件相连的RGMII接口上过滤IP协议字段为ESP的报文,强制转发到加密卡上;
数据往返过程包括以下子步骤,
步骤2.1,当一个加密的GTPU报文到达基站时,其MAC地址填充的是CPU和加密卡的MAC地址,则在交换芯片上首先查询访问控制列表ACL,如果匹配到是一个ESP的加密报文,会被转发到加密卡上;
步骤2.2,加密卡收到ESP的加密报文后,根据配置的加解密算法和密钥进行解密,然后将解密后的明文放到PCIE指定空间,由PCIE接口发送通知中断doorbell到CPU;
步骤2.3,CPU收到通知中断doorbell后,响应中断,从PCIE指定空间读取解密后的GTPU报文,并送给CPU上的LTE协议栈处理;
步骤2.4,CPU的LTE协议栈发送用户数据到UE,UE回复用户数据到基站后,CPU将回应消息组装成GTPU报文后,判断是需要向核心网发送的加密报文时,就将GTPU明文放到PCIE对应的发送空间上,向加密卡发送通知中断doorbell;
步骤2.5,加密卡收到通知中断doorbell后,从PCIE指定空间读取需要加密的GTPU明文,根据配置的密钥和加解密算法进行加密;
步骤2.6,交换芯片从加密卡相连的端口收到步骤2.5所得加密报文后会查询MAC地址表发往核心网。
而且,在初始化过程之后,数据往返过程之前,进行ARP报文交互,交换芯片收到CPU和加密卡的ARP响应报文时,基于在交换芯片与加密卡连接的SGMII端口上禁止MAC地址学习,只记录CPU相应的MAC地址转发表。
而且,所述交换芯片为QCA8334芯片。
本发明对比传统的加密数据处理技术有以下创新点:
1.CPU处理IPSec的IKE协议,加密卡处理报文加解密,实现了协议与数据处理分离,既保障了协议的灵活性,又提高了性能。
2.利用硬件架构设计避免CPU和IPSec加密卡的IP/MAC地址冲突,解决了基站只能拥有1个IP地址的问题。
3.使用CPU处理IKE协议,降低了对IPSec加密卡的要求,仅只用支持加解密算法,通用性更强。
附图说明
图1为本发明实施例中硬件架构设计的结构图;
图2为本发明实施例中初始化过程流程图;
图3为本发明实施例中交换芯片的MAC地址学习过程。
具体实施方式
本发明主要针对LTE基站用户面加密数据处理的优化,适用但并不限于LTE基站,本方案同样适用于其它在嵌入式系统中CPU和功能芯片之间协同处理数据的设计方法。该方法能满足无线通信基站建设中高速加密数据传输的需求,有效减少CPU资源的占用,本方法充分利用高性能的IPSec加密卡、CPU和加密卡协同工作的硬件架构设计,交换芯片的业务硬件分流等一系列前沿技术,能有效减少CPU资源调度、提升处理性能。
以下结合附图和实施例详细说明本发明技术方案。
本发明实施例提供一种基于Linux系统的LTE基站用户面加解密数据性能优化方法,利用IPSec加密卡处理用户面加解密数据提升性能,利用硬件架构设计避免CPU和IPSec加密卡的IP/MAC地址冲突,利用CPU的开源IKE协议对IPSec加密卡做控制,从而实现数据加解密的控制与数据分离;包括硬件架构设计、初始化过程和LTE用户面数据处理过程三部分内容。
参见图1,本发明实施例的硬件架构设计包括:CPU、IPSec加密卡以及做数据分流的交换芯片(switch)。现有的硬件架构中只会存在CPU(由CPU做软加密),或者只有IPSec加密卡(没有IKE协议处理功能),而本发明打破了这种常规设计,并增加了交互芯片。CPU和IPSec、交换芯片之间分别建立连接,IPSec和交换芯片之间也建立连接。
硬件架构设计中,CPU和IPSec加密卡都通过一个交换芯片连接到外部网络,CPU通过SMI总线控制交换芯片(本实施例中采用高通QCA8334交换芯片),通过I2C总线控制和配置加密卡,CPU和加密卡之间通过PCIE接口传递数据。QCA8334交换芯片与CPU和加密卡之间分别采用SGMII接口传递数据,QCA8334交换芯片通过RGMII接口连接到PHY(物理层)器件,最终从PHY器件经mdi总线输出到整机面板上RJ45口。具体实施时,具体连接可参见相应的接口协议。RGMII是属于mdi总线上的一个通信标准。例如,具体实施时QCA8334交换芯片通过其端口port1连接CPU、通过其端口port6连接加密卡,实现传递数据,通过port0连接PHY器件,实现连接到外部网络。为简化起见,将交换芯片与CPU、加密卡之间传递数据的端口分别记为P2、P3,将交换芯片与PHY器件之间与外部网络传递数据的端口记为P1。
参见图2,初始化过程包括以下子步骤,
步骤1.1,LTE系统启动时,CPU通过SMI总线控制QCA8334交换芯片,在QCA8334交换芯片与加密卡连接的SGMII端口上禁止MAC地址学习。加密卡发出来的IP报文,其MAC地址不会被记录到交换芯片中,其他单播报文查询MAC转发表时,因为加密卡的MAC地址没有记录,因此不会有任何单播报文转发到加密卡。
步骤1.2,LTE系统获取到IP地址后,CPU通过I2C总线控制加密卡,将CPU上的网口IP地址和MAC地址配置到加密卡的网口上。LTE系统获取到IP地址后,因为LTE基站设备对外只能有一个MAC地址和IP地址,而有对外业务需要配置IP地址的包括CPU和加密卡,因此,CPU需要将CPU上的网口IP地址和MAC地址配置到加密卡的网口上,由交换芯片QCA8334来筛选报文是发给CPU还是加密卡。
步骤1.3,LTE系统与安全网关建立IPSec隧道时,CPU与安全网关进行IKE协商,记录协商出来的密钥、SA和加解密算法。LTE系统与安全网关建立IPSec隧道时,CPU上安装开源的IPSec协议(openswan或者strongswan),由开源IPSec协议与安全网关进行IKE协商,协商出来的密钥、SA(安全关联)和加解密算法都会保存到开源协议中,并且如果隧道参数变化,保存的参数也会根据协商结果随之改变。然后CPU按照常规和SGW进行LTE协商。
步骤1.4,CPU将步骤1.3协商出来的密钥、SA和加解密算法通过I2C总线配置到加密卡中,加密卡将会根据配置的密钥、SA和加解密算法对进入的报文进行加解密。CPU将前面协商出来的密钥、SA和加解密算法通过I2C总线配置到加密卡中,这个配置过程是一个动态的过程,如果IPSec隧道撤销,CPU就需要删除加密卡中的配置,如果IPSec隧道更新参数,CPU就需要更新加密卡中的配置。
步骤1.5,CPU通过SMI总线控制交换芯片QCA8334,配置ACL规则到交换芯片QCA8334上,ACL规则信息:在QCA8334与PHY器件相连的RGMII接口上过滤IP协议字段为ESP的报文,强制转发到加密卡上。ESP字段是IP报文格式中表示ipsec报文的格式字段。ACL(AccessControlList,访问控制列表)是路由器和交换机接口的指令列表,用来控制端口进出的数据包。此ACL规则结合步骤1.1中的禁止mac地址学习功能,就能够保证在没有MAC/IP地址冲突的情况下,加密报文会转发到加密卡上,这个加密报文就不会路由转发CPU上。CPU不需要处理加解密而节省了CPU资源。
参见图3,初始化之后,基站和核心网交互LTE数据之前会有ARP报文交互,ARP(AddressResolutionProtocol,地址解析协议),是根据IP地址获取物理地址的一个TCP/IP协议。其交互过程如下:
1.CPU和加密卡都配置相同的MAC地址00:11:22:33:44:55和IP地址1.1.1.1
2.当外面的网元需要与1.1.1.1通信时,首先会从P1端口发送一个ARP请求报文到交换芯片,查询1.1.1.1的MAC地址
3.ARP请求报文是一个广播报文,在QCA8334交换芯片上会被广播到CPU和加密卡上。
4.CPU收到这个ARP请求报文,发现自己就是1.1.1.1,就会将MAC00:11:22:33:44:55封装成ARP响应报文发送回QCA8334交换芯片。加密卡和CPU一样,也会发送同样的ARP响应报文到QCA8334交换芯片。
5.QCA8334交换芯片收到这个ARP响应报文之后,会将MAC地址00:11:22:33:44:55记录到自己的MAC转发表中,但是交换芯片上的P3端口禁止了MAC地址学习功能,而P2端口是允许学习,因此交换芯片上只会记录这样一条MAC地址转发表:发送00:11:22:33:44:55的报文会发送到P2端口。
可见,因为禁止了交换芯片P3端口的mac地址学习能力,虽然加密卡回应了ARP请求,但是在交换芯片上,还是只会记录发往MAC00:11:22:33:44:55的数据包会从P2走。那么对于来自于核心网的非加密报文,就会正常转发到CPU上,而加密报文会被ACL转发到加密卡上。
数据往返过程包括以下子步骤:
步骤2.1,一个加密的GTPU报文到达基站时,其MAC地址填充的是CPU/加密卡的MAC,在QCA8334上首先查询访问控制列表ACL,匹配到是一个ESP的加密报文,会被转发到加密卡上。由于CPU和加密卡拥有同一个IP/MAC地址,从核心网过来的加密GTPU报文到达基站时,在QCA8334上首先查询ACL,IP协议号字段是否是ESP协议,匹配到是一个ESP的加密报文,会被转发到加密卡上。而如果是非加密的LTE控制面消息,就会查询QCA8334上的MAC转发表,发往CPU去处理。
步骤2.2,加密卡收到ESP的加密报文后,根据之前配置好的解密算法、密钥进行解密,然后将解密后的明文放到PCIE的指定空间,由PCIE接口发送通知中断doorbell到CPU,本步骤只完全由加密卡硬件完成,不涉及CPU的处理,也不会消耗CPU资源。
步骤2.3,CPU收到doorbell信号后,响应中断,按照和加密卡约定的PCIE空间地址(即步骤2.2加密卡存放解密后的明文时PCIE的指定空间)读取解密后的GTPU报文,接着报文送给CPU上的LTE协议栈处理。
步骤2.4,CPU的LTE协议栈发送用户数据到UE,UE回复用户数据到基站后,CPU将回应消息组装成GTPU报文后,判断是需要向核心网发送的加密报文时,就将GTPU明文放到PCIE对应的发送空间上,向加密卡发送通知中断doorbell信号。
步骤2.5,加密卡收到doorbell信号后,按照和CPU约定的PCIE空间地址(即步骤2.3CPU存放明文时PCIE对应的发送空间)读取需要加密的GTPU明文,根据之前配置的密钥和加密算法进行加密,因为加密报文只会加密IP字段之后的信息,因此加密卡需要在密文前面组装IP字段以及MAC字段,形成完整的IP报文,而源IP、源MAC、目的IP、目的MAC这些信息都由CPU配置在加密卡中。
步骤2.6,交换芯片QCA8334从加密卡相连的端口(P3端口)收到步骤2.5所得加密报文后会查询MAC地址表发往核心网;并且由于此端口禁止了MAC地址学习功能,因此从P3端口来的源MAC地址并不会被学习到交换芯片中,不会影响发往CPU的非加密报文。从基站外部来看,只会看到CPU,而看不到加密卡。
本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代,但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。
Claims (3)
1.一种IPSec加密卡与CPU协同的用户面数据处理方法,用于LTE基站用户面数据处理,其特征在于:设置CPU、加密卡以及做数据分流的交换芯片,所述加密卡为IPSec加密卡;
CPU通过SMI总线控制交换芯片,通过I2C总线控制和配置加密卡,CPU和加密卡之间通过PCIE接口传递数据,交换芯片与CPU和加密卡之间分别采用SGMII接口传递数据,交换芯片通过RGMII接口连接到PHY器件;
初始化过程包括以下子步骤,
步骤1.1,LTE系统启动时,CPU通过SMI总线控制交换芯片,在交换芯片与加密卡连接的SGMII端口上禁止MAC地址学习,使得加密卡发出来的IP报文,其MAC地址不会被记录到交换芯片中;
步骤1.2,LTE系统获取到IP地址后,CPU通过I2C总线控制加密卡,将CPU上的网口IP地址和MAC地址配置到加密卡的网口上;
步骤1.3,LTE系统与安全网关建立IPSec隧道时,CPU与安全网关进行IKE协商;
步骤1.4,CPU将步骤1.3协商出来的密钥、SA和加解密算法通过I2C总线配置到加密卡中;
步骤1.5,CPU通过SMI总线控制交换芯片,配置ACL规则到交换芯片上,ACL规则包括在交换芯片与PHY器件相连的RGMII接口上过滤IP协议字段为ESP的报文,强制转发到加密卡上;
数据往返过程包括以下子步骤,
步骤2.1,当一个加密的GTPU报文到达基站时,其MAC地址填充的是CPU和加密卡的MAC地址,则在交换芯片上首先查询访问控制列表ACL,如果匹配到是一个ESP的加密报文,会被转发到加密卡上;
步骤2.2,加密卡收到ESP的加密报文后,根据配置的加解密算法和密钥进行解密,然后将解密后的明文放到PCIE指定空间,由PCIE接口发送通知中断doorbell到CPU;
步骤2.3,CPU收到通知中断doorbell后,响应中断,从PCIE指定空间读取解密后的GTPU报文,并送给CPU上的LTE协议栈处理;
步骤2.4,CPU的LTE协议栈发送用户数据到UE,UE回复用户数据到基站后,CPU将回应消息组装成GTPU报文后,判断是需要向核心网发送的加密报文时,就将GTPU明文放到PCIE对应的发送空间上,向加密卡发送通知中断doorbell;
步骤2.5,加密卡收到通知中断doorbell后,从PCIE指定空间读取需要加密的GTPU明文,根据配置的密钥和加解密算法进行加密;
步骤2.6,交换芯片从加密卡相连的端口收到步骤2.5所得加密报文后会查询MAC地址表发往核心网。
2.根据权利要求1所述的IPSec加密卡与CPU协同的用户面数据处理方法,其特征在于:在初始化过程之后,数据往返过程之前,进行ARP报文交互,交换芯片收到CPU和加密卡的ARP响应报文时,基于在交换芯片与加密卡连接的SGMII端口上禁止MAC地址学习,只记录CPU相应的MAC地址转发表。
3.根据权利要求1或2所述的IPSec加密卡与CPU协同的用户面数据处理方法,其特征在于:所述交换芯片为QCA8334芯片。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510954045.7A CN105610790B (zh) | 2015-12-17 | 2015-12-17 | IPSec加密卡与CPU协同的用户面数据处理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510954045.7A CN105610790B (zh) | 2015-12-17 | 2015-12-17 | IPSec加密卡与CPU协同的用户面数据处理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105610790A true CN105610790A (zh) | 2016-05-25 |
CN105610790B CN105610790B (zh) | 2019-01-18 |
Family
ID=55990328
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510954045.7A Active CN105610790B (zh) | 2015-12-17 | 2015-12-17 | IPSec加密卡与CPU协同的用户面数据处理方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105610790B (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107147673A (zh) * | 2017-06-21 | 2017-09-08 | 中国电子信息产业集团有限公司第六研究所 | 基于灵活加密解密卡的远程无线加密通信技术 |
CN107888519A (zh) * | 2017-11-14 | 2018-04-06 | 湖北三江航天红峰控制有限公司 | 一种局域千兆以太网交换机 |
CN108040132A (zh) * | 2017-11-10 | 2018-05-15 | 中国电子科技集团公司第三十二研究所 | RapidIO转万兆网关协议实现的系统 |
CN108924157A (zh) * | 2018-07-25 | 2018-11-30 | 杭州迪普科技股份有限公司 | 一种基于IPSec VPN的报文转发方法及装置 |
CN109639513A (zh) * | 2019-01-29 | 2019-04-16 | 郑州云海信息技术有限公司 | 一种IPSec方案调试装置、方法和系统 |
CN110245526A (zh) * | 2019-05-07 | 2019-09-17 | 杭州电子科技大学 | 一种基于PCIe接口的加密设备和方法 |
CN113438162A (zh) * | 2021-05-21 | 2021-09-24 | 翱捷科技股份有限公司 | 一种二层转发的实现方法及装置 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1492317A (zh) * | 2003-08-27 | 2004-04-28 | 武汉理工大学 | 一种利用DSP处理IPSec安全协议中加/解密的系统 |
CN1878055A (zh) * | 2005-06-07 | 2006-12-13 | 北京握奇数据系统有限公司 | 一种分离式大数据量加/解密设备及实现方法 |
CN101222512A (zh) * | 2008-01-25 | 2008-07-16 | 华为技术有限公司 | 加解密卡及加密方法和解密方法 |
US20100303233A1 (en) * | 2009-05-26 | 2010-12-02 | Fujitsu Limited | Packet transmitting and receiving apparatus and packet transmitting and receiving method |
US20140242975A1 (en) * | 2011-10-06 | 2014-08-28 | Mitsubishi Electric Corporation | Base station device and communication system |
-
2015
- 2015-12-17 CN CN201510954045.7A patent/CN105610790B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1492317A (zh) * | 2003-08-27 | 2004-04-28 | 武汉理工大学 | 一种利用DSP处理IPSec安全协议中加/解密的系统 |
CN1878055A (zh) * | 2005-06-07 | 2006-12-13 | 北京握奇数据系统有限公司 | 一种分离式大数据量加/解密设备及实现方法 |
CN101222512A (zh) * | 2008-01-25 | 2008-07-16 | 华为技术有限公司 | 加解密卡及加密方法和解密方法 |
US20100303233A1 (en) * | 2009-05-26 | 2010-12-02 | Fujitsu Limited | Packet transmitting and receiving apparatus and packet transmitting and receiving method |
US20140242975A1 (en) * | 2011-10-06 | 2014-08-28 | Mitsubishi Electric Corporation | Base station device and communication system |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107147673A (zh) * | 2017-06-21 | 2017-09-08 | 中国电子信息产业集团有限公司第六研究所 | 基于灵活加密解密卡的远程无线加密通信技术 |
CN108040132A (zh) * | 2017-11-10 | 2018-05-15 | 中国电子科技集团公司第三十二研究所 | RapidIO转万兆网关协议实现的系统 |
CN107888519A (zh) * | 2017-11-14 | 2018-04-06 | 湖北三江航天红峰控制有限公司 | 一种局域千兆以太网交换机 |
CN108924157A (zh) * | 2018-07-25 | 2018-11-30 | 杭州迪普科技股份有限公司 | 一种基于IPSec VPN的报文转发方法及装置 |
CN108924157B (zh) * | 2018-07-25 | 2021-04-27 | 杭州迪普科技股份有限公司 | 一种基于IPSec VPN的报文转发方法及装置 |
CN109639513A (zh) * | 2019-01-29 | 2019-04-16 | 郑州云海信息技术有限公司 | 一种IPSec方案调试装置、方法和系统 |
CN110245526A (zh) * | 2019-05-07 | 2019-09-17 | 杭州电子科技大学 | 一种基于PCIe接口的加密设备和方法 |
CN110245526B (zh) * | 2019-05-07 | 2021-04-23 | 杭州电子科技大学 | 一种基于PCIe接口的加密方法 |
CN113438162A (zh) * | 2021-05-21 | 2021-09-24 | 翱捷科技股份有限公司 | 一种二层转发的实现方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN105610790B (zh) | 2019-01-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105610790A (zh) | IPSec加密卡与CPU协同的用户面数据处理方法 | |
US10555171B2 (en) | WiFi protected access 2 (WPA2) pass-through virtualization partition | |
CA2543097C (en) | System and method for grouping multiple vlans into a single 802.11 ip multicast domain | |
US7818796B2 (en) | Bridged cryptographic VLAN | |
US8386772B2 (en) | Method for generating SAK, method for realizing MAC security, and network device | |
US9258282B2 (en) | Simplified mechanism for multi-tenant encrypted virtual networks | |
JP4407452B2 (ja) | サーバ、vpnクライアント、vpnシステム、及びソフトウェア | |
EP2213036B1 (en) | System and method for providing secure network communications | |
US20080198863A1 (en) | Bridged Cryptographic VLAN | |
US20090034431A1 (en) | ENTERPRISE NETWORK ARCHITECTURE FOR IMPLEMENTING A VIRTUAL PRIVATE NETWORK FOR WIRELESS USERS BY MAPPING WIRELESS LANs TO IP TUNNELS | |
US20070121565A1 (en) | Network partitioning using encryption | |
WO2005045642A2 (en) | Secure, standards-based communications across a wide-area network | |
CN106301765B (zh) | 加密和解密芯片及其实现加密和解密的方法 | |
US20140208099A1 (en) | Service plane encryption in ip/mpls networks | |
CN102932377A (zh) | 一种ip报文过滤方法及装置 | |
JP2015181233A (ja) | リンク層セキュリティー伝送をサポートする交換設備およびデータ処理方法 | |
EP3041277A1 (en) | Frame transfer method, related apparatus, and communications system | |
US9106618B2 (en) | Control plane encryption in IP/MPLS networks | |
CN110691074B (zh) | 一种IPv6数据加密方法、IPv6数据解密方法 | |
WO2012126432A2 (zh) | 数据传输的方法、设备和系统 | |
CN100466599C (zh) | 一种专用局域网的安全访问方法及用于该方法的装置 | |
CN104618211A (zh) | 一种基于隧道的报文处理方法和总部网关设备 | |
US11095610B2 (en) | Methods and apparatus for autonomous network segmentation | |
US20240015009A1 (en) | AUTOMATIC IN-BAND MEDIA ACCESS CONTROL SECURITY (MACsec) KEY UPDATE FOR RETIMER DEVICE | |
KR20170119564A (ko) | 레이어2 보안을 위한 MACsec 어댑터 장치 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
CB02 | Change of applicant information | ||
CB02 | Change of applicant information |
Address after: 430074, No. 88, postal academy road, Hongshan District, Hubei, Wuhan Applicant after: Wuhan post and Telecommunications Science Research Institute Co., Ltd. Address before: 430074, No. 88, postal academy road, Hongshan District, Hubei, Wuhan Applicant before: Wuhan Inst. of Post & Telecom Science |
|
GR01 | Patent grant | ||
GR01 | Patent grant |