Patent Application
20070271453
According to the present invention the nodes will become addressable in an overlay network. In embodiments of the invention, the nodes have IPv6 address in the overlay network thus avoiding the limitations of the IPv4 address space.
Internet nodes that are behind NATs (Network Address Translators) or NAPTs (Network Address and Port Translators) and/or firewalls typically have grey IP address that is usually dynamically allocated (through DHCP (Dynamic Host Configuration Protocol)). The grey IP address is not routable in the Internet, and it would not make sense to map a hostname to such IP address. Usually such nodes are only able to initiate connections as Party A (originating party) to Internet nodes (located on the other side of the NAT/NAPT/Firewall).
In specific configurations dynamic DNS server in Internet can be utilized to first determine the currently valid IP address of the node (as it is visible in the Internet), and then to associate this IP address to hostname. The dynamic DNS server will then serve this information in the Internet Name server network. Depending on the network configuration between the node and the Internet (especially NAT/NAPT/Firewall) just by making the association (hostname, IP address) is not enough for truly communicating with the node from Internet.
The combination of dynamic DNS with tunneling enables the terminal to have IP address that stays valid, and it handles NAT, NAPT and firewall traversal issues.
As with addressability, Internet nodes that are behind NATs or NAPTs and/or firewalls typically have grey IP address that is usually dynamically allocated (through DHCP). The grey IP address is not routable in the Internet, and it would not make sense to map a hostname to such IP address. Usually such nodes are only able to initiate connections as Party A (originating party) to Internet nodes (located on the other side of the NAT/NAPT/Firewall).
It is possible to utilize known tunneling technologies (like IPSec, PPTP (Point-to-Point Tunnelling Protocol), Teredo) that tunnel all communication in and out of the node through a tunneling server (or all the way end-to-end). When initiating tunneling connection from node (e.g. mobile terminal) towards Internet, the NAT/NAPT/Firewall traversal problems can be mitigated. The networks where the nodes like mobile terminals are, usually allow communication towards Internet to be initiated, but they block communication from Internet towards the nodes in these networks (due to security or charging issues).
Furthermore, the tunneling protocols may contain functions such as heartbeat that will keep alive the connection from the node to the tunneling server in the Internet. They may also contain functions to identify if communication can be initiated directly between two nodes, bypassing need for tunneling server supported communication between those nodes.
In embodiments of the invention the tunneling protocols are used to connect all nodes to an overlay network where each terminal is assigned an IP address that is reachable in that network by other nodes of the same network. The overlay network is another network set up on top of multiple networks (i.e., the Internet).
Utilizing any one or two of IPv6 addresses for mobile terminals, providing (dynamic) DNS entries, or implementing tunneling may not solve addressing and reachability problem of mobile terminals (or home PCs or set top boxes).
It has been found that the combination of the three in the following manner can solve the stated problems in a way that is independent of the network configuration of the network the node is currently in:
An overlay network is defined. This overlay network is a network built on top of the current IPv4 network, and it is IPv6 based.
Nodes that are behind NAT/NAPT/Firewalls initiate themselves connection to tunneling server that provides access to the IPv6 overlay network. Multiple tunneling technologies can be utilized and some tunneling servers may support only one or all of the tunneling technologies utilized. Heartbeat function for created tunnel might be used to keep the tunnel open, when required.
Tunneling server assigns the node an IPv6 address that is routable in the overlay network. The tunneling server stores at runtime the association between the nodes “real address”, i.e., the IPv4 Internet address and the current IPv6 address. Thus it is capable of routing packets with IPv6 address through tunnel to the corresponding node.
Nodes update their (or alternatively the tunneling server does this on their behalf) overlay network address to dynamic IPv6 DNS server available to other nodes in the overlay network.
The result is that all nodes connected to the overlay network can request with hostname the current IPv6 address of another node connected to the overlay network. The (hostname, IPv6 address) pair is kept valid as the information is updated to the dynamic DNS server always the IPv6 address changes.
Because the IPv6 address of the node is assigned by the tunneling server (one function of “Proxy server” described below), the IPv6 packets in the overlay network will be routed to this tunneling server based on known Internet technologies. Furthermore, as the tunneling server knows the IPv4 addresses from each of the nodes connected to it, it can route the IPv6 packets correctly to the tunneling clients it has.
To solve the addressing and reachability of the mobile terminals (and home appliances), in Internet a stack of the mobile terminal capability to tunnel communication through an overlay network is implemented, and this capability is provided to applications. An overlay network is created in Internet where terminal registers. (Various) operators are enabled to take part into operating the overlay network. First applications are created to utilize the solution and that accumulate value to the terminal, (e.g., implementing web server to terminals, with sufficient access control to limit cost implications).
An overlay network is a virtual network built over one or more physical networks. The Internet is itself an example of an overlay network. In overlay networks the individual links that connect nodes can comprise multiple routers and hosts. The chosen architectural approach is based on overlay proxy servers where the clients of the overlay network register to get addressing, reachability and packet filtering services. The packet routing, which is based on known Internet technologies, takes place between the proxy servers. Enhancements to proxy based overlay architecture enable clients to communicate directly with each other in specific cases (i.e., packets routable directly between clients).
The present invention combines technology blocks such as firewall, tickets (or vouchers or shared secret) in a way that the combination may provide more value than the technology blocks each alone.
In the following it is described how firewall(s) and tickets/shared secret exchanged between nodes (parties A and B) can be used to weed out unwanted incoming traffic before it causes costs to the receiving party (especially in case of cellular packet network where the receiving party pays for incoming traffic).
If packets are routable for example to a mobile terminal, the receiving party may have to pay for the incoming traffic. However, the network does not provide any means to allow or block incoming traffic based on party sending the packets or the application (port) for which the packet is intended. If mobile terminals become addressable and reachable by other nodes in the Internet (or on an overlay network set up on top of the Internet), unless the network and client software implementations are under strong control, it is not possible to keep nodes either from sending packets to any node in the network (not knowing the receiver) or to keep nodes from targeting specific hostname. Thus, filtering out of incoming packets is an issue.
As mentioned above, the invention is to combine technologies of firewall (network side and in special case, on the node itself), and tickets (based on vouchers and/or shared secret between the nodes). The invention does not require a “Managed” or safe underlying network. The trust relations needed are only between the node and the entity in network handling the firewall function, and between the nodes that have either exchanged the shared secret, or otherwise generated a ticket that enables the other specific node to make firewall traversal when connecting the node.
As described above, a node has joined the overlay network, and established tunneling connection with a tunneling server (function) of a proxy server. The proxy server contains two new functionalities, firewall and firewall authorization/authentication server. Here, the authorization/authentication server is called firewall managing server.
The firewall is programmed by default to block all incoming traffic towards the node (it may also by default block all communication from the node until the node has provided it credentials, this is optional).
In general, the firewall may as well be a firewall on the administrative boundary of a company, and have nothing to do with the connectivity network.
Authorization where Party B gives (directly or indirectly through a third party) rights to Party A may be based on multitude of approaches. One general approach is to utilize a shared secret where both nodes know something nobody else does, and by checking credentials sent by the other party the authorization is given.
Another approach is to use public key cryptography in a way that Party B provides party A a signed ticket, and this ticket is checked against Party B's public key when Party A needs to be authorized, as shown in
For example, as shown in
The ticket is based on certificates that identify a user (or a device). The Certificate is trusted by out of band means by the issuer of the ticket.
The Ticket typically includes parameters such as
Hostname of Service Provider
URL of Service Provider authorization server
Certificate of Service Provider (original issuer, optional)
Certificate of consumer
Validity period
Forwarding rules (e.g. how many steps are allowed)
Signature of ticket issuer (over the complete ticket)
Unique ticket identity
The Certificate may be issued by a Certificate Authority, or it may be self-signed. The level of trust defines the usage space and conventions. In many cases, especially in peer to peer applications, it is enough that the issuer of the ticket knows that the intended consumer is in possession of the certificate, and trust the consumer to keep the associated private key secret.
The ticket can be defined to be valid for a dedicated consumer only, or it can be defined to allow for forwarding. The forwarding allows for delegation of ticket distribution. When a ticket is forwarded the original ticket is appended with the certificate of the new consumer, and this new ticket is singed by the private key of the forwarding consumer. This mechanism creates a forwarding trail in the ticket that can be evaluated by the Service Provider when the ticket is used for service authorization.
The ticket is signed by the issuer, and thus an atomic unit. It includes the absolute expiry time relative to the Service Providers clock. Thus, if a ticket is forwarded it still expires at the exact time defined in the original ticket.
The ticket distribution can be executed in several different contexts, for example by means of messaging (email), online transaction, or in proximity environments (like Bluetooth or Infrared).
The service provider may at any time revoke tickets. This can be done either by revoking a specific ticket, or by revoking all the tickets that are issued to a specific certificate. Both of these revocation methods make it possible to revoke specific tickets, or chains of tickets created by forwarding.
There are situations, for example online ticket distribution, where the consumer does not yet have a ticket. It is then possible to out of band deliver a shared secret, such as a PIN code, to the consumer, and temporarily configure the firewall managing server to accept this particular shared secret.
In an environment such as the connectivity network described above, utilizing only a firewall with (semi) static rules for filtering unwanted incoming packets is not appropriate. There may be specific cases where access should be provided from home PC or some other system in the Internet to access always the mobile phone, but even in those cases the IP address may change, and a hostname would be more preferably identified. However, this would lead to gethostbyname type of queries by the firewall affecting its scalability greatly.
Utilizing only authorization end-to-end between nodes may not enable filtering unwanted packets before they enter the radio interface, incurring costs to the receiving party.
It is the combination presented by the invention that can solve the stated problems:
A firewall is placed in the network. All overlay communication towards node (Party B) goes through this firewall. The firewall may be optimized to handle the following type of rules: 128-bit IPv6 source address, 128-bit IPv6 destination address, drop or forward, and validity period for forwarding.
A logical entity called Firewall managing server is placed in the network. This entity may have two functions, verification/authentication server and authorization server. The firewall managing server may be part of the firewall. In an alternative, it is a separate entity as this may enable better scalability of the firewall.
As shown in communication 1. in
Party B keeps its own hostname, and the hostname of the Firewall managing server always up-to-date when it is connected to the overlay network. The overlay network configuration has provided it address pair of proxy (tunneling) server and firewall managing server. Party B may set the hostname of the Firewall managing server to invalid address 0000:0000: . . . if it does not require authorization—thus indicating to any connecting party that the authorization process can be terminated.
Party B provides to the authorization server function of firewall managing server its public key(s) used for verification of the remote host authorization attempts (cf. communication 2. in
As shown in communication 3. in
When the authorization server function of the Party B's FW managing server receives over a connection the ticket from A, it will make authorization challenge to Party A. This may be done to ensure that Party A is really the party A that the ticket was generated for (cf. communications 4, 5 in
If authorization challenge is successful, the FW managing server will set firewall rule to accept packets from the Party A's IPv6 address to Party B's IPv6 address (cf. communication 6 in
The result is that only those nodes that have Party A's IPv6 address or which can successfully spoof source address, can send packets over the radio interface to party B.
Because a secure end-to-end connection (based on SSL, IPSEC, or other technology) is not provided, this provided level of security is only used for filtering unwanted packets.
If during the handshake between Party A and the Firewall managing server additional credentials are created, these can easily be used to set up secure end-to-end connection if needed.
In the following an enhancement of the invention will be described.
Considering a case where a terminal (Party B) is connected through access that does not have incoming traffic implications, it can set the address of its hostname for firewall managing server to invalid address. This would effectively give possibility to any node (Party A) to send packets to this node, which may not be desirable.
Another approach is to implement in the Party B:
Local Firewall that can be controlled similarly as the above-described firewall in the network, i.e., with the setting of firewall rules for dropping or forwarding packets.
Local Firewall managing server.
Party B updates the hostname in the dynamic DNS server to point to its current IPv6 address (i.e., the hostname of Party B's node and the firewall managing server hostname both point to the IPv6 address currently valid for Party B node).
Unless Party A has got authorization from the local Firewall managing server of Party B, the local firewall in Party B's node will not forward packets from Party A's IPv6 address to any of the applications. This provides IPv6 address granularity for the Party B to weed out unwanted packets, and to base the approach on the same ticket paradigm as with the “network supported” case described above.
This may not solve the filtering of incoming packets before they enter the radio interface of Party B. However, it may still provide value by limiting what parties can send packets to Party B even if it is connected over link where there is no cost implications for incoming packets (for example, to limit strain on batteries).
Another enhancement of the invention is for Party B to generate more than one type of tickets that are provided to other parties, including Party A. The approach is similar to the enhancement case above. However, additional functions are needed in terminal of Party B as follows:
Generation of multiple concurrently valid tickets
Local association of ticket to applications that it enables, for example Visitor ticket only provides access to mobile web server to view my pictures of share folder.
Firewall with the rules of format:
In the following an embodiment of the invention will be described.
The embodiment provides enhancements or functionality in an overlay network client to help it function more effectively in the connectivity overlay network.
As described above, there are ways of using firewalls where the owner of the node protected by the firewall hands out credentials to other nodes. By presenting proper credentials, an external node can reconfigure the firewall so as to initiate IP-traffic with the protected node. A firewall in the context of the present application may also comprise functions not present in all firewalls, such as allowing a certain volume of flow from a defined IP address.
The same concept can be applied both to local (on the node itself) and remote (on a device upstream on the routing path) firewalls. Remote firewalls can be used as a cost-control mechanism—not just access control—if the cost of the Internet connection of the node increases with the increased IP-traffic.
For purposes of this invention, cases are considered where the credentials used by the external node to reconfigure firewall are such that they can be used to identify the party using the credentials. For example: The party is a member of a given group, the party is such and such node, the party is such and such person, the party is the same party as the one who last reconfigured the firewall 10 hours and 3 minutes ago.
According to the embodiment,
quota policies and parameters for third parties may be decided;
the third party may be required to identify itself in order to be able to initiate any IP-traffic to an own node (in practice, this means that there is a firewall in place);
notes may be taken as to which IP address(es) the third party is using;
the amount of traffic through the firewall caused by each third party (including traffic initiation by own node) may be monitored;
if the third party is causing too much traffic inbound, the firewall may be caused to send a flow control message to the node(s) of the third party in order to reduce the flow; and
if the third party is causing too much outbound traffic, the firewall may be caused to send the flow control message to the own node.
The quota policies can be quite simple, such as “Third party X can use Y bits per second”, or they can be quite complex taking into account the overall bandwidth being used at any given time or the bandwidth used by the third party over different periods of time, and the like.
If the invention is used with a policy containing long term restrictions, e.g. bits per one month, the decisions about sending the control messages should use some more complex logic than simple thresholding of the number of bits. Differential, integrating and derivative controllers (so called PID controllers), rule based logic, artificial intelligence or fuzzy logic are some alternatives.
The application level control can be based on the IP port numbers or there can be some other system to match connections to different applications.
The ICMP protocol is a simple way to control all IP traffic. Other protocols, if supported and understood by the firewall, can be used as well. The other protocols may have limited effect e.g. because they are dealing with audio stream only or file transfer only.
Used bearer type can also influence the currently applied quota policy: cost, power consumption etc.
Current resource consumption situation can also influence applied quota: for example, how much a user utilizes device resources for applications serving herself/himself, and how much she/he can afford to be used to serve remote users.
In an addition to the control of traffic on the node level, the invention can be used to control traffic on the application level. For example, better quota policies can be configured for one application than another. Then the traffic for one application could not be limited even if the traffic for another application is already started to be limited. This application level control may be or may not be connected to the node identities. Then it is possible to have the same application quota policies for all the nodes or have the node identity based control on applications.
The node 30 hosting the service(s), referred to as serving node in the following, decides quota policies and parameters for third parties, including e.g. bandwidth parameters for the remote node 20. In communication 1 in
The remote node 20 is required to identify itself at the firewall 10 to be able to initiate any IP traffic to the serving node 30 (communication 2. in
The firewall 10 makes notes which IP address(es) the remote node 20 is using and starts monitoring the IP traffic caused by the remote node 20 (process 3. in
In communications 4a., 4b., to 6a., 6b, the remote node 20 sends IP packets 1 to 3 to the serving node 30 through the firewall 10.
According to traffic restrictions for the remote node 20, after having received the third IP packet the firewall 10 may send a flow control message to the remote node 20 in order to reduce the flow (communication 7. in
Then, after a while, again in accordance with the traffic restrictions for the remote node 20, the firewall 10 sends a further flow control message to the remote node 20 (communication 8. in
Thereupon, the remote node 20 sends a further IP packet (IP packet 4, communications 9a., 9b. in
Upon receiving the IP packets from the remote node 20, the serving node 30 starts to send IP packets 5, 6 to the remote node 20 through the firewall 10 (communications 10a., 10b., and 11a., 11b. in
In the above example, merely three IP packets are allowed to be transmitted between the remote node 20 and the serving node 30 within a short time interval. However, this is only an example and other restriction policies are possible.
It is to be understood that the above description is illustrative of the invention and is not to be construed as limiting the invention. Various modifications and applications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 06114280.8 | May 2006 | EP | regional |
