Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1999-08-24
2004-06-15
ElHady, N. (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S229000, C707S793000
Reexamination Certificate
active
06751677
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention pertains to communication networks. More particularly, this invention relates to providing a secure and transparent network gateway that does not require complex configuration to the associated firewall.
2. Description of the Related Art
In an open-ended network system such as Internet, a firewall is typically employed between servers and remote accessing clients (e.g., user terminals). The main purpose of the firewall is to control external accesses to and from the servers. This means that the firewall allows the external accesses to the servers to cross the firewall in a controlled fashion.
FIG. 1
shows one such prior art arrangement of the firewall.
In
FIG. 1
, communication between the user terminal
11
and the target object servers
12
is conducted using Object Request Broker (ORB) transparent protocol over a TCP/IP (Transmission Control Protocol-Internet Protocol) communications protocol. When tie user terminal
11
wants to access a particular object in one of the target object servers
12
, the terminal
11
uses an Interoperable Object Reference (IOR) to issue an object invocation using an object reference of the requested object. The object invocation is referred to as the user access request below. The object reference typically includes the TCP/IP port number and IP (Internal Protocol) address of the object. The port number and IP address specify the target object server that contains the requested object.
The firewall
13
has a number of TCP/IP ports and IP addresses, each configured or opened to correspond to one of the servers
12
. When the user access request enters the firewall
13
, the firewall
13
checks if the port and IP address specified in the user access request are opened in the firewall
13
. If the port and IP address are opened in the firewall
13
, the request passes through the firewall
13
and reaches the designation target object server. Then a communication channel can be established for transferring the requested object to the user terminal
11
. If the firewall
13
does not have the corresponding port opened, the firewall
13
does not let the user access request to pass through it and does not establish communication channel for the user access request.
One disadvantage of this prior art firewall is that the firewall has statically configured target object ports and IP addresses. Adding new target object servers requires reconfiguration of the firewall. This can only be done by opening new ports and IP addresses. For security reasons, these ports and IP addresses cannot be opened ahead of time because it creates security loopholes. This means that the firewall does not have any flexibility.
One prior solution to solving the problem of accessing the target objects is to employ a CORBA (Common Object Request Broker Architecture) gateway behind the firewall, as can be seen from FIG.
2
. The CORBA gateway can also be implemented as part of the firewall. One such prior CORBA gateway is the Wonderwall manufactured and sold by Iona Technologies PLC from Ireland.
In
FIG. 2
, the firewall
22
is configured to have one port number and IP address designated to the CORBA gateway
23
. All user access requests to the servers
24
are forwarded to the CORBA gateway
23
by the firewall
22
. The CORBA gateway
23
maps all of the servers
24
. Each of the target object servers
24
has an individual IP address and at least one port number. The CORBA gateway
23
includes a mapping lookup table that specifies the port numbers and IP addresses of all the servers
24
connected to the CORBA gateway
23
. Each pair of port number and IP address stored in the mapping lookup table of the CORBA gateway
23
can be retrieved from the lookup table using an object key. The object key is part of the object reference from the user access request. Whenever a user access request passes through the gateway
23
, the request has to be examined and routed by the gateway
23
according to the content of the object key in the user access request.
In order for a user access request to access a particular target object server, the object reference of the access request is first proxified at the user terminal (e.g., terminal
21
) using the IOR such that the proxified request points to the CORBA gateway
23
, instead of the intended target object server. The proxification is done by specifically replacing the port number and IP address of the object reference used by the user access request that point to the particular target object server with the port number and IP address of the CORBA gateway
23
. To access the target object server, a TCP/IP connection between the user terminal (e.g., the terminal
21
) and the gateway
23
must first be established. This is done through the ORB protocol in the user terminal
21
upon receiving the object reference from the client application. In this case, the firewall
22
must have the IP address and port configured in order for the TCP/IP connection to go through. Once the TCP/IP connection is established, the ORB protocol in the user terminal
21
sends the request that contains the object key in the request header.
At the CORBA gateway
23
, the server port number and IP address are extracted from the request header by using the object key of the access request to search the mapping lookup table in the CORBA gateway
23
. The CORBA gateway
23
establishes another connection (i.e., gateway-target object server) and forwards the request over this connection to the target object server. This dynamically maps the port number and IP address of a particular target object server to the CORBA gateway
23
.
However, disadvantages are associated with the prior CORBA gateway. One disadvantage associated is that the gateway typically does not allow the firewall to provide end-to-end security for the communication (e.g., authentication, confidentiality, and integrity). This means that SSL (secure socket layer) protocol cannot be used, for example, between the firewall
22
and the servers
24
as a single session. This is due to the fact that the CORBA gateway requires access to request header in order to extract the object key. Connections have to be terminated at the firewall/gateway and encrypted data have to be decrypted to allow examination of the object reference headers and to make filtering decisions. If SSL is used, secure communication can only establishes two separate sessions. One of which is between the user terminal and the firewall and the other is between the firewall and the target object servers. This means that a single SSL session cannot be established between the user terminal and the target object servers. As a consequence, encryption of data cannot be preserved from end-to-end. There is no direct authentication between the user terminal and the target object servers. The gateway has to be trusted to pass client and target object server credentials (e.g., identity certificate). However, this credential must be passed as additional payload. This means that the target object server must be modified to manage user credentials.
Another disadvantage is that the configuration of access control list based on object keys of the prior CORBA gateway is static, complex, and manual. Moreover, the prior CORBA gateway does not provide a mechanism for authenticating clients and target object servers at the firewall. Depending on security policy, the client authentication may be necessary at the firewall before commencing traffic to the target object servers. This protection is necessary for malicious outside attacks and the firewall creates a first line of defense. Authenticating target object servers at the firewall may be necessary in situations where security policy requires that an authorized resource is available at the target address, not a Trojan horse. A client or user terminal may use a Trojan horse to penetrate Internet network.
SUMMARY OF THE INVENTION
One feature of the present invention is to provide a secure and transparent network con
Ilnicki Slawomir K.
Rice James P.
Chang Jung-won
ElHady N.
Hewlett--Packard Development Company, L.P.
LandOfFree
Method and apparatus for allowing a secure and transparent... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for allowing a secure and transparent..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for allowing a secure and transparent... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3314774