Issue 2648: new_target (firewall-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Section 4.7.4 - description of new_target operation. The first para states: "The new_target operation informs the firewall that it should prepare itself to receive requests destined for the specified target. The object returned from this operation is the destination on the firewall to which a request on the target should be sent i.e. the object_key in the return object should be used in the GIOP request header." and the last para says: "The object returned by the new_target operation must contain an object key which allows the proxy to uniquely identify the target. A client is not required to open a new connection to the proxy server, even when the target object(s) are located in different servers." The last sentence implies that the IOR returned from the new_target has the same host/port number as the GIOPProxy. This may not be true. For example if a firewall is load balancing across ports and network interfaces, the host/ports may be differnt, and in this situation a new connection is required. Resolution: Revised Text: Actions taken: May 10, 1999: received issue Discussion: End of Annotations:===== From: "Martin Chapman" To: , Subject: new_target Date: Mon, 10 May 1999 11:31:42 +0100 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Firewall issue Section 4.7.4 - description of new_target operation. The first para states: "The new_target operation informs the firewall that it should prepare itself to receive requests destined for the specified target. The object returned from this operation is the destination on the firewall to which a request on the target should be sent i.e. the object_key in the return object should be used in the GIOP request header." and the last para says: "The object returned by the new_target operation must contain an object key which allows the proxy to uniquely identify the target. A client is not required to open a new connection to the proxy server, even when the target object(s) are located in different servers." The last sentence implies that the IOR returned from the new_target has the same host/port number as the GIOPProxy. This may not be true. For example if a firewall is load balancing across ports and network interfaces, the host/ports may be differnt, and in this situation a new connection is required. Proposed Resolution: Change in the last para : "A client is not required to open a new connection to the proxy server" to "If the host/port in the returned IOR is identical to the IOR of the GIOPProxy (to which a connection should already exist), a client is not required to open a new connection to the proxy server." ---------------------------------------------------------------------- Martin Chapman ------------| email: mchapman@iona.com --| voice x2398 IONA Technologies ----------| ftp: ftp.iona.com -| tel: +353-1-6625255 The IONA Building ---------| http://www.iona.com| fax: +353-1-6625244 Shelbourne Road -| In the USA call: 1-800 orbix4u --------- Dublin 4, Ireland. ---------| ---------------- 1-800 6724948 --------- --------------------------------- "Making software work together (tm)" From: "Niebuhr, Brian" To: "'firewall-rtf@omg.org'" Subject: Issue 2 Date: Tue, 24 Aug 1999 22:58:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: d4087a799b55af9f1788a8f2828b882e Issue 2 See also Firewall RTF issue 2648 Description: The method for requesting a PASSTHRU connection is under-specified. Since the proxy is not able to inspect the traffic of a PASSTHRU connection, it will not be able to identify the target of that connection, and the firewall will be unable to route the traffic correctly. For example, assume that new_target() is invoked with the PASSTHRU argument and an object reference is returned which contains a different host/port pair than the current connection. When the new connection is opened up, that connection is supposedly a PASSTHRU connection and the firewall cannot look at the traffic. However, how is the firewall to know what the real target is? The firewall has no means to distinguish that connection from any other connection it receives on that port. The solution that immediately presents itself is to use a port per target, but this solution is not scalable, and even a reasonable use of CORBA will quickly cause the firewall to run out of ports. Proposed Solution: There are several possible solutions to this problem: 1) Require that a PASSTHRU connection take place on the same connection that was used to negotiate the PASSTHRU connection. Using this method we eliminate all ambiguity as to what target the client is trying to reach. In the discussion on issue 2648 Martin suggests a change in section 4.7.4 from, "A client is not required to open a new connection to the proxy server" to, "If the host/port in the returned IOR is identical to the IOR of the GIOPProxy (to which a connection should already exist), a client is not required to open a new connection to the proxy server." We suggest a further change to, "If the request was for a NORMAL mode connection, then if the host/port in the returned IOR is identical to the IOR of the GIOPProxy (to which a connection should already exist), a client is not required to open a new connection to the proxy server. If the request was for a PASSTHRU mode connection, then the returned IOR must have a NULL object reference and the current connection must be used for subsequent communication with the requested target. Once the Reply message for a PASSTHRU request has been sent, the connection is assumed to be in PASSTHRU mode and the firewall will not interpret any data passing on that connection." 2) This solution is a variation on the first which is less restrictive, but also adds complexity to the specification. We would like to be able to use some number of ports ( 1 <= ports <= c, where c is an arbitrary constant ) and to reuse those ports as often as necessary. In order to do this, we need to have a means of specifying the target for a given connection. For this solution we assume Martin's rewording from solution 1, but not the revised rewording from solution 1. To facilitate specification of a target on a PASSTHRU connection, we suggest the following operation be added to the GIOPProxy object: //IDL module Firewall { ... interface GIOPProxy { ... void start_passthru(in Object proxy); }; }; The start_passthru() operation will be used to indicate that a PASSTHRU connection is beginning and allows the client to specify the target for that connection. Opening a PASSTHRU connection will be done as follows: The client invokes new_target(target, PASSTHRU) and is returned a reference that contains the host and port of the proxified reference (which could be the same as the host and port of the current connection). The client then invokes start_passthru() with the returned reference as the argument. Once the start_passthru() operation has been called, the GIOPProxy will reply and indicate a NO_PERMISSION exception if applicable. Once the reply for the start_passthru() method is sent, all subsequent communication on that connection will not be inspected by the firewall. Leave it up to the vendors to reuse ports effectively. For example, a vendor could associate a port with a target until a connection is made on that port. Then that port would be free to be associated with a different target for the next connection that comes in on that port. For this solution it is important that the vendors solutions eliminate all ambiguity as to the target that is to be reached. This solution is as restrictive as solution 1 however, because the vendor is forced to use many ports (that is, the vendor will have to have the same number of ports as the number of proxified targets it has created that have not been contacted for a connection. This number is potentially large). In this case the vendor has no ability to use just a constant number of ports unless it wants to unnecessarily restrict traffic flow. From: "Niebuhr, Brian" To: "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: vote2, draft 3. Date: Tue, 14 Dec 1999 15:57:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: =k]d9_oA!!1T;!!n_Ne9 Just a couple of comments on these issues: 2648: The resolution supplied sufficiently covers the issue in the summary, but somewhere along the way an issue that I raised ("The method for requesting a PASSTHRU connection is under-specified.") was placed in the discussion of 2648. If that issue can be separated out and made into a separate issue we have no problems with the proposed resolution for this issue. The text that I originally posted is included after my comments here.