Issue 2261: passthrough connection (firewall-rtf) Source: (, ) Nature: Clarification Severity: Summary: Summary: I would like to get some clarification on the PASSTHROUGH/Untrusted Proxy issue. In page 4-45, the spec says "It is possible to support pass-through through multiple proxies. For example if in the above example there was another proxy B2 between B and C, during processing the new_target operation from A, B can try to establish a pass-through connection to C via a call to new_target on B2. If this fails, due to NO_PERMISSION for example, B should fall back to try to connect through B2 using the NORMAL mode.". If the connection (B - B2) is NORMAL, the whole connection is not a PASSTHROUGH since the client will see the B2"s identity in the SSL session. Should B throw back the NO_PERMISSION to the client if B get NO_PERMISSION from B2 for PASSTHROUGH connection? If the answer is no (seems to me that is what spec says), does this mean that it is possible that the client request a PASSTHROUGH connection but actually get a NORMAL connection? Resolution: Revised Text: Actions taken: December 16, 1998: received issue Discussion: End of Annotations:===== Return-Path: From: "Martin Chapman" To: Subject: FW: passthrough connection Date: Wed, 16 Dec 1998 09:39:04 -0000 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 -----Original Message----- From: Wei Chen [mailto:wchen@inprise.com] Sent: 16 December 1998 00:55 To: firewall-rtf Subject: passthrough connection Hi, all, I would like to get some clarification on the PASSTHROUGH/Untrusted Proxy issue. In page 4-45, the spec says "It is possible to support pass-through through multiple proxies. For example if in the above example there was another proxy B2 between B and C, during processing the new_target operation from A, B can try to establish a pass-through connection to C via a call to new_target on B2. If this fails, due to NO_PERMISSION for example, B should fall back to try to connect through B2 using the NORMAL mode.". If the connection (B - B2) is NORMAL, the whole connection is not a PASSTHROUGH since the client will see the B2's identity in the SSL session. Should B throw back the NO_PERMISSION to the client if B get NO_PERMISSION from B2 for PASSTHROUGH connection? If the answer is no (seems to me that is what spec says), does this mean that it is possible that the client request a PASSTHROUGH connection but actually get a NORMAL connection? In other words, can the client assume it is really talking to the server when it get a PASSTHROUGH? Or it is a proxy's decision whether the connection should be a PASSTHROUH or not? Thanks. - Wei Chen From: "Niebuhr, Brian" To: "'firewall-rtf@omg.org'" Subject: Issue 5 Date: Tue, 24 Aug 1999 23:00:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 21c72c5b3ccb8b9182fd107d771749c5 Issue 5 See also Firewall RTF issue 2261 Description: If there is a chain of firewalls and the client is able to negotiate a PASSTHRU connection on the first firewall, but somewhere in the chain the attempt to establish a PASSTHRU connection fails, the specification states that the intermediate firewalls should attempt to create a NORMAL mode connection. This seems to be a violation of the security that the client thought it was getting by having a direct connection to the server. Is this really the best policy for this situation? Proposed Solution: The firewall that did not allow the PASSTHRU connection should return a NO_PERMISSION exception as required by the specification. Each firewall in the chain should then also return the NO_PERMISSION exception until the exception reaches the client. In this instance a PASSTHRU connection will not be created. In section 4.13, the sentence that reads "If this fails, due to NO_PERMISSION for example, B should fall back to try to connect through B2 using the NORMAL mode" should be changed to "If this fails, due to NO_PERMISSION for example, B should also return a NO_PERMISSION exception" X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 29 Nov 1999 13:44:43 -0500 (EST) From: Polar Humenn To: Martin Chapman cc: Paul Kyzivat , firewall-rtf@omg.org Subject: RE: Round 1 In-Reply-To: <002c01bf3a85$8fe25760$4d01020a@leo.dublin.iona.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: To: mchapman@iona.com, firewall-rtf@omg.org Subject: Re: VOTE 1 draft 2 (Issue 2261) Message-ID: <3556574816.944154412@ews-proj-2.hpl.hp.com> In-Reply-To: <002601bf3b52$70e24fa0$4d01020a@leo.dublin.iona.ie> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: >~9e9J^P!!&Tnd9#m:e9 --On 30 November 1999, 16:46 +0000 Martin Chapman wrote: > Issue 2261: passthrough connection (firewall-rtf) [...] > Section 4.7.4, Page 4-15 2nd para (under new_target) [...proposed replacement text...] > The object returned by a successful call to new_target is used to > send > the actual request. If a NORMAL connection was established, a GIOP > request containing the returned object's object_key ishould be sent > to an > address contaitned in the returned object's IOR. If the mode was > PASSTHRU > or PASSTHRUONLY, a GIOP request containing the target object's > object_key > should be sent to an address contained in the returned object's IOR" > This wording suggests to me that the client is expected to take an object key out of one IOR, and use it with the connection data from a different IOR, and I don't like that at all. I think that the proxy must return a reference from new_target that contains the same object key as in the target object reference. If there are multiple profiles in the target object ref, the proxy has a choice about picking one, or doing something clever to return several profiles. Instead of the text above, I would like something like this: "The object returned by a successful call to new_target is used to send the actual request. Note that if the mode was PASSTHRU or PASSTHRUONLY, the object key (or keys) in the reference returned by the proxy must be object keys that were in the target reference, since the proxy does not modify the requests on a PASSTHRU or PASSTHRUONLY connection. The proxy must also use separate incoming connections for separate target connections since it does not observe the content of requests, and therefore cannot select a target connection on the basis of object key." Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Reply-To: From: "Martin Chapman" To: "Owen Rees" , Subject: RE: VOTE 1 draft 2 (Issue 2261) Date: Fri, 3 Dec 1999 11:37:28 -0000 Message-ID: <000a01bf3d82$c7420a20$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3556574816.944154412@ews-proj-2.hpl.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: p[ld9V*k!!mJL!!GP)e9 Its much of a muchness whether the firewall or the client does this. either the firewall creates a proxy IOR with the correct object key (the key of the proxy for normal, the key of the target for passthru) or it always returns an IOR with the key of the proxy object - in the later case the client needs to send giop requests to the address of the proxy but uses the object key in the target. The advantage of the client doing it is that you could, if you wanted to, do object operations (is_a for e.g.) on both the proxy and the target - the former scenarios excludes this. martin. > -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: 02 December 1999 17:07 > To: mchapman@iona.com; firewall-rtf@omg.org > Subject: Re: VOTE 1 draft 2 (Issue 2261) > > > --On 30 November 1999, 16:46 +0000 Martin Chapman > wrote: > > > Issue 2261: passthrough connection (firewall-rtf) > > [...] > > Section 4.7.4, Page 4-15 2nd para (under new_target) > > [...proposed replacement text...] > > The object returned by a successful call to new_target is used to > send > > the actual request. If a NORMAL connection was established, a GIOP > > request containing the returned object's object_key ishould be > sent to an > > address contaitned in the returned object's IOR. If the mode > was PASSTHRU > > or PASSTHRUONLY, a GIOP request containing the target object's > object_key > > should be sent to an address contained in the returned object's > IOR" > > This wording suggests to me that the client is expected to take an > object > key out of one IOR, and use it with the connection data from a > different > IOR, and I don't like that at all. I think that the proxy must > return a > reference from new_target that contains the same object key as in > the > target object reference. If there are multiple profiles in the > target > object ref, the proxy has a choice about picking one, or doing > something > clever to return several profiles. Instead of the text above, I > would like > something like this: > > "The object returned by a successful call to new_target is used to > send > the actual request. > > Note that if the mode was PASSTHRU or PASSTHRUONLY, the object key > (or > keys) in the reference returned by the proxy must be object keys > that were > in the target reference, since the proxy does not modify the > requests on a > PASSTHRU or PASSTHRUONLY connection. The proxy must also use > separate > incoming connections for separate target connections since it does > not > observe the content of requests, and therefore cannot select a > target > connection on the basis of object key." > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > Date: Mon, 06 Dec 1999 15:38:36 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org Subject: RE: Vote 1 draft 3 Issue 2261 Message-ID: <3896878566.944494716@ews-proj-2.hpl.hp.com> In-Reply-To: <000401bf3d97$0c3948a0$4d01020a@leo.dublin.iona.ie> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: /K/e9'46!!;WQd97Ok!! I am going to vote NO on this one, so I thought I would explain why first. --On 03 December 1999, 14:02 +0000 Martin Chapman wrote: > Issue 2261: passthrough connection (firewall-rtf) > Section 4.7.4, Page 4-15 2nd para (under new_target) > The object returned by a successful call to new_target is used to send > the actual request. If a NORMAL connection was established, a GIOP > request containing the returned object's object_key should be sent to an > address contaitned in the returned object's IOR. If the mode was PASSTHRU > or PASSTHRUONLY, a GIOP request containing the target object's object_key > should be sent to an address contained in the returned object's IOR" If there are two proxies, and PASSTHRU is requested, and the second proxy refuses PASSTHRU, the first should try NORMAL. If this suceeds, the second proxy will return an IOR to the first proxy and will expect the object key in that IOR to be used. What IOR can the first proxy return to the client to make the client use that key? If the client will use the target object's key than there is no way to make this work. I don't think we can fix the wording around PASSTHRU until after we have agreed on the behaviour we are trying to describe. In particular, we need to resolve the points being discussed under issue 2867 before we can be sure that issue 2261 is resolved in a consistent way. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285