Source: http://www.google.com/patents/US20040057430?dq=5435091
Timestamp: 2016-12-03 05:21:07
Document Index: 183093999

Matched Legal Cases: ['art 102', 'art 103', 'art 102', 'art 102', 'art 103', 'art 102', 'art 103', 'art 102', 'art 103', 'art 102', 'art 102', 'art 102', 'art 103', 'art 103', 'art 102', 'art 103', 'art 103', 'art 102', 'art 102', 'art 102', 'art 102', 'art 102', 'art 103', 'art 103', 'art 102', 'art 1101', 'art 1101']

Patent US20040057430 - Transmission of broadcast packets in secure communication connections ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA method and devices are provided for handling a broadcast packet in a computer (131, 132, 612, 622, 632, 711, 721, 731, 741, 1111, 1112, 1301) that has an IPsec-protected connection to a part (121, 122, 141, 732, 733, 742, 743, 1113, 1114) of a logical network segment (101, 601, 701, 1101) within which...http://www.google.com/patents/US20040057430?utm_source=gb-gplus-sharePatent US20040057430 - Transmission of broadcast packets in secure communication connections between computersAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20040057430 A1Publication typeApplicationApplication numberUS 10/611,358Publication dateMar 25, 2004Filing dateJun 30, 2003Priority dateJun 28, 2002Also published asUS7505473Publication number10611358, 611358, US 2004/0057430 A1, US 2004/057430 A1, US 20040057430 A1, US 20040057430A1, US 2004057430 A1, US 2004057430A1, US-A1-20040057430, US-A1-2004057430, US2004/0057430A1, US2004/057430A1, US20040057430 A1, US20040057430A1, US2004057430 A1, US2004057430A1InventorsSanteri PaavolainenOriginal AssigneeSsh Communications Security Corp.Export CitationBiBTeX, EndNote, RefManPatent Citations (6), Referenced by (25), Classifications (11), Legal Events (10) External Links: USPTO, USPTO Assignment, EspacenetTransmission of broadcast packets in secure communication connections between computers
[0028] The exemplary embodiments of the invention presented in this patent application are not to be interpreted to pose limitations to the applicability of the appended claims. The verb “to comprise” is used in this patent application as an open limitation that does not exclude the existence of also unrecited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated. DETAILED DESCRIPTION OF THE INVENTION [0029] [0029]FIG. 1 illustrates an arrangement where a logical network segment 101 consists of two physical network parts, which are a wired part 102 and a wireless part 103. Two exemplary hosts 111 and 112 are shown within the wired part 102; the actual number of hosts within the wired part 102 can be anything between only few and several thousands. Similarly two exemplary hosts 121 and 122 are shown as operating within the wireless part 103; also similarly the number of hosts within the wireless part may vary considerably and does not have any specific importance. Between the wired part 102 and the wireless part 103 there is a gateway 131, which for the purposes of the following description is specifically designated as a security gateway. Physically it belongs both to the wired part 102 and the wireless part 103. Between the logical network segment 101 and an outside wired network 104 there is a router 132, which we designate as a security router and which still belongs to the wired part 102. [0030] As a practical example we may think that the logical network segment 101 is the LAN (Local Area Network) of a company. The wired hosts 111 and 112 are conventional desktop computers with a cable connection to the company LAN. The security gateway 131 is located in a conference room at the company's premises, where wireless access to the company LAN is offered to mobile workstations 121 and 122. The security router 132 implements a connection between the company LAN 101 and the Internet 104. [0031] [0031]FIG. 1 illustrates additionally how a remote “road warrior” host 141 has been coupled to the logical network segment 101 through the outside wired network 104. Physically the remote host 141 may be located anywhere in the world; one of the tasks of the security router 132 is to mask this fact so that from the viewpoint of the other devices of the logical network segment 101 the remote host appears to be within the same network segment. The virtual apperance of the remote workstation 141 within the logical network segment 101 has been illustrated with dotted lines and reference designator 141′. [0032] The wired part 102 of the logical network segment 101 is considered to be inherently safe, which means e.g. that hosts 111 and 112 may communicate with each other through the wired part 102 without using IPsec or other security measures comparable thereto. In clear contrast thereto the wireless part 103 is not inherently safe, because eavesdropping on wireless communications is relatively easy and because any arbitrary visiting host, friendly or hostile, may attempt registering into the wireless part 103. Also the outside wired network 104 is assumed to be unsafe. The word “security” in the designations of the gateway 131 and the router 132 emphasizes their responsibility for providing security to connections between “inside” hosts within the wired part 102 and “outside” hosts within either the wireless part 103 or the outside wired network 104. Using IPsec implies that SAs must be set up between each of the wireless hosts 121 and 122 and the security gateway 131, as well as between the remote host 141 and the security router 132. [0033] For the purpose of providing a good understanding of the associated problems, we may briefly recapitulate the process of handling the IP addresses of the “dubious” hosts 121, 122 and 141. The security gateway 131 (or a separate address server coupled thereto) keeps a stock of dynamically allocatable IP addresses that are considered to belong to the internal address space of the logical network segment 101. When a wireless host registers into the wireless part 103 of the logical network segment 101, it gets one of these dynamically allocatable internal IP addresses for identifying itself during its stay. An ARP (Address Resolution Protocol) proxy functionality at the security gateway 131 takes care of handling any ARP queries from other hosts in the logical network segment 101: whenever there comes an ARP query that aims at finding out the machine address that corresponds to a certain IP address allocated to a wireless host, the security gateway 131 responds to the query by giving its own machine address. ARP is discussed in detail e.g. in the document Plummer, D.: “An Ethernet Address Resolution Protocol—or—Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware”, RFC 826, Symbolics, Inc. November 1982. [0034] The situation is similar if the remote host 141 would contact the logical network segment 101 through a telephone network, by making a direct call to a modem bank that constitutes a part of a security router. Also in that case the remote host gets an internal IP address for temporary use, and the security router takes care of the ARP proxy functionality. The arrangement of FIG. 1 resembles more a situation where the remote host 141 calls the modem bank of a local ISP (Internet Service Provider) at its current location and gets a temporarily allocated IP address from a stock of dynamically allocatable IP addresses kept by the ISP. For the purposes of making a connection to the security router 132 and applying IPsec-based security to the communication over such a connection the remote host uses this “external” IP address, where the address being external means that it does not belong to the internal address space of the logical network segment 101. Hosts within the logical network segment 101 would not recognize such an IP address as qualified for secure transmissions, so the security router 132 additionally allocates a dynamically allocatable internal IP address for the remote host. This “virtual” IP address is communicated to the remote host which uses its parallelly with the “real” IP address it received from the local ISP. Using virtual IP addresses is described in detail in an Internet Draft document “draft-ietf-ipsec-dhcp-13.txt”, published in 2001 by the Internet Society, available at http://www.ietf.org/shadow.html and incorporated herein by reference. [0035] Entrusting a router with the task of managing secure communications requires the router to have rather advanced capabilities. An alternative is to use a simpler router and to connect a security gateway to the wired part 102 of the logical network segment 101. Such a security gateway would act as the interface between secured communications towards the outside network 104 and inherently secure communications within the wired part 102. [0036] Let us now consider what happens when one of the hosts 111 and 112 within the wired part 102 of the logical network segment 101 sends out a broadcast packet. All other hosts within the wired part 102 receive the broadcast packet without problems. Also the security gateway 131 and the security router 132 receive the broadcast packet. However, each IPsec-secured connection—from the security gateway 131 to the wireless host 121, from the security gateway 131 to the wireless host 122 and from the security router 132 to the remote host 141—is rigorously bound to the dynamically allocated IP address of the host in question and requires an SA for the transmission of packets. The network broadcast address in the broadcast packet cannot be used for identifying anything that could be authenticated, so without the measures of the present invention the broadcast packet that originated within the wired part 102 would not propagate to any of the wireless hosts 121 and 122 or the remote host 141. [0037] For the sake of general interest we may also consider, what would happen if the security requirement on the wireless part 103 would be loosened to the extent of not requiring the use of IPsec. In that case the gateway 131 would just “shout out loud” the broadcast packet as it is, i.e. relay it from the wired medium to the wireless medium, and every wireless host in the wireless part 103 would receive it essentially simultaneously with their wired counterparts in the wired part 102. A corresponding general relaying function is not possible at the security router 132, because broadcast packets are only meant to propagate through the logical network segment 101 and relaying them out into the outside wired network 104 would violate this principle. [0038] [0038]FIG. 2 illustrates the principle of secure broadcast relaying according to an embodiment of the present invention. The fact that certain wireless hosts are present in a wireless part of a packet-switched network already requires them to be on-line. In other words we may assume that at a certain time instant prior to the appearance of a broadcast packet there must have occurred the setting up of a security association between each wireless host and the security gateway, which security association has not yet expired when the broadcast packet comes. In FIG. 2 step 201 represents setting up an SA between the security gateway 131 and a first wireless host 121, and step 202 represents setting up an SA between the security gateway 131 and a second wireless host 122. These SAs are still alive when at step 203 a wired host 111 decides to transmit a broadcast packet through the logical network segment. At step 204 the security gateway 131 receives the broadcast packet, duplicates it into as many copies as there SA-connected wireless hosts, and encapsulates each copy appropriately so that it can be sent over the SA for which it was created. Transmitting the encapsulated copies of the broadcast packet to the wireless hosts may be designated as relaying, although it is not the exact copy of what the security gateway received but an encapsulated version thereof that is transmitted further. Step 205 represents relaying to the first wireless host 121 and step 206 represents relaying to the second wireless host 122. [0039] Steps 201 and 202, i.e. the setting up of SAs that stand waiting for something to be transmitted from the gateway 131 to the wireless hosts, usually take place as a part of normal network traffic. It is possible, however, to make either the wireless hosts or the gateway or both execute a dedicated keepalive process the purpose of which is to ensure that an SA from the gateway to each wireless host always exists, if only the wireless host in question is otherwise in condition for standing by, waiting for transmissions from the gateway to occur. [0040] [0040]FIG. 3 illustrates a corresponding situation regarding a case where a distant host designated as the road warrior contacts the Internet through a local ISP at its current location and seeks contact with the secure network segment in which broadcast packets are expected to occur. At step 301 the distant host initiates the setting up of a network connection, and as a consequence thereof contacts the local ISP at step 302. At step 303 the local ISP provides the distant host with a temporary IP address, which it communicates to the distant host at step 304. Using this IP address and the connectivity services of the local ISP the distant host contacts the security router or security gateway of the secure network segment at step 305. An SA is set up between the security router or security gateway and the distant host at step 306. At step 307 the security router or security gateway allocates an internal IP address for the distant host (internal meaning internal to the secure network segment), which internal IP address is communicated to the distant host at step 308. At step 309 the distant host sets up a virtual network connection that uses the internal IP address it received. Up to this point the procedure may follow completely known measures; the present invention is not yet required to be involved. [0041] At step 310 a broadcast originator in the secure network segment transmits a broadcast packet, so that the security router or security gateway is among the devices that receive said broadcast packet. At step 311 the security router or security gateway duplicates the broadcast packet and encapsulates it so that it can be transmitted through an SA to the distant host. The transmission or “relaying” of the encapsulated broadcast packet takes place at step 312. [0042] [0042]FIG. 4 illustrates briefly what happens at the step where a security gateway or a security router encapsulates a broadcast packet according to one part of the present invention for enabling its transmission through an SA to a wireless or distant host. Before encapsulation the packet is a normal IP packet, comprising an IP header 401, a payload field 402 and possibly some other fields 403. The IP header 401 comprises, among other values, the network broadcast address as a destination address value. Simple IPsec processing would preserve the original IP header and add a security header (an AH header or ESP header, where AH means Authentication Header and ESP means Encapsulating Security Payload) between the header and a payload field. Such processing is not applicable here, because the network broadcast address within the original IP header is not suitable for authenticating. Instead, the packet is transformed so that a new IP header 411 is added to the beginning of the packet, followed by the security header 412, the original IP header 413, the payload field 414 and the other fields 415, if they exist. The address values in the new IP header 411 are selected so that they match with the authenticated addresses of the endpoints of the SA through which the encapsulated broadcast packet is to be transmitted. Encryption of fields 413, 414 and 415 in the encapsulated packet is performed as per the definitions of the applied IPsec protection. [0043] In the cases described so far we have assumed that the originator of the broadcast packet is connected directly to the secure, wired part of the logical network segment where broadcast packets occur. This is not necessarily true, since both wireless hosts—having a wireless, IPsec-protected direct connection to the secure network and distant hosts that have IPsec-protected access the secure network through an insecure intermediate network may need to transmit broadcast packets as well. FIG. 5 illustrates how the invention is applied in such a case. [0044] [0044]FIG. 5 is most readily applicable to a situation where two wireless hosts have IPsec-protected wireless connections to a security gateway, which is also a node of the secure wired network having wired hosts connected thereto. Steps 501 and 502 show how said wireless hosts have set up, at some previous moment, SAs between themselves and the security gateway. At step 503 one of the wireless hosts decides to transmit a broadcast packet, which is composes according to known measures. However, the wireless host cannot just transmit the broadcast packet to the security gateway through an SA because of authentication reasons that have already been described. Therefore the wireless host encapsulates the broadcast packet at step 504 so that it can thereafter transmit it to the security gateway at step 505. It should be noted that even if the packet itself is destined farther (i.e. to all hosts in the logical network segment) than the security gateway, steps 504 and 505 only aim at transmitting it through an SA the endpoint of which is at the security gateway. IPsec-based protective processing keeps any potential other wireless hosts within range from noticing that actually a broadcast packet came through the air—therefore the quotation marks around the word “broadcast” at step 505. [0045] At step 506 the security gateway decapsulates the packet it received from the first wireless host and recognizes the content as including a broadcast packet. At step 507 it forwards the broadcast packet as it is into the wired part of the logical network segment. Additionally it must ensure that other such hosts that employ IPsec receive the broadcast. Therefore the security gateway duplicates the broadcast packet at step 508 into as many copies as there are other wireless hosts online at the moment, and encapsulates each copy appropriately so that it can be transmitted to the wireless host in question. At step 509 the security gateway relays the re-encapsulated broadcast packet(s) to all other wireless hosts than that from which the packet originally came from. [0046] Only certain nuances of the procedure change if we consider cases where at least one of the IPsec-using hosts is a distant host communicating through an unsecure wired network or where there are at least two security gateways for wireless connections in the same network. If there are involved a first security gateway for wireless connections and a separate second security gateway or security router for distant connections or wireless connections in a separate location, the functionality shown in a single “router or gateway” column in FIG. 5 is split into two: one device receives the original encapsulated broadcast packet from the originator host and performs the decapsulating and forwarding functions, while the other receives the forwarded broadcast packet and performs the re-encapsulating and relaying functions. [0047] It should be noted that certain types of packets may exist that could be considered as broadcast packets but the handling of which should nevertheless be different than what has been described above. Let us assume that a wireless host wants to broadcast an ARP request where it inquires the machine address of the security gateway or some other host that is “behind” the security gateway in the sense that the latter acts as an ARP proxy on behalf of the host in question. When the security gateway has decapsulated the ARP request packet, it notices that this is something that it can respond to exhaustively all by itself. In that case it does not need to forward the packet any further despite of its basic nature as a broadcast packet. It may respond directly to the host that sent the ARP request packet. [0048] A special case could be considered where there is no “secure wired part” of a logical network segment at all, meaning that in no part of even the wired network can security be guaranteed and consequently IPsec must be employed in all connections. It is completely possible to use IPsec in a fabric-like network architecture where each node can communicate directly with each other node; it is then only required that separate SAs are set up for every peer-to-peer connection in the network. Hoever, the present invention does not work in such an environment unless at least one of two conditions is met. The first of these is that the network architecture is not completely fabric-like after all but there is a central node in the network. That knows how to receive a broadcast packet (encapsulated and through an SA) from its originator and how to de-encapsulate, duplicate and re-encapsulate the broadcast packet so that the central node can further relay the broadcast packets to all other devices in the logical network segment. The second possibility is that every node in the network is by itself able to convert the conventional procedure of releasing a broadcast packet into one where a number of SAs are successively set up between the originator and all other hosts in the logical network segment for transmitting a copy of the broadcast packet to every receiving device in turn. [0049] [0049]FIG. 6 illustrates the application of the invention in a case where a logical network segment 601 consists of three different physical networks 611, 621 and 631, the connections between which go through an intermediate network 641 that does not belong to the logical network segment 601. The physical networks 611, 621 and 631 can also be designated as subnets. As a practical example we may consider that the logical network segment 601 is a corporate LAN of a company that occupies three different buildings. Connections between the buildings go through the public Internet and require IPsec protection, while within each physical network 611, 621 and 631 (inside the walls of each building) plaintext communication is allowed. For setting up and maintaining the protected connections between the subnets 611, 621 and 631 there is a security gateway or security router at each of them. In FIG. 6 these appear as the border routers 612, 622 and 632 respectively. The hosts that belong to each subnet are designated as 613 and 614; 623 and 624; as well as 633 and 634 respectively. [0050] In order to fulfil their task of securely connecting the different subnets into a single logical network segment the security routers 612, 622 and 632 routinely maintain SAs between themselves. When now one of the host transmits a broadcast packet that should be distributed to all hosts of the logical network segment, the broadcast packet first appears in the subnet where the transmitting host is located. The security router of that subnet receives the broadcast packet, encapsulates it appropriately and transmits it to the other security routers through the SAs. Each receiving security router decapsulates the packet, recognizes it to be a broadcast packet and broadcasts it within the subnet in question. [0051] [0051]FIG. 7 illustrates a combination of many features that have been separately discussed above. A logical network segment 701 consists of several physically separate subnets, of which first and second subnets 710 and 720 are wired subnets, a third subnet 730 is a wireless subnet and a fourth subnet 740 is a virtual subnet where distant hosts are made to logically appear as hosts of the logical network segment 701. Security gateways 711, 721, 731 and 741 couple the various subnets to each other with connections that go through an inherently unsafe outside network 705. In the first subnet 710 hosts 712 and 713 are directly connected to the security gateway 711; similarly in the second subnet 720 hosts 722 and 723 are directly connected to the security gateway 721. In the third subnet 730 wireless hosts 732 and 733 have wireless connections to the corresponding security gateway 731, and in the fourth (virtual) subnet 740 the logical appearances 742′ and 743′ of certain hosts are seen to have connections to a security gateway 741. Actually the hosts 742 and 743 are located somewhere within the unsafe outside network 705, and connections from them to the security gateway 741 go through the server 706 of an ISP somewhere in the Internet. [0052] [0052]FIG. 8 shows a chain of events that is related to the incident of a distant host transmitting a broadcast type packet in the logical network segment 701 illustrated in FIG. 7. At the top left part of FIG. 8 the distant hosts log in into the logical network segment 701. Regarding host 742, the associated steps are initiating 801 a connection, contacting 802 an ISP 706, allocation 803 of a temporary IP address at the ISP 706, communicating 804 the allocated temporary IP address to the host 742, contacting 805 the security gateway 741, setting up 806 an SA between the host 742 and the security gateway 741, allocating 807 a virtual IP address internal to the address space of the logical network segment, communicating 808 the allocated virtual IP address to the host 742 and setting up 809 a virtual IP connection at the host 742. Regarding host 743 the same operations are performed at steps 811, 812, 813, 814, 815, 816, 817, 818 and 819 respectively. [0053] The various security gateways must also have set up SAs between themselves; this is shown in FIG. 8 as steps 821, 822, 823, 824, 825 and 826. Additionally the wireless hosts 732 and 733 in the wireless subnet must set up SAs between them and the wireless security gateway 731. Setting up the wireless SAs is shown in FIG. 8 as steps 827 and 828. [0054] At step 831 a distant host 742 composes a broadcast packet. It cannot transmit it as such, so it encapsulates it at step 832 for transmission 833 over an appropriate SA to the security gateway 741. At step 834 the security gateway decapsulates the packet and notices that it is a broadcast packet on its way to all other devices in the logical network segment 701. There are only IPsec-protected connections from the security gateway 741 to the other parts of the logical network segment 701, so recognizing the packet as a broadcast packet triggers a series of re-encapsulation and transmission operations. The order in which the forwarding to the other parts of the network is performed is not important. As an example, in FIG. 8 the security gateway 741 first re-encapsulates 835 and transmits 836 the broadcast packet to the other distant host 743, which subsequently re-decapsulates the packet at step 837. [0055] Other re-encapsulation and transmission operations follow at the security gateway 741: to the wireless security gateway 731 at steps 838 and 839, to the first wired security gateway 711 at steps 840 and 841, and to the second wired security gateway 721 at steps 842 and 843. The last-mentioned device re-decapsulates the broadcast packet at step 844 and forwards it as a single broadcast-type transmission 845 to the hosts 722 and 723 in the corresponding subnet. Similar re-decapsulating and forwarding operations take place at the first wired security gateway 711 at steps 846 and 847. At the wireless security gateway 731 there is a re-decapsulating operation at step 848, but the wireless security gateway 731 cannot simply forward the broadcast packet in a single transmission. Instead, it performs a second re-encapsulation at step 849 before transmitting 850 the packet to the first wireless host 732, which then again decapsulates the packet at step 851. Regarding the second wireless host 733 similar second re-encapsulating 852, transmitting 853 and second decapsulating 854 take place. [0056] [0056]FIG. 9 illustrates a method according to an embodiment of the invention: the method in question is meant to be executed by a security gateway that may have protected and/or unprotected connections to other devices of a logical network segment and that should be able to handle broadcast packets. An IPsec-capable security gateway is expected to constantly maintain SAs to hosts that are online, as well as to keep a list of such hosts. The operation according to the method in FIG. 9 begins when the security gateway receives a packet either from an unprotected connection according to step 901 or from a protected connection according to step 902, in which latter case there is the inevitable decapsulating step 903. At step 904 the security gateway examines, whether the received packet was a broadcast packet. If not, the packet will be processed in some other way. In a positive case the security gateway checks at step 905, whether it has any unprotected connections into which it should forward the broadcast packet; naturally if the broadcast packet came through an unprotected connection, the security gateway will not transmit it again into the same connection. If appropriate unprotected connections are found, the security gateway forwards the packet into such connections at step 906. A negative finding at step 905 leads directly to step 907. [0057] At step 907 the security gateway checks, whether it has any protected connections into which it should forward the broadcast packet. Again if the broadcast packet originally came through a protected connection, the security gateway will not transmit it again into the same connection. The number of protected connections into which the broadcast packet must be transmitted is obtained from the ever-updated list of such connections. At step 908 the security gateway initializes a counter N, after which it circulates the loop of encapsulating the broadcast packet for transmission at step 909, transmitting the encapsulated packet at step 910, checking the counter value at step 911 and increasing the counter value by one if needed at step 912, until the check at step 911 shows that all protected connections have been dealt with. An end state 913 follows; a direct jump to the end state 913 is also possible from step 907 if it is found there that no protected connections currently exist into which the packet should be transmitted. [0058] [0058]FIG. 10 illustrates a method to be executed by a host that may have either a protected or an unprotected network connection. When an upper layer application commands the transmission of a broadcast packet, the host checks first at step 1001, whether the current network connection is protected or not. If the network connection is unprotected, transmission of the broadcast packet proceeds according to known methods at step 1002. If, however, the network connection is found to be protected, the host encapsulates the broadcast packet at step 1003 for transmission over a protected connection, and transmits the encapsulated packet at step 1004. A broadcasting accomplished state 1005 follows either step 1004 or step 1002. [0059] Certain special cases need to be considered. One of them is the situation of FIG. 1, where a logical network segment 1101 is extended to cover a separately located physical subnet 1102 so that there is a wireless connection between the subnet 1102 and the rest of the logical network segment, and additionally the subnet 1102 comprises wireless hosts. As an example we may think that the subnet 1102 is located in a rail car, while the basic parts of the logical network segment 1101 are stationary. A first wireless gateway 1111 is located in (or has a protected connection to) the stationary part of the logical network segment, and a second wireless gateway 1112 acts both as the common long distance transceiver of the whole rail car and as the local short-distance base station and network hub within the subnet 1102. Two wireless hosts 1113 and 1114 are shown in FIG. 11. [0060] Transmitting broadcast packets according to the invention in the arrangement of FIG. 11 requires the chaining of two encapsulation—decapsulation rounds. If the broadcast packet originated within the fixed part 1101 of the logical network segment, the first wireless gateway 1111 encapsulates it first for transmission to the second wireless gateway 1112. The latter decapsulates the packet only to find out that it is a broadcast packet. Thereafter the second wireless gateway 1112 re-encapsulates and transmits the packet as many times as there are currently hosts online within the subnet 1102. In the other direction if the originator of the broadcast packet was one of the wireless hosts 1113 and 1114, the originator host encapsulates the broadcast packet for the first time before transmitting it to the second wireless gateway 1112. Again the last-mentioned decapsulates the packet only to find out that it is a broadcast packet, and re-encapsulates and transmits the packet as many times as there are currently other hosts online within the subnet 1102. Additionally the second wireless gateway 1112 re-encapsulates and transmits the packet to the first wireless gateway 1111, which decapsulates it and takes care of forwarding it as an ordinary broadcast packet into the fixed part 1101 of the logical network segment. [0061] Another special case concerns FIG. 12, where a first device 1201 and a second device 1202 have multiple currently active SAs 1211, 1212, 1213 and 1214 existing between them. If we now suppose that one of the devices 1201 and 1202 should relay a broadcast packet to the other, how should it select the SA through which the broadcast packet should be transmitted in encapsulated form? There are basically two possible solutions that differ in the basic viewpoint of which of the devices should contain more intelligence. The first alternative is to assume that every device that encapsulates broadcast packets for relaying is capable of selecting exactly one SA from each “bunch” of SAs that have the same destination. It is easy as such to provide a set of rules for performing such a selection: for example we may define that the transmitting device should always select that SA that is oldest (or newest) in the sense that it was established the longest (or shortest) time ago. Or we may utilize the fact that every SA has a well-defined lifetime either in time or in byte count or both, and state that always that SA should be selected that has more (or less) of its lifetime left than any other currently existing SA. Or we may simply state that the transmitting device should always select that SA that is encountered first (or last) on a list of SAs to a certain receiving device. Or we may allow the transmitting device to pick the SA at random. The only thing to watch out for is that the selected SA really terminates at the intended receiving device. It is well known that SAs may be nested within each other so that even if a certain outer SA terminates at a certain other device, an inner SA therewithin may continue further from that other device to yet another device. [0062] The second basic alternative is to allow the transmitting device to ignore the fact that some of it currently active SAs actually terminate at a same receiving device. As a consequence the transmitting device simply duplicates, encapsulates and transmits the broadcast packet into each and every outgoing SA that is only known to terminate at a device that belongs to the logical network segment within which the broadcast packet is circulating. It is then on the responsibility of the receiving device to note that it may receive copies of the same broadcast packet through different incoming SAs. Again the practical implementation is simple as such: it is easy to make a receiving device store all received broadcast packets into a temporary buffer, so that it may compare a received broadcast packet to the contents of the buffer and to ignore all such received broadcast packets for which an exact copy already exists in the buffer. However, the first basic alternative is regarded as the more advantageous one, because it helps to avoid unnecessary delays that could result from superfluous duplicating and encapsulating at a security gateway. Additionally bandwidth is often scarce at a wireless interface, and transmitted byte count may be a basis for charging, so it is usually best to avoid unnecessary transmissions. [0063] We will conclude by describing certain device embodiments of the invention. FIG. 13 illustrates a computer device 1301 where a higher layers component 1302 schematically includes all such functionality that in the seven-layered OSI (Open Systems Interconnection) model are located at the IF layer or higher. We may assume that the computer device 1301 is a security gateway or an intelligent security router according to an embodiment of the invention. From the higher layers component 1302 there are two IP-based connections to other computer devices: one through a first IPsec component 1311 and the lower layers 1312 that are known to be used below the IP level, and the other through a second IPsec component 1321 and the lower layers 1322 that are known to be used below the IP level. In practice even security gateway devices seldom have more than one network interface where IPsec is enabled, because the “internal” network interface connects the security gateway to a secure internal network where IPsec is not needed. The double IPsec approach is shown in FIG. 13 for the purpose of completeness and to emphasize the fact that IPsec must be used whenever security must be provided to IP-based data communication. In the following we will only describe the leftmost interface in FIG. 13. [0064] According to the requirements of the IPsec standard, each interface where IPsec is enabled must have certain databases associated with the IPsec component. These databases include a Security Policy Database (SPD) and a Security Association Database (SAD), which additionally must differentiate between inbound and outbound data traffic because of the directionality of many parameters associated with the SAs. In FIG. 13 the IPsec component 1311 is shown to have an outbound database block 1313 and an inbound database block 1314, each of which has an SPD part and an SAD part. For the purposes of the present invention the SAD part is the most important, because it provides the information about the SAs into which transmitted, encapsulated broadcast packets must be directed. [0065] As a part of the higher layers component 1302 there is shown a broadcast packet handler 1350 that includes handling functions 1351 and 1352 for received and transmitted broadcast packets respectively. A major component of the received broadcast packets handling functions 1351 is a packet forwarder 1353 that is arranged to forward received broadcast packets to the applications that use these packets as well as to the transmitted broadcast packets handling functions 1352 to be transmitted further in encapsulated form into SAs. For the latter purpose the transmitted broadcast packets handling functions 1352 include a duplicator 1354 the task of which is to duplicate the broadcast packets for encapsulation into different SAs. An RX/TX interface 1355 forwards received broadcast packets both from IPsec-protected and from unprotected network interfaces to the broadcast packets handling functions 1351; it also forwards broadcast packets to be transmitted from the transmitted broadcast packets handling functions 1352 to IPsec-protected and unprotected network interfaces as required. A network address interface 1356 provides the handling functions 1351 and 1352 with the necessary information about currently valid network addresses. An applications interface 1357 forwards received broadcast packets to applications and conveys broadcast packet transmission orders from applications to the transmitted broadcast packets handling functions 1352. [0066] A host implementation would be similar to that described above, with the exception that hosts very seldom have more than one network interface, which means that the lower right part within block 1301 (blocks 1321 and 1322 as well as the associated databases) can be ignored. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS6112251 *Jan 13, 1998Aug 29, 2000Cabletron Systems, Inc.Virtual local network for sending multicast transmissions to trunk stationsUS7286467 *Jul 12, 2002Oct 23, 2007Nortel Networks LimitedFailure protection for packet telephonyUS20010034788 *Jan 22, 2001Oct 25, 2001Mcternan Brennan J.System and method for receiving packet data multicast in sequential looping fashionUS20030058274 *Mar 14, 2001Mar 27, 2003Jake HillInterface deviceUS20040030804 *May 23, 2003Feb 12, 2004Nortel Networks LimitedMulti-cast enabled address resolution protocol (ME-ARP)US20050100016 *Oct 1, 2004May 12, 2005The Fantastic CorporationSystem and method for sending packets over a computer network* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7464089Aug 19, 2005Dec 9, 2008Connect Technologies CorporationSystem and method for processing a data stream to determine presence of search termsUS7486673Aug 29, 2005Feb 3, 2009Connect Technologies CorporationMethod and system for reassembling packets prior to searchingUS8179870 *Sep 29, 2004May 15, 2012Intel CorporationMethod and apparatus for securing devices in a networkUS8249073 *Mar 25, 2010Aug 21, 2012Fujitsu LimitedMethod and system for forwarding and switching over protected pathsUS8542662 *Apr 24, 2012Sep 24, 2013Intel CorporationMethod and apparatus for securing devices in a networkUS8817716 *Aug 29, 2008Aug 26, 2014Telefonaktiebolaget L M Ericsson (Publ)Efficient working standby radio protection schemeUS9246703 *Mar 9, 2011Jan 26, 2016Brocade Communications Systems, Inc.Remote port mirroringUS9270572Dec 6, 2011Feb 23, 2016Brocade Communications Systems Inc.Layer-3 support in TRILL networksUS9374301May 8, 2013Jun 21, 2016Brocade Communications Systems, Inc.Network feedback in software-defined networksUS9401818Mar 17, 2014Jul 26, 2016Brocade Communications Systems, Inc.Scalable gateways for a fabric switchUS9401872Oct 25, 2013Jul 26, 2016Brocade Communications Systems, Inc.Virtual link aggregations across multiple fabric switchesUS9413691Jan 13, 2014Aug 9, 2016Brocade Communications Systems, Inc.MAC address synchronization in a fabric switchUS9450870Nov 5, 2012Sep 20, 2016Brocade Communications Systems, Inc.System and method for flow management in software-defined networksUS9455935 *Jan 19, 2016Sep 27, 2016Brocade Communications Systems, Inc.Remote port mirroringUS9485148Mar 12, 2015Nov 1, 2016Brocade Communications Systems, Inc.Fabric formation for virtual cluster switchingUS20060075014 *Sep 29, 2004Apr 6, 2006Intel CorporationMethod and apparatus for securing devices in a networkUS20090268734 *Jan 5, 2006Oct 29, 2009Koninklijke Philips Electronics, N.V.Efficient address-space extension to pseudo multi-homed hostsUS20100272107 *Nov 26, 2007Oct 28, 2010Oktavian PappTechnique for address resolution in a data transmission networkUS20110149900 *Aug 29, 2008Jun 23, 2011Laura ClimaEfficient Working Standby Radio Protection SchemeUS20110235640 *Mar 25, 2010Sep 29, 2011Fujitsu Network Communications, Inc.Method and system for forwarding and switching over protected pathsUS20110299532 *Mar 9, 2011Dec 8, 2011Brocade Communications Systems, Inc.Remote port mirroringUS20120210132 *Apr 24, 2012Aug 16, 2012Tharappel Francis MMethod and apparatus for securing devices in a networkUS20150304116 *Oct 28, 2013Oct 22, 2015Pismo Labs Technology Ltd.Methods and systems for transmitting broadcast dataUS20160134563 *Jan 19, 2016May 12, 2016Brocade Communications Systems, Inc.Remote port mirroringUS20160205157 *Mar 27, 2013Jul 14, 2016Alcatel-Lucent Usa Inc.Broadcasting in communication networks* Cited by examinerClassifications U.S. Classification370/390, 370/466International ClassificationH04L12/18, H04L29/06, H04L12/46Cooperative ClassificationH04L63/164, H04L12/4633, H04L12/1836European ClassificationH04L12/18E, H04L63/16C, H04L12/46ELegal EventsDateCodeEventDescriptionNov 4, 2003ASAssignmentOwner name: SSH COMMUNICATIONS SECURITY CORP., FINLANDFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PAAVOLAINEN, SANTERI;REEL/FRAME:014101/0555Effective date: 20001006Apr 19, 2004ASAssignmentOwner name: SFNT FINLAND OY, FINLANDFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SSH COMMUNICATIONS SECURITY CORP.;REEL/FRAME:015215/0805Effective date: 20031117Apr 16, 2007ASAssignmentOwner name: DEUTSCHE BANK TRUST COMPANY AMERICAS, AS COLLATERAFree format text: FIRST LIEN PATENT SECURITY AGREEMENT;ASSIGNOR:SAFENET, INC.;REEL/FRAME:019161/0506Effective date: 20070412Apr 19, 2007ASAssignmentOwner name: DEUTSCHE BANK TRUST COMPANY AMERICAS, AS COLLATERAFree format text: SECOND LIEN PATENT SECURITY AGREEMENT;ASSIGNOR:SAFENET, INC.;REEL/FRAME:019181/0012Effective date: 20070412Mar 5, 2008ASAssignmentOwner name: SAFENET, INC., MARYLANDFree format text: CHANGE OF NAME;ASSIGNOR:SFNT FINLAND OY;REEL/FRAME:020609/0987Effective date: 20060316Mar 19, 2010ASAssignmentOwner name: SAFENET, INC.,MARYLANDFree format text: PARTIAL RELEASE OF COLLATERAL;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS, AS FIRST AND SECOND LIEN COLLATERAL AGENT;REEL/FRAME:024103/0730Effective date: 20100226Owner name: SAFENET, INC., MARYLANDFree format text: PARTIAL RELEASE OF COLLATERAL;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS, AS FIRST AND SECOND LIEN COLLATERAL AGENT;REEL/FRAME:024103/0730Effective date: 20100226Aug 13, 2010ASAssignmentOwner name: AUTHENTEC, INC., FLORIDAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SAFENET, INC.;REEL/FRAME:024823/0745Effective date: 20100226Aug 22, 2012FPAYFee paymentYear of fee payment: 4Feb 4, 2013ASAssignmentOwner name: INSIDE SECURE, FRANCEFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AUTHENTEC, INC.;REEL/FRAME:029748/0128Effective date: 20121201Aug 29, 2016FPAYFee paymentYear of fee payment: 8RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services