Issue 2866: Reusing PASSTHRU (firewall-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Description: Reusing PASSTHRU connections by the firewall should be expressly disallowed by the specification. With the current wording of the specification, a vendor may attempt to reuse PASSTHRU connections. While this will work in some cases, it is not interoperable because there are cases when reusing PASSTHRU connections will not work. For example, connection reuse when SSL is in use will not work because all of the information that distinguishes data streams is contained within the encrypted portion of SSL packets. If two SSL connections try to share a single connection, there will be an SSL protocol failure because the server will not be able to separate the data streams before it processes the SSL packet. Resolution: Revised Text: Actions taken: August 24, 1999: received issue Discussion: End of Annotations:===== From: "Niebuhr, Brian" To: "'firewall-rtf@omg.org'" Subject: Issue 4 Date: Tue, 24 Aug 1999 22:59:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: c59d1246bf05e84f6f7e0ddfb120f3fa Issue 4 See also issue 2 Description: Reusing PASSTHRU connections by the firewall should be expressly disallowed by the specification. With the current wording of the specification, a vendor may attempt to reuse PASSTHRU connections. While this will work in some cases, it is not interoperable because there are cases when reusing PASSTHRU connections will not work. For example, connection reuse when SSL is in use will not work because all of the information that distinguishes data streams is contained within the encrypted portion of SSL packets. If two SSL connections try to share a single connection, there will be an SSL protocol failure because the server will not be able to separate the data streams before it processes the SSL packet. Proposed Solution: Text should be added to the specification stating that reuse of PASSTHRU connections by the firewall is prohibited. One example is, "The GIOP Proxy may not reuse a PASSTHRU connection to a target to transmit data for a subsequent connection to the same target." Reply-To: From: "Martin Chapman" To: Subject: issue 2866 Date: Wed, 1 Dec 1999 16:43:25 -0000 Message-ID: <001001bf3c1b$300b6560$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: RIIe9]V_!!DKB!!5SN!! Do we want to explictly prevent this, provide a warning, or leave the text as is.My personal view on this is that if vendors can think of clever ways to reuse these connections then let them so I would opt the leave the text as is. Any other opinions? Issue 2866: Reusing PASSTHRU (firewall-rtf) Click here for this issue's archive. Nature: Uncategorized Issue Severity: Summary: Reusing PASSTHRU connections by the firewall should be expressly disallowed by the specification. With the current wording of the specification, a vendor may attempt to reuse PASSTHRU connections. While this will work in some cases, it is not interoperable because there are cases when reusing PASSTHRU connections will not work. For example, connection reuse when SSL is in use will not work because all of the information that distinguishes data streams is contained within the encrypted portion of SSL packets. If two SSL connections try to share a single connection, there will be an SSL protocol failure because the server will not be able to separate the data streams before it processes the SSL packet Resolution: Revised Text: Actions taken: August 24, 1999: received issue Discussion: ---------------------------------------------------------------------- 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: RE: issue 2866 Date: Wed, 1 Dec 1999 12:24:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: TLOd9bgPe9GP@!!cc%e9 > Do we want to explictly prevent this, provide a warning, or > leave the text > as is.My personal view on this is that if vendors can think > of clever ways > to reuse these connections then let them so I would opt the > leave the text > as is. > Any other opinions? Actually, as we discussed this issue amongst ourselves here we came to the conclusion that the reuse of PASSTHRU connections by the firewall was technically impossible for the following reason: Say host X is behind a client-side firewall and establishes a PASSTHRU connection to a server. If host Y (also behind the same firewall) attempts to establish a PASSTHRU connection as well and the firewall decides to reuse the old connection to the server, when packets come back from the server the firewall will be unable to correctly demultiplex them to either X or Y because it is unable to look at the data stream. Therefore I would suggest a warning in the spec, but leaving it the way it is may be sufficient. Brian _________________________ Brian Niebuhr Network Associates - NAI Labs 3060 Washington Rd. (Rt. 97) Glenwood, MD 21738 443-259-2349 bniebuhr@nai.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 1 Dec 1999 16:54:37 -0500 (EST) From: Polar Humenn To: Martin Chapman cc: firewall-rtf@omg.org Subject: Re: issue 2866 In-Reply-To: <001001bf3c1b$300b6560$4d01020a@leo.dublin.iona.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: )ph!!"*(!!f6>!!fVV!! Yes, this is a implemenation issue to be worked out behind the interface of the proxy manager. It has no bearing on how you use one of these things, only the way you build it. It is an implemation issue. Cheers, -Polar On Wed, 1 Dec 1999, Martin Chapman wrote: > Priority: Normal > X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 > X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 > Importance: Normal > Status: RO > X-Status: > X-Keywords: > X-UID: 10422 > > > Do we want to explictly prevent this, provide a warning, or leave > the text > as is.My personal view on this is that if vendors can think of > clever ways > to reuse these connections then let them so I would opt the leave > the text > as is. > Any other opinions? > > > Issue 2866: Reusing PASSTHRU (firewall-rtf) > Click here for this issue's archive. > Nature: Uncategorized Issue > Severity: > Summary: Reusing PASSTHRU connections by the firewall should be > expressly > disallowed by the specification. With the current wording of the > specification, a vendor may attempt to reuse PASSTHRU > connections. While > this will work in some cases, it is not interoperable because there > are > cases when reusing PASSTHRU connections will not work. For example, > connection reuse when SSL is in use will not work because all of the > information that distinguishes data streams is contained within the > encrypted portion of SSL packets. If two SSL connections try to > share a > single connection, there will be an SSL protocol failure because the > server > will not be able to separate the data streams before it processes > the SSL > packet > Resolution: > Revised Text: > Actions taken: > August 24, 1999: received issue > > Discussion: > > > ---------------------------------------------------------------------- > 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 - ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: From: "Martin Chapman" To: "Niebuhr, Brian" , Subject: RE: issue 2866 Date: Thu, 2 Dec 1999 11:08:34 -0000 Message-ID: <000701bf3cb5$9312e760$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 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 0i[d942Rd9-\2e9DI$!! I agree that it doesn't make sense for a a firewall itself to reuse a passthru connection. However a client can decide that it has a useful connection to the server via a passthru connection and could resue it rather than invoke new_target again. How about adding the following text in the new_target section: "For every successful PASSTHRU or PASSTHRUONLY connection requested, the GIOP Proxy shall establish a separate connection to its next hop, whether that be another GIOP Proxy or the target itself." Martin. > -----Original Message----- > From: Niebuhr, Brian [mailto:Brian_Niebuhr@NAI.com] > Sent: 01 December 1999 20:24 > To: firewall-rtf@omg.org > Subject: RE: issue 2866 > > > > Do we want to explictly prevent this, provide a warning, or > > leave the text > > as is.My personal view on this is that if vendors can think > > of clever ways > > to reuse these connections then let them so I would opt the > > leave the text > > as is. > > Any other opinions? > > Actually, as we discussed this issue amongst ourselves here > we came to the conclusion that the reuse of PASSTHRU > connections by the firewall was technically impossible for > the following reason: Say host X is behind a client-side > firewall and establishes a PASSTHRU connection to a server. > If host Y (also behind the same firewall) attempts to > establish a PASSTHRU connection as well and the firewall > decides to reuse the old connection to the server, when > packets come back from the server the firewall will be > unable to correctly demultiplex them to either X or Y > because it is unable to look at the data stream. > > Therefore I would suggest a warning in the spec, but leaving > it the way it is may be sufficient. > > Brian > > _________________________ > Brian Niebuhr > Network Associates - NAI Labs > 3060 Washington Rd. (Rt. 97) > Glenwood, MD 21738 > 443-259-2349 > bniebuhr@nai.com > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 2 Dec 1999 08:46:39 -0500 (EST) From: Polar Humenn To: Martin Chapman cc: "Niebuhr, Brian" , firewall-rtf@omg.org Subject: RE: issue 2866 In-Reply-To: <000701bf3cb5$9312e760$4d01020a@leo.dublin.iona.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: E I agree that it doesn't make sense for a a firewall itself to reuse a > passthru connection. > However a client can decide that it has a useful connection to the server > via a passthru connection and could resue it rather than invoke new_target > again. > > How about adding the following text in the new_target section: > "For every successful PASSTHRU or PASSTHRUONLY connection requested, the > GIOP Proxy shall establish a separate connection to its next hop, whether > that be another GIOP Proxy or the target itself." I don't agree with any of this. I still don't see why that matters, it is an implementation issue. I don't think a paragraph like the one above should be put there. Lets say we have just a straight TCP/IIOP firewalls. Client1-----IIOPFw1-----IIOPFw2-----Target | Client2----/ The first IIOP firewall, IIOPFw1 is smart enough during its PASSTHRU to block up the GIOP messages (or even SECIOP messages!), but doesn't look inside them. All it has to do is read the message lengths in the GIOP header to multiplex correctly. (Incidentally SECIOP uses the same header!). Why shouldn't the firewall use the same connection for Client2 to the next firewall if it is warranted? Just because this SSL crap is all buggered up. Don't cripple a good thing. Cheers, -Polar > Martin. > > > -----Original Message----- > > From: Niebuhr, Brian [mailto:Brian_Niebuhr@NAI.com] > > Sent: 01 December 1999 20:24 > > To: firewall-rtf@omg.org > > Subject: RE: issue 2866 > > > > > > > Do we want to explictly prevent this, provide a warning, or > > > leave the text > > > as is.My personal view on this is that if vendors can think > > > of clever ways > > > to reuse these connections then let them so I would opt the > > > leave the text > > > as is. > > > Any other opinions? > > > > Actually, as we discussed this issue amongst ourselves here > > we came to the conclusion that the reuse of PASSTHRU > > connections by the firewall was technically impossible for > > the following reason: Say host X is behind a client-side > > firewall and establishes a PASSTHRU connection to a server. > > If host Y (also behind the same firewall) attempts to > > establish a PASSTHRU connection as well and the firewall > > decides to reuse the old connection to the server, when > > packets come back from the server the firewall will be > > unable to correctly demultiplex them to either X or Y > > because it is unable to look at the data stream. > > > > Therefore I would suggest a warning in the spec, but leaving > > it the way it is may be sufficient. > > > > Brian > > > > _________________________ > > Brian Niebuhr > > Network Associates - NAI Labs > > 3060 Washington Rd. (Rt. 97) > > Glenwood, MD 21738 > > 443-259-2349 > > bniebuhr@nai.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: "Niebuhr, Brian" To: firewall-rtf@omg.org Subject: RE: issue 2866 Date: Thu, 2 Dec 1999 07:59:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: U~He9$R)e9A"p!!]!C!! Comments below... > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, December 02, 1999 8:47 AM > To: Martin Chapman > Cc: Niebuhr, Brian; firewall-rtf@omg.org > Subject: RE: issue 2866 > > > On Thu, 2 Dec 1999, Martin Chapman wrote: > > > I agree that it doesn't make sense for a a firewall itself > to reuse a > > passthru connection. > > However a client can decide that it has a useful connection > to the server > > via a passthru connection and could resue it rather than > invoke new_target > > again. > > > > How about adding the following text in the new_target section: > > "For every successful PASSTHRU or PASSTHRUONLY connection > requested, the > > GIOP Proxy shall establish a separate connection to its > next hop, whether > > that be another GIOP Proxy or the target itself." > > I don't agree with any of this. I still don't see why that > matters, it is > an implementation issue. I don't think a paragraph like the one > above > should be put there. > > Lets say we have just a straight TCP/IIOP firewalls. I don't know if this clears up the issue any, but the question at hand only refers to PASSTHRU connections through GIOP Proxy firewalls. I'm not sure if that's what you meant to say here. > > Client1-----IIOPFw1-----IIOPFw2-----Target > | > Client2----/ > > The first IIOP firewall, IIOPFw1 is smart enough during its > PASSTHRU to > block up the GIOP messages (or even SECIOP messages!), but > doesn't look > inside them. All it has to do is read the message lengths in the > GIOP > header to multiplex correctly. (Incidentally SECIOP uses the same > header!). Why shouldn't the firewall use the same connection > for Client2 > to the next firewall if it is warranted? Actually the implication of a PASSTHRU connection is that any protocol could be sent through that connection. Most likely it will be SSL rather than something more convienient like IIOP or SECIOP. But this implies that the firewall shouldn't even attempt to look at the traffic because to the firewall the data should just be an opaque stream of bytes. I think looking at the data would actually be a violation of the intent of a PASSTHRU connection and shouldn't be allowed for the normal operation of a GIOP Proxy. Brian > Just because this SSL crap is all buggered up. Don't cripple > a good thing. > > Cheers, > -Polar > > > Martin. > > > > > -----Original Message----- > > > From: Niebuhr, Brian [mailto:Brian_Niebuhr@NAI.com] > > > Sent: 01 December 1999 20:24 > > > To: firewall-rtf@omg.org > > > Subject: RE: issue 2866 > > > > > > > > > > Do we want to explictly prevent this, provide a warning, or > > > > leave the text > > > > as is.My personal view on this is that if vendors can think > > > > of clever ways > > > > to reuse these connections then let them so I would opt the > > > > leave the text > > > > as is. > > > > Any other opinions? > > > > > > Actually, as we discussed this issue amongst ourselves here > > > we came to the conclusion that the reuse of PASSTHRU > > > connections by the firewall was technically impossible for > > > the following reason: Say host X is behind a client-side > > > firewall and establishes a PASSTHRU connection to a server. > > > If host Y (also behind the same firewall) attempts to > > > establish a PASSTHRU connection as well and the firewall > > > decides to reuse the old connection to the server, when > > > packets come back from the server the firewall will be > > > unable to correctly demultiplex them to either X or Y > > > because it is unable to look at the data stream. > > > > > > Therefore I would suggest a warning in the spec, but leaving > > > it the way it is may be sufficient. > > > > > > Brian > > > > > > _________________________ > > > Brian Niebuhr > > > Network Associates - NAI Labs > > > 3060 Washington Rd. (Rt. 97) > > > Glenwood, MD 21738 > > > 443-259-2349 > > > bniebuhr@nai.com > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > Principal 2-212 Center for Science & Technology > mailto:polar@adiron.com CASE Center/Syracuse University > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > From: "Niebuhr, Brian" To: firewall-rtf@omg.org Subject: RE: issue 2866 Date: Thu, 2 Dec 1999 07:34:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 5OX!!Zp_d9mgL!!M\A!! On your first point, I agree with your analysis. I did not mean to imply that a client could not reuse a passthru connection, just the intermediate proxies. I also agree with the proposed change. Brian > -----Original Message----- > From: Martin Chapman [mailto:mchapman@iona.com] > Sent: Thursday, December 02, 1999 6:09 AM > To: Niebuhr, Brian; firewall-rtf@omg.org > Subject: RE: issue 2866 > > > I agree that it doesn't make sense for a a firewall itself to reuse > a > passthru connection. > However a client can decide that it has a useful connection > to the server > via a passthru connection and could resue it rather than > invoke new_target > again. > > How about adding the following text in the new_target section: > "For every successful PASSTHRU or PASSTHRUONLY connection > requested, the > GIOP Proxy shall establish a separate connection to its next > hop, whether > that be another GIOP Proxy or the target itself." > > Martin. > > > -----Original Message----- > > From: Niebuhr, Brian [mailto:Brian_Niebuhr@NAI.com] > > Sent: 01 December 1999 20:24 > > To: firewall-rtf@omg.org > > Subject: RE: issue 2866 > > > > > > > Do we want to explictly prevent this, provide a warning, or > > > leave the text > > > as is.My personal view on this is that if vendors can think > > > of clever ways > > > to reuse these connections then let them so I would opt the > > > leave the text > > > as is. > > > Any other opinions? > > > > Actually, as we discussed this issue amongst ourselves here > > we came to the conclusion that the reuse of PASSTHRU > > connections by the firewall was technically impossible for > > the following reason: Say host X is behind a client-side > > firewall and establishes a PASSTHRU connection to a server. > > If host Y (also behind the same firewall) attempts to > > establish a PASSTHRU connection as well and the firewall > > decides to reuse the old connection to the server, when > > packets come back from the server the firewall will be > > unable to correctly demultiplex them to either X or Y > > because it is unable to look at the data stream. > > > > Therefore I would suggest a warning in the spec, but leaving > > it the way it is may be sufficient. > > > > Brian > > > > _________________________ > > Brian Niebuhr > > Network Associates - NAI Labs > > 3060 Washington Rd. (Rt. 97) > > Glenwood, MD 21738 > > 443-259-2349 > > bniebuhr@nai.com > > > X-Authentication-Warning: marcy.adiron.com: polar owned process doing > -bs Date: Thu, 2 Dec 1999 14:25:35 -0500 (EST) From: Polar Humenn To: "Niebuhr, Brian" cc: firewall-rtf@omg.org Subject: RE: issue 2866 In-Reply-To: > Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: <#;!!^G$!!=@Je9DC8!! On Thu, 2 Dec 1999, Niebuhr, Brian wrote: > I don't know if this clears up the issue any, but the question at hand > only refers to PASSTHRU connections through GIOP Proxy firewalls. I'm > not sure if that's what you meant to say here. > > > > > Client1-----IIOPFw1-----IIOPFw2-----Target > > | > > Client2----/ > > > > The first IIOP firewall, IIOPFw1 is smart enough during its > > PASSTHRU to > > block up the GIOP messages (or even SECIOP messages!), but > > doesn't look > > inside them. All it has to do is read the message lengths in the GIOP > > header to multiplex correctly. (Incidentally SECIOP uses the same > > header!). Why shouldn't the firewall use the same connection > > for Client2 > > to the next firewall if it is warranted? > > Actually the implication of a PASSTHRU connection is that any > protocol could be sent through that connection. Most likely it > will be SSL rather than something more convienient like IIOP or > SECIOP. But this implies that the firewall shouldn't even attempt > to look at the traffic because to the firewall the data should just > be an opaque stream of bytes. I think looking at the data would > actually be a violation of the intent of a PASSTHRU connection and > shouldn't be allowed for the normal operation of a GIOP Proxy. Okay, say its a violation? So What? How are you going to enforce it?! By just saying it's not CORBA compliant firewall? Saying something is a violation that is quite unenforceable is just a point of contention. Semantics that go beyond the interface that are not functional but just restrictive are a bad idea. You keep the firewall from looking at the contents of messages by using encryption, such as SECIOP or SSLIOP, or some other protocol from the client. It doesn't matter. In fact, even a smart firewall can diseminate SSL packets as they fly by and multiplex them over one connection over a copperating VPN boxes, which are basically firewalls, correct? (Super encryption, I know). It's just my opinion, but I say the point is moot and the firewall is free to implement whatever behind the interface. The only semantics that it can enforce is just has to make sure that invocations on the new target get toward where its suppose to go, just as good as any other good IP router could do. Notice, I said "toward" and not explicitly "to". I recommend to close the issue. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com