[go: up one dir, main page]

HK1112348A - Client assisted firewall configuration - Google Patents

Client assisted firewall configuration Download PDF

Info

Publication number
HK1112348A
HK1112348A HK08107176.3A HK08107176A HK1112348A HK 1112348 A HK1112348 A HK 1112348A HK 08107176 A HK08107176 A HK 08107176A HK 1112348 A HK1112348 A HK 1112348A
Authority
HK
Hong Kong
Prior art keywords
firewall
socket
passive
open
mobile device
Prior art date
Application number
HK08107176.3A
Other languages
Chinese (zh)
Inventor
M‧帕登
P‧M‧霍克斯
G‧G‧罗丝
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 高通股份有限公司
Publication of HK1112348A publication Critical patent/HK1112348A/en

Links

Description

Client-assisted firewall configuration
Cross Reference to Related Applications
[0001] This application claims priority to U.S. provisional application No.60/638,271, entitled "CLIENTASSISTED FIREWALL CONFIGURATION", filed on 21.12.2004, U.S. provisional application No.60/638,271, the entire disclosure of which is incorporated herein by reference.
Technical Field
[0002] The present invention relates generally to data communications, and more particularly to how to configure firewalls and reduce network traffic.
Background
[0003] Firewalls are security devices that protect a network from unauthorized access and malicious attacks. Unauthorized access may be to obtain sensitive information or to disrupt the functionality of the network. Traditional firewalls divide the network into two segments: the firewall comprises an inner section and an outer section, wherein the inner section is positioned behind the firewall, and the outer section is positioned outside the firewall. To prevent unauthorized access, firewalls need to examine packets and sessions to determine whether they should be transmitted to an intended destination or blocked or dropped.
[0004] The firewall is typically located at the entry point and it scans the incoming traffic and compares it to predetermined criteria. Traffic that does not match the predetermined criteria will be blocked or dropped. Depending on the tolerable complexity and desired level of protection, the predetermined criteria may include a variety of parameters such as port number, application ID, source, destination, content filter, IP address, machine name, TCP/IP flag, and other parameters. The number of matching parameters that determine whether to let the packet pass establishes the protection granularity. A coarser-grained firewall may inadvertently block intended incoming traffic because it is mistaken for unexpected traffic, while it may not be enough to prevent unexpected traffic.
[0005] The security policy may be defined and/or enforced by a network administrator at a central point. While different users may have different network access preferences and needs, users may still be unable to select which services are available and/or disabled for their terminals. Different users may want different types of traffic flows. These flows are affected by network security policies. For example, one user may want to block transmissions from a particular transmission control protocol/internet protocol (TCP/IP) network address, while another user may be wanting to receive such transmissions. One user may want to have a transmission from a particular subnet address of the network while another user wants all transmissions from that subnet address. Other users may want to get message traffic destined for a particular port or application, while a different user may want to block all incoming connections and only allow outgoing connections.
[0006] The firewall acts as a gatekeeper. The firewall in the vicinity of each device places a firewall around each terminal or mobile device. In this case, the illegal packet is not discarded until it reaches the terminal or mobile device. Thus, the network bandwidth that is at a premium in a wireless network is wasted as such because the packet has already consumed the radio resources needed to transmit the packet. These wasted resources are preferably redistributed to other connections for better utilization. The waste of resources increases user costs because it increases message transmission and decreases overall throughput because the transmission of packets over the wireless link requires the use of resources.
[0007] To overcome the above and other disadvantages, a need exists for a technique that: unwanted or undesired packets are blocked before transmission to the device, thereby reducing network traffic. We also need a technique that: the device is enabled to dynamically modify one or more firewall policies so that the device can specify particular packets, senders, and/or other packet criteria. The configured firewall may be remote from the communication endpoint or device. There is also a need for the ability to automatically revoke firewall policies during communications in order to provide protection.
Disclosure of Invention
[0008] The following presents a simplified summary of one or more embodiments in order to provide a basic understanding of some aspects of the embodiments. This summary is not an extensive overview of the one or more embodiments, and is intended to neither identify key or critical elements of the embodiments nor delineate the scope of the embodiments. Its sole purpose is to present some concepts of the described embodiments in a simplified form as a prelude to the more detailed description that is presented later.
[0009] In accordance with one or more embodiments and corresponding descriptions thereof, various aspects of configuring a firewall and/or reducing network traffic are disclosed. According to one embodiment is a method for use by a mobile device to configure a firewall to reduce unwanted network traffic. The method comprises the following steps: establishing network connection with a network firewall; communicate with a network firewall to manage network traffic. According to some embodiments, the method may comprise: detecting whether a passive socket has been created; the network firewall is requested to permit the flow to the passive socket to pass through. In some embodiments, the method may comprise: closing the web server; the passive socket is closed. The firewall may be contacted with closed passive socket information and may be requested to deny passage of a flow to the closed passive socket. If the passive socket is closed, the method can automatically revoke the request for the firewall to permit the flow to the passive socket to pass.
[0010] According to another embodiment is a method for a host to automatically recover from a disconnected or terminated session. The method comprises the following steps: requesting the remote firewall to permit passage of packets destined for the at least one open socket; detecting a disconnected session; a packet request directed to at least one open socket is revoked. The method may further comprise: reestablishing a new session; requesting to let the desired flow pass. According to some embodiments, requesting permission to pass packets to the at least one open socket comprises: a list of currently open sockets is generated.
[0011] According to another embodiment is a mobile device for configuring a network firewall. The mobile device includes: a processor that analyzes information related to configuring a firewall to reduce traffic; a memory operatively connected to the processor. The mobile device may further include: an establisher that establishes communication with an external source; a designator that designates parameters related to packets received from the external source and transmits the parameters to a firewall. The mobile device also includes an invalidator that requests that the passage of the at least one parameter be revoked. In some embodiments, the mobile device may include: a transmitter to transmit at least one policy update to a firewall; a receiver that receives an acknowledgement or a denial of the policy from a firewall.
[0012] According to another embodiment is an apparatus for reducing network traffic in a mobile device. The device includes: a detection module that detects at least one firewall; a communication module in communication with the at least one firewall; a dynamic update module that dynamically updates policies related to the at least one firewall. The apparatus may further include: a monitoring module that monitors a list of passive sockets; alternatively, a designation module designates an expected incoming flow.
[0013] According to another embodiment is a computer-readable medium for use in a mobile device, the medium comprising computer-executable instructions for: establishing network connection; a passive socket associated with the established network connection is detected. The instructions further include: contacting the firewall; requesting the firewall to permit the flow through to the passive socket. According to some embodiments, the instructions may include: disconnecting the network connection; closing the passive socket; contacting the firewall; requesting the firewall to deny passage of flows destined for the closed passive socket.
[0014] According to another embodiment is a processor in a mobile device for executing instructions to dynamically update firewall policies. The instructions may include: detecting at least one firewall; communicating with the at least one firewall; dynamically updating a policy associated with the at least one firewall. The processor may further include instructions to: the policy is automatically withdrawn at about the same time that the session is disconnected.
[0015] According to another embodiment is a handset that dynamically configures a firewall. The mobile phone comprises: an initializer that establishes a session with a firewall; a designator that designates at least one flow and transmits the at least one flow to a firewall; an invalidator operable to undo the passage of the at least one stream. According to some embodiments, the specifier may specify a parameter associated with at least one packet or request packets from one or more senders. According to some embodiments, the invalidator may revoke the passage of the at least one packet, re-request packets from one or more senders, automatically revoke the passage based on at least one packet parameter, or revoke the passage based on user input.
[0016] To the accomplishment of the foregoing and related ends, the one or more embodiments comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative aspects and are indicative of but a few of the various ways in which the principles of the various embodiments may be employed. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings and the described embodiments are intended to include all such aspects and their equivalents.
Drawings
[0017] FIG. 1 is a block diagram illustrating a communication system utilizing firewall technology;
[0018] FIG. 2 illustrates a system for client-assisted firewall configuration;
[0019] FIG. 3 illustrates a system for automatically and dynamically configuring firewall policies;
[0020] FIG. 4 illustrates a system for automatically and dynamically configuring firewall policies;
[0021] FIG. 5 illustrates a system for configuring a firewall and reducing network traffic;
[0022] FIG. 6 shows a flow diagram of a method of dynamically passing a legitimate incoming data stream;
[0023] FIG. 7 shows a flow chart of a method of automatic recovery of a data stream;
[0024] FIG. 8 illustrates a flow chart of a method of automating firewall protection and reducing network traffic;
[0025] fig. 9 shows a block diagram of a configuration concept of a terminal.
Glossary
[0026] Firewall-a device that only allows packets that satisfy a "security policy" to enter or leave the network.
[0027] Host-a network node that uses the network as a packet transmission medium. In a mobile device network, the host is typically a cell phone or a wireless computer.
[0028] Flow-bidirectional packet switching between two different entities.
Detailed Description
[0029] Various embodiments are now described with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more embodiments. It may be evident, however, that such embodiment(s) may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing these embodiments.
[0030] As used in this application, the terms "component," "module," "system," and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, or software in execution. For example, a component may be, but is not limited to: a process running on a processor, an object, an executable, a thread of execution, a program, and/or a computer. For ease of illustration, both an application running on a computing device and the computing device itself can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the internet with other systems by way of the signal).
[0031] In addition, various embodiments are described in the context of a subscriber station. A subscriber station can also be called a system, a subscriber unit, a subscriber station, mobile, host, handset, remote station, access point, base station, remote terminal, access terminal, user terminal, user agent, or user device. The user equipment may be a cellular telephone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), a handheld device having wireless communication capabilities, or other processing device connected to a wireless modem.
[0032] Moreover, various aspects or features described herein can be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from a computer-readable device, carrier, or media. For example, computer-readable media may include, but are not limited to: magnetic storage devices (e.g., hard disk, floppy disk, magnetic tape, etc.), optical disks (e.g., CD, DVD, etc.), smart cards, flash memory devices (e.g., card, stick, key drive, etc.).
[0033] Various embodiments are contemplated to be deployed around a system that includes multiple components, modules, etc. It is to be understood and appreciated that the various systems may include additional components, modules, etc. and/or may not include all of the components, modules, etc. shown in the figures. Combinations of these methods may also be used.
[0034] Referring now to the drawings, fig. 1 is a block diagram illustrating a communication system 100 utilizing firewall technology that may be implemented with a portable device or terminal, a portable (mobile) phone, a personal digital assistant, a personal computer (desktop or laptop), or other electronic and/or communication device. The system 100 includes a firewall 102, the firewall 102 filtering incoming and/or outgoing data, referred to as data or network packets 104 and 106. The firewall 102 may operate at a network operator, infrastructure equipment, or the like. Packets 104 and 106 may be any type of communication message that includes a set of data sent from one device and/or transmitted to another device. Firewall technology inspects each packet (incoming data), classifies each packet, and performs one or more actions based on the inspection and/or classification results. Typical actions are: passing packets through, intercepting packets, and/or routing packets in a particular manner. The stateful packet filter may also consider previously seen packets when performing classification.
[0035] Firewall 102 may allow data packet 104 from sender 108 to be transmitted to receiver 110, sender 108 being located on one side of firewall 102 and receiver 110 being located on the other side of firewall 102, but this is for example purposes and not limitation. Packets 104 transmitted by sender 108 destined to reach receiver 110 are relayed or otherwise permitted to pass through firewall 102. Packets 104 that are not intended and/or legitimate for the recipient 110 are intercepted by the firewall 102 and are not relayed to the recipient 110. In this way, the receiver 110 is unaware of, and does not receive, packets that the receiver 110 does not expect and/or unwanted packets.
[0036] The receiver 110 can communicate with the firewall 102 to provide a set of policy rules regarding packets 104 that the sender 108 and/or receiver 110 wishes the firewall 102 to pass through and packets that the receiver 110 wishes the firewall 102 to intercept. In this way, the recipient 110 acts as a server. In other words, the recipient 110 may want an external sender 108 to contact the recipient 110. Thus, the recipient 110 can communicate directly with the firewall 102 to dynamically update the policy.
[0037] Receiver 110 can also automatically determine which flows or packets 104 are intended by examining the passive socket list. For example, recipient 110 may open or create a passive socket to act as a server. Recipient 110 notifies firewall 102 that packets 104 destined for the socket should be transmitted to recipient 110. If the recipient closes contact with the web server, the previously created passive socket is closed. Recipient 110 may notify firewall 102 of the passive socket being closed and request firewall 102 to deny all other traffic destined for the passive socket.
[0038] The receiver 110 may also relay the packet 106 through the firewall 102 to the sender 108. In this way, the receiver 110 acts as a client and the firewall 102 may block the packet 106 or allow the packet 106 to be transmitted to the sender 108 according to various protocols and techniques. For example, firewall 102 may pass or reject packet 106 according to criteria predetermined by a network provider. The firewall 102 may also route the packet 106 according to a policy established by the intended recipient of the packet (in this case, the sender 108). Thus, firewall 102 may maintain different sets of rules or policies for different devices.
[0039] Fig. 2 illustrates a system 200 for client-assisted firewall configuration. The system 200 includes a firewall 202 and a host 204 (e.g., a mobile device) that may be communicating. For example, host 204 may be a cellular phone, smart phone, laptop, handheld communication device, handheld computing device, satellite radio, global positioning system, PDA, and/or other suitable device that communicates over wireless network 200. Although multiple firewalls 202 and hosts 204 may be included in the system 200, it should be understood that for simplicity only a single firewall 202 is depicted in the figure that sends communication data signals to a single host 204.
[0040] The host 204 includes a transmitter 206, and the host 204 can initiate a data flow or communication session via the transmitter 206 and/or request an update to a policy maintained by the firewall 202. The host may also include a receiver 208, and the host 204 may receive an acknowledgement or rejection of the policy from the firewall 202 through the receiver 208 and/or may receive a data stream or packet.
[0041] The host 204 may respond to packets sent from the firewall 202 via the transmitter 206. When host 202 issues a data stream, it acts like a client and is considered "active". When host 202 responds to a data stream, it acts like a server and is considered "passive". Active flows are considered outgoing while passive flows are incoming.
[0042] When the host 204 acts as a server, the host 204 can communicate directly with the firewall 202 and manipulate firewall rules. For example, the host 204 may inform the firewall 202 of particular communications, senders from which the host 204 wishes to receive communications, and so on. The host 204 can automatically notify the firewall 202 of any broken or interrupted sessions and revoke the policy of those sessions so that the firewall 202 will block those sessions from being transmitted to the host 204. Configuring firewall 202 in this manner, packets destined for host 204 but not intended for host 204 are intercepted before being sent. This reduces network traffic because the host does not send the packets first and then discard them. A determination is made in the firewall 202 before the packet is sent to the host 204.
[0043] Host 204 may include a decoder component (not shown) that may decode the received signal and/or data packets therein for processing. After successfully decoding the data packet, an acknowledgement component (not shown) can generate an acknowledgement to indicate successful decoding of the data packet and can send the acknowledgement to the firewall 202 to inform the sender of the communication (not shown) that the data packet has been received and decoded, and therefore, no retransmission is required.
[0044] Fig. 3 illustrates a system 300 for automatically and dynamically configuring firewall policies. System 300 includes a firewall 302 and a host 304 (e.g., a mobile device), firewall 302 may be included in a network infrastructure. Host 304 may receive incoming data packet 306 or may initiate outgoing data packet 308. When an incoming packet 306 is received, the host operates in a passive mode, functioning similarly to a server. When initiating an outbound packet 308, the host 304 operates in an active mode, functioning similarly to a client. The data packets 306 and 308 should generally pass through the firewall 302, whether in the ingress mode or the egress mode. Based on a set of rules or policies 310, the firewall 302 may intercept, pass through, or redirect the packets 306 and 308.
[0045] The host 304 may include a designator 312, an invalidator 314, and an initializer 316, which may be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware). The designator 312, the invalidator 314, and/or the initializer 316 may communicate directly with the firewall 302, or they may communicate via a transmitter (not shown) and a receiver (not shown). When a packet 306 destined for host 304 is transmitted to firewall 302, firewall 302 may determine whether packet 306 should be transmitted to host 304 or intercepted. Such a determination may be based on a predetermined policy 310. The policy includes various criteria such as allowed stream end points, resource limitations, etc. In some embodiments, policies 310 may be dynamically changed or modified by host 304 through selective enforcement techniques.
[0046] Specifier 312 may specify parameters associated with packet 306 that host 304 wishes to receive and communicate these parameters to firewall 302. These parameters need to be constrained by policy 310. Host 304 may request that a specified incoming stream (e.g., packet 306) be transmitted. The designator 312 may designate a flow by a set of criteria, e.g., matching (or not matching) some or all of the fields in the packet header. The packet typically has a header, and may also have a header of a higher layer protocol (e.g., Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), and/or Transmission Control Protocol (TCP), etc.). The criteria or parameters specified by the specifier 312 may include, but are not limited to: an exact value, a list of values, a range of values, an open socket, etc.
[0047] Invalidator 314 can request that the transfer of the specified flow or all flows already requested by host 304 be undone. For example, the designator 312 can request that one or more types of packets and/or packets from one or more senders should be transmitted to the host 304. Invalidator 314 may revoke a request for a particular packet if it is determined after the request to transmit the packet that the packet is no longer expected. Such revocation may be performed automatically and independently by system 300 based on certain parameters (e.g., packet size, packet type, or other criteria).
[0048] Revocation may also be based on user manual input received from host 304. For example, a packet may be designated for a user. However, the user may determine that such a grouping is no longer desirable for a variety of reasons. The user may manually drop these packets through an interface associated with the host, such as invalidator 314.
[0049] Host 304 may provide various types of user interfaces. For example, host 304 may provide a Graphical User Interface (GUI), a command line interface, and the like. For example, a GUI can be presented that allows a user to have a region or means to load, import, read, etc. parameter information, intercepted packets, intercepted senders, and/or system queries to prompt the user whether or not to want to intercept such packets/senders. These regions include known text regions and/or image regions including dialog boxes, static controls, drop-down menus, list boxes, pop-up menus, editable controls, combo boxes, radio buttons, selection boxes, push buttons, graphic boxes. In addition, things that facilitate the presentation, such as vertical and/or horizontal scroll bars for navigation, toolbar buttons to determine whether a region is visible, may also be used.
[0050] In one example, a command line interface may be used. For example, the command line interface may prompt the user (e.g., with a text message and tone on the display) to provide a text message. The user may provide appropriate information, such as greek numeric input, corresponding to options provided in the interface prompt or a response to a question presented in the prompt. It should be appreciated that the command line interface may be used in conjunction with a GUI and/or API. Further, the command line interface may be used in conjunction with hardware (e.g., video cards) and/or displays with limited graphics support capabilities (e.g., black and white displays, EGA displays) and/or low bandwidth communication channels.
[0051] The protocol periodically exchanges packets in both directions (ingress and egress) so the host 304 and firewall 302 can be aware of the disconnected session in time. For example, firewall 302 and/or host 304 can determine whether the session is disconnected based on whether there is a lack of traffic from peers (e.g., other mobile devices, other communication devices, etc.). The decision made based on the disconnected session may be included in the protocol as part of itself. In some embodiments, the determination may be provided by an underlying transport, such as a Transmission Control Protocol (TCP) live segment.
[0052] If it is determined that the session has been disconnected or terminated, the previously requested stream by host 304 may be automatically dropped. In this way, all packets destined for host 304 are automatically intercepted by firewall 302 and are not passed to host 304. Thus, disconnected sessions and/or incomplete packets are not transmitted along the wireless interface, and therefore do not occupy valuable and scarce resources.
[0053] The following description is for the purpose of illustration, and not for the purpose of limitation. Handset or host 304 may run a web server that creates a passive socket that listens on TCP port 80. The firewall control component (e.g., designator 312) may detect that a passive socket is created on TCP port 80. The control component establishes contact with firewall 302 requesting firewall 302 to pass the flow destined for handset TCP port 80. Firewall 302 may acknowledge or deny the request. Others may also send out an incoming stream to contact the web server of the handset. Later, the handset's web server will shut down, thereby closing the passive socket on TCP port 80. At about the same time or significantly different, the firewall control component on the handset can detect the closing of the passive socket. The control component may establish contact with the firewall and request that the firewall deny all other traffic to the handset on TCP port 80. It should be appreciated that in IP networks, the flow may differ significantly from that described above, since both the flow and the topology are for the endpoint address.
[0054] Host 304 may establish a session through initializer 316 in order to initiate a new session or to recover from a disconnected session and then automatically drop the data stream. The initializer 316 is able to determine with which firewall 302 the host 304 is communicating because the host 304 may be a mobile device that may move from one geographic area or cell to another. As the device moves, it may need to establish contact with one or more firewalls. The initializer 316 can communicate with the specifier 312 and request that the desired stream be delivered (or re-requested for a disconnected session).
[0055] Fig. 4 illustrates a system 400 for automatically and dynamically configuring firewall policies. The system 400 includes a firewall 402, the firewall 402 capable of transmitting, intercepting, or rerouting incoming packets and/or outgoing packets. There is also a host 404 that may include a designator 406, an invalidator 408, and an initializer 410. Host 404 operates in a passive mode for incoming packets and an active mode for outgoing packets. The system 400 operates in a manner similar to the system 300 shown in fig. 3.
[0056] The system 400 may include a memory 412 operatively connected to the host 404. The memory 412 may store information related to requested incoming flows, matching criteria, designated flows, dropped flows, open network sockets, etc., all of which involve configurable firewall techniques and reduce traffic in the wireless communication system. The processor 414 is operatively coupled to the host 404 (and/or the memory 412) for analyzing information related to configurable firewall techniques and reducing traffic in the wireless communication system. Processor 414 may be dedicated to analyzing information received by the host and/or generating information to be transmitted by host 404, controlling one or more components of system 400, and/or both analyzing and generating information received by host 404 and controlling one or more components of system 400.
[0057] The memory 412 may store protocols relating to expected packets, packet flows, senders, communication types, etc., and take steps to control communications, etc., between the host and the firewall 402, so that the system 400 may use the stored protocols and/or algorithms to reduce communication traffic in the wireless network, as described above. It will be appreciated that the data store (e.g., memories) components described herein can be either volatile memory or nonvolatile memory, and can include both volatile and nonvolatile memory. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory, by way of example only, and not by way of limitation. Volatile memory can include Random Access Memory (RAM), which acts as external cache memory. RAM is available in many forms, such as synchronous RAM (DRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM), by way of example only, and not by way of limitation. The memory 412 of the disclosed embodiments is intended to comprise, without being limited to, these and any other suitable types of memory.
[0058] The system 500 shown in fig. 5 is used to configure firewalls and reduce network traffic. The illustrated modules may be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware). System 500 may include a detector 502 that may detect one or more firewalls in a network. The communicator 504 may communicate with the detected firewall. Such communications may include, but are not limited to: requesting a session to be established, indicating to let a specified incoming flow pass, dropping one or more incoming flows, or other types of communications. The system 500 also includes an updater 506 that can update policies associated with a firewall. The update policy may include changes to an existing policy that are automatically determined by the system 500 or changes that are manually entered into the system 500 by a user.
[0059] In some embodiments, system 500 may also include a checker 508 and a designator 510. The checker 508 can check a list of open network sockets, which can be open passive network sockets. Designator 510 can generate an appropriate request to the firewall when listening for a passive socket, and can generate a revocation when the passive socket is closed. If the system 500 is recovering from a disconnected or terminated session, the passive sockets in the current list can be enumerated to generate the appropriate request.
[0060] With respect to the exemplary systems described above, methodologies that may be implemented in accordance with one or more aspects of various embodiments are better appreciated with reference to FIGS. 6-8. While, for purposes of simplicity of explanation, the methodologies are described and shown as a series of acts (or functional blocks), it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance with the methodologies, occur in different orders and/or concurrently with other acts from that shown and described herein. Moreover, not all illustrated acts may be required to implement a methodology in accordance with one or more aspects of the described embodiments. It should be understood that various acts may be implemented in software, hardware, a combination of software and hardware, or other suitable means (e.g., devices, systems, processes, components) that perform the functions associated with the acts. It should also be appreciated that these acts are merely illustrative of certain aspects of the present application in a simplified manner, and that these aspects may also be illustrated using a lesser and/or greater number of acts. Moreover, not all illustrated acts may be required to implement a methodology in accordance with the following. Those skilled in the art will appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram.
[0061] Fig. 6 is a flow diagram of a method 600 of dynamically admitting a legitimate incoming data stream. The legitimate incoming data stream was requested in advance by the device. For example, a device may know or infer from a previously received flow that it will drop a particular type of traffic, source-specific traffic, etc., if it receives the traffic, or will refuse to receive the traffic when it receives it. The device may also obtain this information based on user-specified parameters. Rather than waiting until such unexpected and/or unpredictable streams are received at the device, the device can identify the streams (e.g., type, source, etc.) before sending them to the device, thereby utilizing valuable bandwidth and resources.
[0062] The method 600 begins at 602, where a pass request is received. The communication request includes information regarding the type, source (from which the mobile device wishes to receive communications), etc. This information may be predetermined by the device and stored on the network periphery or on the firewall. If a pass request has been received for some of the traffic streams, it is sent to the device. If no traffic request is received for some traffic flow, it is intercepted before being sent to the device.
[0063] Various criteria may be used to specify the streams that should match the transmission criteria. In some embodiments, the various criteria may be information that the streams should not match. For example, the criteria may be some or all of the fields in the packet header. The header is the part of the message that contains information that directs how the message reaches the correct destination. The header includes a sender address, a receiver address, a priority, routing instructions, synchronization pulses, and the like. The IP packet may have a higher layer protocol header, such as Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), and/or Transmission Control Protocol (TCP). The criteria may include an accuracy value, a list of values, and/or a range of values.
[0064] At 604, a determination is made as to whether a request to cancel has been received. The undo request may be for a specified flow, or it may be for all flows that have been previously requested. If the determination at 604 is that a revocation request has not been received ("NO"), the method 600 proceeds to 606, whereupon streaming is allowed to the device. If the determination at 604 is that a request to cancel has been received ("YES"), the method 600 proceeds to 608, whereupon the pass is intercepted before being sent to the device.
[0065] In the method 600 described above, a network firewall may receive a pass request and a revocation of a requested flow from a mobile device (e.g., a handset). Depending on whether the network firewall receives a pass and/or drop request from the mobile device, the network firewall may allow or intercept the passage of incoming data streams.
[0066] Fig. 7 is a flow diagram of a method 700 of automatically restoring data flow. In some cases, a session established by requesting the remote firewall to permit passage of at least one open socket may be disconnected, interrupted, or terminated for various reasons, when it is desired to provide automatic recovery. At 702, the host and/or firewall detect a disconnected session. Since the protocol periodically exchanges (e.g., ingress, egress) packets in both directions, both the host and the firewall are aware of the disconnected session in time, in most cases occurring at approximately the same time as the session disconnection. Such awareness may be due to the lack of observation of traffic from the peer devices. This may be performed as part of the protocol itself or provided by an underlying transport (e.g., a TCP live segment).
[0067] When the session is disconnected or terminated, the corresponding host requested flow is dropped 704. By dropping the requested stream, the integrity and confidentiality of the host is protected. Thus, no traffic is allowed to pass to the host, and such traffic is blocked before being sent to the host, thereby not taking up bandwidth.
[0068] According to some embodiments, if the host wants to resume the data flow, a new session may be reestablished in 706. The new session may be based on the new request or it may be based on the re-establishment of a passive socket list to generate an appropriate request. At 708, a pass request (or re-request) for the desired flow is established.
[0069] In the method 700 described above, for example, an apparatus (e.g., a mobile device) may detect a disconnected session and contact a network firewall to drop a requested flow. The device may reestablish a new session with the firewall and request the intended flow pass if desired (by the user).
[0070] Fig. 8 is a flow diagram of a method 800 of automatic firewall configuration and reduction of network traffic. Reduced network traffic may include unwanted and/or unexpected traffic, disconnected sessions, terminated sessions, and so forth. In 802, the handset wishes to receive an incoming communication stream and operate in a passive mode or act as a server. At 804, the handset creates a passive socket. For example, a passive socket may be on a TCP disconnect 80. In some embodiments, passive sockets may be included in a series of open passive sockets, which are periodically or continuously monitored for changes, modifications, etc. At 806, contact or communication is established with the firewall. This contact or communication may be triggered when a passive socket is created. In 808, the communication can include a remote firewall policy update, e.g., the firewall grants the flow a request to a passive socket. The communication may also include a list of passive network sockets resulting from one or more open sessions. The list may also include those services that the host is aware of and those services that the host is providing at any given time.
[0071] An ingress flow originated by an external party to one or more of the listed open passive sockets may be granted access by the firewall. If the web server shuts down or terminates, the passive socket on TCP port 80 is closed. At 810, a determination is made as to whether the passive socket is on or off (e.g., terminated or destroyed). If the socket is on ("yes"), then in 812, the transfer or continuation of the transmission of the foreign packet, flow, communication, etc. is permitted. If the socket is off as a result of the determination at 810 ("no"), then a revocation request is generated at 814. The revocation request may be automatically sent upon detection of a socket closure. The request may include an instruction to the firewall to deny further traffic to TCP port 80. When resuming from a disconnected or terminated session, the current list of passive sockets may be listed to generate an appropriate request.
[0072] In the method 800 described above, for example, the mobile device may establish a network connection, detect an open passive socket, establish contact with a firewall, and request an admitted flow. The mobile device may also determine whether the passive socket is on or off and, if so, generate a revocation request directed to the firewall.
[0073] Referring now to fig. 9, a conceptual block diagram of a possible configuration of a terminal 900 is shown. Those of ordinary skill in the art will appreciate that the exact configuration of terminal 900 can vary depending on the particular application and the overall design constraints. The processor 902 may implement the various embodiments disclosed herein. Terminal 900 can have a front-end transceiver 904 coupled to an antenna 906. The baseband processor 908 may be coupled to the transceiver 904. The baseband processor 908 may be implemented with a software-based architecture or any other type of architecture. The microprocessor may serve as a running platform for software programs that provide control and overall system management functions, etc. A Digital Signal Processor (DSP) may have an embedded communication software layer to run specialized algorithms to reduce the processing requirements of the processor. The DSP may be used to provide various signal processing functions such as pilot signal acquisition, time synchronization, frequency tracking, spread-spectrum processing, modulation and demodulation functions, and forward error correction.
[0074] The terminal 900 can also include various user interfaces 910 coupled to the baseband processor 908. The user interface 910 may include a keyboard, mouse, touch screen, display, ringer, vibrator, speaker, microphone, camera, and/or other input/output devices.
[0075] The baseband processor 908 includes a processor 902. In a software design of the baseband processor 908, the processor 902 may be a software program running on a microprocessor. However, those of ordinary skill in the art will appreciate that the processor 902 is not limited by this embodiment and may be implemented by any means known in the art, including a hardware configuration, a software configuration, or a combination thereof, provided that it is capable of performing the various functions described herein. The processor 902 may be coupled to the memory 912, the memory 912 for storing data.
[0076] It is to be understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. When the systems and/or methods are implemented using software, firmware, middleware or microcode, program code or code segments, they can be stored in a machine-readable medium, such as a storage medium. These necessary tasks are performed by a processor. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
[0077] The above description includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the aforementioned embodiments, but one of ordinary skill in the art may recognize that many further combinations and permutations of various embodiments are possible. Accordingly, the embodiments described in this application are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.

Claims (33)

1. A method for use by a mobile device to configure a firewall to reduce unwanted network traffic, comprising:
establishing network connection with a network firewall; and
communicating with the network firewall to manage network traffic.
2. The method of claim 1, further comprising:
detecting whether a passive socket has been created; and
requesting the network firewall to permit the flow through to the passive socket.
3. The method of claim 2, further comprising:
closing the web server;
destroying the passive socket;
contacting the firewall; and
requesting the firewall to deny passage of a flow to the passive socket.
4. The method of claim 2, further comprising:
determining whether the passive socket is open or closed; and
if the socket is open, other communications directed to the passive socket are permitted to pass.
5. The method of claim 2, further comprising:
determining whether the passive socket is open or closed; and
automatically revoking the request for the firewall to permit the flow to the passive socket to pass.
6. A method for a host to automatically recover from a disconnected session, comprising:
requesting the remote firewall to permit passage of packets destined for the at least one open socket;
detecting a disconnected session;
revoking a packet request directed to at least one open socket;
reestablishing a new session; and
request to let the desired stream go through.
7. The method of claim 6, requesting permission to pass packets destined for the at least one open socket comprising:
a list of currently open sockets is generated.
8. The method of claim 6, requesting to pass the intended stream comprising:
the open socket list is regenerated.
9. The method of claim 6, detecting a disconnected session comprising:
determining that the at least one open socket is closed.
10. The method of claim 6, detecting a disconnected session comprising:
no traffic from peer devices is observed.
11. A mobile device for configuring a network firewall, comprising:
a processor that analyzes information related to configuring a firewall to reduce traffic; and
a memory operatively connected to the processor.
12. The mobile device of claim 11, further comprising:
an establisher that establishes communication with an external source; and
a designator that designates parameters related to packets received from the external source and transmits the parameters to a firewall.
13. The mobile device of claim 12, said external source being a web server.
14. The mobile device of claim 12, the parameter being an open passive socket.
15. The mobile device of claim 12, further comprising:
an invalidator requesting to revoke the passage of the at least one parameter.
16. The mobile device of claim 11, further comprising:
a transmitter to transmit at least one policy update to a firewall; and
a receiver that receives an acknowledgement or a denial of the policy from a firewall.
17. An apparatus in a mobile device for reducing network traffic, comprising:
a detection module that detects at least one firewall;
a communication module in communication with the at least one firewall; and
an update module that dynamically updates policies related to the at least one firewall.
18. The apparatus of claim 17, further comprising:
a monitoring module that monitors a list of passive sockets.
19. The apparatus of claim 17, further comprising:
a designation module that designates an expected incoming flow.
20. A computer-readable medium for use in a mobile device, the medium comprising computer-executable instructions for:
establishing network connection;
detecting a passive socket related to the established network connection;
contacting the firewall; and
requesting the firewall to permit the flow through to the passive socket.
21. The computer-readable medium of claim 20, further comprising computer-executable instructions for:
disconnecting the network connection;
destroying the passive socket;
contacting the firewall; and
requesting the firewall to deny passage of a flow to the destroyed passive socket.
22. The computer-readable medium of claim 20, further comprising computer-executable instructions for:
determining whether the passive socket is open or closed; and
if the socket is open, other communications directed to the passive socket are permitted to pass.
23. The computer-readable medium of claim 20, further comprising computer-executable instructions for:
determining whether the passive socket is open or closed; and
automatically revoking the request for the firewall to permit the flow to the passive socket to pass if the passive socket is closed.
24. A processor for use in a mobile device to execute instructions to dynamically update firewall policies, the instructions comprising:
detecting at least one firewall;
communicating with the at least one firewall; and
dynamically updating a policy associated with the at least one firewall.
25. The processor of claim 24, the instructions further comprising:
the policy is automatically withdrawn at about the same time that the session is disconnected.
26. A handset to dynamically configure a firewall, comprising:
an initializer that establishes a session with a firewall;
a designator that designates at least one flow and transmits the at least one flow to a firewall; and
an invalidator operable to undo the passage of the at least one stream.
27. The handset of claim 26, said designator designating a parameter associated with at least one of the packets.
28. The handset of claim 27, said parameter comprising one of:
accurate value, list of values, value field, and open socket.
29. The handset of claim 27, said invalidator revoking the passage of said at least one packet.
30. The handset of claim 26, said designator requesting packets from one or more senders.
31. The handset of claim 30, said invalidator invalidating requests for packets from one or more senders.
32. The handset of claim 26, said invalidator automatically invalidating said pass based on at least one grouping parameter.
33. The handset of claim 26, said deactivator cancelling said pass in response to user input.
HK08107176.3A 2004-12-21 2005-12-21 Client assisted firewall configuration HK1112348A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US60/638,271 2004-12-21

Publications (1)

Publication Number Publication Date
HK1112348A true HK1112348A (en) 2008-08-29

Family

ID=

Similar Documents

Publication Publication Date Title
CA2591933C (en) Client assisted firewall configuration
US11949654B2 (en) Distributed offload leveraging different offload devices
US7853998B2 (en) Firewall propagation
US11159361B2 (en) Method and apparatus for providing notification of detected error conditions in a network
US7559082B2 (en) Method of assisting an application to traverse a firewall
WO2006041080A1 (en) Firewall system and firewall control method
US20050160165A1 (en) Network management using short message service
US11838317B2 (en) Method for providing a connection between a communications service provider and an internet protocol, IP, server, providing a service, as well as a perimeter network, comprising the IP server, and an IP server providing the service
US20060059552A1 (en) Restricting communication service
WO2007014507A1 (en) System and method for controling ngn service-based firewall
CN101340275B (en) Data card and its data processing and transmission method
KR20070110864A (en) Method, apparatus, and computer program product for enabling negotiation of firewall features by endpoints
WO2007003992A2 (en) Method, system & computer program product for discovering characteristics of middleboxes
US12238064B1 (en) Software defined perimeter integration for software defined cellular telecommunications networks
HK1112348A (en) Client assisted firewall configuration
Moser et al. Extending software defined networking to end user devices
US9338021B2 (en) Network traffic redirection in bi-planar networks
JP2007519356A (en) Remote control gateway management with security
Gopal et al. User plane firewall for 3G mobile network