WO2018121528A1 - 报文处理 - Google Patents

报文处理 Download PDF

Info

Publication number
WO2018121528A1
WO2018121528A1 PCT/CN2017/118627 CN2017118627W WO2018121528A1 WO 2018121528 A1 WO2018121528 A1 WO 2018121528A1 CN 2017118627 W CN2017118627 W CN 2017118627W WO 2018121528 A1 WO2018121528 A1 WO 2018121528A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
user session
session entry
unlisted
entry
Prior art date
Application number
PCT/CN2017/118627
Other languages
English (en)
French (fr)
Inventor
周英
吴文
晁岳磊
Original Assignee
新华三技术有限公司
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 新华三技术有限公司 filed Critical 新华三技术有限公司
Priority to JP2019534829A priority Critical patent/JP6824417B2/ja
Priority to EP17885544.1A priority patent/EP3547626B1/en
Priority to US16/474,037 priority patent/US10992584B2/en
Publication of WO2018121528A1 publication Critical patent/WO2018121528A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/215—Flow control; Congestion control using token-bucket
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • Portal authentication is a flexible network access control technology.
  • the user name and password of the user are obtained through a web page (Web) page, and the user is authenticated to achieve the purpose of access control.
  • the user host (or the Portal client) can access the external network using HTTP (HyperText Transfer Protocol) or HTTPS (Hyper Text Transfer Protocol over Secure Socket Layer).
  • HTTP HyperText Transfer Protocol
  • HTTPS Hyper Text Transfer Protocol over Secure Socket Layer
  • Internet Internet
  • the user host When using HTTPS to access the Internet, the user host sends an HTTPS message. After receiving the packet, the BRAS (Broadband Remote Access Server) device can determine whether the user has been authenticated. If the portal authentication has not been performed, the BRAS device will spoof the Web server accessed by the user host to establish a TCP (Transmission Control Protocol) connection and an SSL (Secure Socket Layer) connection with the user host. The user host pushes the redirect page so that the user enters a username and password in the redirect page.
  • TCP Transmission Control Protocol
  • SSL Secure Socket Layer
  • the BRAS device can interact with the Portal server.
  • the user is authenticated by using the user name and password entered by the user. After the authentication is passed, the user can go online and the host can access the Internet.
  • FIG. 1 is a flowchart of a message processing method according to an exemplary embodiment of the present disclosure
  • FIG. 2 is a flowchart of a message processing method according to another exemplary embodiment of the present disclosure.
  • FIG. 3 is a schematic diagram of a hardware layer matching an HTTPS message according to an exemplary embodiment of the present disclosure
  • FIG. 4 is a schematic structural diagram of an access gateway device where a packet processing apparatus is located according to an exemplary embodiment of the present disclosure
  • FIG. 5 is a schematic structural diagram of an access gateway device according to an exemplary embodiment of the present disclosure.
  • FIG. 6 is another schematic structural diagram of an access gateway device according to an exemplary embodiment of the present disclosure.
  • first, second, third, etc. may be used in the present disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as second information without departing from the scope of the present disclosure.
  • second information may also be referred to as first information.
  • word "if” as used herein may be interpreted as "when” or “when” or “in response to a determination.”
  • the following embodiments of the present disclosure provide a message processing method, and a message processing apparatus to which the method can be applied.
  • the method of an embodiment of the present disclosure may be performed by an access gateway device such as a BRAS device.
  • the access gateway device receives the HTTPS message sent by the user host; searches for the unlisted user session entry that matches the HTTPS message; and finds the matching unlisted user session entry. If it is determined that the user session corresponding to the online user session entry has not obtained the token, the token is obtained from the first token bucket, wherein the number of tokens in the first token bucket is determined according to the access gateway.
  • the CPU processing capability of the device is set. When the token is successfully obtained, the HTTPS packet is sent to the CPU for processing. When the token is unsuccessful, the HTTPS packet is discarded.
  • the first token bucket is set, and the number of tokens in the first token bucket is set according to the CPU processing capability of the access gateway device, and an unupline user session entry is added to record the unlisted user. Session information. You can limit the number of HTTPS packets sent to the CPU. Only the HTTPS packets of the user session that received the token are sent to the CPU for processing. The HTTPS packets of the user session that have not obtained the token are discarded directly. It is sent to the CPU for processing, which limits the flow of HTTPS packets sent to the CPU. When a large number of users need to go online in a short period of time, the CPU processing load of the access gateway device can be reduced, and the actual CPU load will not exceed the normal processing capability.
  • a first token bucket may be preset, and the number of tokens in the first token bucket is set according to the CPU processing capability of the access gateway device, and the processing capacity of the CPU is larger, and the first token bucket is used. The greater the number of tokens in .
  • the packet processing method performed by the access gateway device includes the following steps:
  • Step S101 Receive an HTTPS message sent by the user host, and find a matching unreached user session entry according to the source IP address and the destination IP address of the HTTPS packet.
  • the user session is identified by the source IP address and the destination IP address, and an unlisted user session entry corresponds to a user session.
  • Step S102 it can be determined whether a matching unlisted user session entry is found, if not, step S103 is performed, and if yes, step S104 is performed;
  • Step S103 the unlisted user session entry including the source IP address and the destination IP address may be configured, and then the process is exited;
  • the unlisted user session entry configured in step S103 can be found in Table 1:
  • the token bucket ID in Table 1 is used to record the ID of the token bucket used to obtain the token.
  • the initial value of the token bucket ID may be 0 or the ID of the first token bucket.
  • the token ID is The ID of the token is used to record the obtained token.
  • the initial value of the token ID may be 0. When the token ID is 0, the user session corresponding to the entry has not yet obtained the token.
  • an acquisition flag may be set in Table 1 to indicate whether the user session corresponding to the entry has acquired the token, and the initial value of the acquisition token may be set to indicate that the corresponding user session has not obtained the token. value.
  • step S104 it can be determined whether the user session corresponding to the online user session entry has obtained the token, if the token has not been obtained, step S105 is performed, and if the token has been acquired, step S109 is performed;
  • the mode 1 or mode 2 may be used to determine whether the user session corresponding to the online user session entry has obtained the token:
  • Manner 2 The obtaining token in the entry determines whether the user session corresponding to the entry has obtained the token.
  • Step S105 obtaining a token from the first token bucket
  • Step S106 it can be determined whether the token acquisition is successful, and if so, step S107 is performed, otherwise, step S108 is performed;
  • the token can be successfully obtained from the first token bucket. Otherwise, if the token does not exist in the first token bucket, the first token cannot be obtained from the first token bucket. The token is obtained in the token bucket.
  • Step S107 the HTTPS message is sent to the CPU for processing, and the token ID in the unlisted user session entry is updated to the ID of the obtained token, and then the process is exited;
  • step S107 if the token bucket ID in the unlisted user session entry is 0, the token bucket ID may be updated to the ID of the first token bucket; if the entry further includes an acquisition token, The acquisition token can then be updated to a value indicating that the corresponding user session has acquired the token.
  • Step S108 the HTTPS packet may be discarded, and then the process is exited;
  • step S109 the HTTPS message can be sent to the CPU for processing, and then the process is exited.
  • the access gateway device processes the HTTPS packets sent by the user host according to the method shown in Figure 1. After the portal authentication is passed, the user is online. The unsuccessful user session entry with the source IP address being the IP address of the user host is deleted. The token obtained by the user session corresponding to the entry is released. The card is recycled to the first token bucket.
  • the corresponding timer may also be started to enable the timer to start timing.
  • the timeout period of the timer reaches the predetermined aging time T, the user still does not go online. If the user session corresponding to the entry has obtained the token, the token needs to be released, and the released token is recycled.
  • the token ID in the entry is set to an initial value, and the timer is restarted to restart the timer.
  • the get tag is included in the entry, the get tag is also updated to a value indicating that the corresponding user session has not yet acquired the token. In this way, the token needs to be reacquired when receiving the HTTPS message corresponding to the user session.
  • the unlisted user session entry may further include an aging time T.
  • a first token bucket and a second token bucket may be preset.
  • the number of tokens in the first token bucket is set according to the CPU processing capability of the access gateway device. The greater the CPU processing capability, the greater the number of tokens in the first token bucket.
  • the number of tokens in the second token bucket is small, which is much smaller than the number of tokens in the first token bucket.
  • the specific number of tokens in the second token bucket can be preset according to actual conditions.
  • the first token bucket is used to limit the number of normal online users, and the second token bucket is used to limit the number of abnormal online users.
  • the packet processing method performed by the access gateway device includes the following steps:
  • Step S201 Receive an HTTPS message sent by the user host, and find a matching undelivered user session entry according to the source IP address and the destination IP address of the HTTPS packet.
  • the user session is identified by the source IP address and the destination IP address, and an unlisted user session entry corresponds to a user session.
  • Step S202 it can be determined whether a matching unlisted user session entry is found, and if not, step S203 is performed, and if yes, step S204 is performed;
  • Step S203 the unlisted user session entry including the source IP address and the destination IP address may be configured, and then the process is exited;
  • the unlisted user session entry configured in step S203 can be found in Table 2:
  • the token bucket ID in Table 2 is used to record the ID of the token bucket used to obtain the token.
  • the initial value of the token bucket ID may be 0 or the ID of the first token bucket.
  • the token ID is used to record the ID of the obtained token.
  • the initial value of the token ID may be 0.
  • the token ID is 0, the user session corresponding to the entry has not obtained the token.
  • the SCount is used to record the number of times the token is successfully acquired. Each time the token is acquired, the value of SCount can be increased by a unit amount. For example, the value of SCount is incremented by 1, and the value of FCount can be set to an initial value; wherein, SCount And the initial value of FCount can be 0;
  • FCount is used to record the number of consecutive failures to obtain a token in the aging time T. Each time the token is failed, the value of FCount can be increased by a unit amount, for example, the value of FCount is increased by one;
  • Aging time T When a non-online user session entry is configured as shown in Table 2, a timer can be started, and the total time duration of the timer is a predetermined aging time T; when the timer time reaches the T, The token obtained by the user session corresponding to the entry is released, the token ID is set to an initial value, and the value of FCount is set to an initial value.
  • an acquisition flag may be set in Table 2 to indicate whether the user session corresponding to the entry has acquired the token, and the initial value of the acquisition token may be set to indicate that the corresponding user session has not obtained the token. value.
  • Step S204 it can be determined whether the user session corresponding to the online user session entry has obtained the token, if the token has not been obtained, step S205 is performed, if the token has been obtained, step S211 is performed;
  • the foregoing method 1 or the foregoing manner 2 may be used to determine whether the user session corresponding to the online session entry of the online user has obtained the token, and details are not described herein.
  • Step S205 it can be determined whether the value of the FCount in the unlined user session entry reaches a predetermined threshold MAX_F, and if so, step S206 is performed, otherwise, step S207 is performed;
  • Step S206 the HTTPS packet may be discarded, and then the process is exited;
  • Step S207 a token can be obtained from the first token bucket
  • Step S208 it can be determined whether the token acquisition is successful, and if so, step S209 is performed, otherwise, step S210 is performed;
  • the token can be successfully obtained from the first token bucket. Otherwise, if the token does not exist in the first token bucket, the first token cannot be obtained from the first token bucket. The token is obtained in the token bucket.
  • Step S209 The HTTPS message is sent to the CPU for processing, and the token ID in the unlisted user session entry is updated to the ID of the acquired token, and the value of SCount is increased by a unit amount, and FCount is The value is set to the initial value and then exits the process.
  • step S209 if the token bucket ID in the unsolicited user session entry is 0, the token bucket ID may be updated to the ID of the first token bucket; if the entry further includes an acquisition token, The acquisition token can then be updated to a value indicating that the corresponding user session has acquired the token.
  • step S210 the HTTPS packet is discarded, and the value of the FCount in the unlisted user session entry is increased by a unit amount, and then the process is exited;
  • step S210 if the token bucket ID in the unlisted user session entry is 0, the token bucket ID may be updated to the ID of the first token bucket.
  • step S211 the HTTPS message can be sent to the CPU for processing, and then the process is exited.
  • the user session corresponding to the entry may be considered as an abnormal online user session.
  • the token bucket for obtaining the token is modified from the first token bucket to the second token bucket.
  • the token bucket ID in the unupline user session entry may be modified to the ID of the second token bucket.
  • the token is acquired from the second token bucket in step S207 as shown in FIG. 2.
  • the entry is deleted, and the token obtained by the user session corresponding to the entry is released.
  • the released token is recycled to the second token bucket, where MAX_S2 is greater than MAX_S1.
  • the user will go online and delete the unsuccessful user session entry whose source IP address is the host IP address IP11, and release the token obtained by the user session corresponding to these entries.
  • the timer may be started to enable the timer to start timing.
  • the timer expires, the user still does not go online. If the user session of the entry has obtained the token, the token is to be released, and the released token is collected into the corresponding token bucket, and the token ID in the entry is set to an initial value. The value of FCount in the entry is set to an initial value, and the timer is restarted to cause the timer to restart timing.
  • the get tag is included in the entry, the get tag is also updated to a value indicating that the corresponding user session has not yet acquired the token. In this way, the subsequent HTTPS message corresponding to the user session needs to reacquire the token.
  • the HTTPS packet sent by the user host will attack the access gateway device.
  • the method shown in FIG. 2 is adopted, by setting a first token bucket for limiting the number of normal online users, and a second token bucket for limiting the number of abnormally unreached user sessions.
  • the number of times the user has obtained the token reaches MAX_S1, the user still does not go online.
  • the user session is considered to be an abnormal online user session.
  • the HTTPS packet of the session is an attack packet.
  • the token can only be obtained from the second token bucket with a small number of tokens, further limiting the traffic of the abnormally unsuccessful user session.
  • a third token bucket may be set.
  • the number of tokens in the third token bucket may be a predetermined percentage of the number of tokens in the first token bucket, for example, 40% of the number of tokens in the first token bucket.
  • the token can be obtained from the first token bucket.
  • the token bucket for acquiring the token can be modified from the first token bucket to the first token bucket.
  • the token bucket used to obtain the token may be modified from the third token bucket to the second token bucket, thereby Get the token in the second token bucket.
  • the message processing method shown in FIG. 2 is described in detail below through a specific example.
  • two token buckets are created on the underlying hardware forwarding layer of the access gateway device, namely, a first token bucket with a token bucket ID of bucket 21 and a second token bucket with a token bucket ID of bucket 22.
  • the number of tokens in the first token bucket is set according to the CPU processing capability of the access gateway device; the number of tokens in the second token bucket is small.
  • the first rule Rule1 is an authentication-free rule.
  • the rule is used to limit the HTTP/HTTPS packets of the IP address of the Portal server or some authentication-free Web servers.
  • the second rule, Rule 2 is used to restrict the redirection of HTTP packets with the destination port number of 80 to the CPU.
  • the third rule Rule3 is used to restrict the redirection of HTTPS packets with the destination port number 443 to the CPU;
  • the fourth rule Rule4 is used to limit the discarding of the packets that miss the above rules Rule1, Rule2, and Rule3.
  • FIG. 3 is a schematic diagram showing the matching order of the respective items on the hardware level, and is not limited.
  • the source IP address of the HTTPS packet is 10.0.0.2
  • the destination IP address is https://100.1.1.2
  • the destination port number is 443.
  • the access gateway device matches the Rule1, the Portal user entry, the Rule2, and the non-lived user session entry respectively, and does not hit, and then continues to match the Rule3, and the result is If the match is matched, the HTTPS packet can be sent to the CPU.
  • the CPU can send an unlisted user session entry as shown in Table 3-1.
  • the matching order of the entry is between Rule2 and Rule3. .
  • the access gateway device After receiving the second HTTPS packet, the access gateway device matches the Rule1, the Portal user entry, and the Rule2, and does not match, and then continues to match the locally saved unsuccessful user session entry. As a result, the entry shown in Table 3-1 is obtained, and the token ID in the entry is 0, and it is determined that the user session corresponding to the entry has not obtained the token, and the token is obtained from the first token bucket bucket21. Token, if the token is successfully obtained, if the ID of the obtained token is 100, the token ID in the entry is updated to 100, the value of SCount is incremented by 1, and the value of FCount is cleared to 0. Matching with Rule3, the HTTPS packet is sent to the CPU for processing according to Rule 3. At this time, Table 3-1 is updated as shown in Table 3-2.
  • the hardware layer matches the Rule1, Portal user entry, and Rule2 after receiving the subsequent HTTPS packet. If no hit occurs, the device continues to talk to the locally saved unlisted user. The entry is matched, and the result is as shown in Table 3-2. According to the token ID in the entry is not 0, it is determined that the user session corresponding to the entry has obtained the token, so it will continue. Matching with Rule3, the HTTPS message is sent to the CPU for processing according to Rule3. The unlisted user session entries as shown in Table 3-2 are not updated at this time.
  • the user After the TCP spoofing process is completed, the user will be authenticated by the portal. After the authentication is passed, the user will go online and the CPU will send the Portal user entry to the hardware level and notify the hardware layer to delete the source IP address as 10.0.0.2. The unsuccessful user session entry, release the token obtained by the user session corresponding to the entry, and reclaim the released token into the token bucket.
  • the hardware layer matches the Rule1, the Portal user entry, and the Rule2 after receiving the subsequent HTTPS packet. If no hit occurs, the session continues to be saved with the locally saved online user. The entry is matched, and the result is as shown in Table 3-3. According to the token ID in the entry, the user session corresponding to the entry has not yet obtained the token. Therefore, the entry is obtained. The token is obtained in a token bucket bucket 21. When the token is successfully acquired, it is assumed that the obtained token has an ID of 100, the token ID in the entry is updated to 100, and the value of SCount is incremented by 1. The value of FCount is cleared to 0, and the matching with Rule3 is continued. The HTTPS packet is sent to the CPU for processing according to Rule 3. At this time, Table 3-3 is updated as shown in Table 3-2. If the token acquisition still fails, the HTTPS packet is discarded, and the value of FCount is incremented by 1. At this time, Table 3-3 is updated as shown in Table 3-4.
  • the timeout period of the timer corresponding to the unsuccessful user session entry reaches T, the token obtained by the user session corresponding to the entry is released, and the released token is recycled to the first token bucket bucket21.
  • the card ID is set to 0, and the value of FCount is cleared to 0, but the value of SCount remains unchanged. Subsequent HTTPS messages need to be reacquired.
  • Case 5 The user has not been online for multiple T times.
  • the user After a plurality of T times, the user has been unable to go online.
  • the value of SCount in the unsuccessful user session entry is always accumulated.
  • the value of SCount reaches MAX_S1, the user session corresponding to the entry can only be restricted.
  • the token is obtained in the second token bucket bucket 22, and the token bucket ID in the undelivered user session entry is modified to bucket 22. Since the number of tokens in the second token bucket 22 is small, the purpose of limiting abnormal users to go online can be achieved.
  • the value of FCount will continue to increase. After receiving the HTTPS packet, if the value of the FCount in the matched online session entry reaches MAX_F, the user session corresponding to the entry is not allowed to obtain the token and the HTTPS packet is discarded. Subsequently, when the timer expires, the value of FCount is cleared to 0, and the user session corresponding to the entry is allowed to acquire the token.
  • the present disclosure also provides an embodiment of a message processing apparatus.
  • Embodiments of the disclosed message processing apparatus can be applied to an access gateway device.
  • the device embodiment may be implemented by software, or may be implemented by hardware or a combination of hardware and software.
  • the access gateway device 40 of the embodiment of the present disclosure includes the following units: a receiving unit 401, a determining unit 402, a processing unit 403, and a searching unit 404, where:
  • the receiving unit 401 is configured to receive an HTTPS packet sent by the user host.
  • the searching unit 404 is configured to: after the receiving unit 401 receives the HTTPS packet, search for an unlisted user session entry that matches the HTTPS packet according to the source IP address and the destination IP address of the HTTPS packet;
  • the determining unit 402 is configured to determine, in the case that the search unit 404 finds an unlisted user session entry, whether the user session corresponding to the online user session entry has obtained the token;
  • the processing unit 403 is configured to obtain a token from the first token bucket if the determining unit 402 determines that the user session corresponding to the unlisted user session entry has not acquired the token.
  • the number of tokens in the first token bucket is set according to the CPU processing capability of the access gateway device.
  • the HTTPS packet is sent to the CPU for processing.
  • the token acquisition fails, Discard the HTTPS packet.
  • the access gateway device 40 further includes a configuration unit 405, where:
  • the configuration unit 405 is configured to: if the search unit 404 does not find the unlisted user session entry that matches the HTTPS packet, configure an unlisted user session entry that includes the source IP address and the destination IP address.
  • the processing unit 403 is further configured to: if the determining unit 402 determines that the user session corresponding to the online user session entry has obtained the token, send the HTTPS message to the CPU for processing.
  • the processing unit 403 is further configured to: when each token is successfully acquired, update the token ID in the unlisted user session entry to the ID of the acquired token;
  • the determining unit 402 is configured to determine whether the user session corresponding to the online session entry of the online user has obtained the token by using the following method: if the token ID in the unconnected user session entry is an initial value, determining that the user is not online The user session corresponding to the session entry has not yet obtained the token. Otherwise, it is determined that the user session corresponding to the online session entry has obtained the token.
  • the processing unit 403 is further configured to: when each token is successfully acquired, increase the value of the token acquisition success count SCount in the unlisted user session entry by a unit amount, and set the value of the token acquisition failure number FCount to The initial value; the value of FCount in the unlived user session entry is increased by a unit amount each time the token acquisition fails.
  • the foregoing access gateway device 40 may further include: an update unit 406, where:
  • the updating unit 406 is configured to modify the first token bucket into a second token bucket when detecting that the value of the SCount in the unlisted user session entry reaches a predetermined first threshold, where the second token bucket is The number of tokens is far less than the number of tokens in the first token bucket; and is also used to delete the unlisted user session entry when it is detected that the value of the SCount in the unlisted user session entry reaches a predetermined second threshold. Wherein the second threshold is greater than the first threshold.
  • the processing unit 403 is further configured to: if the determining unit 402 determines that the value of the FCount in the unlisted user session entry reaches a predetermined threshold, discarding the HTTPS packet.
  • the foregoing access gateway device 40 may further include:
  • the timing unit 407 is further configured to: when a non-online user session entry is configured, start a timer corresponding to an unonline user session entry, and restart the timer when the timer time reaches a predetermined aging time;
  • the processing unit 403 is further configured to: when the timeout period of the timer reaches the predetermined aging time, if it is determined that the user session corresponding to the online user session entry has obtained the token, the unupline user session entry is updated to The value of FCount in the unlisted user session entry is set to an initial value corresponding to the state in which the user session has not obtained the token.
  • FIG. 6 is another schematic structural diagram of an access gateway device according to an embodiment of the present disclosure.
  • the access gateway device includes a processor 601, and a machine readable storage medium 602 that stores machine executable instructions.
  • Processor 601 and machine readable storage medium 602 can communicate via system bus 603.
  • the processor 601 can perform the message processing method described above by reading and executing the machine executable instructions in the machine readable storage medium 602.
  • the machine-readable storage medium 602 referred to herein can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like.
  • the machine-readable storage medium may be: RAM (Radom Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as a hard disk drive), solid state drive, any type of storage disk. .
  • the machine readable storage medium 602 is configured to store a program instruction executed by the receiving unit 401, a program instruction executed by the determining unit 402, a program instruction executed by the processing unit 403, a program instruction run by the searching unit 404, a program instruction executed by the configuration unit 405, The program instructions run by the update unit 406 and the program instructions run by the timing unit 407.
  • the processor 601 is configured to execute a program instruction executed by the receiving unit 401, a program instruction executed by the determining unit 402, a program instruction executed by the processing unit 403, a program instruction run by the searching unit 404, a program instruction executed by the configuration unit 405, and an updating unit 406.
  • the processor 601 implements the message processing method as described above by executing program instructions executed by the respective units as described above.
  • processor 601 by reading and executing machine executable instructions in machine readable storage medium 602, processor 601 is caused to:
  • the token is obtained from the first token bucket, where the number of tokens in the first token bucket is determined according to the The CPU processing capability setting of the access gateway device,
  • the HTTPS packet is sent to the CPU for processing.
  • the HTTPS packet is discarded when the token acquisition fails.
  • the processor 601 is further prompted by the machine executable instruction:
  • processor 601 is also prompted by machine executable instructions:
  • the HTTPS packet is sent to the CPU for processing.
  • processor 601 is also prompted by machine executable instructions:
  • the user session corresponding to the online user session entry has been determined to have a token by:
  • the token ID in the unlisted user session entry is an initial value, it is determined that the user session corresponding to the unlisted user session entry has not obtained the token.
  • processor 601 is also prompted by machine executable instructions:
  • the value of the token acquisition success count SCount in the unlisted user session entry is increased by a unit amount, and the number of token acquisition failures in the unlisted user session entry is FCount.
  • the value is set to the initial value;
  • the value of the FCount in the unlisted user session entry is increased by a unit amount each time the token acquisition fails.
  • processor 601 is also prompted by machine executable instructions:
  • the access gateway device Upon detecting that the value of the SCount in the unlisted user session entry reaches a predetermined first threshold, the access gateway device modifies the first token bucket into a second token bucket, where The number of tokens in the second token bucket is much smaller than the number of tokens in the first token bucket;
  • the access gateway device Upon detecting that the value of the SCount in the unlisted user session entry reaches a predetermined second threshold, the access gateway device deletes the unlisted user session entry, where the second threshold is greater than The first threshold is described.
  • processor 601 is also prompted by machine executable instructions:
  • the HTTPS packet is discarded.
  • the processor 601 is further caused by the machine executable instruction when configuring the unlisted user session entry:
  • the timer corresponding to the unreached user session entry is started to be timed
  • the device embodiment since it basically corresponds to the method embodiment, reference may be made to the partial description of the method embodiment.
  • the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, ie may be located A place, or it can be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment. Those of ordinary skill in the art can understand and implement without any creative effort.

Abstract

本公开提供一种报文处理方法及装置，其中，根据该方法的示例，接收用户主机发来的HTTPS报文，并根据HTTPS报文的源IP地址和目的IP地址查找与该HTTPS报文匹配的未上线用户会话表项。在查找到未上线用户会话表项的情况下，若判断出该未上线用户会话表项所对应的用户会话尚不具有令牌，则从第一令牌桶中获取令牌，其中，第一令牌桶中的令牌数量根据接入网关设备的CPU处理能力设定。在令牌获取成功时，将该HTTPS报文上送给CPU进行处理。在令牌获取失败时，将该HTTPS报文丢弃。

Description

报文处理
相关申请的交叉引用
本专利申请要求于2016年12月26日提交的、申请号为201611220634.3、发明名称为“报文处理方法及装置”的中国专利申请的优先权，该申请的全文以引用的方式并入本文中。
背景技术
门户(Portal)认证是一种灵活的网络访问控制技术，通过网页(Web)页面获取用户的用户名和密码，对用户进行身份认证，以达到访问控制的目的。用户主机(或Portal客户端)可以使用HTTP(HyperText Transfer Protocol，超文本传输协议)或者HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer，基于安全套接层的HTTP)访问外部网络，例如，Internet(互联网)。
当使用HTTPS访问Internet时，用户主机会发出HTTPS报文。BRAS(Broadband Remote Access Server，宽带远程接入服务器)设备接收到该报文后，可判断用户是否已经认证过。若尚未进行Portal认证，则BRAS设备会仿冒用户主机所访问的Web服务器来与用户主机建立TCP(Transmission Control Protocol，传输控制协议)连接和SSL(Secure Socket Layer，安全套接层)连接，并且可向用户主机推送重定向页面，以便用户在该重定向页面中输入用户名和密码。
后续，BRAS设备可与Portal服务器进行交互，使用用户输入的用户名和密码完成对用户的Portal认证，在认证通过后用户上线，用户主机可以正常访问Internet。
附图说明
图1是本公开一示例性实施例示出的报文处理方法的流程图；
图2是本公开另一示例性实施例示出的报文处理方法的流程图；
图3是本公开一示例性实施例示出的硬件层面对HTTPS报文进行匹配的示意图；
图4是本公开一示例性实施例示出的报文处理装置所在接入网关设备的结构示意图；
图5是本公开一示例性实施例示出的接入网关设备的一种结构示意图；
图6是本公开一示例性实施例示出的接入网关设备的另一种结构示意图。
具体实施方式
下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。
在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
在基于HTTPS的TCP仿冒过程中，用户主机与BRAS设备之间的报文交互很多。这样，当短时间内有大量用户需要上线时，BRAS设备的CPU处理负担会急剧增加。当超出了CPU的正常处理能力时，就会导致设备瘫痪。为了解决上述问题，本公开以下实施例中提供了一种报文处理方法，以及一种可以应用该方法的报文处理装置。
本公开实施例的方法可以由BRAS设备等接入网关设备来执行。在该方法中，接入网关设备接收用户主机发来的HTTPS报文；查找与该HTTPS报文匹配的未上线用户会话表项；在查找到所述匹配的未上线用户会话表项的情况下，若判断出该未上线用户会话表项所对应的用户会话尚未获取到令牌，则从第一令牌桶中获取令牌，其中，第一令牌桶中的令牌数量根据接入网关设备的CPU处理能力设定；在令牌获取成功时，将该HTTPS报文上送给CPU进行处理，在令牌获取失败时，将该HTTPS报文丢弃。这样，设置了第一令牌桶，第一令牌桶中的令牌数量根据接入网关设备的CPU处理能力来设定，并且，新增了未上线用户会话表项来记录未上线用户的会话信息。可以限制上送CPU的HTTPS报文数量，只有获取到了令牌的用户会话的HTTPS报文才上送给CPU进行处理，而未获取到令牌的用户会话的HTTPS 报文会直接丢弃、而不会上送给CPU进行处理，从而实现了对上送CPU的HTTPS报文的限流。在短时间内有大量用户需要上线时，能够减轻接入网关设备的CPU处理负担，确保CPU实际负荷不会超出正常处理能力。
一种实施例中，可预先设置一个第一令牌桶，第一令牌桶中的令牌数量根据接入网关设备的CPU处理能力来设定，CPU处理能力越大，第一令牌桶中的令牌数量越多。此时，如图1所示，接入网关设备执行的报文处理方法包括以下步骤：
步骤S101，可接收用户主机发来的HTTPS报文，根据该HTTPS报文的源IP地址和目的IP地址，查找匹配的未上线用户会话表项。
本公开实施例中用户会话通过源IP地址和目的IP地址来被标识，一个未上线用户会话表项对应于一个用户会话。
步骤S102，可判断是否查找到了匹配的未上线用户会话表项，若否，则执行步骤S103，若是，则执行步骤S104；
步骤S103，可配置包含该源IP地址和目的IP地址的未上线用户会话表项，之后退出本流程；
假设，步骤S101中接收到的HTTPS报文的源IP地址为IP11，目的IP地址为IP12，则，在步骤S103中配置的未上线用户会话表项可以参见表1所示：
表1
Figure PCTCN2017118627-appb-000001
表1中的令牌桶标识ID用于记录用于获取令牌的令牌桶的ID，令牌桶ID的初始值可以为0，也可以为第一令牌桶的ID；令牌ID为用于记录获取到的令牌的ID，令牌ID的初始值可以为0，当令牌ID为0时表示该表项所对应的用户会话尚未获取到令牌。
或者，还可以在表1中设置一个获取标记，用于指示该表项所对应的用户会话是否已经获取到了令牌，该获取标记的初始值可以设置为表示对应用户会话尚未获取到令牌的值。
步骤S104，可判断该未上线用户会话表项所对应的用户会话是否已经获取到了令牌，若尚未获取到令牌，则执行步骤S105，若已经获取到了令牌，则执行步骤S109；
其中，可以采用方式一或方式二来判断未上线用户会话表项所对应的用户会话是否已经获取到了令牌：
方式一、若该表项中的令牌ID为初始值，则确定该表项所对应的用户会话尚未获取到令牌，否则，确定该表项所对应的用户会话已经获取到了令牌；
方式二、通过该表项中的获取标记来判断该表项所对应的用户会话是否已经获取到了令牌。
步骤S105，可从第一令牌桶中获取一个令牌；
步骤S106，可判断令牌获取是否成功，若是，则执行步骤S107，否则，执行步骤S108；
如果第一令牌桶中还存在令牌，则此时可以从第一令牌桶中成功获取到令牌，否则，如果第一令牌桶中不存在令牌，则此时无法从第一令牌桶中获取到令牌。
步骤S107，可将该HTTPS报文上送给CPU进行处理，将该未上线用户会话表项中的令牌ID更新为获取到的令牌的ID，之后退出本流程；
在步骤S107中，如果该未上线用户会话表项中的令牌桶ID为0，则可将该令牌桶ID更新为第一令牌桶的ID；若该表项中还包含获取标记，则可将该获取标记更新为表示对应用户会话已经获取到了令牌的值。
步骤S108，可将该HTTPS报文丢弃，之后退出本流程；
步骤S109，可将该HTTPS报文上送给CPU进行处理，之后退出本流程。
在基于HTTPS的TCP仿冒过程中，接入网关设备每次接收到用户主机发来的HTTPS报文后，均按照如图1所示的方法进行处理。后续，用户Portal认证通过，用户上线，此时会删除源IP地址为用户主机IP地址IP11的未上线用户会话表项，释放这些表项所对应的用户会话获取到的令牌，将释放的令牌回收到第一令牌桶中。
另外，在步骤S103中配置未上线用户会话表项时，还可以开启对应的定时器，以使该定时器开始计时。当该定时器的计时时间到达预定老化时间T时，此时用户仍然没有上线，若该表项所对应的用户会话已经获取到了令牌，则需要释放该令牌，将释放的令牌回收到第一令牌桶中，将该表项中的令牌ID置为初始值，重启该定时器，以使该定时器重新开始计时。另外，在该表项中包含获取标记时，还会将该获取标记更新为表示对应用户会话尚未获取到令牌的值。这样，后续再接收到该用户对话对应的HTTPS报文时需要重新获取令牌。在这种情况下，如以下参照表2所描述的，未上线用户会话表项还可以包括老化时间T。
另一种实施例中，可预先设置一个第一令牌桶和一个第二令牌桶。第一令牌桶中的令牌数量根据接入网关设备的CPU处理能力来设定，CPU处理能力越大，第一令牌桶中的令牌数量越多。第二令牌桶中的令牌数量很少、远少于第一令牌桶中的令牌数量，第二令牌桶中令牌的具体数量可以根据实际情况进行预先设定。第一令牌桶用于限制正常未上线用户会话的数量，第二令牌桶用于限制异常未上线用户会话的数量。此时，如图2所示，接入网关设备执行的报文处理方法包括以下步骤：
步骤S201，接收用户主机发来的HTTPS报文，根据该HTTPS报文的源IP地址和目的IP地址，查找匹配的未上线用户会话表项；
本公开实施例中用户会话通过源IP地址和目的IP地址来被标识，一个未上线用户会话表项对应于一个用户会话。
步骤S202，可判断是否查找到了匹配的未上线用户会话表项，若否，则执行步骤S203，若是，则执行步骤S204；
步骤S203，可配置包含该源IP地址和目的IP地址的未上线用户会话表项，之后退出本流程；
假设，步骤S201中接收到的HTTPS报文的源IP地址为IP11，目的IP地址为IP12，则，在步骤S203中配置的未上线用户会话表项可以参见表2所示：
表2
Figure PCTCN2017118627-appb-000002
表2中的令牌桶ID用于记录用于获取令牌的令牌桶的ID，令牌桶ID的初始值可以为0，也可以为第一令牌桶的ID；
令牌ID用于记录获取到的令牌的ID，令牌ID的初始值可以为0，当令牌ID为0时表示该表项所对应的用户会话尚未获取到令牌；
SCount用于记录令牌获取成功的次数，每获取到一次令牌，可将SCount的值增加单位量，例如，将SCount的值加1，并且可将FCount的值置为初始值；其中，SCount和FCount的初 始值可以为0；
FCount用于记录老化时间T内连续获取令牌失败的次数，每次获取令牌失败，可将FCount的值增加单位量，例如，将FCount的值加1；
老化时间T：在配置如表2所示的未上线用户会话表项时，可开启一个定时器，该定时器的计时总时长为预定老化时间T；当该定时器的计时时间到达T时，释放该表项所对应的用户会话获取到的令牌，将令牌ID置为初始值，将FCount的值置为初始值。
或者，还可以在表2中设置一个获取标记，用于指示该表项所对应的用户会话是否已经获取到了令牌，该获取标记的初始值可以设置为表示对应用户会话尚未获取到令牌的值。
步骤S204，可判断该未上线用户会话表项所对应的用户会话是否已经获取到了令牌，若尚未获取到令牌，则执行步骤S205，若已经获取到了令牌，则执行步骤S211；
其中，可以采用上述方式一或上述方式二来判断未上线用户会话表项所对应的用户会话是否已经获取到了令牌，这里不再赘述。
步骤S205，可判断该未上线用户会话表项中的FCount的值是否达到预定的阈值MAX_F，若是，则执行步骤S206，否则，执行步骤S207；
步骤S206，可丢弃该HTTPS报文，之后退出本流程；
步骤S207，可从第一令牌桶获取一个令牌；
步骤S208，可判断令牌获取是否成功，若是，则执行步骤S209，否则，执行步骤S210；
如果第一令牌桶中还存在令牌，则此时可从第一令牌桶中成功获取到令牌，否则，如果第一令牌桶中不存在令牌，则此时无法从第一令牌桶中获取到令牌。
步骤S209，可将该HTTPS报文上送给CPU进行处理，将该未上线用户会话表项中的令牌ID更新为获取到的令牌的ID，将SCount的值增加单位量，将FCount的值置为初始值，之后退出本流程。
在步骤S209中，如果该未上线用户会话表项中的令牌桶ID为0，则可将该令牌桶ID更新为第一令牌桶的ID；若该表项中还包含获取标记，则可将该获取标记更新为表示对应用户会话已经获取到了令牌的值。
步骤S210，可将该HTTPS报文丢弃，将该未上线用户会话表项中的FCount的值增加单位量，之后退出本流程；
在步骤S210中，如果该未上线用户会话表项中的令牌桶ID为0，则可将该令牌桶ID更新为第一令牌桶的ID。
步骤S211，可将该HTTPS报文上送给CPU进行处理，之后退出本流程。
另外，在本实施例的方法中，在检测到未上线用户会话表项中的SCount的值达到预定的第一阈值MAX_S1时，可认为该表项对应的用户会话为异常未上线用户会话，将用于获取令牌的令牌桶从第一令牌桶修改为第二令牌桶，具体的，可以将未上线用户会话表项中的令牌桶ID修改为第二令牌桶的ID，这样，在如图2所示的步骤S207中就会从第二令牌桶中获取令牌。后续，如果该表项中的SCount的值继续增加，在检测到SCount的值达到预定的第二阈值MAX_S2时，删除该表项，释放该表项所对应的用户会话获取到的令牌，将释放的令牌回收到第二令牌桶中，其中，MAX_S2大于MAX_S1。
若用户Portal认证通过，用户上线，则会删除源IP地址为用户主机IP地址IP11的未上线用户会话表项，释放这些表项所对应的用户会话获取到的令牌。
另外，在步骤S203中配置未上线用户会话表项时，还可以开启定时器，以使该定时器开始计时，当该定时器的计时时间到达预定老化时间T时，此时用户仍然没有上线，若该表项所对应的用户会话已经获取到了令牌，则需要释放该令牌，将释放的令牌回收到对应的令牌桶中，将该表项中的令牌ID置为初始值，将该表项中的FCount的值置为初始值，重启该定时器，以使该定时器重新开始计时。另外，在该表项中包含获取标记时，还会将该获取标记更新为表示对应用户会话尚未获取到令牌的值。这样，后续该用户对话对应的HTTPS报文需要重新获取令牌。
在实际应用场景中，用户主机开机后，其上安装的大量程序可能会自动发出HTTPS报文来请求连接服务器，但是，由于用户并不需要使用这些程序，因此不会输入用户名和密码，从而无法完成Portal认证，这些程序就会一直发出HTTPS报文来请求连接服务器。在这种情况下，用户主机发出的HTTPS报文就会对接入网关设备造成攻击。本公开实施例中采用如图2所示的方法，通过设置一个用于限制正常未上线用户会话数量的第一令牌桶和一个用于限制异常未上线用户会话数量的第二令牌桶，当用户会话获取到令牌的次数达到了MAX_S1时用户仍然没有上线，此时，认为该用户会话为异常未上线用户会话，该会话的HTTPS报文是攻击报文，限制该异常未上线用户会话只能从令牌数量很少的第二令牌桶中获取令牌，进一步限制异常未上线用户会话的流量。
显然，还可以设置三个令牌桶，甚至更多的令牌桶，从而实现更加精细化的限流方式。 以设置三个令牌桶为例，除了设置上述第一令牌桶和第二令牌桶以外，还可设置第三令牌桶。第三令牌桶中的令牌数量可以为第一令牌桶中令牌数量的预定百分比，例如，为第一令牌桶中令牌数量的40％。初始时，可从第一令牌桶获取令牌，当检测到接入网关设备的CPU负载超过预定负载阈值时，可将用于获取令牌的令牌桶从第一令牌桶修改为第三令牌桶，从而，可从第三令牌桶中获取令牌。后续，当检测到未上线用户会话表项中的SCount的值达到MAX_S1时，可将用于获取令牌的令牌桶从第三令牌桶修改为第二令牌桶，从而，可从第二令牌桶中获取令牌。
下面通过一个具体实例，对如图2所示的报文处理方法进行详细说明。在本实施例中，在接入网关设备的底层硬件转发层面创建2个令牌桶，分别是令牌桶ID为bucket21的第一令牌桶和令牌桶ID为bucket22的第二令牌桶。第一令牌桶中令牌数量根据接入网关设备的CPU处理能力来设定；第二令牌桶中的令牌数量很少。
接入网关设备上的使能了Portal功能的端口上会固定的下发以下4条规则：
第一条规则Rule1：为免认证规则，该规则用于限定将目的IP地址为Portal服务器或一些免认证的Web服务器的IP地址的HTTP/HTTPS报文，直接转发出去；
第二条规则Rule2：用于限定将目的端口号为80的HTTP报文重定向到CPU；
第三条规则Rule3：用于限定将目的端口号为443的HTTPS报文重定向到CPU；
第四条规则Rule4：用于限定将未命中上述规则Rule1、Rule2和Rule3的报文进行丢弃。
如果用户通过Portal认证，则会下发Portal用户表项，Portal用户表项的匹配顺序在Rule1与Rule2之间，后续，用户主机发出的HTTP/HTTPS报文会根据该Portal用户表项进行转发。本公开实施例中新增的未上线用户会话表项的匹配顺序位于Rule2与Rule3之间，用以对未上线用户主机的HTTPS报文进行限流，确保CPU(301)的实际负荷不会超出正常处理能力，并且保护CPU不受攻击。Rule1、Portal用户表项、Rule2、未上线用户会话表项、Rule3、Rule4的匹配顺序如图3所示。图3只是示意性示出了硬件层面上各个表项的匹配顺序，并不具有限制性。
情况一：接收到未上线用户会话的首个HTTPS报文
假设，该HTTPS报文的源IP地址为10.0.0.2，目的IP地址为https://100.1.1.2，目的端口号为443。
则，接入网关设备在硬件层面接收到该HTTPS报文后，分别与Rule1、Portal用户表项、 Rule2、未上线用户会话表项进行匹配，均没有命中，则继续与Rule3进行匹配，结果为匹配，则可将该HTTPS报文上送给CPU，CPU可在硬件层面中下发一条如表3-1所示的未上线用户会话表项，该表项的匹配顺序在Rule2与Rule3之间。
表3-1
Figure PCTCN2017118627-appb-000003
情况二：接收到该未上线用户会话的第二个HTTPS报文
接入网关设备在硬件层面接收到该第二个HTTPS报文后，分别与Rule1、Portal用户表项、Rule2进行匹配，均没有命中，则继续与本地保存的未上线用户会话表项进行匹配，结果命中如表3-1所示的表项，根据该表项中的令牌ID为0，确定该表项所对应的用户会话尚未获取到令牌，则从第一令牌桶bucket21中获取令牌，如果令牌获取成功，假设，获取到的令牌的ID为100，则将该表项中的令牌ID更新为100，将SCount的值加1，将FCount的值清0，继续与Rule3进行匹配，按照Rule3将该HTTPS报文上送给CPU进行处理，此时，表3-1更新为如表3-2所示。
表3-2
Figure PCTCN2017118627-appb-000004
如果令牌获取失败，则丢弃该HTTPS报文，将FCount的值加1，此时，表3-1更新为表3-3所示。
表3-3
Figure PCTCN2017118627-appb-000005
情况三：接收到该未上线用户会话的后续HTTPS报文
如果在情况二中，获取令牌成功，则硬件层面在接收到后续HTTPS报文后，分别与Rule1、Portal用户表项、Rule2进行匹配，均没有命中，则继续与本地保存的未上线用户会话表项进行匹配，结果命中如表3-2所示的表项，根据该表项中的令牌ID不为0，确定该表项所对应的用户会话已经获取到了令牌，因此，会继续与Rule3进行匹配，按照Rule3将该HTTPS报文上送给CPU进行处理。此时不会对如表3-2所示的未上线用户会话表项进行更新。
这样，在基于HTTPS的TCP仿冒过程完成后，会对用户进行Portal认证，认证通过后，用户上线，CPU会向硬件层面下发Portal用户表项，并通知硬件层面删除源IP地址为10.0.0.2的未上线用户会话表项，释放这些表项所对应的用户会话获取到的令牌，将释放的令牌回收到令牌桶中。
如果在情况二中，获取令牌失败，则硬件层面在接收到后续HTTPS报文后，分别与Rule1、Portal用户表项、Rule2进行匹配，均没有命中，则继续与本地保存的未上线用户会话表项进行匹配，结果命中如表3-3所示的表项，根据该表项中的令牌ID为0，确定该表项所对应的用户会话尚未获取到令牌，因此，会从第一令牌桶bucket21中获取令牌，在令牌获取成功时，假设，获取到的令牌的ID为100，将该表项中的令牌ID更新为100，将SCount的值加1，将FCount的值清0，继续与Rule3进行匹配，按照Rule3将该HTTPS报文上送给CPU进行处理，此时，表3-3更新为如表3-2所示。如果令牌获取依然失败，则丢弃该HTTPS报文，将FCount的值加1，此时，表3-3更新为如表3-4所示。
表3-4
Figure PCTCN2017118627-appb-000006
情况四：未上线用户会话表项超时
未上线用户会话表项对应的定时器的计时时间到达T时，将该表项所对应的用户会话获取到的令牌释放，将释放的令牌回收到第一令牌桶bucket21中，将令牌ID置为0，将FCount的值清0，但是，SCount的值保持不变。后续HTTPS报文需要重新获取令牌。
情况五：在多个T时间内用户一直未能上线
经历了多个T时间，用户一直未能上线，未上线用户会话表项中的SCount的值会一直累加，当检测到SCount的值达到MAX_S1时，限制该表项所对应的用户会话只能从第二令牌桶bucket22中获取令牌，将未上线用户会话表项中的令牌桶ID修改为bucket22。由于第二令牌桶bucket22中的令牌数量很少，可以达到限制异常用户上线的目的。
后续，当检测到SCount的值达到MAX_S2时，删除该未上线用户会话表项，其中，MAX_S2大于MAX_S1。
情况六：在一个T时间内用户一直未能上线
如果在一个T时间内一直获取不到令牌，FCount的值会一直增加。在接收到HTTPS报文后，若匹配的未上线用户会话表项中的FCount的值达到了MAX_F，则不允许该表项所对应的用户会话获取令牌，直接丢弃该HTTPS报文。后续，在定时器的计时时间到达T时，将FCount的值清0后，才会允许该表项所对应的用户会话获取令牌。
与前述报文处理方法的实施例相对应，本公开还提供了报文处理装置的实施例。
本公开报文处理装置的实施例可以应用在接入网关设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。
请参考图4，本公开实施例的接入网关设备40中包括以下单元：接收单元401、判断单元402、处理单元403和查找单元404，其中：
接收单元401，用于接收用户主机发来的HTTPS报文；
查找单元404，用于在接收单元401接收到HTTPS报文后，根据HTTPS报文的源IP地址和目的IP地址查找与HTTPS报文匹配的未上线用户会话表项；
判断单元402，用于在查找单元404查找到未上线用户会话表项的情况下，判断该未上线用户会话表项所对应的用户会话是否已经获取到了令牌；
处理单元403，用于若判断单元402判断出该未上线用户会话表项所对应的用户会话尚未获取到令牌，则从第一令牌桶中获取令牌。其中，第一令牌桶中的令牌数量根据接入网关设备的CPU处理能力设定，在令牌获取成功时，将该HTTPS报文上送给CPU进行处理，在令牌获取失败时，将该HTTPS报文丢弃。
如图5所示，上述接入网关设备40中还包括配置单元405，其中：
配置单元405，用于若查找单元404没有查找到与该HTTPS报文匹配的未上线用户会话 表项，则配置包含源IP地址和目的IP地址的未上线用户会话表项。
其中，处理单元403，还用于若判断单元402判断出该未上线用户会话表项所对应的用户会话已经获取到了令牌，则将该HTTPS报文上送给CPU进行处理。
其中，处理单元403，还用于在每次令牌获取成功时，将该未上线用户会话表项中的令牌ID更新为获取到的令牌的ID；
判断单元402具体用于通过以下方式判断未上线用户会话表项所对应的用户会话是否已经获取到了令牌：若未上线用户会话表项中的令牌ID为初始值，则判断出未上线用户会话表项所对应的用户会话尚未获取到令牌，否则，判断出未上线用户会话表项所对应的用户会话已经获取到了令牌。
其中，处理单元403，还用于在每次令牌获取成功时，将未上线用户会话表项中的令牌获取成功次数SCount的值增加单位量，将令牌获取失败次数FCount的值置为初始值；在每次令牌获取失败时，将未上线用户会话表项中的FCount的值增加单位量。
如图5所示，上述接入网关设备40中还可以包括：更新单元406，其中：
更新单元406，用于在检测到未上线用户会话表项中的SCount的值达到预定的第一阈值时，将第一令牌桶修改为第二令牌桶，其中，第二令牌桶中的令牌数量远小于第一令牌桶中的令牌数量；还用于在检测到未上线用户会话表项中的SCount的值达到预定的第二阈值时，删除该未上线用户会话表项，其中，第二阈值大于第一阈值。
其中，处理单元403，还用于若判断单元402判断出该未上线用户会话表项中的FCount的值达到了预定阈值，则丢弃该HTTPS报文。
如图5所示，上述接入网关设备40中还可以包括：
计时单元407，还用于在配置未上线用户会话表项时，开启未上线用户会话表项对应的定时器进行计时，当定时器的计时时间到达预定老化时间时，重启该定时器；
处理单元403，还用于当定时器的计时时间到达预定老化时间时，若判断出未上线用户会话表项所对应的用户会话已经获取到了令牌，则将该未上线用户会话表项更新为对应用户会话尚未获取到令牌的状态，将该未上线用户会话表项中的FCount的值置为初始值。
参考图6，图6为本公开实施例的接入网关设备的另一结构示意图。该接入网关设备包括：处理器601、存储有机器可执行指令的机器可读存储介质602。处理器601与机器可读存储介质602可经由系统总线603通信。通过读取并执行机器可读存储介质602中的机器可 执行指令，处理器601可执行上文描述的报文处理方法。
本文中提到的机器可读存储介质602可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：RAM(Radom Access Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘。
机器可读存储介质602，用于存放接收单元401运行的程序指令、判断单元402运行的程序指令、处理单元403运行的程序指令、查找单元404运行的程序指令、配置单元405运行的程序指令、更新单元406运行的程序指令、计时单元407运行的程序指令。
处理器601，用于执行接收单元401运行的程序指令、判断单元402运行的程序指令、处理单元403运行的程序指令、查找单元404运行的程序指令、配置单元405运行的程序指令、更新单元406运行的程序指令、计时单元407运行的程序指令。处理器601通过执行如上各个单元所运行的程序指令，来实现如上所述的报文处理方法。
在一个示例中，通过读取并执行机器可读存储介质602中的机器可执行指令，处理器601被促使：
接收用户主机发来的基于安全套接层的超文本传输协议HTTPS报文；
根据所述HTTPS报文的源互联网协议IP地址和目的IP地址查找与所述HTTPS报文匹配的未上线用户会话表项，
在查找到所述未上线用户会话表项的情况下，
若判断出所述未上线用户会话表项所对应的用户会话尚不具有令牌，则从第一令牌桶中获取令牌，其中，所述第一令牌桶中的令牌数量根据所述接入网关设备的CPU处理能力设定，
在令牌获取成功时，将所述HTTPS报文上送给CPU进行处理，
在令牌获取失败时，将所述HTTPS报文丢弃。
其中，在未查找到所述未上线用户会话表项的情况下，处理器601还被机器可执行指令促使：
配置包含所述源IP地址和目的IP地址的未上线用户会话表项。
其中，处理器601还被机器可执行指令促使：
若判断出所述未上线用户会话表项所对应的用户会话已经具有令牌，则将所述HTTPS报文上送给CPU进行处理。
其中，处理器601还被机器可执行指令促使：
在每次令牌获取成功时，将所述未上线用户会话表项中的令牌标识ID更新为获取到的令牌的ID；
通过以下方式判断所述未上线用户会话表项所对应的用户会话是否已经具有令牌：
若所述未上线用户会话表项中的令牌ID为初始值，则判断出所述未上线用户会话表项所对应的用户会话尚未获取到令牌，
否则，判断出所述未上线用户会话表项所对应的用户会话已经获取到了令牌。
其中，处理器601还被机器可执行指令促使：
在每次令牌获取成功时，将所述未上线用户会话表项中的令牌获取成功次数SCount的值增加单位量，并将所述未上线用户会话表项中的令牌获取失败次数FCount的值置为初始值；
在每次令牌获取失败时，将所述未上线用户会话表项中的所述FCount的值增加单位量。
其中，处理器601还被机器可执行指令促使：
在检测到所述未上线用户会话表项中的所述SCount的值达到预定的第一阈值时，所述接入网关设备将所述第一令牌桶修改为第二令牌桶，其中，所述第二令牌桶中的令牌数量远小于所述第一令牌桶中的令牌数量；
在检测到所述未上线用户会话表项中的所述SCount的值达到预定的第二阈值时，所述接入网关设备删除该未上线用户会话表项，其中，所述第二阈值大于所述第一阈值。
其中，处理器601还被机器可执行指令促使：
若判断出所述未上线用户会话表项中的所述FCount的值达到了预定阈值，则丢弃所述HTTPS报文。
其中，在配置所述未上线用户会话表项时，处理器601还被所述机器可执行指令促使：
开启所述未上线用户会话表项对应的定时器进行计时；
若当所述定时器的计时时间到达预定老化时间时所述未上线用户会话表项所对应的用户会话已经获取到了令牌，则
将所述未上线用户会话表项更新为对应用户会话尚未获取到令牌的状态，
将所述未上线用户会话表项中的FCount的值置为初始值，并
重启该定时器。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上对本公开实施例所提供的方法和装置进行了详细介绍，本文中应用了具体个例对本公开的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本公开的方法及其核心思想；同时，对于本领域的一般技术人员，依据本公开的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本公开的限制。

Claims (15)

  1. 一种报文处理方法，包括：
    接入网关设备接收用户主机发来的基于安全套接层的超文本传输协议HTTPS报文；
    所述接入网关设备根据所述HTTPS报文的源互联网协议IP地址和目的IP地址查找与所述HTTPS报文匹配的未上线用户会话表项，
    在查找到所述未上线用户会话表项的情况下，
    若判断出所述未上线用户会话表项所对应的用户会话尚不具有令牌，则所述接入网关设备从第一令牌桶中获取令牌，其中，所述第一令牌桶中的令牌数量根据所述接入网关设备的CPU处理能力设定，
    在令牌获取成功时，所述接入网关设备将所述HTTPS报文上送给CPU进行处理，
    在令牌获取失败时，所述接入网关设备将所述HTTPS报文丢弃。
  2. 根据权利要求1所述的方法，其中，在未查找到所述未上线用户会话表项的情况下，所述方法还包括：
    所述接入网关设备配置包含所述源IP地址和目的IP地址的未上线用户会话表项。
  3. 根据权利要求1所述的方法，其中，所述方法还包括：
    若判断出所述未上线用户会话表项所对应的用户会话已经具有令牌，则所述接入网关设备将所述HTTPS报文上送给CPU进行处理。
  4. 根据权利要求1所述的方法，其中，
    在每次令牌获取成功时，所述接入网关设备还将所述未上线用户会话表项中的令牌标识ID更新为获取到的令牌的ID；
    通过以下方式判断所述未上线用户会话表项所对应的用户会话是否已经具有令牌：
    若所述未上线用户会话表项中的令牌ID为初始值，则所述接入网关设备判断出所述未上线用户会话表项所对应的用户会话尚未获取到令牌，
    否则，所述接入网关设备判断出所述未上线用户会话表项所对应的用户会话已经获取到了令牌。
  5. 根据权利要求1所述的方法，其中，
    在每次令牌获取成功时，所述接入网关设备将所述未上线用户会话表项中的令牌获取成功次数SCount的值增加单位量，并将所述未上线用户会话表项中的令牌获取失败次数FCount的值置为初始值；
    在每次令牌获取失败时，所述接入网关设备将所述未上线用户会话表项中的所述FCount的值增加单位量。
  6. 根据权利要求5所述的方法，其中，所述方法还包括：
    在检测到所述未上线用户会话表项中的所述SCount的值达到预定的第一阈值时，所述接入网关设备将所述第一令牌桶修改为第二令牌桶，其中，所述第二令牌桶中的令牌数量远小于所述第一令牌桶中的令牌数量；
    在检测到所述未上线用户会话表项中的所述SCount的值达到预定的第二阈值时，所述接入网关设备删除该未上线用户会话表项，其中，所述第二阈值大于所述第一阈值。
  7. 根据权利要求5所述的方法，其中，所述方法还包括：
    若判断出所述未上线用户会话表项中的所述FCount的值达到了预定阈值，则所述接入网关设备丢弃所述HTTPS报文。
  8. 根据权利要求2所述的方法，其中，配置所述未上线用户会话表项，包括：
    开启所述未上线用户会话表项对应的定时器进行计时；
    若当所述定时器的计时时间到达预定老化时间时所述未上线用户会话表项所对应的用户会话已经获取到了令牌，则所述接入网关设备
    将所述未上线用户会话表项更新为对应用户会话尚未获取到令牌的状态，
    将所述未上线用户会话表项中的FCount的值置为初始值，并
    重启该定时器。
  9. 一种接入网关设备，包括：
    处理器；以及
    存储有机器可执行指令的非暂时性机器可读存储介质，其中，通过读取并执行所述机器可执行指令，所述处理器被促使：
    接收用户主机发来的基于安全套接层的超文本传输协议HTTPS报文；
    根据所述HTTPS报文的源互联网协议IP地址和目的IP地址查找与所述HTTPS报文匹配的未上线用户会话表项，
    在查找到所述未上线用户会话表项的情况下，
    若判断出所述未上线用户会话表项所对应的用户会话尚不具有令牌，则从第一令牌桶中获取令牌，其中，所述第一令牌桶中的令牌数量根据所述接入网关设备的CPU处理能力设定，
    在令牌获取成功时，将所述HTTPS报文上送给CPU进行处理，
    在令牌获取失败时，将所述HTTPS报文丢弃。
  10. 根据权利要求9所述的设备，其中，在未查找到所述未上线用户会话表项的情况下，所述处理器还被所述机器可执行指令促使：
    配置包含所述源IP地址和目的IP地址的未上线用户会话表项。
  11. 根据权利要求9所述的设备，其中，所述处理器还被所述机器可执行指令促使：
    若判断出所述未上线用户会话表项所对应的用户会话已经具有令牌，则将所述HTTPS报文上送给CPU进行处理。
  12. 根据权利要求9所述的设备，其中，所述处理器还被所述机器可执行指令促使：
    在每次令牌获取成功时，将所述未上线用户会话表项中的令牌ID更新为获取到的令牌的ID；
    通过以下方式判断所述未上线用户会话表项所对应的用户会话是否已经具有令牌：
    若所述未上线用户会话表项中的令牌ID为初始值，则判断出所述未上线用户会话表项所对应的用户会话尚未获取到令牌，
    否则，判断出所述未上线用户会话表项所对应的用户会话已经获取到了令牌。
  13. 根据权利要求9所述的设备，其中，所述处理器还被所述机器可执行指令促使：
    在每次令牌获取成功时，将所述未上线用户会话表项中的令牌获取成功次数SCount的值增加单位量，并将所述未上线用户会话表项中的令牌获取失败次数FCount的值置为初始值；
    在每次令牌获取失败时，将所述未上线用户会话表项中的所述FCount的值增加单位量。
  14. 根据权利要求13所述的设备，其中，所述处理器还被所述机器可执行指令促使：
    在检测到所述未上线用户会话表项中的所述SCount的值达到预定的第一阈值时，所述接入网关设备将所述第一令牌桶修改为第二令牌桶，其中，所述第二令牌桶中的令牌数量远小于所述第一令牌桶中的令牌数量；
    在检测到所述未上线用户会话表项中的所述SCount的值达到预定的第二阈值时，所述接入网关设备删除该未上线用户会话表项，其中，所述第二阈值大于所述第一阈值。
  15. 根据权利要求13所述的设备，其中，所述处理器还被所述机器可执行指令促使：
    若判断出所述未上线用户会话表项中的所述FCount的值达到了预定阈值，则丢弃所述HTTPS报文。
PCT/CN2017/118627 2016-12-26 2017-12-26 报文处理 WO2018121528A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2019534829A JP6824417B2 (ja) 2016-12-26 2017-12-26 パケット処理方法およびアクセスゲートウェイ機器
EP17885544.1A EP3547626B1 (en) 2016-12-26 2017-12-26 Packet processing
US16/474,037 US10992584B2 (en) 2016-12-26 2017-12-26 Processing packet

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201611220634.3 2016-12-26
CN201611220634.3A CN108243115B (zh) 2016-12-26 2016-12-26 报文处理方法及装置

Publications (1)

Publication Number Publication Date
WO2018121528A1 true WO2018121528A1 (zh) 2018-07-05

Family

ID=62702227

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/118627 WO2018121528A1 (zh) 2016-12-26 2017-12-26 报文处理

Country Status (5)

Country Link
US (1) US10992584B2 (zh)
EP (1) EP3547626B1 (zh)
JP (1) JP6824417B2 (zh)
CN (1) CN108243115B (zh)
WO (1) WO2018121528A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6841785B2 (ja) * 2018-03-29 2021-03-10 日本電信電話株式会社 情報処理装置、情報処理方法及び情報処理プログラム
CN111600832B (zh) * 2019-07-25 2022-09-30 新华三技术有限公司 报文处理方法及装置
US11483361B2 (en) * 2020-06-24 2022-10-25 KORD, Inc. Audio stem access and delivery solution
CN113542150B (zh) * 2021-07-14 2023-06-02 杭州海康威视数字技术股份有限公司 一种数据传输方法、装置及中心端网桥

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101018206A (zh) * 2007-02-14 2007-08-15 华为技术有限公司 分片报文处理方法与装置
CN101459583A (zh) * 2007-12-13 2009-06-17 华为技术有限公司 报文处理方法和装置、以及报文发送方法和装置
CN104270364A (zh) * 2014-09-30 2015-01-07 杭州华三通信技术有限公司 一种超文本传输协议报文处理方法和装置
CN104519021A (zh) * 2013-09-29 2015-04-15 杭州华三通信技术有限公司 防止恶意流量攻击的方法及装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7253717B2 (en) * 2000-11-29 2007-08-07 Mobile Technics Llc Method and system for communicating with and tracking RFID transponders
US20040125796A1 (en) * 2002-12-30 2004-07-01 Reader Scot A. N rate, N‘precedence meter/marker
WO2005073929A1 (en) * 2004-01-20 2005-08-11 Harrow Products Llc Access control system with energy-saving optical token presence sensor system
JP2006013757A (ja) 2004-06-24 2006-01-12 Matsushita Electric Ind Co Ltd ホームネットワーク遠隔管理システム
JP4507005B2 (ja) * 2007-10-25 2010-07-21 Ｎｅｃアクセステクニカ株式会社 無線通信システム，無線通信方法及びプログラム
US8763082B2 (en) * 2008-05-13 2014-06-24 At&T Mobility Ii Llc Interactive client management of an access control list
JP2010252049A (ja) * 2009-04-15 2010-11-04 Sony Corp 通信装置及び通信方法、コンピューター・プログラム、並びに通信システム
US9729467B2 (en) * 2009-05-12 2017-08-08 Qualcomm Incorporated Method and apparatus for managing congestion in a wireless system
DE102009026124A1 (de) * 2009-07-07 2011-01-13 Elan Schaltelemente Gmbh & Co. Kg Verfahren und System zur Erfassung, Übertragung und Auswertung sicherheitsgerichteter Signale
JP5725162B2 (ja) * 2011-03-31 2015-05-27 富士通株式会社 排他制御方法、および排他制御プログラム
US9722972B2 (en) * 2012-02-26 2017-08-01 Oracle International Corporation Methods and apparatuses for secure communication
US9417910B2 (en) * 2012-12-20 2016-08-16 Oracle International Corporation System and method for implementing shared probabilistic counters storing update probability values
JP6307593B2 (ja) * 2013-04-26 2018-04-04 インターデイジタル パテント ホールディングス インコーポレイテッド 必要とされる認証保証レベルを達成するための多要素認証
US9531749B2 (en) * 2014-08-07 2016-12-27 International Business Machines Corporation Prevention of query overloading in a server application
US9984110B2 (en) * 2014-08-21 2018-05-29 Dropbox, Inc. Multi-user search system with methodology for personalized search query autocomplete
US9990485B2 (en) * 2014-09-26 2018-06-05 Assa Abloy Ab Anti-passback algorithm for reading a public or secure object
US9135412B1 (en) * 2015-02-24 2015-09-15 Wowza Media Systems, LLC Token-based security for remote resources
US9942217B2 (en) * 2015-06-03 2018-04-10 At&T Intellectual Property I, L.P. System and method for generating a service provider based secure token
US9979747B2 (en) * 2015-09-05 2018-05-22 Mastercard Technologies Canada ULC Systems and methods for detecting and preventing spoofing
US20180063152A1 (en) * 2016-08-29 2018-03-01 Matt Erich Device-agnostic user authentication and token provisioning

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101018206A (zh) * 2007-02-14 2007-08-15 华为技术有限公司 分片报文处理方法与装置
CN101459583A (zh) * 2007-12-13 2009-06-17 华为技术有限公司 报文处理方法和装置、以及报文发送方法和装置
CN104519021A (zh) * 2013-09-29 2015-04-15 杭州华三通信技术有限公司 防止恶意流量攻击的方法及装置
CN104270364A (zh) * 2014-09-30 2015-01-07 杭州华三通信技术有限公司 一种超文本传输协议报文处理方法和装置

Also Published As

Publication number Publication date
US20190372899A1 (en) 2019-12-05
EP3547626A4 (en) 2019-11-20
CN108243115A (zh) 2018-07-03
CN108243115B (zh) 2021-06-29
US10992584B2 (en) 2021-04-27
EP3547626A1 (en) 2019-10-02
JP2020503763A (ja) 2020-01-30
EP3547626B1 (en) 2021-03-03
JP6824417B2 (ja) 2021-02-03

Similar Documents

Publication Publication Date Title
WO2018121528A1 (zh) 报文处理
US10951495B2 (en) Application signature generation and distribution
US8522311B2 (en) Authentication techniques
US9935980B2 (en) Adding firewall security policy dynamically to support group VPN
US20170318059A1 (en) Single pass load balancing and session persistence in packet networks
CN109327395B (zh) 一种报文处理方法及装置
US9461980B1 (en) Predictive prefetching of attribute information
EP3313032B1 (en) Cloud platform security realization
CN106656975B (zh) 一种攻击防御方法及装置
US20160028716A1 (en) Routing protocol authentication migration
CN107800697B (zh) 接入认证方法及装置
US10021192B2 (en) Communication control device and communication control method
US10419386B2 (en) Endpoint identifiers registration
US10999379B1 (en) Liveness detection for an authenticated client session
CN107547562B (zh) 一种portal认证方法和装置
CN106506270B (zh) 一种ping报文处理方法及装置
JP5902264B2 (ja) 通信制御装置、通信制御システム、通信制御方法、および通信制御プログラム
WO2016106718A1 (zh) 一种网络控制方法与虚拟交换机
US8811179B2 (en) Method and apparatus for controlling packet flow in a packet-switched network
JP2002108729A (ja) ネットワーク接続装置及び同装置に適用されるファイアウォール制御プログラムを記憶したコンピュータ読み取り可能な記憶媒体
CN107547322B (zh) 一种报文处理方法、装置及宽带远程接入服务器bras
TWI818167B (zh) 通訊系統、資訊提供裝置、電腦可讀取記憶媒體及資訊提供方法
JP2011166312A (ja) 仮想プライベートネットワークシステム、通信方法及びコンピュータプログラム
JP6705590B2 (ja) パケットフィルタリング装置、パケットフィルタリング方法およびパケットフィルタリングプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17885544

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019534829

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017885544

Country of ref document: EP

Effective date: 20190624