Issue 2865: Proxified object references (firewall-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Proxified object references obtained by invoking new_target() should not be passed between ORBs. Instead the original IOR containing the target and firewall information should be passed. The reason for this is that the IOR does not contain enough information to inform the second ORB whether or not it is a reference for a NORMAL or PASSTHRU connection, or whether it is a proxified reference at all. This issue is very tightly related to issue 2, so we will describe how it fails for each of the possible solutions to the PASSTHRU establishment problem outlined in issue 2. One solution for which this is not an issue is the solution of using a port per target. However, this is not a viable solution because it is restrictive and will fail under moderate load. For solution 1 we don"t have a problem because no object reference is returned by set_target(), therefore it cannot be passed to other ORBs. For solution 2 we have a problem because the second ORB won"t know whether it is supposed to first invoke start_passthru() or simply start making requests. Therefore it may get a connection type that it wasn"t expecting. For solution 3 we have a problem because once the original connection has been made, the reference is invalid. This occurs because the firewall does not have knowledge of how many clients are expected to try to connect to that target, and it may attempt to claim that port for reuse before another client has connected. Proposed Solution: The passing of object references obtained by invoking new_target() should be expressly prohibited by the specification. One example is, "The object reference returned by new_target() may not be passed to another client. Instead the original reference that was passed as the argument to new_target() must be passed to the second client, and the second client will follow the rules of the traversal algorithm to reach the desired target." Resolution: Revised Text: Actions taken: August 24, 1999: received issue Discussion: End of Annotations:===== From: "Niebuhr, Brian" To: "'firewall-rtf@omg.org'" Subject: Issue 3 Date: Tue, 24 Aug 1999 22:59:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ee17de8f4342d2bbc86f0f77d45df403 Issue 3 See also issue 2 Description: Proxified object references obtained by invoking new_target() should not be passed between ORBs. Instead the original IOR containing the target and firewall information should be passed. The reason for this is that the IOR does not contain enough information to inform the second ORB whether or not it is a reference for a NORMAL or PASSTHRU connection, or whether it is a proxified reference at all. This issue is very tightly related to issue 2, so we will describe how it fails for each of the possible solutions to the PASSTHRU establishment problem outlined in issue 2. One solution for which this is not an issue is the solution of using a port per target. However, this is not a viable solution because it is restrictive and will fail under moderate load. For solution 1 we don't have a problem because no object reference is returned by set_target(), therefore it cannot be passed to other ORBs. For solution 2 we have a problem because the second ORB won't know whether it is supposed to first invoke start_passthru() or simply start making requests. Therefore it may get a connection type that it wasn't expecting. For solution 3 we have a problem because once the original connection has been made, the reference is invalid. This occurs because the firewall does not have knowledge of how many clients are expected to try to connect to that target, and it may attempt to claim that port for reuse before another client has connected. Proposed Solution: The passing of object references obtained by invoking new_target() should be expressly prohibited by the specification. One example is, "The object reference returned by new_target() may not be passed to another client. Instead the original reference that was passed as the argument to new_target() must be passed to the second client, and the second client will follow the rules of the traversal algorithm to reach the desired target." 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: 2865: This is another issue that is dependent upon the problem of how a PASSTHRU connection is established and what is returned from the call to new_target(PASSTHRU). We believe that the PASSTHRU issues (2261, 2865, and the buried issue in 2648 that I mentioned in the last paragraph) need to be resolved all together in a consistent manner. It seems that the PASSTHRU problems as a whole has been repeatedly overlooked. Below I have included my original statement of the problem and a couple of proposed solutions. Note that I have made a slight change from my original post to solution 1). I believe that these solutions solve the issues I have mentioned above, and if we can agree on one we can get these issues closed. Here it is: 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 must be the IOR returned from subsequent calls to new_target() (or the target IOR if on the last proxy before the server) 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 beable 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 Objectproxy); }; }; 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. 3) 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. _________________________ Brian Niebuhr Network Associates - NAI Labs 3060 Washington Rd. (Rt. 97) Glenwood, MD 21738 443-259-2349 bniebuhr@nai.com > -----Original Message----- > From: Martin Chapman [mailto:mchapman@iona.com] > Sent: Tuesday, December 14, 1999 10:22 AM > To: firewall-rtf@omg.org > Subject: vote2, draft 3. > > > latest up date folding in comments. > I haven't changed anything based on Owens last message about > issue 2651. > Persnally I like most of what is said ther (see the reply), but I'm > interested in other feedback. > > I'd like to freeze the text tomorrow, and formally call for > votes (to close > friday) > Cheers, > Martin. > > > ---------------------------------------------------------------------- > 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 Cc: "'Owen Rees'" Subject: RE: vote2, draft 3. vote revised since draft 2 Date: Thu, 16 Dec 1999 10:03:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: iK-!!;ked9+V)e9:~@e9 comments below > -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: Thursday, December 16, 1999 11:12 AM > To: mchapman@iona.com; firewall-rtf@omg.org > Subject: Re: vote2, draft 3. vote revised since draft 2 > ... > 2865: if references returned from new_target would work when > passed to a > different ORB, why prohibit it? If other constraints mean > they would not > work, the prohibition is implied anyway. There is no need to > say either > way, and saying risks being inconsistent with other constraints. ... My concern is that the lifetime of the proxy objects created by the call to new_target is undefined. So once the proxy object has been "consumed", knowledge of that object may disappear, that is, there may no longer be a process listening on that port or the mapping from the proxy object to the target object might have been removed. So essentially the target becomes unreachable even though there may be a means to reach it via the GIOPProxy object. (Remember, the ORB receiving the proxified reference does not know the actual target, only the proxified target. Therefore it can't even retry because it doesn't have the target information) What I'm trying to avoid is the situation where Vendor A's ORB knows that Vendor A's GIOPProxy has a specified behavior in this situation (such as, the port will always be open and the mapping from proxy object to target object is done in such a way that the target can always be determined from the proxy object) so Vendor A's products will always work together. However this behavior is not specified, and if someone tries to use Vendor A's ORB with Vendor B's GIOPProxy, the application won't work. Brian _________________________ Brian Niebuhr Network Associates - NAI Labs 3060 Washington Rd. (Rt. 97) Glenwood, MD 21738 443-259-2349 bniebuhr@nai.com