Determining trusted file awareness via loosely connected events and file attributes
US-2024364713-A1 · Oct 31, 2024 · US
US9491144B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-9491144-B2 |
| Application number | US-201514842216-A |
| Country | US |
| Kind code | B2 |
| Filing date | Sep 1, 2015 |
| Priority date | Feb 12, 2014 |
| Publication date | Nov 8, 2016 |
| Grant date | Nov 8, 2016 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
Methods and apparatus for supporting secure packet communications, e.g., sRTP/sRTCP, which are resistant to denial of service attacks are described. A received packet is identified to correspond to a particular stream being received, the stream having a current expected set of packet sequence numbers, e.g., a current window including a next expected packet sequence number and at least one packet sequence number in the expected packet window on each side of the expected packet sequence number. Unencrypted information from the received packet, e.g., a received packet sequence number, is used to determine at least one of: to drop the received packet, or to assign the packet to one of a plurality of policing levels. If the packet passes policing at its assigned policing level, the packet may undergo authentication and decryption to determine if it is a valid packet.
Opening claim text (preview).
What is claimed is: 1. A communications method, the method comprising: receiving, at a input/output interface of a communications device, a packet including a packet sequence number; operating a processor in said communications device to determine whether to pass or drop said packet based on said packet sequence number and an expected range of packet sequence numbers, said expected range of packet sequence numbers including a next expected packet sequence number, at least a preceding packet sequence number and at least a subsequent packet sequence number, said preceding packet sequence number preceding said next expected packet sequence number in said expected range of packet sequence numbers, said subsequent packet sequence number following said next expected packet sequence number in said expected range of packet sequence numbers, said operating a processor in said communication device to determine whether to pass or drop said packet based on said packet sequence number and an expected range of packet sequence numbers includes operating said processor to determine a packet priority policing level to apply based on the value of said packet sequence number; dropping said packet without decrypting said packet if said packet fails a policing policy corresponding to the determined priority policing level; decrypting said packet if said packet passes the policing policy corresponding to the determined priority policing level to produce decrypted packet content; checking the decrypted packet content to determine if said packet is a valid packet; dropping the packet if it is determined that said decrypted packet is not a valid packet; passing the packet if it is determined that said decrypted packet is a valid packet; and when a packet is passed updating at least one of the next expected packet sequence number or a set of gap packet sequence numbers stored in a memory of said communications device based on said packet sequence number of the packet being passed. 2. The method of claim 1 , wherein determining whether to pass or drop said packet based on said packet sequence number and an expected range of packet sequence numbers includes: dropping said packet if said packet sequence number is a repeat of a sequence number of a previously passed valid packet. 3. The method of claim 1 , wherein said communications device is a session border controller. 4. The method of claim 1 further comprising performing one or more reasonableness checks on the received packet prior to making a policy policing determination with respect to said packet. 5. The method of claim 1 , wherein different packet policing levels correspond to different policing levels of a multi-level bucket policer. 6. The method of claim 1 , wherein different packet policing levels correspond to different levels of bandwidth. 7. The method of claim 1 , wherein said packet is a sRTP or a sRTCP packet. 8. A communications method, the method comprising: receiving, at a input/output interface of a communications device, a packet including a packet sequence number; and operating a processor in said communication device to determine whether to pass or drop said packet based on said packet sequence number and an expected range of packet sequence numbers, said expected range of packet sequence numbers including a next expected packet sequence number, at least a preceding packet sequence number and at least a subsequent packet sequence number, said preceding packet sequence number preceding said next expected packet sequence number in said expected range of packet sequence numbers, said subsequent packet sequence number following said next expected packet sequence number in said expected range of packet sequence numbers, said operating a processor in said communications device to determine whether to pass or drop said packet based on said packet sequence number and an expected range of packet sequence numbers includes operating said processor in said communication device to determine a packet priority policing level to apply based on the value of said packet sequence number relative to the location of the expected packet sequence number in the expected range of packet sequence numbers. 9. The method of claim 8 wherein said determination to pass or drop said packet depends on the resources available for transmitting packets corresponding to the priority policing level to which the packet is assigned. 10. The method of claim 9 wherein said priority policing levels correspond to different policing levels of a multi-level bucket policer. 11. A session border controller comprising: a input/output interface configured to receive a packet including a packet sequence number; a memory; and a processor configured to: determine whether to pass or drop said packet based on said packet sequence number and an expected range of packet sequence numbers, said expected range of packet sequence numbers including a next expected packet sequence number, at least a preceding packet sequence number and at least a subsequent packet sequence number, said preceding packet sequence number preceding said next expected packet sequence number in said expected range of packet sequence numbers, said subsequent packet sequence number following said next expected packet sequence number in said expected range of packet sequence numbers, said configured to determine whether to pass or drop said packet based on said packet sequence number and an expected range of packet sequence numbers includes being configured to determine a packet priority policing level to apply to said packet based on the value of said packet sequence number; drop said packet without decrypting said packet if said packet fails a policing policy corresponding to the determined priority policing level; decrypt said packet if said packet passes the policing policy corresponding to the determined priority policing level to produce decrypted packet content; check the decrypted packet content to determine if said packet is a valid packet; drop the packet if it is determined that said decrypted packet is not a valid packet; pass the packet if it is determined that said decrypted packet is a valid packet; and update at least one of the next expected packet sequence number or a set of gap packet sequence numbers stored in said memory based on said packet sequence number of the packet being passed. 12. The session border controller of claim 11 , wherein said processor is further configured to drop said packet if said packet sequence number is a repeat of a sequence number of a previously passed valid packet. 13. The session border controller of claim 11 , wherein said processor in said session border controller is further configured to perform one or more reasonableness checks on the received packet prior to making a policy policing determination with respect to said packet. 14. The session border controller of claim 13 , wherein said packet is a sRTP or a sRTCP packet. 15. The session border controller of claim 11 , wherein different packet policing levels correspond to different policing levels of a multi-level bucket policer. 16. The session border controller of claim 11 , wherein different packet policing levels correspond to different levels of bandwidth. 17. The session border controller of claim 13 , wherein said one or more reasonableness checks include at least one of a timestamp field value reasonableness check or a SSRC field value reasonableness check. 18. The session border controller of claim 11 wherein said processor is further configured to determine sa
Filtering policies (mail message filtering H04L51/212) · CPC title
Denial of Service · CPC title
Filtering by information in the payload · CPC title
Detecting local intrusion or implementing counter-measures · CPC title
Filtering by address, protocol, port number or service, e.g. IP-address or URL · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.