[go: up one dir, main page]

CN115473660A - 网络传输层数据处理方法、设备及存储介质 - Google Patents

网络传输层数据处理方法、设备及存储介质 Download PDF

Info

Publication number
CN115473660A
CN115473660A CN202110655627.0A CN202110655627A CN115473660A CN 115473660 A CN115473660 A CN 115473660A CN 202110655627 A CN202110655627 A CN 202110655627A CN 115473660 A CN115473660 A CN 115473660A
Authority
CN
China
Prior art keywords
transport layer
layer data
network transport
kernel
ebpf
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.)
Pending
Application number
CN202110655627.0A
Other languages
English (en)
Inventor
郭天
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN202110655627.0A priority Critical patent/CN115473660A/zh
Priority to EP22819245.6A priority patent/EP4354285A4/en
Priority to PCT/CN2022/090383 priority patent/WO2022257643A1/zh
Priority to US18/568,817 priority patent/US20240275816A1/en
Priority to JP2023575990A priority patent/JP7651733B2/ja
Publication of CN115473660A publication Critical patent/CN115473660A/zh
Pending legal-status Critical Current

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/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
    • 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/166—Implementing security features at a particular protocol layer at the transport layer
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/62—Uninstallation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/18—Protocol analysers
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • 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/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例涉及通信领域，公开了一种网络传输层数据处理方法、设备及存储介质，解决了传统的网络传输层加密处理方法对系统环境或上层应用不透明所带来的额外的部署、配置、运维、开发负担，以及风险的技术问题。本申请中，网络传输层数据处理方法应用于运行在内核的扩展伯克利包过滤器eBPF程序，包括：获取需要分发的网络传输层数据包；对所述网络传输层数据包进行解析，确定需要对所述网络传输层数据包进行的网络传输层数据处理方式；根据所述网络传输层数据处理方式，对所述网络传输层数据包进行处理。

Description

网络传输层数据处理方法、设备及存储介质
技术领域
本申请实施例涉及通信领域，特别涉及一种网络传输层数据处理方法、设备及存储介质。
背景技术
当前，随着日益严峻的网络安全环境，系统间进程的网络传输层通信加密和其他安全保护措施变得越来越重要。Linux作为目前业界主流的商用产品运行系统，提供了多种内置的网络传输层加密协议与相关实现。目前较为常见的网络传输层加密处理方法或机制有：互联网安全协议(Internet Protocol Security，IPSec)和传输层安全协议(TransportLayer Security，TLS)。如图1所示，在实际应用中，IPSec是工作在开发式系统互联通信参考模块(Open SystemInterconnection Reference Model，OSI模型)位于第三层的网络层，通过对IP协议包进行加密和认证来保护所有基于IP协议的通信；而TLS则是工作在OSI模型位于第四层的传输层，一般在一种可靠的传输层协议，如面向连接的传输控制协议(Transmission Control Protocol，TCP)、无连接的用户数据报协议(User DatagramProtocol，UDP)基础上为上层应用提供数据安全和完整性保护，具体是采用客户端-服务器模型的方式，在两个应用程序之间创建一个安全的传输连接/隧道，以防止交互的数据被窃听或篡改。
虽然上述加密处理方法或机制可以实现数据在内核的加密或解密处理，但是基于IPSec协议的方式，在实际应用中需要系统管理员修改系统的网络配置或连接拓扑，如创建新的虚拟网络设备、修改全局路由表等，即对系统运行环境有侵入式的配置需求；而基于TLS协议的方式，在实际应用中需要应用程序主动发起并参与传输连接/隧道的建立过程，相关配置参数和敏感数据，如数字证书等一般也需要应用程序自身来维护，即对经验程序自身有侵入式配置需求。
也就是说，对于传统的网络传输层加密处理方法，其对系统环境或上层应用是不透明的。它们需要系统环境或上层应用改变自身的状态，并参与到实际的加解密流程中。这种不透明带来了额外的部署、配置、运维以及开发的负担，同时也带来了额外的风险，如任何一个错误的配置或实现都可能导致数据保护失效，或是对系统环境造成不利影响，进而影响到其他应用。
发明内容
本申请实施例的目的在于提供一种网络传输层数据处理方法、设备及存储介质，旨在解决上述技术问题。
为解决上述技术问题，本申请的实施例提供了一种网络传输层数据处理方法，应用于运行在内核的扩展伯克利包过滤器eBPF程序，所述网络传输层数据处理方法包括：获取需要分发的网络传输层数据包；对所述网络传输层数据包进行解析，确定需要对所述网络传输层数据包进行的网络传输层数据处理方式；根据所述网络传输层数据处理方式，对所述网络传输层数据包进行处理。
为实现上述目的，本申请实施例还提供了一种网络传输层数据处理方法，包括：应用于运行在用户面的管理程序，所述网络传输层数据处理方法包括：在所述管理程序启动后，监测是否接收到针对运行在内核的eBPF程序的操作指令和/或所述eBPF程序统计的针对网络传输层数据包处理过程中的统计数据；如果接收到针对所述eBPF程序的操作指令，根据所述操作指令对所述eBPF程序进行处理；如果接收到所述eBPF程序统计的针对网络传输层数据包处理过程中的统计数据，对所述统计数据进行处理。
为实现上述目的，本申请实施例还提供了一种网络传输层数据处理设备，包括：运行在用户面的管理程序和运行在内核的eBPF程序，至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述管理程序用于向所在环境的内核加载所述eBPF程序，以使所述eBPF程序运行在所述内核，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的任意一种网络传输层数据处理方法。
为实现上述目的，本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序。所述计算机程序被处理器执行时实现上述所述的任意一种网络传输层数据处理方法。
本申请实施例提出的网络传输层数据处理方法、设备及存储介质，通过在用户面加载并运行能够管理eBPF程序的管理程序，进而利用管理程序预先将eBPF程序注册到内核中，由eBPF程序去拦截需要内核分发，如发送出去的网络传输层数据包、接收的网络传输层数据包，并确定需要分发的网络传输层数据包的网络传输层数据处理方式，最终由eBPF程序根据确定的网络传输层数据处理方式，对当前拦截的网络传输层数据包进行处理。整个网络传输层数据处理过程在改写后的内核中的eBPF程序便可以完成，无需系统环境或上层应用改变自身的状态，并参与到实际的网络传输层数据处理过程中，做到了对系统环境或上层应用的透明化，从而无需额外的部署、配置、运维以及开发成本，也保证了良好的系统环境与上层应用的兼容性。
除此之外，本实施例提供的网络传输层数据处理方案，除了单纯的基于加载在内核中的eBPF程序对网络传输层数据包进行加密或解密处理，还可以设置eBPF程序与上层应用，如运行在用户面的应用程序配合，实现联合加密或解密处理，从能够根据实际业务需求，在尽可能减小对上传应用修改的情况下，联合上层应用的加密/解密方式，进一步提升网络传输层数据包在传输过程中的安全性。
此外，基于eBPF技术自身的安全性和高性能，也保证了本实施例提供的网络传输层数据处理方案的安全性和整体性能。
附图说明
一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定。
图1是传统的IPSec协议、TLS协议与OSI模型的对应关系示意图；
图2是本申请实施例提供的应用于管理程序的网络传输层数据处理方法的流程示意图；
图3是本申请实施例提供的应用于管理程序的网络传输层数据处理方法的又一流程示意图；
图4针对图2或图3所示的网络传输层数据处理方法中涉及的管理程序与eBPF程序之间的交互示意图；
图5是本申请实施例提供的应用于eBPF程序的网络传输层数据处理方法的流程示意图；
图6是本申请实施例提供的应用于eBPF程序的网络传输层数据处理方法的又一流程示意图；
图7是基于本申请实施例提供的网络传输层数据处理方法在节点A和节点B之间实现全透明传输加密的示意图；
图8是基于本申请实施例提供的网络传输层数据处理方法在节点A和节点B之间实现与上层应用程序联合加密的示意图；
图9是本申请实施例提供的网络传输层数据处理设备的结构示意图。
具体实施方式
本申请实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
本申请实施例中术语“多个”是指两个或两个以上，其它量词与之类似。
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。
参见图2，图2是本申请实施例提供的网络传输层数据处理方法的流程图，在本实施例中，该方法主要应用于运行在用户面的管理程序。
如图2所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：
步骤201，在管理程序启动后，监测是否接收到针对运行在内核的eBPF程序的操作指令和/或eBPF程序统计的针对网络传输层数据包处理过程中的统计数据。
需要说明的，本实施例中所说的eBPF程序(extended Berkeley Packet Filter，扩展伯克利过滤器)其原本的目标是实现一种全新的包过滤器，以取代IPTABLE(一种网络防火墙)，但是后续的演进对其功能进行了扩展。现在eBPF程序本质上是运行在内核里的特殊代码，用户可以在其规定的限制下编写功能代码，这些代码编译成字节码后将加载到内核里一个特殊的虚拟机内执行。因此，为了能够根据实际的业务需求对eBPF程序进行管理，本实施例提供了运行在用户面的管理程序，从而使得用户能够通过管理程序，实现对运行在内核中的eBPF程序的管理。
基于上述论述，为了保证本实施例提供的网络传输层数据处理方法的实现，以及对eBPF程序的管理，管理程序不仅要负责向内核中加载，或者说注册eBPF程序，还提供了用户交互接口。
具体的，上述所说管理程序向内核中加载eBPF程序，具体是将eBPF程序实现相应功能的字节码加载到内核的指定位置，以便当网络传输层数据包需要内核分发，如向外发送，或者接收时，到达内核的网络传输层数据包能够被加载在内核中的eBPF程序拦截，进而由eBPF程序根据对应的功能接口/函数对网络传输层数据包进行相应处理。
相应地，管理程序提供的用户交互接口，具体用于接收用户作出的针对运行在内核中的eBPF程序的操作指令。
进一步地，在一个例子中，管理程序还用于通过用户交互接口将eBPF程序反馈的处理网络传输层数据包过程中产生的统计数据，如成功加密的数量/解密的数量等，和/或eBPF程序的运行状态、当前配置参数等信息反馈给用户，供用户根据eBPF程序的当前运行情况进行后续操作。
通过上述描述可知，管理程序启动后，具体是通过监测用户交互接口来确定当前是否有针对运行在内核的eBPF程序的操作指令，通过监测与内核中运行的eBPF程序交互的接口，如系统调用函数/接口(syscall)来确定是否接收到eBPF程序统计的针对网络传输层数据包处理过程中的统计数据。
相应地，如果监测到接收到了针对运行在内核的eBPF程序的操作指令，则进入步骤202；如果监测到接收到了运行在内核的eBPF程序输出的网络传输层数据包，则进入步骤203。
此外，应当理解的，在一个例子中，管理程序如果接收到运行在内核的eBPF程序反馈的当前状态信息，如解密成功的网络传输层数据包的数量、加密成功的网络传输层数据包的数量，以及eBPF程序当前进行加解密时依据的加解密条件、规则等，管理程序可以根据预先配置的业务需求，对接收到的上述信息进行存储和/或以预设形式展示，还或者通过用户交互接口反馈给用户。
步骤202，根据操作指令对eBPF程序进行处理。
具体的说，在一个例子中，管理程序通过用户交互接口接收到的针对运行在内核中的eBPF程序的操作指令分为如下3种：操作指令为配置信息更新指令，或者eBPF程序替换指令，或者eBPF程序卸载指令。
相应地，针对上述3中不同的操作指令，管理程序对已经运行在内核中的eBPF程序进行的处理也有所差异，具体如下：
(1)在操作指令为配置信息更新指令时，对已经运行在内核中的eBPF程序进行的处理具体为：
首先，从配置信息更新指令中提取需要更新的配置信息。
可理解的，本实施例中所说的配置信息包括加解密条件、加密规则、解密规则中的任意一种或几种。
关于上述所说的加解密条件，具体为预先约定的针对采用哪类网络传输层协议、对应的四元组(源端口号、目的端口号、源IP地址、目的IP地址)的网络传输层数据包需要进行加密处理，或解密处理。
相应地，上述所说的加密规则，至少包括了对需要进行加密处理的网络传输层数据包进行加密处理所采用的具体加密算法。
进一步地，如果规定的加密算法需要用到密钥，则加密规则中还需要包括采用规定的加密算法进行加密所需的密钥。
相应地，上述所述的解密规则，至少包括了对需要进行解密处理的网络传输层数据包进行解密处理所采用的具体解密算法。
进一步地，如果规定的解密算法需要用到密钥，则解密规则中还需要包括采用规定的解密算法进行解密所需的密钥。
此外，应当理解的，加密处理和解密处理通常是成对出现的，因而对于网络传输层数据包的发送方，比如节点A中运行在内核中的eBPF程序关于加密处理的相关配置信息需要与网络传输层数据包的接收方，比如B节点中运行在内核中的eBPF程序关于解密处理的相关配置信息是相互配合的。
然后，根据提取的需要更新的配置信息对已经运行在内核中的eBPF程序对应的配置信息映射表更新。
具体的说，本实施例中所说的配置信息映射表，即eBPF技术中涉及的BPF MAP。在具体应用中，可以针对能够运行在内核中的不同eBPF程序分别设计一个对应的BPF MAP，也可以设计一个全局的BPF MAP，对于所有能够运行在内核中的eBPF程序都统一共用一个BPFMAP。但不论哪种方式，在根据业务需要预先设计BPF MAP时，均需将eBPF程序进行加密、解密等出来所需的参数定义到BPF MAP中。
相应地，基于设计好的BPF MAP，管理程序在对运行在内核中的eBPF程序进行管理时，如配置信息的修改时，只需将需要修改的配置信息更新到该BPF MAP中，eBPF程序被内核激活后，便会主动去BPF MAP中查找需要的配置信息，然后根据查找到的配置信息作出相应操作。
也就是说，BFP MAP实质是内核提供的一种交换机制/通信机制，基于BPF MAP运行在用户面的管理程序和运行在内核的eBPF程序便可以实现交互。
(2)在操作指令为eBPF程序替换指令时，对已经运行在内核中的eBPF程序进行的处理具体为：
首先，从eBPF程序替换指令中提取替换eBPF程序。
然后，将替换eBPF程序注册到内核中，并在替换eBPF程序注册到内核后，卸载内核中运行的eBPF程序。
(3)在操作指令为eBPF程序卸载指令时，对已经运行在内核中的eBPF程序进行的处理具体为：卸载内核中运行的eBPF程序。
步骤203，对统计数据进行处理。
具体的说，在一个例子中，管理程序在接收到eBPF程序提供的对网络传输层数据包进行加密/解密处理时统计的统计数据，如成功加密的数量或成功解密的数量时，对接收到的统计数据进行的处理可以是将统计数据存储到预设存储区域和/或以预设形式展示。
此外，值得一提的是，在实际应用中，管理程序除了在接收到的操作指令是eBPF程序卸载指令，并卸载eBPF程序后会退出当前的消息处理操作，停止执行本实施例提供的网络传输层数据处理方法，其他情况下，如根据配置参数修改指令，或eBPF程序替换指令完成对已经运行在内核中的eBPF程序的处理后，以及对统计数据进行处理后，均会自动进入下一次消息处理。
通过上述描述不难发现，本实施例提供的网络传输层数据处理方法，通过在用户面部署，并启动管理程序，由管理程序向内核中加载能够实现加解密处理的eBPF程序，并监测运行在内核中的eBPF程序的反馈，以及用户作出的操作指令，进而根据监测到的结果，在用户面直接作出相应结果，或者对运行在内核中的eBPF程序进行管理，从而实现对eBPF程序的动态管理。由于整个过程，无需系统环境或上层应用改变自身的状态，并参与到实际的网络传输层数据处理过程中，因此在系统环境、上层应用没有任何变更的情况下，便可以实现网络传输层数据的加解密处理。
此外，由于管理程序直接对运行在内核中eBPF程序进行管理，因此能够在系统环境、上层应用没有感知的情况下，就可以实现对进行加解密处理的eBPF程序的激活、去激活，配置信息的变更等操作，从而能够动态的调整对需要传输的数据，即网络传输层数据包进行加解密处理，使得网络传输层数据处理能够更加满足实际变动的业务需要。
基于此，本实施例提供的网络传输层数据处理方法，真正做到了对系统环境或上层应用的透明化，从而无需额外的部署、配置、运维以及开发成本，也保证了良好的系统环境与上层应用的兼容性。
此外，基于eBPF技术自身的安全性和高性能，也保证了本实施例提供的网络传输层数据处理方案的安全性和整体性能。
此外，在一个例子中，如果不追求绝对的透明，或者是有特殊的数据保护需求，eBPF程序也可以和上层应用配合起来完成对数据的加密或保护。例如，上层应用可以有意发送内容不合法的数据包，如果接收方的环境部署了对应的eBPF程序(同时参数配置正确)，那么在接收方内核看到数据前，eBPF程序可以将不合法的数据修复，然后再交由内核处理，从而让接收方应用能正确读取信息；如果接收方环境没有部署对应的eBPF程序(或者参数配置不正确)，那么接收方内核(以及可能正在监听传输线路的恶意中间人)会认为数据包非法而将其丢弃，从而保护了数据的安全。
对于这种联合加密方式，如果节点，比如节点A是通过上层应用进行加密，则对于仅作为向外发送网络传输层数据包的节点A，在用户面可以不部署管理程序，内核中不加载eBPF程序。
相应地，对于接收节点A通过上层应用加密的网络传输层数据包的节点B，则需要在用户面部署管理程序，在内核中记载eBPF程序，从而配合实现对网络传输层数据包的处理。
参见图3，图3是本申请实施例提供的网络传输层数据处理方法的又一流程图，在本实施例中，该方法主要应用于运行在用户面的管理程序。
在本实施例中，引入了管理程序向内核加载eBPF程序的具体操作，如图3所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：
步骤301，从预设地址读取配置信息。
具体的说，为了保证内核有需要分发的网络传输层数据时，不管是向内，即内核从其他节点接收到的网络传输层数据包，还是向外，即内核需要发送给其他节点的网络传输层数据包，能够在到达内核时，被内核中运行的eBPF程序拦截，并由eBPF程序对拦截的网络传输层数据包进行相应的网络传输层数据处理，如加密处理或解密处理，需要保证内核中已经运行了eBPF程序。因此，在初次执行本实施例提供的网络传输层数据处理方法时，当管理程序被部署到用户面，并启动后，管理程序需要先从预设地址读取配置信息，比如从存储在用户面的某一配置信息文件中读取。
此外，在本实施例中，管理程序从预设地址读取的配置信息同样包括加解密条件、加密规则、解密规则中的任意一种或几种。
步骤302，检查需要注册到内核的eBPF程序和配置信息的完整性。
具体的说，为了保证基于被注册到内核的eBPF程序处理网络传输层数据包的性能、安全性，管理程序在将预先设计好的eBPF程序注册到内核，将读取的配置信息配置到eBPF程序对应的配置信息映射表前，需要先检查eBPF程序和配置信息的完整性。
步骤303，如果eBPF程序和配置信息均完整，将eBPF程序注册到内核中，以使eBPF程序运行在内核。
具体为管理程序向所在环境的内核加载eBPF程序的字节码，并在将eBPF程序加载到内核中，后续通过系统调用函数/接口(syscall)与eBPF程序进行数据交换。
此外，管理程序也向外提供管理和查询接口，如用户交互接口，以便根据外部输入的操作指令，对运行在内核中的eBPF程序进行相应处理。
步骤304，将配置信息配置到eBPF程序对应的配置信息映射表中。
具体的说，本实施例中所说的配置信息映射表，即eBPF技术中涉及到的BPF MAP。在实际应用中，本实施例中提供的eBPF程序与管理程序之间可以通过一个或多个BPF MAP进行配置数据或运行时统计的统计数据的交互。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
步骤305，进入消息处理循环操作。
具体的说，上述所说的进入消息处理循环操作是指预先构建消息队列，在每次监测到有需要处理的消息，如针对eBPF程序的操作指令和/或eBPF程序在BPF MAP中写入针对网络传输层数据包处理过程中统计的统计数据时，先将接收到的需要处理的消息添加到消息队列，然后依次从消息队列读取需要处理信息，根据当前读取的需要处理的信息的具体类型，进入步骤306至步骤309任一步骤，并执行对应的操作。
步骤306，如果接收到针对eBPF程序的配置信息更新指令，从配置信息更新指令中提取需要更新的配置信息，根据提取的需要更新的配置信息对eBPF程序对应的配置信息映射表更新。
步骤307，如果接收到针对eBPF程序的eBPF程序替换指令，从eBPF程序替换指令中提取替换eBPF程序，将替换eBPF程序注册到内核中，并在替换eBPF程序注册到内核后，卸载内核中运行的所述eBPF程序。
步骤308，如果接收到针对eBPF程序的eBPF程序卸载指令，卸载内核中运行的所述eBPF程序。
步骤309，如果eBPF程序统计的针对网络传输层数据包处理过程中的统计数据，将将统计数据存储到预设存储区域和/或以预设形式展示。
不难发现，本实施例中的步骤306至步骤307与图2所示的实施例中步骤202和步骤203给出的几种具体处理方式大致相同，在此就不再赘述。
此外，关于本实施例中所涉及的管理程序、需要读取的配置信息、eBPF程序以及外部输入之间的交互，具体如图4所示，此处不再赘述。
由此，本实施例提供的网络传输层数据处理方法，在进行网络传输层数据处理之前，利用运行在用户面的管理程序向内核加载eBPF程序，并对eBPF程序进行配置管理，如将eBPF程序进行加解密处理时用到的配置信息配置到配置信息映射表，从而在有需要内核分发的网络传输层数据包时，能够由eBPF程序进行相应的加密处理、解密处理。
参见图5，图5是本申请实施例提供的网络传输层数据处理方法的流程图，在本实施例中，该方法主要应用于运行在内核的eBPF程序。
需要说明的，本实施例所说的网络传输层数据处理方法，具体是指运行在内核的eBPF程序对内核需要分发的网络传输层数据包的加密处理或解密处理。
如图5所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：
步骤501，获取需要分发的网络传输层数据包。
可理解的，本实施例中所说的需要分发的网络传输层数据包具体是指需要内核向本节点的上层应用，如运行在用户面上的应用程序分发接收到的网络传输层数据包，即需要分发的网络传输层数据包来自其他节点。
此外，在一个例子中，需要分发的网络传输层数据包还可以是由内核向其他节点分发，即需要分发的网络传输层数据包是需要内核向其他节点发送的。
此外，值得一提的是，在实际应用中，加载到内核中的eBPF程序，并非一直处于运行状态，或者说激活状态，只有在有需要分发的网络传输层数据包到达内核时，才会由内核触发，进而去执行本实施例中提供的网络传输层数据处理方法。
相应地，上述获取到的需要分发的网络传输层数据包，实质是在内核触发eBPF程序后，传输给eBPF程序的。
步骤502，对网络传输层数据包进行解析，确定需要对网络传输层数据包进行的网络传输层数据处理方式。
具体的说，通常情况下网络传输层数据包的协议头中会携带传输该网络传输层数据包所采用的的协议、四元组等信息，因此在确定需要对网络传输层数据包进行的网络传输层数据处理方式时，通过对网络传输层数据包进行解析，进而提取网络传输层数据包的协议头，然后根据协议头和预先配置的加解密条件，判断该网络传输层数据包是否需要加密或解密。
相应地，如果通过判断确定网络传输层数据包需要进行加密，则确定需要对网络传输层数据进行的网络传输层数据处理方式为加密处理方式；如果通过判断确定网络传输层数据包需要进行解密，则确定需要对网络传输层数据进行的网络传输层数据处理方式为解密处理。
需要说明的是，本实施例中所说的加解密条件具体是由运行在用户面的管理程序提供的。在实际应用中，加解密条件可以是预先规定的好的针对哪些协议传输的网络传输层数据包进行加密或解密。
进一步，加解密条件还可以是规定针对某一具体端口号(源端口号和/或目的端口号)、某一具体IP地址(源IP地址和/或目的IP地址)。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，需要说明的，在实际应用中，在确定需要对网络传输层数据包进行的网络传输层数据处理方式之前，可以先确定网络传输层数据包是否需要进行网络传输层数据处理，如果不需要则直接交由内核进行后续分发操作，如果需要再确定需要进行的网络传输层数据处理方式。
此外，在本实施例中，对需要分发的网络传输层数据包进行的网络传输层数据处理方式大致分为加密处理和解密处理。而在实际应用中，通常是对需要发送给其他节点的网络传输层数据包才进行加密处理，对从其他节点接收到的网络传输层数据包要进行的是解密处理。基于此，在确定需要对网络传输层数据包进行的网络传输层数据处理方式时，具体可以先确定当前的网络数据是需要发送出去的，还是接收到的。
相应地，如果是接收到的，具体是判断网络传输层数据包是否需要解密；如果是需要发送出的，具体是判断网络传输层数据包是否需要加密。
步骤503，根据网络传输层数据处理方式，对网络传输层数据包进行处理。
具体的说，在确定的网络传输层数据处理方式为加密处理方式时，对网络传输层数据包进行的处理具体为：
首先，从预先配置的加密规则中选取目标加密规则。
具体的说，上述预先配置的加密规则同样是由运行在用户面的管理程序提供的。具体是由管理程序从预设地址读取包括了加密规则的配置信息，然后将读取到的配置信息配置到eBPF程序对应的配置信息映射表中。故而，上述选取目标加密规则的操作，具体是从配置信息映射表中选取适合当前需要进行加密处理的网络传输层数据包的加密规则。
需要说明的是，在实际应用中，加密规则至少需要包括具体的加密算法。
进一步地，对于需要涉及密钥的，加密规则还需要包括加密密钥，可以理解为加密参数。
此外，关于如何选取适合当前需要进行加密处理的网络传输层数据包的目标加密规则，在实际应用中可以根据当前需要进行加密处理的网络传输层数据包的协议头的内容确定。
比如，预先规定采用某一协议，或者某一特定端口号，或者某一IP地址对应的具体加密方法和密钥，进而在选取目标加密规则时，更加需要进行加密处理的网络传输层数据包的协议头便可以快速、准确的选取一个适合该网络传输层数据包的加密规则。
此外，值得一提的是，在一个例子中，也可以是所有需要进行加密的网络传输层数据包均采用同一加密规则。
然后，根据目标加密规则，对网络传输层数据包的载荷部分进行加密处理。
接着，根据加密后的载荷部分，更新协议头，得到加密后的网络传输层数据包。
由于进行加密处理之后，加密后的载荷部分的长度通常会与加密前的载荷部分的长度存在差异，因而为了保证加密处理后的网络传输层数据包在传输到其他节点后，不会因为协议头中记录的长度信息和实际接收到的网络传输层数据包的载荷部分的长度不一致，而将加密后的网络传输层数据包误认为非法数据。因此，在根据目标加密规则对网络传输层数据包的载荷部分进行加密处理之后，需要根据加密后的载荷部分更新协议头，进而保证最终得到加密后的网络传输层数据包的协议头记录的信息与加密后的载荷部份的长度一致。
最后，将加密后的网络传输层数据包交由内核，由内核对加密后的网络传输层数据包进行分发。
由此，实现了对需要分发网络传输层数据的加密处理。
相应地，在确定的网络传输层数据处理方式为解密处理方式时，对网络传输层数据包进行的处理方式具体为：首先，从预先配置的解密规则中选取目标解密规则；然后，根据目标解密规则，对网络传输层数据包的载荷部分进行解密处理；接着，根据解密后的载荷部分，更新协议头，得到解密后的网络传输层数据包；最后，将解密后的网络传输层数据包交由内核，由内核对解密后的网络传输层数据包进行分发。
可理解的，为了保证经eBPF程序加密处理后的网络传输层数据包在到达对端节点的内核中，能够运行在对端节点内核中的eBPF程序解密，解密规则需要与加密规则相对应，以保证加密后的网络传输层数据包能够被解密，进而还原出原始的网络传输层数据包。
由此，本实施例提供的网络传输层数据处理方法，通过在用户面加载并运行能够管理eBPF程序的管理程序，进而利用管理程序预先将eBPF程序注册到内核中，由eBPF程序去拦截需要内核分发，如发送出去的网络传输层数据包、接收的网络传输层数据包，并确定需要分发的网络传输层数据包的网络传输层数据处理方式，最终由eBPF程序根据确定的网络传输层数据处理方式，对当前拦截的网络传输层数据包进行处理。整个网络传输层数据处理过程在改写后的内核中的eBPF程序便可以完成，无需系统环境或上层应用改变自身的状态，并参与到实际的网络传输层数据处理过程中，做到了对系统环境或上层应用的透明化，从而无需额外的部署、配置、运维以及开发成本，也保证了良好的系统环境与上层应用的兼容性。
此外，在一个例子中，如果不追求绝对的透明，或者是有特殊的数据保护需求，eBPF程序也可以和上层应用配合起来完成对数据的加密或保护。例如，上层应用可以有意发送内容不合法的数据包，如果接收方的环境部署了对应的eBPF程序(同时参数配置正确)，那么在接收方内核看到数据前，eBPF程序可以将不合法的数据修复，然后再交由内核处理，从而让接收方应用能正确读取信息；如果接收方环境没有部署对应的eBPF程序(或者参数配置不正确)，那么接收方内核(以及可能正在监听传输线路的恶意中间人)会认为数据包非法而将其丢弃，从而保护了数据的安全。
对于这种联合加密方式，如果节点，比如节点A是通过上层应用进行加密，则对于仅作为向外发送网络传输层数据包的节点A，在用户面可以不部署管理程序，内核中不加载eBPF程序。
相应地，对于接收节点A通过上层应用加密的网络传输层数据包的节点B，则需要在用户面部署管理程序，在内核中记载eBPF程序，从而配合实现对网络传输层数据包的处理。
此外，基于eBPF技术自身的安全性和高性能，也保证了本实施例提供的网络传输层数据处理方案的安全性和整体性能。
此外，值得一提的是，由于eBPF程序是由运行在用户面的管理程序加载到内核中的，并且管理程序能够管理eBPF程序。因此，在实际应用中，如果运行在内核中的eBPF程序接收到了用户面的管理程序下发的配置信息更新指令，则根据配置信息更新指令，更新预先配置的配置信息，即配置在配置信息映射表中的配置信息，具体可以是加解密条件、加密规则、解密规则中的任意一种或几种。由此，实现了对运行在内核中的eBPF程序的动态更新，使得运行在内核中的eBPF程序能够更好的适应于实际的网络传输层数据处理需求。
参见图6，图6是本申请实施例提供的网络传输层数据处理方法的流程图，在本实施例中，该方法主要应用于运行在内核的eBPF程序。
如图6所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：
步骤601，获取需要分发的网络传输层数据包。
不难发现，本实施例中的步骤601与图5所示的实施例中的步骤501大致相同，在此就不再赘述。
步骤602，对网络传输层数据包进行解析，确定网络传输层数据包是否需要处理。
具体的说，在实际应用中，需要内核分发的网络传输层数据包并非每一个都需要进行加密或解密处理，比如对于仅仅是相对端节点作出的收到其发送的信息或请求的响应。因此，在确定需要分发的网络传输层数据包的网络传输层数据处理方式前，可以先根据解析出的网络传输层数据包的协议头中携带的标识信息确定当前需要分发的网络传输层数据包是否需要进行加密处理或解密处理。
相应地，如果确定网络传输层数据包需要进行处理，则进入步骤603，确定网络传输层数据包具体需要进行的网络传输层数据处理方式。反之，如果确定网络传输层数据包不需要处理，则直接进入步骤610，即直接将拦截的网络传输层数据包交由内核，由内核对其进行分发即可。
步骤603，确定网络传输层数据包是需要发送的网络传输层数据包，还是接收到的网络传输层数据包。
根据上述论述可知，对于需要进行网络传输层数据处理的网络传输层数据包，在网络传输层数据包是需要由内核发送至其他节点的网络传输层数据包时，需要进行的网络传输层数据处理方式为加密处理方式。
相应地，对于需要进行网络传输层数据处理的网络传输层数据包是需要由内核反馈给上层应用，即位于用户面应用程序，或者说网络传输层数据包是内核从其他节点接收到的网络传输层数据包时，需要进行的网络传输层数据处理方式为解密处理方式。
基于此，只需确定网络传输层数据包是需要发送的网络传输层数据包，还是接收到的网络传输层数据包便可以快速确定需要进行处理的网络传输层数据包的具体处理方式。
相应地，如果确定网络传输层数据包是需要发送的网络传输层数据包，则进入步骤603。反之，如果确定网络传输层数据包是接收到的网络传输层数据包，则进入步骤607。
步骤604，对网络传输层数据包的载荷部分进行加密。
步骤605，更新网络传输层数据包的协议头。
步骤606，将加密后的网络传输层数据包交由内核，由内核对加密后的网络传输层数据包进行分发。
步骤607，对网络传输层数据包的载荷部分进行解密。
步骤608，更新网络传输层数据包的协议头。
步骤609，将解密后的网络传输层数据包交由内核，由内核对解密后的网络传输层数据包进行分发。
步骤610，将网络传输层数据包交由内核，由内核对网络传输层数据包进行分发。
由此，本实施例提供的网络传输层数据处理方法，通过利用eBPF程序，很好地解决了传统网络传输层数据传输加密协议在使用中对系统环境和上层应用带来的侵入影响，提供了更灵活、更强大的数据传输加密与保护功能，同时在安全性上有更好的隔离与保证。
此外，需要说明的是，eBPF技术支持多种程序类型，不同类型的程序适用于不同的用途，而当前比较适合实现传输加密功能的类型是流量控制(Traffic Control，TC)。因此，本实施例中所说的对网络传输层数据包进行加密处理或加密处理的eBPF程序，具体为TC类型的eBPF程序。通过在内核中加载TC类型的eBPF程序能够直接拦截Linux内核对于网络传输层数据包的处理入口和出口，在内核对网络传输层数据包进行接收或发送前，TC程序就可以直接访问到缓存原始的网络传输层数据包的内存缓存区，然后根据原始的网络传输层数据包对应的内存缓存区地址，从内存缓存区获取需要处理的网络传输层数据包，接着对获取到网络传输层数据包进行相应的网络传输层数据处理操作，并在完成相应的网络传输层数据处理操作后，再交由内核，由内核对其进行分发处理。
显然，通过利用TC类型的eBPF程序，就可以将数据加解密的具体实现和配置逻辑集成到一个软硬件单元中，从而在系统环境和上层应用都不了解任何细节的情况下完成网络传输层数据的加解密。再加上eBPF程序和内核一样，都是可以在运行时动态加载/卸载的，因此本实施例提供的网络传输层数据处理方法可以实现运行时的加解密功能激活/去激活，或动态替换加密算法和配置数据，而与此同时操作系统和上层应用对这些行为变更可以一无所知。
此外，需要说明的是，本实施例中采用TC类型的eBPF程序是基于目前eBPF技术的现状而确定的，如果在后续eBPF技术的快速演进中，出现了其他适合的类型，依旧可以实现本实施例实现的方法。即，本实施例中采用TC类型的eBPF程序实现网络传输数据处理，只是一种具体的实现方式，对本实施例提供的技术方案本身并不构成任何限定。
此外，在一个例子中，如果不追求绝对的透明，或者是有特殊的数据保护需求，eBPF程序也可以和上层应用配合起来完成对数据的加密或保护。例如，上层应用可以有意发送内容不合法的数据包，如果接收方的环境部署了对应的eBPF程序(同时参数配置正确)，那么在接收方内核看到数据前，eBPF程序可以将不合法的数据修复，然后再交由内核处理，从而让接收方应用能正确读取信息；如果接收方环境没有部署对应的eBPF程序(或者参数配置不正确)，那么接收方内核(以及可能正在监听传输线路的恶意中间人)会认为数据包非法而将其丢弃，从而保护了数据的安全。
此外，为了更好的理解基于本实施例提供的应用于运行在用户面的管理程序的网络传输层数据处理方法和应用于运行在内核的eBPF程序的网络传输层数据处理，以下结合图7和图8，对基于管理程序和eBPF程序的配合实现的网络传输层数据处理，具体为加密和解密过程进行具体说明。
首先，需要说明的是，在实际应用中，网络传输层数据包的接收方(以下称为数据接收方)和网络传输层数据包的发送方(以下称为数据发送方)必须是都使用Linux系统的，同时内核版本需要大于4.3，且开启了eBPF相关功能。
进一步地，数据通信双方，即数据发送方和数据接收方需要使用标准的网络传输层协议栈，如IP、TCP/UDP通信。
此外，可以理解的，在实际应用中，运行在用户面的管理程序和运行在内核的eBPF程序可以是封装在一个软件包SDK中，以软件形态进行分发与部署的，也可以是封装到一个便携式硬件内，以硬件单元的形态分发与部署的。
此外，当前市面上一些主流厂商的网卡已经支持直接加载并运行eBPF程序。这意味着具体的网络传输层数据处理工作不再依赖操作系统内核完成，而是由网卡内的专用芯片来完成。因此，对于此类设备，eBPF程序可以直接加载到该设备内运行，只需要单独管理需要运行在用户面的管理程序，并建立二者通信即可。
参见图7，图7为节点A和节点B之间实现全透明传输加密的示意图，即位于用户面的应用程序(上层应用)不参与加密、解密，整个传送加密过程，对于节点A和节点B的系统环境、上层应用均是没有感知的。
为了便于后续描述，首先假定上层应用，即应用程序与加密系统(管理程序+eBPF程序)符合如下设定：
上层应用以TCP协议在1080端口与另一个远端的相同应用通信，如图7中的节点A和节点B；节点A和节点B的网络设备均为eth0；eBPF程序的文件名称为eBPF.elf；eBPF程序中负责加密的函数名为encrypt；eBPF程序中负责解密的函数名为decrypt。
对于管理程序，其需要在节点A和节点B上运行，并通过如下命令加载eBPF程序(具体是加载eBPF程序中的加密函数和解密函数)：
加载eBPF程序中的加密函数：tc filter add dev eth0 egress bpf da objeBPF.elf sec encrypt
加载eBPF程序中的解密函数：tc filter add dev eth0 inress bpf da objeBPF.elf sec decrypt
执行完上述两条加载命令后，不论是节点A的内核，还是节点B的内核在向eth0发送网络传输层数据包时(egress)，均会调用之前挂载的eBPF程序中的encrypt函数，并将原始的内核数据缓存(socket kernel buffer，简称skb)指针传递给函数。
对于encrypt函数的处理流程，具体如下：
(1)对skb进行以太网协议分析(解析并剥离ethernet头)。
(2)确定网络传输层数据包的载荷部分是否为IP协议，如果不是，则直接结束处理，即进入步骤(10)。
(3)对载荷部分进行IP协议分析(解析并剥离IP头)，如果IP头的载荷协议指示不为TCP，则直接结束处理，即进入步骤(10)。
(4)对载荷部分进行TCP协议分析(解析并剥离TCP头)，确定目的端口是否为1080，如果不是，则直接结束处理，即进入步骤(10)。
(5)计算IP协议的数据载荷范围(起始指针与结束指针)。
(6)使用流加密算法(Rivest Cipher 4，RC4)对IP协议载荷进行加密。
可理解的，上述给出的仅为一种具体的加密算法，在实际应用中，本领域技术人员可以根据需要选择加密算法，并将选择的加密算法发送至管理程序，由管理程序进行配置。
(7)将加密后的数据写回(可利用内核中的bpf helper函数中的bpf_skb_store_bytes)，并更新IP头(主要是长度与校验码，可以利用bpf helper函数中的bpf_l3_csum_replace)。
(8)调用内核中的bpf helper函数：bpf_skb_adjust_room，更新skb。
(9)结束处理(内核会继续完成更新后数据的发送工作)。
由此，完成了eBPF程序对网络传输层数据包的加密处理。
相应地，在执行加载命令后，不论是节点A的内核，还是节点B的内核从eth0接收到网络传输层数据包时(ingress)，均会调用之前挂载的eBPF程序中的decrypt函数，并将原始数据缓存(sk_buff，简称skb)指针传递给函数。
对于decrypt函数的处理流程，具体如下：
(1)对skb进行以太网协议分析(解析并剥离ethernet头)。
(2)确定载荷部分是否为IP协议，如果不是，则直接结束处理，即进入步骤(9)。
(3)进行IP协议分析(解析并剥离IP头)，如果IP头的载荷协议指示不为TCP，则直接结束处理，即进入步骤(9)。
(4)对载荷部分进行TCP协议分析(解析并剥离TCP头)，如果格式正确，说明数据未加密，直接结束处理，即进入步骤(9)。
(5)使用RC4算法对IP载荷部分进行解密处理。
可理解的，由于上述加密过程是采用的RC4算法，因此解密过程中同样需要采用RC4算法。
(6)对解密后的数据进行TCP协议头检查，如果数据是非法的，比如某个字段的取值不再合法范围内，或目的端口不为1080，则直接结束处理，即进入步骤(9)。
(7)将解密后的数据写回(可利用bpf helper函数:bpf_skb_store_bytes)，并更新IP头(主要是长度与校验码，可以利用bpf helper函数：bpf_l3_csum_replace)。
(8)调用内核中的bpf helper函数：bpf_skb_adjust_room，更新skb。
(9)结束处理(内核会继续完成更新后数据的接收工作)。
由此，完成了eBPF程序对网络传输层数据包的解密处理。
此外，值得一提的是，在实际应用中encrypt函数和decrypt函数还需要执行如下操作：
从指定的配置信息映射表(BPF MAP)中获取管理程序传递的必要参数，如RC4加密算法相关参数、TCP端口号等；将一些运行统计数据记录到指定的BPF MAP中，如加/解密包总数、成功/失败次数等。
此外，值得一提的是，管理程序除了在初始化阶段加载eBPF程序外，还要负责如下工作：通过BPF MAP向encrypt函数和decrypt函数传递必要的参数，如RC4加密算法相关参数、TCP端口号等；通过BPF MAP读取汇总encrypt函数和decrypt函数在运行时记录的统计数据，如加/解密包总数、成功/失败次数等；通过命令行(或其他形式，如Restful等)接口，让用户可以管理查询eBPF程序的运行参数，如四元组信息(端口号、地址等)和运行状态，如成功加密/解密的数量，检测到多少非法或合法的数据等。
通过上述描述可以发现，在全透明传输加密方式下，上层应用并不参与到网络传输层的加解密流程中，因此其完全不知晓底层传输加密系统采用的算法、参数、时机等细节，在发送和接收网络数据时也不考虑加解密，全部以明文格式处理。这样上层应用无需作任何操作或配置修改即可实现网络传输层数据的加解密，而且上层应用对加密流程细节一无所知，即使被攻击者攻陷，其也无法了解实际的加解密流程细节，也无法获取关键的加解密敏感数据，如密钥等，从而既解决了传统不透明的传输加密所带来的额外的部署、配置、运维、开发负担，以及风险的技术问题，又保证了传输的网络传输层数据包中数据内容的安全性。
参见图8，图8为节点A和节点B之间实现与上层应用程序联合加密的示意图，即位于用户面的应用程序参与到了运行在内核的eBPF程序的对需要分发的网络传输层数据包的加密处理或解密处理。
具体的说，在有上层应用参与的合作传输加密方式下，上层应用会与加密系统配合完成传输数据的加解密流程。配合的方法有很多种，如：
方式1：应用程序负责发送数据的加密，对端eBPF程序负责对收到的数据解密。
方式2：应用程序负责对收到的数据解密，对端eBPF程序负责发送数据的加密。
方式3：应用程序负责发送和接收数据的加解密，eBPF程序负责在发送和接收数据时对已加密的数据进行加扰和解扰，即由eBPF程序对上层应用加密或解密后的数据进行二次处理。
需要说明的是，上述不同配合方式的目标只有一个：必须在上层应用和eBPF程序都存在的情况下才能正常完成数据的加解密过程。缺失任何一个环节都会导致数据无法正常解密。这种灵活多样的联合加解密机制虽然损失了部分透明性(上层业务需要参与到加解密过程中来)，但有效提升了数据加密的整体安全度。
关于上述方式3，在实际应用中，与节点A和节点B中均需要部署管理程序和eBPF程序，并eBPF程序均支持encrypt函数和decrypt函数的调用。其大致实现与针对图7的描述类似，只是用户面的应用程序增加了加密和加密操作。
以下结合图8针对上述所说的方式1进行具体说明，其他联合加密方式的思路类似，只是具体实施动作和适用的场景不同。
关于上述所说的方式1，具体为在节点A中，应用程序利用预设的加密算法，如非对称加密算法对需要发送的数据进行加密，在节点B中，在用户面部署管理程序，在内核中加载用于解密的eBPF程序。该方法特别适用于有以下特征或需求的场景：数据发送端的应用完全受控(可修改代码及配置)；数据传输信道不可信且不受控；数据接收端的应用不受控(不可修改代码或配置)；发送端与接收端所在环境的网络配置不能或不便于修改；只要求对发送数据进行加密，对远端发回的响应数据不要求加密。
为了便于后续描述，首先假定上层应用与加密系统符合如下设定：
上层应用以TCP协议在1080端口与另一个远端的相同应用通信，如图8中的节点A和节点B；节点A和节点B的网络设备均为eth0；节点B的用户面运行有管理程序，节点B的内核运行有eBPF程序，该eBPF程序的文件名称为eBPF.elf，且该eBPF程序仅负责解密，负责解密的函数名为decrypt。
对于数据发送端，即图8中的节点A，上层应用使用一种非对称加密算法(如X25519椭圆曲线加密算法或类似的其他算法)，并使用公钥对要发送的TCP载荷数据进行加密，然后再发送。同时，节点A不需要驻留管理程序，也无须加载任何eBPF程序。
对于数据接收端，即图8中的节点B，在用户面需要驻留管理程序，在内核需要驻留eBPF程序，并且对于节点B中的管理程序，需要通过如下命令加载eBPF程序(具体是加载eBPF程序中的解密函数)：加载eBPF程序中的解密函数：tc filter add dev eth0 inressbpf da obj eBPF.elf sec decrypt。
相应地，在执行完上述加载命令后，如节点B的内核从eth0接收到来自节点A发送的网络传输层数据包时(ingress)，会调用之前挂载的eBPF程序中的decrypt函数，并将skb指针传递给函数。
关于decrypt函数的处理流程，具体如下：
(1)对skb进行以太网协议分析(解析并剥离ethernet头)。
(2)确定载荷部分是否为IP协议，如果不是，则直接结束处理，即进入步骤(8)。
(3)进行IP协议分析(解析并剥离IP头)，如果IP头的载荷协议指示不为TCP，则直接结束处理，即进入步骤(8)。
(4)对载荷部分进行TCP协议分析(解析并剥离TCP头)，如果格式非法或目的端口号不等于1080，则直接结束处理，即进入步骤(8)。
(5)使用X25519算法和私钥对TCP载荷部分进行解密处理。
可理解的，上述给出的仅为一种具体的解密算法，在实际应用中，本领域技术人员可以根据需要选择加密算法，并将选择的解密算法发送至管理程序，由管理程序进行配置。
此外，可理解的，eBPF程序进行解密时所依据解密方法，需要与节点A中应用程序采用的加密方法相对应。
(6)将解密后的数据写回(可利用bpf helper函数中的bpf_skb_store_bytes)，并更新TCP与IP头(主要是长度与校验码，可以利用bpf helper函数中的bpf_l3_csum_replace以及bpf_l4_csum_replace)。
(7)调用内核中的bpf helper函数中的bpf_skb_adjust_room，更新skb。
(8)结束处理(内核会继续完成更新后数据的接收工作)。
由此，在节点B中利用内核中的eBPF程序完成了对网络传输层数据包的解密。
此外，值得一提的是，decrypt函数还需要执行以下操作：从指定的BPF MAP中获取管理程序传递的必要参数，如X25519加密算法相关参数、私钥、TCP端口号等；将一些运行统计数据记录到指定的BPF MAP中，如加/解密包总数、成功/失败次数等。
此外，值得一提的是，在实际应用中，运行在节点B的用户面中的管理程序除了在初始化阶段加载eBPF程序外，还要负责如下工作：通过BPF MAP向decrypt函数传递必要的参数，如X25519加密算法相关参数、私钥、TCP端口号等；通过BPF MAP读取汇总decrypt函数在运行时记录的统计数据，如解密包总数、成功/失败次数等；通过命令行(或其他形式，如Restful等)接口，让用户可以管理查询eBPF程序的运行参数和运行状态。
由此，实现了上层应用与eBPF程序的联合加密，在尽可能保证透明化的情况下，进一步提升了传输的数据的安全性。
通过上述描述可知，本实施例提供的网络传输层数据处理方法，能够在系统环境配置与上层应用没有感知的情况下实现网络传输层通信加密，因此具备较低的部署成本和良好的环境与应用兼容性。同时，能够在运行时随时变更加密的算法、参数以及激活开关，上层应用也可以选择与该系统配合以实现自定义的联合加密保护机制，因此具备良好的灵活性和扩展能力。最后，由于基于eBPF技术，该方法在安全性和性能上也有保证。
此外，应当理解的是，上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。
参见图9，图9是本申请实施例提供的网络传输层数据处理设备的结构示意图。
如图9所示，本实施例提供的网络传输层数据处理设备包括：包括至少一个处理器901；以及，与至少一个处理器通信连接的存储器902。
此外，为了能够实现全透明传输加密，或者根据业务需求与上层应用程序联合实现传输加密，网络传输层数据处理设备还包括运行在用户面的管理程序和运行在内核的eBPF程序。
其中，管理程序用于向所在环境的内核加载，或者说注册eBPF程序，以使eBPF程序能够运行在内核中，存储器902存储有可被至少一个处理器901执行的指令，指令被至少一个处理器901执行，以使至少一个处理器901能够执行上述应用于管理程序的方法实施例所描述的网络传输层数据处理方法，或者应用于eBPF程序的方法实施例所描述的网络传输层数据处理方法。
其中，存储器902和处理器901采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器901和存储器902的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器901处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器901。
处理器901负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器902可以被用于存储处理器901在执行操作时所使用的数据。
本申请实施例还涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例所描述的网络传输层数据处理方法。
即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域的普通技术人员可以理解，上述各实施例是实现本申请的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (11)

1.一种网络传输层数据处理方法，其特征在于，应用于运行在内核的扩展伯克利包过滤器eBPF程序，所述网络传输层数据处理方法包括：
获取需要分发的网络传输层数据包；
对所述网络传输层数据包进行解析，确定需要对所述网络传输层数据包进行的网络传输层数据处理方式；
根据所述网络传输层数据处理方式，对所述网络传输层数据包进行处理。
2.如权利要求1所述的网络传输层数据处理方法，其特征在于，所述对所述网络传输层数据包进行解析，确定需要对所述网络传输层数据包进行的网络传输层数据处理方式，包括：
对所述网络传输层数据包进行解析，提取出所述网络传输层数据包的协议头；
根据所述协议头和预先配置的加解密条件，判断所述网络传输层数据包是否需要加密或解密，所述加解密条件由运行在用户面的管理程序提供；
如果所述网络传输层数据包需要进行加密，确定需要对所述网络数据进行的网络传输层数据处理方式为加密处理方式；
如果所述网络传输层数据包需要进行解密，确定需要对所述网络数据进行的网络传输层数据处理方式为解密处理方式。
3.如权利要求2所述的网络传输层数据处理方法，其特征在于，所述网络传输层数据处理方式为所述加密处理方式；
所述根据所述网络传输层数据处理方式，对所述网络传输层数据包进行处理，包括：
从预先配置的加密规则中选取目标加密规则，所述加密规则由所述管理程序提供；
根据所述目标加密规则，对所述网络传输层数据包的载荷部分进行加密处理；
根据加密后的所述载荷部分，更新所述协议头，得到加密后的所述网络传输层数据包；
将加密后的所述网络传输层数据包交由内核，由所述内核对加密后的所述网络传输层数据包进行分发。
4.如权利要求2所述的网络传输层数据处理方法，其特征在于，所述网络传输层数据处理方式为所述解密处理方式；
所述根据所述网络传输层数据处理方式，对所述网络传输层数据包进行处理，包括：
从预先配置的解密规则中选取目标解密规则，所述解密规则由所述管理程序提供；
根据所述目标解密规则，对所述网络传输层数据包的载荷部分进行解密处理；
根据解密后的所述载荷部分，更新所述协议头，得到解密后的所述网络传输层数据包；
将解密后的所述网络传输层数据包交由内核，由所述内核对解密后的所述网络传输层数据包进行分发。
5.如权利要求1至4中任一项所述的网络传输层数据处理方法，其特征在于，所述方法还包括：
接收运行在用户面的管理程序下发的配置信息更新指令；
根据所述配置信息更新指令，更新预先配置的配置信息，所述配置信息包括加解密条件、加密规则、解密规则中的任意一种或几种。
6.一种网络传输层数据处理方法，其特征在于，应用于运行在用户面的管理程序，所述网络传输层数据处理方法包括：
在所述管理程序启动后，监测是否接收到针对运行在内核的eBPF程序的操作指令和/或所述eBPF程序统计的针对网络传输层数据包处理过程中的统计数据；
如果接收到针对所述eBPF程序的操作指令，根据所述操作指令对所述eBPF程序进行处理；
如果接收到所述eBPF程序统计的针对网络传输层数据包处理过程中的统计数据，对所述统计数据进行处理。
7.如权利要求6所述的网络传输层数据处理方法，其特征在于，所述操作指令为配置信息更新指令，或者eBPF程序替换指令，或者eBPF程序卸载指令；
所述如果接收到针对所述eBPF程序的操作指令，根据所述操作指令对所述eBPF程序进行处理，包括：
在所述操作指令为所述配置信息更新指令时，从所述配置信息更新指令中提取需要更新的配置信息，根据提取的所述需要更新的配置信息对所述eBPF程序对应的配置信息映射表更新；
在所述操作指令为所述eBPF程序替换指令时，从所述eBPF程序替换指令中提取替换eBPF程序，将所述替换eBPF程序注册到内核中，并在所述替换eBPF程序注册到所述内核后，卸载所述内核中运行的所述eBPF程序；
在所述操作指令为所述eBPF程序卸载指令时，卸载所述内核中运行的所述eBPF程序。
8.如权利要求6所述的网络传输层数据处理方法，其特征在于，所述如果接收到所述eBPF程序统计的针对网络传输层数据包处理过程中的统计数据，对所述统计数据进行处理，包括：
将所述统计数据存储到预设存储区域和/或以预设形式展示。
9.如权利要求6至8中任一项所述的网络传输层数据处理方法，其特征在于，在所述管理程序启动后，监测是否接收到针对运行在内核的eBPF程序的操作指令和/或所述eBPF程序统计的针对网络传输层数据包处理过程中的统计数据之前，所述方法还包括：
从预设地址读取配置信息，所述配置信息包括加解密条件、加密规则、解密规则中的任意一种或几种；
检查需要注册到内核的所述eBPF程序和所述配置信息的完整性；
如果所述eBPF程序和所述配置信息均完整，将所述eBPF程序注册到内核中，以使所述eBPF程序运行在所述内核；
将所述配置信息配置到所述eBPF程序对应的配置信息映射表中。
10.一种网络传输层数据处理设备，其特征在于，包括：运行在用户面的管理程序和运行在内核的eBPF程序，至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；
其中，所述管理程序用于向所在环境的内核加载所述eBPF程序，以使所述eBPF程序运行在所述内核，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至5任一所述的网络传输层数据处理方法，或者权利要求6至9任一项所述的网络传输层数据处理方法。
11.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的网络传输层数据处理方法，或者权利要求6至9任一项所述的网络传输层数据处理方法。
CN202110655627.0A 2021-06-11 2021-06-11 网络传输层数据处理方法、设备及存储介质 Pending CN115473660A (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN202110655627.0A CN115473660A (zh) 2021-06-11 2021-06-11 网络传输层数据处理方法、设备及存储介质
EP22819245.6A EP4354285A4 (en) 2021-06-11 2022-04-29 Method for processing data of a network transport layer, as well as device and storage medium
PCT/CN2022/090383 WO2022257643A1 (zh) 2021-06-11 2022-04-29 网络传输层数据处理方法、设备及存储介质
US18/568,817 US20240275816A1 (en) 2021-06-11 2022-04-29 Network transport layer data processing method, and device and storage medium
JP2023575990A JP7651733B2 (ja) 2021-06-11 2022-04-29 ネットワークトランスポート層データ処理方法、機器および記憶媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110655627.0A CN115473660A (zh) 2021-06-11 2021-06-11 网络传输层数据处理方法、设备及存储介质

Publications (1)

Publication Number Publication Date
CN115473660A true CN115473660A (zh) 2022-12-13

Family

ID=84365362

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110655627.0A Pending CN115473660A (zh) 2021-06-11 2021-06-11 网络传输层数据处理方法、设备及存储介质

Country Status (5)

Country Link
US (1) US20240275816A1 (zh)
EP (1) EP4354285A4 (zh)
JP (1) JP7651733B2 (zh)
CN (1) CN115473660A (zh)
WO (1) WO2022257643A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116582500A (zh) * 2023-06-28 2023-08-11 建信金融科技有限责任公司 报文传输方法、报文处理方法及其装置
CN118312243A (zh) * 2024-06-07 2024-07-09 芯云晟(杭州)电子科技有限公司 智能网卡的eBPF卸载方法、基于eBPF卸载的可编程RSS方法及装置
CN120378223A (zh) * 2025-06-25 2025-07-25 浪潮电子信息产业股份有限公司 网络通信动态加密方法、加解密系统、设备、介质及产品

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116016702B (zh) * 2022-12-26 2024-09-27 浪潮云信息技术股份公司 一种应用可观测数据采集处理方法、装置及介质
CN116661948A (zh) * 2023-05-31 2023-08-29 昭通亮风台信息科技有限公司 一种基于eBPF的Java虚拟机内存访问方法和系统
CN117544506B (zh) * 2023-11-09 2024-05-24 北京中电汇通科技有限公司 一种基于eBPF技术的容器云DNS性能优化方法
CN117857646B (zh) * 2024-02-28 2024-07-19 荣耀终端有限公司 数据网络共享方法、电子设备及存储介质
US20250286910A1 (en) * 2024-03-05 2025-09-11 Netscout Systems, Inc. Systems and methods for correlating decrypted tls messages with network data in real time
CN119484546A (zh) * 2024-11-11 2025-02-18 浪潮通信信息系统有限公司 基于eBPF程序的knative自动扩容方法及系统

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8458467B2 (en) * 2005-06-21 2013-06-04 Cisco Technology, Inc. Method and apparatus for adaptive application message payload content transformation in a network infrastructure element
US7840712B2 (en) * 2007-05-03 2010-11-23 Harris Corporation Hybrid internet protocol encryptor/decryptor bypass device
JP5032219B2 (ja) 2007-06-29 2012-09-26 株式会社東芝 演算方式を制御して情報を処理する装置、方法およびプログラム
JP4737243B2 (ja) 2008-07-11 2011-07-27 ソニー株式会社 集積回路装置及びデータ伝送システム
WO2018104929A1 (en) * 2016-12-07 2018-06-14 Arilou Information Security Technologies Ltd. System and method for using signal waveform analysis for detecting a change in a wired network
CN110352400B (zh) * 2017-03-08 2021-05-04 华为技术有限公司 用于处理报文的方法和装置
US10868893B2 (en) * 2017-03-31 2020-12-15 Xilinx, Inc. Network interface device
US10623372B2 (en) 2017-12-06 2020-04-14 Nicira, Inc. Load balancing IPsec tunnel processing with extended Berkeley packet filter (eBPF)
US20210058989A1 (en) * 2019-11-06 2021-02-25 Intel Corporation Network coding and delay-efficient integrated access and backhaul network topologies
CN111580931A (zh) * 2020-05-10 2020-08-25 江苏省互联网行业管理服务中心 支持多元协议变量的组合表达式的匹配规则引擎
CN111818041B (zh) * 2020-07-06 2022-06-03 桦蓥(上海)信息科技有限责任公司 一种基于网络层报文解析的实时报文处理系统及方法
CN112817597B (zh) * 2021-01-12 2024-03-15 山东兆物网络技术股份有限公司 运行在用户空间的基于ebpf的软件容器实现方法
CN112860484A (zh) * 2021-01-29 2021-05-28 深信服科技股份有限公司 容器运行时异常行为检测、模型训练方法及相关装置
US11956212B2 (en) * 2021-03-31 2024-04-09 Palo Alto Networks, Inc. IoT device application workload capture

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116582500A (zh) * 2023-06-28 2023-08-11 建信金融科技有限责任公司 报文传输方法、报文处理方法及其装置
CN118312243A (zh) * 2024-06-07 2024-07-09 芯云晟(杭州)电子科技有限公司 智能网卡的eBPF卸载方法、基于eBPF卸载的可编程RSS方法及装置
CN118312243B (zh) * 2024-06-07 2024-09-27 芯云晟(杭州)电子科技有限公司 智能网卡的eBPF卸载方法、基于eBPF卸载的可编程RSS方法及装置
CN120378223A (zh) * 2025-06-25 2025-07-25 浪潮电子信息产业股份有限公司 网络通信动态加密方法、加解密系统、设备、介质及产品
CN120378223B (zh) * 2025-06-25 2025-09-12 浪潮电子信息产业股份有限公司 网络通信动态加密方法、加解密系统、设备、介质及产品

Also Published As

Publication number Publication date
EP4354285A4 (en) 2025-06-04
EP4354285A1 (en) 2024-04-17
US20240275816A1 (en) 2024-08-15
JP2024527477A (ja) 2024-07-25
JP7651733B2 (ja) 2025-03-26
WO2022257643A1 (zh) 2022-12-15

Similar Documents

Publication Publication Date Title
CN115473660A (zh) 网络传输层数据处理方法、设备及存储介质
CN111787025B (zh) 加解密处理方法、装置、系统以及数据保护网关
US10250571B2 (en) Systems and methods for offloading IPSEC processing to an embedded networking device
US20180139191A1 (en) Method, Device, and System for Processing VXLAN Packet
US5898784A (en) Transferring encrypted packets over a public network
US8713305B2 (en) Packet transmission method, apparatus, and network system
EP1917780B8 (en) System and method for processing secure transmissions
US20110119487A1 (en) System and method for encryption rekeying
US12088569B1 (en) Protocol free encrypting device
US8365269B2 (en) Embedded communication terminal
WO1997026735A1 (en) Key management for network communication
CN104935593A (zh) 数据报文的传输方法及装置
CN113055269B (zh) 虚拟专用网络数据的传输方法及装置
WO1997026731A1 (en) Data encryption/decryption for network communication
US7047425B2 (en) Scaleable muti-level security method in object oriented open network systems
CN100426753C (zh) 一种基于snmp的网络管理方法
CN115967511A (zh) 加解密方法、装置及计算机可读存储介质
CN113315787B (zh) 加密保护方法、装置及存储介质
JP2004328563A (ja) 暗号通信装置および暗号通信システム
CN116546532A (zh) 通信测试方法、设备及存储介质
US8181011B1 (en) iSCSI name forwarding technique
CN114978784B (zh) 一种数据保护设备及系统
CN118138227B (zh) 一种远程量子加密传输的边缘安全更新方法及装置
US20240296254A1 (en) Method and system for fpga-based encrypted vpn
CN102148704A (zh) 一种加密型交换机通用网管接口的软件实现方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination