Anti-replay processing method and device utilizing the same

An anti-replay processing method. The method is utilized in a service function path (SFP) to monitor packet count in the SFP to identify replay attack event, and recognizes a segment of the SFP where the replay attack event occurs as an insecure path. The method further initiates a secure path bypassing the insecure path, labels normal SFC packets with an asserted secure flag, and blocks replayed packets without the asserted secure flag at the exit stage of the secure path.

BACKGROUND

1. Technical Field

The disclosure relates to computer techniques, and more particularly to data packet security using anti-replay protection.

2. Description of Related Art

Network function virtualization (NFV) is becoming a key driver and architecture in many large enterprise networks. Generally, NFV realizes virtualization of certain network functions that would traditionally be implemented as separate network appliances, such as firewalls, accelerators, intrusion detection, load balances and others.

NFV implementations increasingly employ service function chains (SFC) to control which functions or services are applied to network traffic. Service function chaining enables virtualized networking functions to be implemented as part of a cloud network. A service function chain defines an ordered list of a plurality of service functions that may be applied to packet flows in the network. A packet flow enters the network through a classifier node that generates a service function path for that flow according to the service function chain policy. The classifier node encapsulates each packet of the flow with a network service header that indicates the service functions to which the flow will be subjected, and the order the service functions will be applied.

Hacker may eavesdrop and duplicate SFC packets to generate replayed SFC packets. Anti-replay protection may perform replay checks using anti-replay window. Performance of such replay checks using anti-replay window may be subject to window size. For example, decreased anti-replay window size may be more strict in blocking duplicated packets at the expense of discarding valid packets that arrived out of order and with a sequence number outside of the window.

DETAILED DESCRIPTION

The present disclosure provides an anti-replay processing method executable by an electronic device for network function virtualization (NFV) and service function chain (SFC). The method determines that a packet replay event occurs between a first service function forwarder and a second service function forwarder in a service function path based on identified abnormal variation between a first packet count received from the first service function forwarder and a second packet count received from the second service function forwarder. The method further responds to the packet replay event by rescheduling an alternative path between the first and second service function forwarders and discriminating normal packets from replayed packets.

With reference toFIG. 1, a SFC controller100is connected to a SFC classifier200and a SF set110. A classifier is an element that performs classification function. An exemplary definition of classification function may be referred to in Internet Engineering Task Force (IETF) RFC 7665. The SFC classifier200may initiate a service function path (SFP) as an instance of a service function chain (SFC). A SFP is a mechanism used by service chaining to express the result of applying more granular policy and operational constraints to the abstract requirements of a SFC. In the service function set110, a SFC classifier200is connected to service function forwarders (SFFs)310,320, and330. The SFF310is connected to service function (SF)411. The SFF320is connected to SF421. The SFF330is connected to SF431.

The SFC controller100includes an efficient track analyzer (ETA)121and a secure path navigator (SPN)122. The SFC controller100may include an exemplary embodiment of a heterogeneous control/policy point as described in RFC 7665. The ETA121may collect SFP packet count utilizing SFC protocol or software defined network protocol, such as OpenFlow, to determine whether a SFP or a segment of the SFP suffers from replay attacks. Upon detecting a replay attack event in a SFP, the ETA121notifies the SPN122to enable a replay protection process. The SPN122being notified of the replay attack event creates a secure path for packets in the SFP to bypass a segment in the SFP where the replay attack event takes place. The SPN122further differentiates the normal packets in the SFP from replayed packets such as by labeling normal packets in the SFP, and facilitates SFFs to block replayed packets.

With reference toFIG. 2, the ETA121may deploy an efficient track flow (step S10) and a track report flow to the SFFs310,320, and330based on SFC or SDN protocol signaling (step S12). With reference toFIG. 3, the ETA121deploys a SFC packet flow801following an SFP. The SFC packet flow801travels through the SFP including the classifier200, the SFF310, the SF411, the SFF310, the SFF320, the SF421, the SFF320, the SFF330, the SF431, and the SFF330in series and to Internet. According to the track report flow, the SFFs310,320, and330periodically report packet count per session in the SFP to the ETA121(step S14). The ETA121calculates the packet count per session in the SFP (step S16). For example, the ETA121records the packet count per session in a data structure which may be represented in Table 1.

Each session in the SFP is identified by an index. For example, the index of a session may include a combination of a service path identifier (SPI), a service index (SI), and a session identifier (ID). With reference toFIG. 5, a network service header (NSH)80of each packet in flow801includes a field804for recording an SPI and a field805for recording an SI. A field806in the NSH80may include a plurality of fields as shown inFIG. 6. A field807includes a session ID. With reference to Table 1, the ETA121calculates and stores a packet count of the classifier200up to 10000, a packet count of the SFF310up to 10000, a packet count of the SFF320up to 10000, a packet count of the SFF330up to 15000 in a data structure.

The ETA121determines whether any SFP stage has abnormal packet count by determining whether a packet replay count derived from the packet count exceeds a predetermined threshold, such as 1% of throughput of the SFP flow801(step S18). For example, a packet replay count in a SFP stage may be obtained from a packet count of the SFP stage subtracted by a packet count of a previous SFP stage. In a condition where no SFP stage has abnormal packet count, the ETA121repeats step S16. In a condition where at least one SFP stage has abnormal packet count, the ETA121marks an unsecured path involving the at least one SFP stage that has abnormal packet count and triggers the SPN122(step S20).

With reference toFIG. 3, the malicious device501eavesdrops packets811from the packet flow, replays and directs packets812into the flow801in the SFP of SF set110, and causes a replay attack event where the SFF330is associated with an abnormal packet count 15000 as shown in Table 1. The packet replay count in the SFF330is 5000 obtained from subtracting 15000 by 10000, which exceeds 1% of packet count 10000 of the SFF320. The ETA121marks an unsecured path ranging from the SFF320to SFF330and notifies the SPN122of the unsecured path.

When the SPN122is notified of the unsecured path, the SPN122initiates a secure forwarder between two SFFs in the unsecured path (step S22) and deploys secure flag rules to SFFs in the secure path (step S24). With reference toFIG. 4, for example, the SPN122initiates a secure forwarder321between the SFFs320and330in the unsecured path. The SFF321directs traffic of packets of flow801from the SFF321to the SFF330. The SPN122deploys secure flag rules to the SFFs320and330. The SFF320, according to the secure flag rules, labels normal packets in the flow801by asserting a secure flag in the header of the normal packets. With reference toFIG. 6, for example, the SFF320stores a secure flag in a reserved field808in the header of each normal packet in the flow801. In an exemplary embodiment, the SFF320utilizes a bit in the field808to record a binary 1 as the asserted secure flag, and record a binary 0 as an non-asserted state. In an alternative exemplary embodiment of the present disclosure, the SFF321, according to the secure flag rules, may label normal packets in the flow801by asserting a secure flag in the header of the normal packets to differentiate from replayed packets.

The SPN122updates forwarding policy tables in the SFFs to direct normal packets in the flow801to travel through the secure path via the secure service forwarder321(step S26). The SPN122deploys secure flag rules to SFFs in the secure path (step S24). With reference toFIG. 4, the secure path includes the SFFs320,321, and330. The SPN122updates forwarding policy tables in the SFFs320,321, and330to direct normal packets in the flow801to follow the secure path via the secure SFF321(step S26). The SPN122deploys block rules to SFFs in the secure path to block replayed packets (step S28) and alerts an administrator (step S30). For example, the SPN122deploys block rules to SFFs320,321, and330in the secure path. The SFF330, according to the block rules, recognizes and blocks packets without the asserted secure flag as replayed packets. Upon receiving a forwarded packet, the SFF330forwards the forwarded packet to a next stage in a condition that the forwarded packet includes the secure flag, and discards the forwarded packet in a condition that the forwarded packet does not include the secure flag.

By updating forwarding rules in the forwarding policy table in Steps S20-S26, the SPN122provides an indication of an alternative route from the SFF320to the SFF330by replacing an original forwarding rule in the SFF320with a new forwarding rule. The original forwarding rule directs traffic of packets in the flow801from the SFF320to the SFF330through an original route. The new forwarding rule directs traffic of packets in the flow801from the SFF320to the SFF330through the alternative route including the secure service function forwarder321.

With reference toFIG. 7, the method of the present disclosure may be implemented by computer program stored in storage media, such mass storage903in a device900. The computer program implementing the disclosed method when loaded to a memory902by a processor901directs the processor901in the device900to execute the disclosed method. The processor901may communicate with other entities through a networking interface904. Each of the SFC controller, classifiers, SFs, and SFFs inFIG. 1may implemented as an exemplary embodiment of the device900. Alternatively, any combination of the SFC controller, classifiers, SFs, and SFFs inFIG. 1may simultaneously run in one or more virtual machines in the device900or in a plurality of exemplary embodiments of the device900.

The anti-replay processing method monitors packet count in a SFP to identify replay attack event, and recognizes a segment of the SFP where the replay attack event occurs as an insecure path. The method further initiates a secure path bypassing the insecure path, labels normal SFC packets with an asserted secure flag, and blocks replayed packets without the asserted secure flag at the exit stage of the secure path.