Issue 2641: Firewall Traversal algorithm (firewall-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The description of firewall traversal in orbos/98-07-03 4.11 has some significant unstated assumptions, and prescribes an algorithm that has several flaws. In orbos/98-07-03 4.11 it says: "A client will determine if it needs to go through a firewall to make a request on the target object. If the client is in the same domain a direct invocation can be made. The client can determine this be examining the host address information in the target IOR." This assumes that the enclave structure maps to host addresses in some way known to all clients. This needs to be made more explicit. Resolution: Revised Text: Actions taken: May 7, 1999: received issue Discussion: End of Annotations:===== Date: Fri, 07 May 1999 12:25:07 +0100 From: Owen Rees To: OMG Issues , OMG Firewall RTF Subject: Firewall Traversal algorithm Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline The description of firewall traversal in orbos/98-07-03 4.11 has some significant unstated assumptions, and prescribes an algorithm that has several flaws. In orbos/98-07-03 4.11 it says: "A client will determine if it needs to go through a firewall to make a request on the target object. If the client is in the same domain a direct invocation can be made. The client can determine this be examining the host address information in the target IOR." This assumes that the enclave structure maps to host addresses in some way known to all clients. This needs to be made more explicit. The prescribed algorithm states that the firewall components are inspected if the client "cannot determine an outbound firewall". This implies that invocations to objects in nested inner enclaves go via the outbound firewall which is poor for security and poor for efficiency. The algorithm also states that the client picks "the first FirewallMechanism" but this is not appropriate for an invocation from within an enclave to an inner enclave. Such a client would be attempting to invoke an inbound proxy from the inside, and this should fail if the firewall is configured to prohibit direct outbound connections. Given that clients need to know how host addresses map to the enclave structure, it would be better for the client to start by examining the FirewallMechanisms in the reference, starting with the innermost, until it finds one it can reach, and only using its configured outbound firewall if it finds no inbound firewall. The description of traversing a GIOP proxy says it uses "the same traversal algorithm as a client" but this will cause a loop unless the client algorithm is corrected to go in the most appropriate direction. In the sections on traversing a TCP firewall to a SOCKS firewall and traversing a SOCKS firewall it is not made clear that the SOCKS library must be reconfigured dynamically depending on the information in the IOR (and this must be protected against concurrent reconfiguration for a multi-threaded client). It should be made explicit what is involved in doing this since the description of SOCKS (4.6) says "... the client host must be configured to route SOCKS requests to the appropriate proxy server. This is controlled by client-side configuration files". Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 From: "Martin Chapman" To: "Owen Rees" , "OMG Issues" , "OMG Firewall RTF" Subject: RE: Firewall Traversal algorithm Date: Mon, 10 May 1999 17:52:45 +0100 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 see below > -----Original Message----- > From: Owen Rees [mailto:Owen_Rees@hplb.hpl.hp.com] > Sent: 07 May 1999 12:25 > To: OMG Issues; OMG Firewall RTF > Subject: Firewall Traversal algorithm > > > The description of firewall traversal in orbos/98-07-03 4.11 has > some > significant unstated assumptions, and prescribes an algorithm that > has > several flaws. > > In orbos/98-07-03 4.11 it says: "A client will determine if it needs > to go through a firewall to make a request on the target object. If > the client is in the same domain a direct invocation can be > made. The > client can determine this be examining the host address information > in > the target IOR." This assumes that the enclave structure maps to > host > addresses in some way known to all clients. This needs to be made > more > explicit. Not sure what you mean here - all this means is if you determine you are in the same ip domain you don't need to use the firewall. > The prescribed algorithm states that the firewall components are > inspected if the client "cannot determine an outbound > firewall". This > implies that invocations to objects in nested inner enclaves go via > the outbound firewall which is poor for security and poor for > efficiency. Yes it is bad security and inefficient but if the client doesn't know about inner enclaves it must treat the target as if it is outside. > > The algorithm also states that the client picks "the first > FirewallMechanism" but this is not appropriate for an invocation > from > within an enclave to an inner enclave. Such a client would be > attempting to invoke an inbound proxy from the inside, and this > should > fail if the firewall is configured to prohibit direct outbound > connections. Ok the wording could be clarified here. > > Given that clients need to know how host addresses map to > the enclave structure, it would be better for the client to start by > examining the FirewallMechanisms in the reference, starting with the > innermost, until it finds one it can reach, and only using its > configured outbound firewall if it finds no inbound firewall. No I disagree here if there's an outbound firewall you should always go through it to get to an outer enclave - or have i missed something. > > The description of traversing a GIOP proxy says it uses "the same > traversal algorithm as a client" but this will cause a loop unless > the > client algorithm is corrected to go in the most appropriate > direction. tres pedantic > > In the sections on traversing a TCP firewall to a SOCKS firewall and > traversing a SOCKS firewall it is not made clear that the SOCKS > library must be reconfigured dynamically depending on the > information > in the IOR (and this must be protected against concurrent > reconfiguration for a multi-threaded client). It should be made > explicit what is involved in doing this since the description of > SOCKS > (4.6) says "... the client host must be configured to route SOCKS > requests to the appropriate proxy server. This is controlled by > client-side configuration files". We sort of glossed over this isse since at the time most socks implememntations couldn't be dynamically configured - I don't know if this is still true. > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > Date: Tue, 11 May 1999 01:45:05 +0100 From: Owen Rees To: Martin Chapman , Owen Rees , OMG Issues , OMG Firewall RTF Subject: RE: Firewall Traversal algorithm Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline --On 10 May 1999, 17:52 +0100 Martin Chapman wrote: > see below > >> -----Original Message----- >> From: Owen Rees [mailto:Owen_Rees@hplb.hpl.hp.com] >> Sent: 07 May 1999 12:25 >> To: OMG Issues; OMG Firewall RTF >> Subject: Firewall Traversal algorithm >> >> >> The description of firewall traversal in orbos/98-07-03 4.11 has > some >> significant unstated assumptions, and prescribes an algorithm that > has >> several flaws. >> >> In orbos/98-07-03 4.11 it says: "A client will determine if it > needs >> to go through a firewall to make a request on the target object. If >> the client is in the same domain a direct invocation can be > made. The >> client can determine this be examining the host address information > in >> the target IOR." This assumes that the enclave structure maps to > host >> addresses in some way known to all clients. This needs to be made > more >> explicit. > > Not sure what you mean here - all this means is if you determine you > are > in the same ip domain you don't need to use the firewall. Could you explain 'IP domain'? How can I determine from two IP addresses that they are in the same domain in the sense that there is no firewall between them? I don't see how any client can determine this by examining host address information. > > > >> The prescribed algorithm states that the firewall components are >> inspected if the client "cannot determine an outbound > firewall". This >> implies that invocations to objects in nested inner enclaves go via >> the outbound firewall which is poor for security and poor for >> efficiency. > > Yes it is bad security and inefficient but if the client doesn't > know > about inner enclaves it must treat the target as if it is outside. If traffic is to be routed out through the firewall and back in again, this has security implications and needs to be made explicit. > >> >> The algorithm also states that the client picks "the first >> FirewallMechanism" but this is not appropriate for an invocation >> from >> within an enclave to an inner enclave. Such a client would be >> attempting to invoke an inbound proxy from the inside, and this >> should >> fail if the firewall is configured to prohibit direct outbound >> connections. > > Ok the wording could be clarified here. > >> >> Given that clients need to know how host addresses map to >> the enclave structure, it would be better for the client to start >> by >> examining the FirewallMechanisms in the reference, starting with >> the >> innermost, until it finds one it can reach, and only using its >> configured outbound firewall if it finds no inbound firewall. > > No I disagree here if there's an outbound firewall you should always >> go > through it to get to an outer enclave - or have i missed something. If the client is inside some enclave nest at some depth, and the target is in some deeper inside enclave, working outwards from the innermost firewall until the client finds a firewall it can invoke directly gives the most direct route. If you insist that the client calls outwards, even when the target is deeper in, this is irrelevant. > >> >> The description of traversing a GIOP proxy says it uses "the same >> traversal algorithm as a client" but this will cause a loop unless >> the >> client algorithm is corrected to go in the most appropriate >> direction. > > tres pedantic Merely pointing that a GIOP proxy must use a different algorithm. A client can never invoke a nested inbound GIOP proxy with the given algorithm. A GIOP proxy must be able to do this to support nested enclaves. > >> >> In the sections on traversing a TCP firewall to a SOCKS firewall >> and >> traversing a SOCKS firewall it is not made clear that the SOCKS >> library must be reconfigured dynamically depending on the >> information >> in the IOR (and this must be protected against concurrent >> reconfiguration for a multi-threaded client). It should be made >> explicit what is involved in doing this since the description of >> SOCKS >> (4.6) says "... the client host must be configured to route SOCKS >> requests to the appropriate proxy server. This is controlled by >> client-side configuration files". > > We sort of glossed over this isse since at the time most socks > implememntations couldn't be dynamically configured - I don't know >> if this > is still true. > >> >> Regards, >> Owen Rees >> Hewlett Packard Laboratories, Bristol, UK >> tel: +44 117 312 9439 fax: +44 117 312 9285 >> Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 From: "Niebuhr, Brian" To: "'firewall-rtf@omg.org'" Subject: Issue 7 Date: Tue, 24 Aug 1999 23:03:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3e4923cf8a6d5a514d8f289b54d013a3 Issue 7 See also Firewall RTF issue 2641 Description: The specification states that the client should pick the first FirewallMechanism from the TAG_FIREWALL_TRANS field of any firewall component in the IOR. This implies that the client will always get to the server via the outermost inbound firewall, regardless of whether the server is actually outside the enclave the client is in or in an inner enclave of the client's enclave. This is both insecure and inefficient. Many commercial firewalls would specifically disallow an inside host to contact the firewall's outside interface. Proposed Solution: The fifth paragraph in 4.11 should be changed to "A client that determines it cannot make a direct invocation needs to traverse firewalls. It looks in the IOR and picks the last FirewallMechanism in the TAG_FIREWALL_TRANS field of any firewall component in the IOR. If a client determines that it cannot make an invocation on that firewall it should proceed toward the first FirewallMechanism until it finds an entry that it can reach. If none of the FirewallMechanisms are reachable, then the client should get the information, from its configuration, on the next outbound firewall that must be traversed, and the request should be sent to that firewall. From: "Niebuhr, Brian" To: "'firewall-rtf@omg.org'" Subject: Issue 8 Date: Tue, 24 Aug 1999 23:03: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: c2ddb11b4e11fe5ae4c57d3cef39b00d Issue 8 See also issue 7 See also Firewall RTF issue 2641 Description: It is not clear how a client is to determine whether it needs to use a firewall or not. Section 4.11 states that "A client will determine if it needs to go through a firewall to make a request on the target object. If the client is in the same domain a direct invocation can be made. The client can determine this by examining the host address information in the target IOR." This is not actually possible using the host address information. Take for example a topology where one organization (call it organization A) uses RFC 1597 addresses (10.x.x.x) as does organization B. If a client gets a reference to a server in organization B, it will think that the server is in its own "IP domain" and not attempt to use a firewall. Proposed Solution: There are two possible solutions to this problem. The first is to find a globally unique mechanism for identifying a host or to tie a host's address to a hierarchical identifier. One such solution would be to only use DNS host names in the IOR. This has a couple of problems though in that it is restrictive to the vendors and firewall specification implementations are tied to DNS. A second solution to this problem is to have clients sequentially attempt each address until they reach a valid firewall or the target server. This is less restrictive but is inefficient.