Google Inc. v. Rockstar Consortium US LP et al

Filing 134

MOTION for Issuance of Letters Rogatory to the Superior Court of Justice of Ontario, Canada for Nortel Networks Corporation, Jean-Pierre Fortin, Angela de Wilton, Jaspreet Harit, Yee-Ning Chan, Brian Finlay Beaton, Bruce Dale Stalkie, Mitch A. Brisebois, Laura A. Mahan, Paul Michael Brennan, Brian Cruickshank, and John Eric Lumsden filed by Google Inc.. (Attachments: # 1 Exhibit A to Google's Notice of Unopposed Motion and Motion for Issuance of Letter Rogatory, # 2 Declaration of Kristin J. Madigan In Support of Google's Unopposed Motion for Issuance of Letter Rogatory, # 3 Exhibit 1, # 4 Exhibit 2, # 5 Exhibit 3, # 6 Exhibit 4, # 7 Exhibit 5, # 8 Exhibit 6, # 9 Exhibit 7, # 10 Exhibit 8, # 11 Exhibit 9, # 12 Exhibit 10, # 13 Exhibit 11, # 14 Exhibit 12, # 15 Exhibit 13, # 16 Exhibit 14, # 17 Exhibit 15, # 18 Exhibit 16, # 19 Exhibit 17, # 20 Exhibit 18, # 21 Exhibit 19, # 22 Exhibit 20, # 23 Exhibit 21, # 24 Proposed Order)(Curran, Patrick) (Filed on 9/29/2014) Modified on 9/30/2014 (cpS, COURT STAFF).

Download PDF
EXHIBIT 4 Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page1 of 13 EXHIBIT C Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page2 of 13 US006128298A United States Patent [19] [11] Patent Number: 6,128,298 W00tt0n et al. [45] Date of Patent: Oct. 3, 2000 [54] INTERNET PROTOCOL FILTER Carl—Mitchell, et al., “Building Internet Firewalls”, Unix Worla', Feb. 1992, pp. 93—103. [75] Inventors: Bruce Anthony Wootton, Raleigh, NC; William G. Colvin, Milton, Canada Chapman, “Network (In)Security Through IP Packet Filter ing”, UNIX Security Symposium III Proceedings, Balti more, MD, Sep. 14—16, 1992, pp. 63—76. Cheswick, “The Design of a Secure Internet Gateway”, USENIX Summer Conference, Anaheim, CA, Jul. 11—15, [73] Assignee: Nortel Networks Corporation, Montreal, Canada 1990, pp. 233—237. Ho, “Implementation of a Secure Gateway on Hughes [21] Appl. No.2 08/842,328 [22] Filed: Apr. 24, 1997 Aircraft’s Engineering Design Network”, 15”” Conference on Local Computer Networks, IEEE, Minneapolis, MN., [60] Related US. Application Data Provisional application No. 60/015,945, Apr. 24, 1996. [51] Int. C1.7 ................................................... .. H04L 12/56 [52] US. Cl. ........................ .. 370/392, 370/390, 370/401, [58] Field Of Search ................................... .. 370/351, 352, 713/201 370/355, 389, 390, 392, 393, 400, 401, 402, 409, 395/2006, 200.62, 200.68, 20072, Sep. 30—Oct. 3, 1990, pp. 180—182. Hoover, “Securing the Enterprise, Firewalls Can Keep You from Getting Burned”,Internet World, Feb. 1995 , pp. 39—47. Koblas, et al., “SOCKS”, UNIX Security Symposium III Proceedings, Baltimore, MD, Sep. 14—16, 1992, pp. 77—83. Lottor, “TCP Port Service Multiplexer (TCPMUX)”, Inter net rfc 1078 (1988), pp. 1,2. Luotonen, et al., “World—Wide Web Proxies”, Computer Networks and ISDN Systems 27 (1994), pp. 147—154. 713/201 (List continued on neXt page.) [56] References Cited Primary Examiner—Ajit Patel U.S. PATENT DOCUMENTS 5,309,437 5,383,179 5,400,334 5/1994 Perlman et al. ...................... .. 370/401 1/1995 Saini et al. ..... .. 370/393 3/1995 Hayssen ................................ .. 370/245 5,606,668 5,623,601 5,778,174 2/1997 Shwed. 4/1997 Vu. 7/1998 Cain. 5,781,550 5,793,763 7/1998 Templin et al. ...................... .. 370/401 8/1998 Mayes et al. ......................... .. 370/389 5,826,014 10/1998 Coley et al. . 5,835,726 11/1998 Shwed et al. . FOREIGN PATENT DOCUMENTS 0 465 201 1/1992 European Pat. Off. . OTHER PUBLICATIONS Axner, “Differing Approaches to Virtual LANs”, Business Communications Review, Dec. 1993, pp. 42—45. Bryan, “Build a Firewall”, Byte, Apr. 1995, pp. 91—96. Bryan, “Firewalls for Sale”, Byte, Apr. 1995, pp. 99—104. Assistant Examiner—Bob A. Phunkulh Attorney, Agent, or Firm—Foley & Lardner [57] ABSTRACT The IP ?lter, embodying the present invention, is a commu nications device designed to provide public network or Internet access to nodes of private networks, advantageously without requiring the private nodes on such networks to register public Internet addresses. The IP ?lter presents a single IP address to the Internet and uses a plurality of IP ports to solve the problem of IP address conservation. It initiates sessions by assigning private side IP sessions to a unique port of the IP ?lter’s public address. The IP ?lter effects a translation between a source port number for the private network and a destination port number for the public network for communication therebetween. Bene?ts of the IP ?lter include private node security and conservation of Internet-registered addresses. 32 Claims, 2 Drawing Sheets /6 INTERNET PRIVATE N ETWORK PUBLIC NETWORK Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page3 of 13 6,128,298 Page 2 OTHER PUBLICATIONS Marotta, et a1., “Internetworking Data Services”, 16th Con ference on Local Computer Networks, IEEE, Minneapolis, MN, Oct. 14—17, 1991, pp. 223—229. PanZieri, et a1., “Interfacing UNIX to Data Communications Networks”, IEEE Transactions on Software Engineering, vol. SE—11, Oct. 1985, pp. 1016—1032. Schauer, et al., “An Internet Gatekeeper”, UNIX Security Symposium III Proceedings, Baltimore, MD, Sep. 14—16, 1992, pp. 49—61. Schroeder, et al. “Autonet: A High Speed, Self—Con?guring Local Area Network Using Point—to—Point Links”, IEEE Journal on Selected Areas in Communications, vol. 9, No. 8, Oct. 1991, pp. 1318—1334. Tolly, “Evaluating Port Switching Hubs—A reality check for virtual workgroups”, Data Communications, Jun. 1993, pp. 52—62. Treese, et al., “X Through the Firewall, and Other Applica tion Relays”, USENIX Summer 1993 Technical Conference, Cincinnati, OH, Jun. 21—25, 1993, pp. 87—98. Cheswick and Bellovin, “Firewalls and Internet Security: Repelling the Wily Hacker”, Addison—Wesley, 1994, pp. 34—36, 54—75. Comer, “Internetworking with TCP/IP”, Prentice—Hall, Inc., 1988, pp. 120—127, 137—141, 194, 195, 208—214, 346, 347. Shapiro, “Structure and Encapsulation in Distribution Sys tems: The Proxy Principle”, The 6th International Confer ence on Distributed Computing Systems, IEEE, Cambridge, MA, May 19—23, 1986, pp. 198—204. Snyder, “Choosing the Right Firewall to Defend Your Net work” Network World, vol. 12, No. 10, Mar. 5, 1995, p. 1. McClimans, “Workarounds Ease the IP Address Shortage”, Data Communications, section Software Views, vol 24, No. Stephensen, “A Blueprint for Firewalls”, LAN Magazine, Egevang et al., “Internet Engineering Task Force, USA” XP2040992 pp. 1—8 (1994). Feb. 1995, pp. 63—70. Tam, et al. “CAPNET—An Approach to Ultra High Speed Networ ”, IEEE International Conference on Communica tions, 1990, pp. 323.1.1—323.1.7. 2, Feb. 23, 1995, (p. 33), pp. 3—5. Kostick, “Building a Linux Firewall”, Linux Journal, Apr. 1996, pp. 49, 52, 53, 55, 57, 58, 61. Stallings, “Internet Security Handbook” XP2040993 pp. 27—37 (1995). Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page4 of 13 U.S. Patent 0a. 3, 2000 Sheet 1 of2 INTERNET PR IVATE NETWORK NETWORK FIG. I 6,128,298 Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page5 of 13 U.S. Patent 0a. 3, 2000 Sheet 2 of2 6,128,298 /2 \ 40 \ ADDRESS usER TRANSLATION INTERFACE 33 '— 34 '30 '- A 42 lP HANDLER ARP ETHERNET TABLE PACKET DRIVER PACKET DRIVER /0 ‘\36 A 32 /4 H.W. PRIVATE NETWORK H.W. PUBLIC NETWORK FIG. 2 Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page6 of 13 6,128,298 1 2 INTERNET PROTOCOL FILTER According to a third eXemplary aspect, the invention provides a method of operating a ?lter node for interfacing ?rst and second data communications netWorks, comprising the steps of: receiving from the ?rst netWork, a data packet having destination information, Which includes a destination This application is based on provisional application 60/015,945 ?led Apr. 26, 1996. BACKGROUND OF THE INVENTION address and a destination port, corresponding to a node in The present invention generally relates to internetWork ?reWalls and, in particular, to an internet protocol (IP) ?lter Whereby a private IP netWork domain is mapped to a single the second netWork and having source information, Which IP address on the public Internet. FireWalls are generally knoWn and characteriZed by com puter servers Which function to couple nodes Within the domain of the private netWork to nodes in a public netWork domain, such as the Internet. A de?ciency of the knoWn ?reWall products is the need for a unique public IP address includes a source address and a source port, corresponding 10 unique value representing a port of the ?lter node; replacing in the data packet the source address With an address of the ?lter node and the source port With the ?lter node port value; 15 and sending to the second netWork the data packet having the replaced source information, Whereby that packet is routed according to its destination information to the corre for each concurrent session or interaction betWeen public sponding second netWork node. According to a fourth exemplary aspect, the invention provides a ?lter node for interfacing ?rst and second data communications netWorks, comprising: means for receiving from the ?rst netWork, a data packet having destination and private nodes. A ?reWall providing conservation of public IP addresses Would be desirable. SUMMARY OF THE INVENTION information, Which includes a destination address and a It is an object of the present invention to provide a neW destination port, corresponding to a node in the public netWork and having source information, Which includes a and improved apparatus for communicatively coupling tWo netWorks. to a node in the ?rst netWork; maintaining the source information taken from the data packet in correlation With a 25 source address and a source port, corresponding to a node in The invention, therefore, according to a ?rst exemplary aspect provides a method of interfacing private and public data communications netWorks, through a ?lter node in communication With both netWorks, the ?lter node having an address knoWn in the public netWork, comprising the steps of: routing from nodes in the private netWork, to the the ?rst netWork; means for maintaining the source infor mation taken from the data packet in correlation With a unique value representing a port of the ?lter node; means for replacing in the data packet the source address With an address of the ?lter node and the source port With the ?lter node port value; and means for sending to the second ?lter node, data packets having destination information, netWork, the data packet having the replaced source information, Whereby that packet is routed according to its Which includes a destination address and a destination port, corresponding to nodes in the public netWork and having destination information to the corresponding second net source information, Which includes a source address and a 35 Work node. source port, of the respective private netWork nodes; for each data packet received from the private netWork, at the ?lter node, maintaining the source information taken from the data packet in correlation With a unique value represent ing a port of the ?lter node, and replacing in the data packet An IP ?lter, embodying the present invention, is a com munications device designed to provide public netWork or Internet access to nodes of private netWorks, advantageously Without requiring the private nodes on such netWorks to register public Internet addresses. The IP ?lter presents a the source address With the ?lter node address and the source port With the ?lter node port value; and routing from the ?lter node, in the public netWork, the data packets having the replaced source information, according to the destination information in each, to the corresponding public netWork single IP address to the Internet and uses a plurality of IP ports to solve the problem of IP address conservation. It initiates sessions by assigning private side IP sessions to a 45 nodes. According to a second exemplary aspect, the invention The IP ?lter effects a translation betWeen a source port provides a method of interfacing private and public data number for the private netWork and a destination port number for the public netWork for communication therebe tWeen. Bene?ts of the IP ?lter include private node security and conservation of Internet-registered addresses. In a particular embodiment, the IP ?lter may support three data transport protocols over the internet protocol: transmis communications netWorks, through a ?lter node in commu nication With both netWorks, comprising the steps of: (a) receiving at the ?lter node, from the private netWork, a data packet having an a destination address corresponding to a node in the public netWork and a source address correspond ing to a node in the private netWork; (b) maintaining, by the ?lter node, the source address taken from the data packet; (c) 55 replacing, in the data packet, the source address With an address of the ?lter node; (d) routing from the ?lter node, in sion control protocol (TCP), user datagram protocol (UDP) and Internet control message protocol (ICMP). Packets of other protocols may be ignored. The TCP protocol prepends a TCP header to a data packet. The source port and destination port numbers are contained in this header. The Internet addresses of the source and destination nodes are contained in the IP header. The IP the public netWork, the data packet having the replaced source address, according to the destination address, to the corresponding public netWork node; (e) Waiting for a return packet from the public netWork, responsive to the data packet having the replaced source information; replacing, address and port information extracted from each packet Will be used to determine Where the IP ?lter should route this in the return packet, the destination address With the main tained source address; and (g)routing from the ?lter node, in the private netWork, the return packet having the replaced unique port of the IP ?lter’s public address Whereby up to 64,512 (=65,536 total —1,024 Well knoWn ports) concurrent sessions may be supported through the single IP address. packet. 65 The IP ?lter maintains a lookup table of information on destination address to the corresponding private netWork each TCP connection. This information includes the port node. from the private node, the private IP address, the assigned Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page7 of 13 6,128,298 3 4 port number of the destination node, and the port number of address packets. The relationship betWeen the tWo addresses is dynamic; that is, a node With an IP address may change its the IP ?lter in the form of an index. When a packet is received from the private network, the private address and corresponding to this packet is not found in the table and if Ethernet address. The information in the address table is obtained from the replies to the node’s broadcast of ARP packets. The source node broadcasts ARP packets to request the TCP header indicates that this is a neW connection the Ethernet address of the destination node, given the request. Then the source address and port number in the packet header are replaced With the IP ?lter’s IP address and destination node’s IP address. If the destination node port number, and the packet is transmitted to the Internet. When the IP ?lter receives a packet from the Internet, the destination port number is used to index the lookup table. When the corresponding table entry is found, the destination address and port number are replaced With the private networks IP address and port number, and the packet is transmitted to the private netWork. If the received packet’s source port is different from the port recorded in the table, and if the packet header information indicates that this packet is the ?rst response on the connection, then the requested information. port number are added to the table as a neW entry, if an entry receives the packet, it sends a reply packet With the 10 Though it does not maintain a true ARP table, the IP ?lter passes ARP packets in a manner similar to TCP and UDP packet passing. When the IP ?lter receives an ARP packet lookup table is updated With the port number assigned by the from a node on the private netWork destined for the public netWork, it replaces the source address information With the ?lter’s address information. The private node’s IP address and the target IP address are placed in a lookup table. When the target node replies With its oWn Ethernet address, the destination address information is changed from that of the IP ?lter to that of the private node before transmitting the Internet node, if needed. When the IP ?lter detects an end of packet to the private node. The private node address infor transmission code in the packet, the lookup table entry is mation is obtained from the table. When an ARP packet is destined for the ?reWall, the ARP packet does not pass through the IP ?lter but is restricted to communications 15 Zeroed. If the IP ?lter receives packets from the Internet that do not have entries in the lookup table corresponding to the IP ?lter port, it ignores the packets. The UDP protocol is connectionless, as opposed to TCP, 25 logged, for example, by Writing them into a text ?le. a connection-oriented protocol. The UDP header contains no codes governing initial connection or end of transmission. The data of interest in the UDP header are the source port The IP ?lter ideally Will process packets as fast as the netWorks present them but When netWork traf?c is too heavy, and destination port. This information, along With the Inter the IP ?lter Will then buffer the packets in tWo queues, one for the private netWork and one for the Internet. TWo source and destination lookup tables may be utiliZed, one for TCP packets and the other for UDP packets. Each net addresses contained in the IP header, are used to deter mine Where the IP ?lter should route this packet. The IP ?lter maintains a lookup table of information on each UDP session. When the IP ?lter receives a UDP packet from the private netWork, it records the source address, the source port number, the destination port number, and the assigned IP ?lter port number as the index to the table. Then the private node address and port number in the packet header are replaced With the address and assigned port number of the IP ?lter. Then the packet is transmitted to the betWeen the ?lter and the one side of the netWork. Events and errors encountered by the IP ?lter may be table is directly indexed by the IP ?lter port number assigned 35 to the communication session. The table entries contain the IP address of the private node, the source port of the private node, and the destination port of the Internet node. If there is no connection on a certain IP ?lter port, then the corre sponding entry in the table may be Zeroed. Packets arriving from both the private netWork and the Internet are processed Internet. When the IP ?lter receives a UDP packet from the using the same lookup table. This arrangement assumes that Internet, it indexes the UDP lookup table and replaces the packet’s destination information, namely the IP ?lter address and assigned port number, With the private address and port number from the lookup table. The lookup table also main designated for UDP communication and some for TCP communication. of the available IP ?lter communications ports some are 45 BRIEF DESCRIPTION OF THE DRAWINGS The invention Will be better understood from the folloW tains an interval indication for an expiration timer on data gram packets received as per standard UDP implementa tions. If the IP ?lter receives packets from the Internet that do not have entries in the lookup table corresponding to the ing description together With reference to the accompanying draWings, in Which: IP ?lter port, it ignores the packets. ?lter coupling a private netWork and a public netWork; and FIG. 2 is a block diagram representing internal compo FIG. 1 is a schematic representing an internet protocol As ICMP packets do not contain port numbers of either source or destination, any ICMP packets received from the private netWork are processed one at a time, With buffering of additional ICMP packets. The IP ?lter reads the private address from the packet header and replaces it With the address of the IP ?lter. The packet is transmitted to the Internet, and the IP ?lter Waits for the response. When it receives the responding packet, the destination address in the packet header is changed from that of the IP ?lter to that nents of the ?lter. 55 referred to as the Internet 16. The private netWork 10 represents a conventional data communications netWork, such as a local area netWork (LAN), having a plurality of of the node on the private netWork. Then the IP ?lter transmits the packet to the private netWork. To successfully deliver packets over an IP protocol netWork, each node must maintain a table of other hosts’ IP addresses and their corresponding Ethernet addresses in an Ethernet based data communications netWork. The nodes actually use the IP addresses and the Ethernet addresses to DETAILED DESCRIPTION Referring to FIG. 1, shoWn for illustration of the present invention is a private netWork 10 communicatively coupled through an internet protocol (IP) ?lter 12 to a public netWork 14 Which may form part of a global data netWork, otherWise 65 nodes 18 each being identi?ed by a unique IP address Within the domain of the private netWork 10. The public netWork 14 and Internet 16 are representative of public domain data communications netWorks also having a plurality of nodes 20 With corresponding IP addresses. Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page8 of 13 6,128,298 6 5 where frIP is the IP address of the IP ?lter 12 on the public network 14, and frPort is the index into the translation table The IP ?lter 12 acts as a gateway through which data packets are exchanged between the private network 10 and the public network 14, thereby providing Internet access to the nodes 18 of the private network 10. The IP ?lter 12 plus an offset value, for example, of 1024 to skip using well known ports. The frPort represents an arbitrary port. The internet node 20 will reply with a packet constitutes one of the private network nodes 18 and is the only such node to have a public IP address that is Internet registered, whereby the IP ?lter 12 essentially also consti (iIP, iPort—frIP, frPort) tutes one of the public nodes 20 and its IP address is known in the public domain. The IP addresses of the other private network nodes 18 are reserved for the private network 10, and not known or registered in the public Internet address domain. As is conventional, associated with the IP address of the IP ?lter 12 are a plurality of IP ports, speci?cally 65,536 in total of which 64,512 are not reserved for pre de?ned protocols and can be used for address translations. Communications between nodes 18 on the private net work 10 are unaffected by the presence of the IP ?lter 12, but to access the public network 14 and particularly the nodes 20 which will be received by the IP ?lter 12 and translated thereby to (iIP, iport—pIP, pPort) 15 translation table. This should be done with a hash table lookup. Translating from the public side can be a direct table lookup since frPort minus 1024 is the index into the table. therein, the private nodes 18 route all communications requests through the IP ?lter 12. The IP ?lter 12 manages the communications between private nodes 18 and the Internet If (iIP, iport) in the packet does not match the corresponding entries in the table, then an unauthoriZed access is logged nodes 20 by modifying header information of data packets received from the private network 10 before transmitting and the packet dropped. each to the public network 14. The modi?cations cause the communications between the private nodes 18 and the public Internet nodes 20 to actually be between the IP ?lter 25 12 and the Internet nodes 20, which route all return com munications to the IP ?lter 12 which subsequently routes the return data packets to the private nodes 18. The IP ?lter 12 accepts no connection requests from the public network 14. All communications between private nodes 18 and public nodes 20 are initiated by the private nodes 18. The IP ?lter 12 is designed to support three data transport protocols over the internet protocol: TCP, UDP and ICMP messages; packets of other protocols are rejected or In respect of TCP, when a SYN packet is received from the private network 10, the IP ?lter 12 locates an unused entry in the table and ?lls it in, setting the type to TCP and state to SYN. Then the packet is forwarded by the general 35 If a SYN packet is received from the public network 14 interface, it is treated as unauthoriZed and logged (except for FTP special case described below). However, a SYN+ACK packet is forwarded if the state of the translation table entry address and ports for packets received from the private network 10 destined to the public network 14 and vise versa. The translation table contains the following for each entry: internet (public) IP address internet (public) Port (PIP) (pPort) (iIP) (iPort) is SYN. After forwarding such a packet the state set to OPEN. If a FIN packet is received by the IP ?lter 12 and if the state in the translation table is not FIN, the state is set to FIN 45 If a RST packet is received, then the translation table entry is deleted. Having regard now to the UDP protocol, when any UDP Ethernet address The basic translation substitutes IP addresses and ports from the private network side to the IP ?lter’s IP address and packet is received from the private network 10 side, the IP 55 ?lter 12 ?rst tries its standard lookup. If a translation table entry is not found, an unused entry is set up and the state set to OPEN. If a free entry is not found in the table, then rather than dropping the packet, a random UDP in the table is overwritten. Since UDP is connectionless and consequently an unreliable transport, if a packet is received from the public network 14 that would have needed the entry that was overwritten, that packet will be dropped and the node 18 on the private side will need to retry. a source—destination of (pIP, pPort—iIP, iPort) This de?nes a “socket” in which the endpoints of the connection (source and destination) are de?ned by the IP addresses in the IP header and the ports in the TCP or UDP header. The IP ?lter 12 will translate the above to and the packet forwarded. If the state is FIN, then the packet is forwarded and the translation table entry is deleted by setting it to 0. AFIN must be sent by each side to close a TCP connection. timer session type/state ports, thereby hiding all nodes 18 on the private network 10 from the public network 14. Apacket originating on the private network side speci?es scheme above. If no free entries exist in the table, then the packet is dropped and the event is logged. Atranslation table is maintained by the IP ?lter 12 to map private IP address In translating packets, when a port is substituted in the TCP or UDP header, the checksum in both the TCP/UCP and IP header must be recalculated. When an IP address is substituted in the IP header, the IP header checksum must be recalculated. Following are special considerations for different proto cols supported by the IP ?lter 12. ignored. private port In general, to translate from the private side, the values (protocol type, pIP, pPort, iIP, iport) must be located in the With regard to FTP, an FTP client establishes a TCP “control” connection with an FTP server on a particular port, for example, port 21. However, when data is to be 65 transmitted, the FTP server will open a TCP connection from its “data” port, for example, which is default 20, to a (frIP, frPort—iIP, iport) destination port speci?ed by the client. Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page9 of 13 6,128,298 8 7 To support this, packets sent by the private network 10 to drivers 30 and 32, an address resolution protocol (ARP) port 21 need to be analyzed for an FTP “port” command at the IP ?lter 12. If detected, then a neW entry in the table must be set up With pPort set to the value in the FTP port command. The IP address and port number in the FTP command must be changed to the IP ?lter’s address and port before forwarding the packet. The state is set to FTPDATA. When a SYN packet is received from the public netWork 14, if a table entry exists and is in FTPDATA state, then the packet is forWarded and the state set to OPEN. For the ICMP protocol, if an ICMP packet is received from the private netWork 10 and if that packet is an echo request (ping), then the IP ?lter 12 locates a neW entry in the translation table. The sequence ?eld of the packet is stored in pPort in the table and the table indeX is put in the sequence ?eld of the packet. The ICMP checksum is recalculated and the standard IP header substitution is done. The type is set table 34, an Ethernet address table 36, an IP handler 38, an address translation 40 and a user interface 42. The packet drivers 30 and 32 control the Ethernet hardWare interfaces in order to communicate With, respectively, the private netWork 10 and the public netWork 14. The IP handler 38 provides a router functionality for receiving and forWarding messages, and maintains the ARP table 34 and the Ethernet table 36. The address translation 40 effects translation betWeen source 10 port numbers from the private netWork 10 and the destina 15 If an echo reply (ping) is received from the public netWork tion port numbers on the public netWork side 14. The user interface 42 enables an operator, via a keyboard and display terminal attached to the processing platform, to interface With the IP ?lter 12. Functions keys are provided to con?g ure the IP ?lter, vieW or copy log ?les, display status, etc. The log ?le Will contain the connect time of TCP or UDP sessions, inbound and outbound traf?c statistics, and invalid access to the IP ?lter 12. To prevent the log ?le from groWing too large, this information Will be logged to a neW 14 interface, then the sequence ?eld is used as the indeX into the table. If the state is PING, then pPort in the table is substituted into the sequence ?eld of the packet, the ICMP checksum recalculated and the standard IP header substitu tion is done. The table entry is then deleted. ?le When the date changes. Routing of packets to and from the IP ?lter 12 is described in the folloWing in terms of a public interface, from the vieW of the public netWork 14, and of a private interface, from the vieW of the private netWork 10. to ICMP and state to PING and the timer set to 1 minute. If an echo request (ping) is received from the public netWork 14, then the IP ?lter 12 Will reply. This alloWs 25 internet access to con?rm that the IP ?lter 12 is reachable and running. If a Destination Unreachable packet is received from the public netWork 14, then the header information contained is eXtracted. If the protocol Was TCP or UDP, the (frIP, frPort—iIP, iport) of the originating packet can be deter mined and the translation table entry located. If the IP address eXtracted from the ICMP matches the address in the table, the IP ?lter 12 forWards the packet to the Ethernet address. Standard aging out of ARP table entries needs to be done. If the IP destination is not on the LAN segment, it Will forWard the packet to the con?gured default router. ICMP Redirect messages sent by the default router 35 private netWork 10 using the standard scheme. Will be ignored. The private interface effects the functionality of a router, All other ICMP packets received from either side are as it needs to be able to forWard packets to one or more dropped and logged. routers to communicate With the remote client stations. A large remote client netWork may access multiple router Since most data communications protocols are based on machines. Conventional routing can result in large routing tables because the routing entries become host addresses instead of subnet addresses. That is, if the netWork is set up either the UDP or TCP protocols, these other protocols are compatible With the IP ?lter 12 as long as they do not initiate negotiations like FTP to have the server open a connection back to the client. Examples of other compatible protocols include: Telnet; TFTP (Trivial File Transfer Protocol); DNS (Domain Name Services); and Web broWsers. The public interface behaves as a host on the LAN segment. To forWard a packet, it checks to see if the destination IP is on the local LAN segment. If it is, it looks up the IP address in its ARP table to ?nd the Ethernet address. If there is no entry in the ARP table, it must put the packet on a queue and send out an ARP request to get the so that a client may come in through either Router1 or 45 Router2, then no single router can be the router for the subnet that that client station is on. A conventional router that Would get routing tables via RIP from all routers on the private netWork Would end up With a large table of host Whenever a packet is transmitted in either direction, the timer ?eld of the translation table entry is set to the con?g ured timeout value (except ping). Each minute, the timer addresses for each remote client connected. This can affect ?eld of all active entries in the tables are decremented and performance in the search time necessary to ?nd the route, the memory required for large tables and the amount of RIP if they become 0, then the translation table entry is deleted. This Will clear out UDP and PING entries Which are no longer in use and also TCP entries Which have had an traffic on the LAN segment betWeen all these routers. abnormal termination and did not send FIN from each side. It could be a security hole to leave an unused entry in the maintain an Ethernet table. For every packet that is for table for too long. A good timeout value to be con?gured To handle routing in this environment, the IP ?lter Will Warded from the private to public side, if a translation entry 55 Would be just longer than the typical TCP keep alive. eXists, use its Ethernet indeX to compare With the Ethernet source address of the incoming packet. If they match, According to a particular embodiment, the private net tional Ethernet hardWare interfaces connected to netWorks nothing more needs to be done. OtherWise, the Ethernet table is searched for the source Ethernet address, adding a neW Ethernet table entry if not found. The indeX to the Ethernet table is then saved in the translation table entry. Then When a packet is being translated from the public to 10 and 14, respectively, and Which is provisioned With appropriate softWare to implement the functionality of the IP private side, the Ethernet address can be retrieved directly from the indeX in the translation table. Thus packets Will be Work 10 and the public netWork 14 are Ethernet based LANs. The IP ?lter 12 may be implemented by a data processing platform Which is equipped With tWo conven ?lter 12. Internal components of the IP ?lter 12 in terms of soft Ware eXecutable by the data processing platform are shoWn in FIG. 2. The internal components include tWo packet 65 routed to the router Which forWarded the packet to the IP ?lter. Those skilled in the art Will recogniZe that various modi ?cations and changes could be made to the invention With Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page10 of 13 6,128,298 9 10 out departing from the spirit and scope thereof. It should a destination port, corresponding to nodes in the public netWork and having source information, Which includes therefore be understood that the claims are not to be con a source address and a source port, of the respective sidered as being limited to the precise embodiments set forth above, in the absence of speci?c limitations directed to each embodiment. What is claimed is: for each outgoing data packet received from the private 1. A method of interfacing private and public data com munications networks, through a ?lter node in communica tion With both networks, the ?lter node having an address correlation With a unique value representing a port of knoWn in the public netWork, comprising the steps of: routing from nodes in the private netWork, to the ?lter private netWork nodes; netWork, at the ?lter node, maintaining the source information taken from the outgoing data packet in the ?lter node, and replacing in the outgoing data 10 routing from the ?lter node, to nodes in the public node, outgoing data packets having destination information, Which includes a destination address and a destination port, corresponding to nodes in the public netWork and having source information, Which includes netWork, the outgoing data packets having the replaced source information, according to the destination infor 15 a source address and a source port, of the respective mation in each, to the corresponding public netWork nodes; routing from nodes in the public netWork, to the ?lter private netWork nodes; node, incoming data packets each having the address of for each outgoing data packet received from the private the ?lter node as the destination address; netWork, at the ?lter node, maintaining the source information taken from the outgoing data packet in correlation With a unique value representing a port of for each incoming data packet received from the public netWork, at the ?lter node, correlating the destination port of the destination information in the incoming data packet to particular source information being main tained and replacing, in the incoming data packet, the the ?lter node, and replacing in the outgoing data packet the source address With the ?lter node address and the source port With the ?lter node port value; and routing from the ?lter node, to nodes in the public packet the source address With the ?lter node address and the source port With the ?lter node port value; destination information With the particular source infor 25 mation; routing from the ?lter node, in the private netWork, the netWork, the outgoing data packets having the replaced incoming data packets having the replaced destination source information, according to the destination infor mation in each, to the corresponding public netWork information to the corresponding private netWork nodes. 2. A method as claimed in claim 1, comprising the steps ignoring by the ?lter node any incoming data packet routing from nodes in the public netWork, to the ?lter data packet can not be correlated to the maintained nodes; received from the public netWork, if the destination port of the destination information in that incoming of: node, incoming data packets each having the address of the ?lter node as the destination address; 35 for each incoming data packet received from the public netWork, at the ?lter node, correlating the destination port of the destination information in the incoming data packet to particular source information being main tained and replacing, in the incoming data packet, the ing the source information from each outgoing data packet as an entry in a lookup table, and the ?lter node port value correlating to the source information con stitutes an indeX into the table for that entry; Wherein the incoming and outgoing data packets include destination information With the particular source infor packets in accordance With a transmission control pro mation; routing from the ?lter node, in the private netWork, the incoming data packets having the replaced destination information to the corresponding private netWork 45 nodes. 3. Amethod as claimed in claim 2, comprising ignoring by the ?lter node any incoming data packet received from the public netWork, if the destination port of the destination tocol (TCP) over an internet protocol (IP); and receiving at the ?lter node an outgoing TCP packet from the private netWork; and if an entry corresponding to the outgoing TCP packet is not found in the lookup table and the outgoing TCP packet indicates that this is a connection request, storing the source information together With the destination information from the outgoing TCP packet as a neW entry in the lookup table. 7. A method as claimed in claim 6, comprising receiving at the ?lter node an incoming TCP packet from the public netWork; and if the source port in the received incoming TCP information in that incoming data packet can not be corre lated to the maintained source information. 4. A method as claimed in claim 3, Wherein maintaining the source information includes storing the source informa tion from each outgoing data packet as an entry in a lookup table, and the ?lter node port value correlating to the source information constitutes an indeX into the table for that entry. 5. Amethod as claimed in claim 4, Wherein the incoming source information, Wherein maintaining the source information includes stor packet is different from the destination port in a source 55 information entry of the lookup table, indeXed by the des tination port in the outgoing TCP packet, and if the incoming TCP packet indicates that this packet is a ?rst response to the connection request, then updating by the ?lter node the and outgoing data packets include packets in accordance destination port in the table entry With the source port from With a transmission control protocol (TCP) over an internet the received incoming TCP packet. protocol (IP). 8. A method as claimed in claim 7, comprising receiving at the ?lter node any incoming TCP packet having an end of transmission code in the packet and Zeroing an entry in the 6. A method of interfacing private and public data com munications netWorks, through a ?lter node in communica tion With both netWorks, the ?lter node having an address lookup table corresponding to that received incomingTCP packet. knoWn in the public netWork, comprising the steps of: routine from nodes in the private netWork, to the ?lter node, outgoing data packets having destination 9. A method as claimed in claim 4, Wherein the data packets include packets in accordance With a user datagram information, Which includes a destination address and protocol (UDP) over an internet protocol (IP). 65 Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page11 of 13 6,128,298 11 12 10. A method of interfacing private and public data (c) replacing, in the data packet, the source address with an address of the ?lter node, wherein the source address communications networks, through a ?lter node in commu nication with both networks, the ?lter node having an includes a port number of the node in the private network and the address of the ?lter node includes a address known in the public network, comprising the steps port number of the ?lter node; of: (d) routing from the ?lter node, in the public network, the data packet having the replaced source address, accord routing from nodes in the private network, to the ?lter node, outgoing data packets having destination information, which includes a destination address and a destination port, corresponding to nodes in the public network and having source information, which includes ing to the destination address, to the corresponding public node network; 10 a source address and a source port, of the respective source information; private network nodes; (f) replacing, in the return packet, the destination address for each outgoing data packet received from the private network, at the ?lter node, maintaining the source information taken from the outgoing data packet in correlation with a unique value representing a port of with the maintained source address; and 15 the ?lter node, and replacing in the outgoing data buffering, at the ?lter node, further data packets received from the private network while waiting for the return packet, and repeating steps (b) through (g) on an individual basis for routing from the ?lter node, to nodes in the public network, the outgoing data packets having the replaced the further packets, if any, that were buffered. 13. A method as claimed in claim 12, wherein the data packets include packets in accordance with an internet source information, according to the destination infor mation in each, to the corresponding public network 25 routing from nodes in the public network, to the ?lter and second data communications networks, comprising the steps of: receiving from the ?rst network, an outgoing data packet having destination information, which includes a des the ?lter node as the destination address; for each incoming data packet received from the public network, at the ?lter node, correlating the destination port of the destination information in the incoming data packet to particular source information being main tained and replacing, in the incoming data packet, the tination address and a destination port, corresponding to a node in the second network and having source information, which includes a source address and a source port, corresponding to a node in the ?rst net destination information with the particular source infor 35 routing from the ?lter node, in the private network, the incoming data packets having the replaced destination going data packet in correlation with a unique value representing a port of the ?lter node; replacing in the outgoing data packet the source address nodes: ignoring by the ?lter node any incoming data packet with an address of the ?lter node and the source port received from the public network, if the destination port of the destination information in that incoming data packet can not be correlated to the maintained source information, wherein maintaining the source information includes stor 45 ing the source information from each outgoing data packet as an entry in a lookup table, and the ?lter node port value correlating to the source information con stitutes an indeX into the table for that entry; wherein the data packets include packets in accordance to the corresponding second network node. 15. A method as claimed in claim 14, further comprising the steps of: receiving from the second network, an incoming data packet having the address of the ?lter node as the correlating the destination port of the destination infor mation in the incoming data packet to particular source protocol (IP); and receiving at the ?lter node a UDP data packet from the information being maintained; 55 replacing, in the incoming data packet, the destination information with the particular source information; sending to the ?rst network the incoming data packet together with an interval indication for an expiration timer as a new entry in the lookup table. having the replaced destination information, whereby 11. A method of interfacing private and public data that packet is routed according to its destination infor mation to the corresponding ?rst network node. 16. A method as claimed in claim 15, comprising ignoring the incoming data packet received from the second network, if the destination port of the destination information in that communications networks, through a ?lter node in commu nication with both networks, comprising the steps of: (a) receiving at the ?lter node, from the private network, a data packet having a destination address correspond ing to a node in the public network and a source address (b) maintaining, by the ?lter node, the source address taken from the data packet; with the ?lter node port value; and sending to the second network the outgoing data packet having the replaced source information, whereby the packet is routed according to its destination information destination address; with a user datagram protocol (UDP) over an internet corresponding to a node in the private network; work; maintaining the source information taken from the out information to the corresponding private network private network, and adding the source information and the destination information from the UDP packet control message protocol (ICMP). 14. A method of operating a ?lter node for interfacing ?rst node, incoming data packets each having the address of mation; (g) routing from the ?lter node, in the private network, the return packet having the replaced destination address to the corresponding private network node. 12. A method as claimed in claim 11, comprising packet the source address with the ?lter node address and the source port with the ?lter node port value; nodes; (e) waiting for a return packet from the public network, responsive to the data packet having the replaced data packet can not be correlated to the maintained source 65 information. 17. Amethod as claimed in claim 16, wherein maintaining the source information includes storing the source informa Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page12 of 13 6,128,298 13 14 tion from the outgoing data packet as an entry in a lookup table, and the ?lter node port value correlating to the source information constitutes an index into the table for that entry. 18. A method as claimed in claim 17, Wherein the incom then updating the destination port in the table entry With the source port from that received incoming TCP packet. 21. A method as claimed in claim 20, comprising receiv ing any incoming TCP packet having an end of transmission code in the packet, and Zeroing an entry in the lookup table corresponding to that received incoming TCP packet. ing and outgoing data packets include packets in accordance With a transmission control protocol (TCP) over an internet 22. A method as claimed in claim 17, Wherein the out protocol (IP). 19. A method of operating a ?lter node for interfacing ?rst and second data communications netWorks comprising the steps of: receiving from the ?rst netWork, an outgoing data packet having destination information, Which includes a des tination address and a destination port, corresponding going and incoming data packets include packets in accor dance With a user datagram protocol (UDP) over an internet 10 23. A method of operating a ?lter node for interfacing ?rst to a node in the second netWork and having source information, Which includes a source address and a 15 source port, corresponding to a node in the ?rst net Work: maintaining the source information taken from the out tination address and a destination port, corresponding to a node in the second netWork and having source source port, corresponding to a node in the ?rst net Work: maintaining the source information taken from the out going data packet in correlation With a unique value representing a port of the ?lter node; replacing in the outgoing data packet the source address With an address of the ?lter node and the source port 25 With an address of the ?lter node and the source port With the ?lter node port value; sending to the second netWork the outgoing data packet having the replaced source information, Whereby that packet is routed according to its destination information to the corresponding second netWork node; receiving from the second netWork, an incoming data packet having the address of the ?lter node as the destination address: correlating the destination port of the destination infor packet having the address of the ?lter node as the mation in the incoming data packet to particular source destination address; information being maintained; replacing, in the incoming data packet, the destination and second data communications netWorks, comprising the steps of: receiving from the ?rst netWork, an outgoing data packet having destination information, Which includes a des information, Which includes a source address and a going data packet in correlation With a unique value representing a port of the ?lter node; replacing in the outgoing data packet the source address With the ?lter node port value; sending to the second netWork the outgoing data packet having the replaced source information, Whereby that packet is routed according to its destination information to the corresponding second netWork node, receiving from the second network, an incoming data protocol (IP). 35 correlating the destination port of the destination infor mation in the incoming data packet to particular source information being maintained; information With the particular source information; sending to the ?rst netWork the incoming data packet replacing, in the incoming data packet, the destination having the replaced destination information Whereby information With the particular source information; sending to the ?rst netWork the incoming data packet that packet is routed according to its destination infor mation to the corresponding ?rst netWork node; having the replaced destination information, Whereby that packet is routed according to its destination infor mation to the corresponding ?rst netWork node; and ignoring the incoming data packet received from the second netWork, if the destination port of the destina tion information in that data packet can not be corre lated to the maintained source information, Wherein maintaining the source information includes stor ignoring the incoming data packet received from the 45 ing the source information from the outgoing data packet as an entry in a lookup table, and the ?lter node Wherein the incoming and outgoing data packets include packets in accordance With a transmission control pro Wherein the outgoing and incoming data packets include 55 20. A method as claimed in claim 19, comprising receiv packets in accordance With a user datagram protocol (UDP) over an internet protocol (IP); and receiving a UDP data packet from the ?rst netWork, and adding the source information and the destination infor mation from the UDP packet together With an interval indication for an expiration timer as a neW entry in the nation information from the TCP packet as a neW entry in the lookup table. tion information in that data packet can not be corre lated to the maintained source information, Wherein maintaining the source information includes stor ing the source information from the outgoing data packet as an entry in a lookup table, and the ?lter node port value correlating to the source information con stitutes an index into the table for that entry; port value correlating to the source information con stitutes an index into the table for that entry tocol (TCP) over an internet protocol (IP): and receiving an outgoing TCP packet from the ?rst netWork; and if an entry corresponding to the outgoing TCP packet is not found in the lookup table and the outgoing TCP packet indicates that this is a connection request, storing the source information together With the desti second netWork, if the destination port of the destina aO lookup table. 24. A method of operating a ?lter node for interfacing ?rst different from the destination port in a source information and second data communications netWorks, comprising the steps of: (a) receiving from the ?rst netWork, a data packet having entry of the lookup table, indexed by the destination port in the outgoing TCP packet, and if that incoming TCP packet a destination address corresponding to a node in the second netWork and a source address corresponding to indicates that it is a ?rst response to the connection request, a node in the ?rst netWork; ing any incoming TCP packet from the second netWork; and if the source port in that received incoming TCP packet is Case5:13-cv-05933-PSG Document1-3 Filed12/23/13 Page13 of 13 6,128,298 15 16 means for replacing, in the data packet, the destination information With the particular source information; and means for sending to the ?rst netWork the data packet (b) maintaining the source address taken from the data packet; (c) replacing, in the data packet, the source address With an address of the ?lter node, Wherein the source address includes a source port number and the address of the having the replaced destination information, Whereby that packet is routed according to its destination infor mation to the corresponding ?rst netWork node. ?lter node includes a port number of the ?lter node; (d) sending to the second netWork the data packet having the replaced source address, Whereby that packet is 29. A?lter node as claimed in claim 28, comprising means for ignoring a data packet received from the second netWork, if the destination port of the destination information in that routed to the corresponding second netWork node; (e) receiving a return packet from the second network, responsive to the data packet having the replaced data packet can not be correlated to the maintained source information. 30. A ?lter node as claimed in claim 29, Wherein the source information; (f) replacing, in the return packet, the destination address With the maintained source address; and 15 (g) sending to the ?rst netWork the return packet having the replaced destination address, Whereby that packet is packet as an entry in a lookup table, and Wherein the ?lter node port value correlating to the source information con stitutes an indeX into the table for that entry. 31. A ?lter node for interfacing ?rst and second data routed to the corresponding ?rst netWork node. 25. A method as claimed in claim 24, comprising buffer ing further data packets received from the ?rst netWork communications netWorks, comprising: While Waiting for the return packet, and repeating steps (b) through (g) on an individual basis for the further packets, if any, that Were buffered. 26. A method as claimed in claim 25, Wherein the data packets include packets in accordance With an internet 25 27. A ?lter node for interfacing ?rst and second data (c) means for replacing, in the data packet, the source address With an address of the ?lter node, Wherein the communications netWorks, comprising: means for receiving from the ?rst netWork, a data packet having destination information, Which includes a des tination address and a destination port, corresponding source address includes a source port number and the address of the ?lter node includes a port number of the ?lter node; to a node in the second netWork and having source information, Which includes a source address and a source port, corresponding to a node in the ?rst net (d) means for sending to the second netWork the data packet having the replaced source address, Whereby 35 (e) means for receiving a return packet from the second the data packet in correlation With a unique value representing a port of the ?lter node; means for replacing in the data packet the source address netWork, responsive to the data packet having the replaced source information; (f) means for replacing, in the return packet, the destina With an address of the ?lter node and the source port tion address With the maintained source address; and (g) means for sending to the ?rst netWork the return With the ?lter node port value; and means for sending to the second netWork, the data packet packet having the replaced destination address, having the replaced source information, Whereby that means for receiving from the second netWork, a data packet having the address of the ?lter node as the destination address; means for correlating the destination port of the destina tion information in the data packet to particular source information being maintained; that packet is routed to the corresponding second netWork node; means for maintaining the source information taken from packet is routed according to its destination information to the corresponding second netWork node. 28. A ?lter node as claimed in claim 27, comprising: (a) means for receiving from the ?rst netWork, a data packet having a destination address corresponding to a node in the second netWork; (b) means for maintaining the source address taken from the data packet; control message protocol (ICMP). Work; means for maintaining the source information includes means for storing the source information from the data 45 Whereby that packet is routed to the corresponding the ?rst netWork node. 32. A?lter node as claimed in claim 31, comprising means for buffering further data packets received from the ?rst netWork While Waiting for the return packet, and means for controlling means (b) through (g) on an individual basis for processing the further packets, if any, that Were buffered.

Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.


Why Is My Information Online?