Issue 7351: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY (firewall-traversal-ftf) Source: Syracuse University (Mr. C. Joncheng Kuo, joncheng_kuo(at)bristol.com) Nature: Uncategorized Issue Severity: Summary: Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue. The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around. For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection. There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference. On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and *effective* BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction? Resolution: Revised Text: Actions taken: May 11, 2004: received issue Discussion: End of Annotations:===== te: Tue, 11 May 2004 10:38:25 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: issues@omg.org CC: firewall-traversal-ftf@omg.org Subject: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY X-Virus-Scanned: Symantec AntiVirus Scan Engine Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue. The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around. For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection. There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference. On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and *effective* BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction? Subject: RE: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY Date: Thu, 13 May 2004 15:35:20 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY Thread-Index: AcQ3ZmljZK2/IZRbRZy9esrT2ecyjwBs+nuA From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4DJaiun014333 I think you've confused the objects and connection sides. See inlined comments. --Rebecca > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Tuesday, May 11, 2004 10:38 AM > To: issues@omg.org > Cc: firewall-traversal-ftf@omg.org > Subject: Firewall FTF Issue: Limitation and ambiguity in the use of > BidirectionalOfferPolicy of DENY > > > Part of this issue has been surfaced in the discussions over the mail > list. I now file it as an issue. > > The Bi-directional GIOP spec says, "An object reference with a > BidirectionalOfferPolicy of DENY must not be invoked over a > bi-directional > connection." Satisfying this policy requirement does not close some > potential limitation and ambiguity when other policies or policy > instances are around. Right. It must not be invoked by the client (connection initiator) side. Note that this is not the client's (connection initiator's) callback object - it's a reference to an object actually on the server (connection acceptor) side. > > For example, at the connection initiator side, we may have two object > references one of which has BidirectionalOfferPolicy of DENY and the > other has BidirectionalOfferPolicy of ALLOW. If these two object > references point to the same server, according to spec, we need two > connections to the server: one is bi-directional and one is not. Fine so far... > However, having a non-bi-directional connection doesn't mean > much. For > invocations on the object reference with the DENY policy, the server > side can always callback using the other bi-directional connection. You're getting your objects mixed up. The server isn't going to callback on the object reference with the DENY offer policy. You are discussing two references on the client initiator side that are used to invoke on server (connection acceptor side)objects. These have offer policies on them but they are not the callback objects. The server (connection acceptor) is not going to invoke on them - it is going to invoke on a different set of object on the connection initiator side. So, the reference with the offer = DENY policy will not be called back to, invoked by the connection acceptor side. > > There is an argument (by Brian Niebuhr) saying that it's not > realistic > to both trust and not trust the same server. However, in > practice, it's > not always possible to tell whether two object references > point to the > same server or not. Furthermore, the client may decide > whether or not to > trust the server of an object reference depending on reasons > other than > the information about the server. For example, the client may > decide to > use BidirectionalOfferPolicy of ALLOW or DENY according to > the source of > an object reference. Fine. > > On the other hand, at the connection acceptor side, things become a > little more interesting. For an object reference with > BidirectionalAcceptPolicy of ALLOW and *effective* > BidirectionalOfferPolicy of DENY (e.g., the default policy on > that ORB), Offer policies don't apply to bidirectional connections on the connection acceptor side. > what shall be the proper behavior of the ORB? According to the > BidirectionalAcceptPolicy, "the ORB may accept and use any > connections > that a client has offered as bi-directional." However, shall > we let the > BidirectionalOfferPolicy of DENY prohibits the use of such a > bi-directional connection? Or shall we allow the use of such a > bi-directional connection because it's in the "reverse" direction? An offer policy doesn't apply to a bidirectional connection on the connection acceptor side. > > > > Date: Fri, 14 May 2004 08:44:33 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: firewall-traversal-ftf@omg.org Subject: Re: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY X-Virus-Scanned: Symantec AntiVirus Scan Engine Comments inline. Bergersen, Rebecca wrote: From: Joncheng Kuo [mailto:ckuo01@syr.edu] However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection. You're getting your objects mixed up. The server isn't going to callback on the object reference with the DENY offer policy. My writing was not clear. What I really means is that, when the client application invokes the object reference with the BidirectionalOfferPolicy=DENY, the server side can always call (back) any object (not object reference) on the ORB of the client application using a bi-directional connection set up by an object reference of the client application that has BidirectionalOfferPolicy=ALLOW. On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and *effective* BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), Offer policies don't apply to bidirectional connections on the connection acceptor side. The BidirectionalOfferPolicy applies to any object reference, including the object references on the connection acceptor side. When the connection acceptor side wants to invoke any object reference, it has to consider about the BidirectionalOfferPolicy on that object reference as well. That's the situation that I'm talking about. Joncheng what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction? An offer policy doesn't apply to a bidirectional connection on the connection acceptor side. Subject: RE: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY Date: Fri, 14 May 2004 15:49:56 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY Thread-Index: AcQ5sTXPQ9vKIdRZSgSgdiVu2AZILgAOLnmg From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Friday, May 14, 2004 8:45 AM To: Bergersen, Rebecca Cc: firewall-traversal-ftf@omg.org Subject: Re: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY Comments inline. Bergersen, Rebecca wrote: From: Joncheng Kuo [mailto:ckuo01@syr.edu] However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection. You're getting your objects mixed up. The server isn't going to callback on the object reference with the DENY offer policy. My writing was not clear. What I really means is that, when the client application invokes the object reference with the BidirectionalOfferPolicy=DENY, the server side can always call (back) any object (not object reference) on the ORB of the client application using a bi-directional connection set up by an object reference of the client application that has BidirectionalOfferPolicy=ALLOW. [Bergersen, Rebecca] That makes sense. On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and *effective* BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), Offer policies don't apply to bidirectional connections on the connection acceptor side. The BidirectionalOfferPolicy applies to any object reference, including the object references on the connection acceptor side. When the connection acceptor side wants to invoke any object reference, it has to consider about the BidirectionalOfferPolicy on that object reference as well. That's the situation that I'm talking about. [Bergersen, Rebecca] No, definitely not. The Offer Policy is only for initiating a bidir connection and is not relevant to and not evaluated for any other operation. In the context of using an established BiDir connection, a connection acceptor does not consider an Offer Policy. Joncheng what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction? An offer policy doesn't apply to a bidirectional connection on the connection acceptor side. Date: Fri, 14 May 2004 18:45:46 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: firewall-traversal-ftf@omg.org Subject: Re: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: The Offer Policy is only for initiating a bidir connection and is not relevant to and not evaluated for any other operation. In the context of using an established BiDir connection, a connection acceptor does not consider an Offer Policy. As an ORB trying to make a GIOP Request due to an invocation on an object reference, how do you know your ORB is at the initiator side or the acceptor side? Joncheng Joncheng what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction? An offer policy doesn't apply to a bidirectional connection on the connection acceptor side. Subject: RE: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY Date: Mon, 17 May 2004 10:54:05 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY Thread-Index: AcQ6BTQLOn1Bw9BmQw+3wVSWMAp8NQCGVx+w From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: When a BiDir offer is made, both the initiating and the accepting ORBs need to keep track of their respective roles. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Friday, May 14, 2004 6:46 PM To: Bergersen, Rebecca Cc: firewall-traversal-ftf@omg.org Subject: Re: Firewall FTF Issue: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY Bergersen, Rebecca wrote: The Offer Policy is only for initiating a bidir connection and is not relevant to and not evaluated for any other operation. In the context of using an established BiDir connection, a connection acceptor does not consider an Offer Policy. As an ORB trying to make a GIOP Request due to an invocation on an object reference, how do you know your ORB is at the initiator side or the acceptor side? Joncheng Joncheng what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction? An offer policy doesn't apply to a bidirectional connection on the connection acceptor side. Subject: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Date: Thu, 3 Jun 2004 16:39:20 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Thread-Index: AcRJqtZbsXtCUOt1Sv2Yqvfj5tZJOQ== From: "Bergersen, Rebecca" To: , Hi! Tom and I had an email exchange discussing the interpretation of the use of Offer, Export and Allow Policies I put forward in resolutions on Ballot 4. After a couple of interchanges, I sent him a diagram and explanations. This seemed to clear up the misunderstanding and as you have seen, he modified his vote. So, I have attached most of our email exchange to this email. As Tom explained in his change of vote, as you have seen, he now agrees with my point of view but thinks the text is still confusing and should include the diagram and explanations that were part of that exchange. Please take a look at the email thread, particularly the diagram and accompanying explanation. Since Tom and I are the only ones who have voted so far, it might be possible to revise the text on the ballot and still complete the vote by EOB Tuesday. I will work with Tom in coming up with revisions. --Rebecca X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C44996.4F7EEABA" Subject: RE: Tom Rutt Vote on Firewall FTF Vote 4 Date: Thu, 3 Jun 2004 14:12:20 -0400 Message-ID: <7ED3E4E1953E8C43BE701691ABB717DA072649@amereast-ems2.boston.amer.iona.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tom Rutt Vote on Firewall FTF Vote 4 Thread-Index: AcRJj1tR7gAIjQ1iQk+aaf1N43qfZgAALnuQ From: "Bergersen, Rebecca" To: "Tom Rutt" Cc: "Bergersen, Rebecca" Comments inline. In particular, look at the bottom of my comments for a diagram that might help. --Becky > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Thursday, June 03, 2004 1:22 PM > To: Bergersen, Rebecca > Subject: Re: Tom Rutt Vote on Firewall FTF Vote 4 > > > I do not mind discussing the vote. > > Bergersen, Rebecca wrote: > > >Hi, Tom! > > > >I don't know if I should be discussing your vote with you, > but I think you are factually wrong on issue 7315 and this > has affected your perception and vote on this and other > issues (you mention 7351 specifically). > > > >You said the proposal, "assumes that > bidirectionalOfferPolicy is a client-side policy for the > connection initiator, when in fact it is a server-side policy for > >the conection initiator." The draft adopted spec says, in > section 15.9 "A BidirectionalOfferPolicy can be applied to a > client ORB, > > > This is the problem, the draft adopted spec uses client orb to mean > connection initiator. And the resolution changes the language to say connection initiator. > > > and it can be overridden for specific object references > received by the client ORB." This is definitely client-side > policy management. > > > This is an error, cited by Syracuse in another issue. The > fact that the > initiator has the POA for this object > instance makes it the server-side as far as policy is > concerned. But the initiator does not have the POA. The acceptor has the POA; the initiator invokes on a reference to that object on the acceptor side. The Offer service context is included in that invocation. Item 3 explicitly states that the OfferPolicy is associated with "specific object references received by the connection initiator ORB". Those object references are to objects on the other side of the connection - the connection acceptor - that's where the POA is. I did > not raise a new issue, but I now > do not understand the difference between export and offer > policy. They > seem to be the same the way > I have characterized it. > The export policy is put on POAs on the connection initiator side. They indicate what servants may used as callback object (i.e. the servants of those POAs having the export policy set to ALLOW. When the POA is created, the ones that have an Export policy of ALLOW have a BiDirId generated for its servants. The offer policy is put (by an override) on object references received from outside the connection initiator. Those references are to POAs (their servants) on the connection acceptor side. If the offer policy is set to ALLOW, an invocation on the object reference that has that effective policy carries an offer service context. The offer service context contains the BiDirIds of the POAs that had an export policy of ALLOW. Since the export policy is set only on POAs, it is a server-side policy. Since the offer policy is set on object references to a POA (its servants) on the other side of the connection, it is a client-side policy. It may also be set on the connection initiator ORB or on a thread in the connection initiator. > >In the resolution the terms "client" and "server" were used > in reference to the text in sections 4.9.1 and 4.9.2, where > those terms are the ones that are used. > > > >You also said, for number two, "It needs to be clarified > that 2. pertains to a server-side policy at the initiator." > The second sentence in #2 of the resolution says, "To > identify such objects, a server-side > BidirectionalExportPolicy is applied to a POA on the > connection initiator side using the > PortableServer::POA::create_POA operation." It *is* directly > stated that a server-side policy on the connection initiator > side is used, Tom. > > > > > I have no major concern about 2, it was just to have clarity and > consistency. the confustion behind 3. was > my main concern, along with the confustion in 1. > > >Finally, for number three, you said, "the offer policy is a > server-side policy > >at the connection initiator orb." As I've pointed out > above, this is absolutely not the intent of the spec. > > > > > Well this means the spec is very confused. I would ask you are the > bidirIDs that the connection initiator > puts in the offer policy pertaining to POAs and object instances that > reside on the connection initiatory orb > or on the connection acceptor orb? I say the orb that has the poa is > the server. As I've said above, the BiDirIds are for POAs sitting in the connection initiator side. These are the objects that are going to be called back from the connection acceptor side. Here's the picture I've been using, where CB is the callback object and OBJ is the object used by the initiator to contact the acceptor. Invocations on OBJ carry Offer service contexts containing BiDirIds of objects that the acceptor can call back. Connection Initiator Connection Acceptor (offer policy) (allow policy) +---------------+ +---------------+ | | | | | CB POA | | CB reference | |(export policy)| Bidir | (allow policy)| |( BiDirId) | connection | | | |<----\ | | | OBJ reference | \----->| OBJ POA | | (offer policy)| | | | | | | +---------------+ +---------------+ > > Please explain your interpretation to me of what the offer policy is > intended to do. The offer policy allows or disallows invocations on the object to which the policy has been applied to carry offer service contexts. If OBJ has had an offer policy override applied to it with a value of ALLOW, the effective policy set when an invocation is made on that object contains an Offer policy of ALLOW. If the value was DENY, then the effective policy set contains an Offer policy of DENY. The policy could be placed on the initiator ORB and the thread as well. However the effective policy overrides resolve themselves, that is the policy applied when an invocation is made on the object. If the effective policy set contains an Offer policy of ALLOW, the invocation will carry an Offer service context that contains the BiDirIds of the CB POAs that haven't already been sent to the Acceptor in previous Offers. If the effective policy set contains an Offer policy of DENY or does not contain an Offer policy, then no Offer service context will be included when the object is invoked. Thus, no BiDirIds will be transmitted in the invocation and there is no implication of bi-directionality involved in the invocation - it's just a standard GIOP Request (or whatever). > > > --Becky > > > > > > > >>-----Original Message----- > >>From: Tom Rutt [mailto:tom@coastin.com] > >>Sent: Wednesday, June 02, 2004 8:35 PM > >>To: firewall-traversal-ftf@omg.org; Bergersen, Rebecca; > >>firewall-ftf@omg.org > >>Subject: Tom Rutt Vote on Firewall FTF Vote 4 > >> > >> > >> > >>Tom Rutt vote on proposals for Firewall FTF Vote 4. > >> > >>I spent several hours going thru these proposed resolutions, and I > >>realized that there are still many problems > >>in the draft adopted specs which will require major work and > >>agreement > >>to resolve. Quite frankly, I do not > >>wish to continue at this level of effort for an activity > which is not > >>that important to my company, and for > >>which I see almost no way to reach fruition in the limited > >>time this FTF > >>has before it runs out. > >> > >>I am concerned with the number of oprn technical issues (most > >>of the 33) > >>which do not yet have proposed resolutions, even when we are within > >>three weeks of the next OMG meeting. > >> > >>Since I spent the effort to work on this vote: I am > >>submitting my vote > >>as follows for Vote 4. > >> > >>I have severe concerns about many of the proposals in vote > 4. I have > >>voted No on many of them, and have given detailed reasons for > >>my NO votes. > >> > >>Issue 6311: Negotiation Session message is unwieldy > >>(firewall-traversal-ftf) > >>YES . no change required > >> > >>Issue 7307: Firewall issue - Number of BiDirIds in a > BiDirOffer Issue > >>NO . The statement is overly constraining on implementations. If a > >>connection initiator knows what > >>Object references it has passed to a given connection > >>respondor, it only > >>is required to send the > >>BIDIR IDs pertaining to that subset of objects it can act as > >>server for. > >> > >>7308: Firewall Issue: Response to failed BiDir challenge is unclear > >>NO: - The current placement of the proposed sentence makes it > >>apply to > >>the entire paragraph above. The discussion > >>seems to indicate the connection termination only applies to the > >>Strong-failed case. Also, it is not clear why the > >>connection responsor must kill the transport connection in > >>all cases (it > >>may want to continue to receive invocations from that > >>connection initiator as client. > >> > >>Issue 7309: Firewall Issue: Connection over which BiDir > >>offers are sent > >>is unspecified > >>NO: This introduces the concept of the bidirectional state > of a given > >>transport connection. This > >>classification is troublesome, as indicated by Issue 7356. > Also, the > >>connection initiator may, in many cases, > >>not need to send all bidir offers to all connection > responders it is > >>currently connected to. > >> > >>Issue 7310: Firewall Issue: Random BiDirIds can't be used for > >>persistent > >>POAs > >>YES > >> > >>Issue 7311: Interplay of Contexts allowed in NegotiateSession > >>messages > >>too ill-defined > >>YES . duplicate of 7314 > >> > >>Issue 7312: What BiDirIds shall be sent over what bidirectional > >>connections? > >>NO: This extra complexity, to an already overwhelming set of three > >>policy constructs (export, offer, accept) is > >>not warranted, if the resolutions for 7307 and 7309 are not > accepted. > >>Also, the proposal seems do define two > >>different values for ALLOW and ALLOW_ALL with no > explanation for the > >>difference between them or the reason > >>to need both values. > >> > >>Issue 7313: Firewall FTF Issue: No end-to-end security for firewall > >>traversal > >>YES > >> > >>Issue 7314: Processing of NegotiateSession messages at > >>various stages of > >>connection set > >>YES: - notice this text never introduces the state > .connection is now > >>bidirectional., because it does not have to. > >> > >> > >>Issue 7315: Targets of Export and Offer Policies incompletely > >>specified > >>NO: While I agree that connection initiator and connection > >>acceptor need > >>to be used in several places where > >>the text .client orb. or .server orb. is used (including in section > >>5.8), this proposal is flawed. It assumes that > >>bidirectionalOfferPolicy > >>is a client-side policy for the connection initiator, when in > >>fact it is > >>a server-side policy for > >>the conection initiator. Also in 1. the words .client (i.e. > >>connection > >>initiator) for some connections and a server (i.e. connection > >>acceptor) > >>for others:. is wrong. The words client and server should not > >>be used in > >>this sentence. It needs to be clarified that 2. > >>pertains to a server-side policy at the initiator. Proposal 3. is > >>incorrect, in that the offer policy is a server-side policy > >>at the connection initiator orb. The existing text in the > >>draft adopted > >>spec is already to be confused, in that it states > >>object references received by the client, but this > >>.clarification. in 3. > >>makes things worse, since it the offer policy is a > server-side policy > >>at the connection initiator orb.is severely flawed. > >>This is related to issue 7351 > >> > >>Issue 7316: Expected behavior of a non-conformant implementation > >>YES > >> > >>Issue 7317: connection_complete field of the > >>FirewallPathRespContext is > >>under specified > >>YES : no change required > >> > >>Issue 7318: How many BI_DIR_GIOP_OFFER service contexts are allowed > >>NO: If the proposal is agreed, then we need to add a > >>clarification that > >>two contexts in a message can be answered by a single > >>Return service context pertaining to both of them. > >> > >>Issue 7332: GIOP and IIOP versioning must be clearly and > consistently > >>specified > >>NO: While I agree with the sentiment, the proposal has only > >>just begun > >>to fix the problem. The procedures for > >>Giop 1.2 bidir have been erroneously removed in the draft > >>adopted GIOP > >>spec. > >>The GIOP spec must continue to retain its existing bidir Section, > >>clarifying that it pertains to versions 1.2 thru 1.4, > >>while the new stuff needs its own section, clarifying that > it is for > >>GIOP 1.5 and beyond. > >> > >>Issue 7351: Limitation and ambiguity in the use of > >>BidirectionalOfferPolicy of DENY > >>NO: This issue has identified a problem with the offer policy text > >>(since it applies to a server-side policy > >>In the connection initiator. So .references received by > >>Client ORB. is > >>an incorrect statement which needs to > >>Be fixed. It was not fixed in the proposed resolution 3 to > issue 7315. > >> > >>Issue 7352: Bi-directional connections considered volatile at > >>connection > >>acceptor side > >>NO: While I agree that the clarification needs to ber made, > >>the current > >>text uses the word .register. > >>an object reference, which is not a defined term in this > >>spec. This will > >>only add confusion, for it is unclear > >>whether an invocation on a persistent connection initiator > >>served object > >>reference which was , say, > >>obtained from a name service by the connection acceptor, acting as > >>client, is really a callback. > >> > >>Issue 7356: when is a connection a "bi-directional connection"? > >>NO . with giop 1.2 bidir the first message on the transport > >>connection > >>contained the service context for bidir, > >>thus each transport connection could be considered either > >>bidir or not > >>bidir. With the new bidir from this spec, > >>this determination can happen at any time over the life of > >>the transport > >>connection. I suggest resolving this by not > >>using the term bidirection connection (as if it were a state) > >>throughout > >>the document. Given policy settings, many > >>connection can become bidirectional capable, and is bidir > >>after a bidir > >>offer is accepted. Can a bidir offer be > >>retracted? Needs further discussion. > >> > >> > >> > >>-- > >>---------------------------------------------------- > >>Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > >>Tel: +1 732 801 5744 Fax: +1 732 774 5133 > >> > >> > >> > >> > >> > >> > > > > > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Received: from amereast-smg1.iona.com ([10.70.2.37]) by amereast-ems2.IONAGLOBAL.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 3 Jun 2004 15:23:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_004_01C449A0.4B4ABA00" Received: from panda.host4u.net (panda.host4u.net [216.71.64.116]) by amereast-smg1.iona.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id i53JNlQ12171 for ; Thu, 3 Jun 2004 15:23:47 -0400 (EDT) Received: from coastin.com (pool-141-153-146-77.mad.east.verizon.net [141.153.146.77]) by panda.host4u.net (8.11.6/8.11.6) with ESMTP id i53JNdD29914 for ; Thu, 3 Jun 2004 14:23:40 -0500 content-class: urn:content-classes:message Subject: Re: Tom Rutt Vote on Firewall FTF Vote 4 Date: Thu, 3 Jun 2004 15:23:21 -0400 Message-ID: <40BF7AA9.3050603@coastin.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tom Rutt Vote on Firewall FTF Vote 4 Thread-Index: AcRJoEuO4xDkSHcjR5Knn8dsio2H6g== From: "Tom Rutt" To: "Bergersen, Rebecca" Becky: Please lets take this discussion to the list soon. Well I never got your interpretation (which makes sense to me given the diagram and explanation) from evaluating and reading the spec over the years. If this is the intent of the spec, the diagram you show and the paragraphs below needs to go into the spec to make this clear. I never dreamt in my foggiest dreams that a policy would have to explicitly be put on every object reference in the connection initiator to every object on the connection acceptor . I actually read the text (given the confusion of "client orb" being used) as being an overide per initiator's object servants to the POA level policy on that initator. This seemed confusing to me, but a viable thing to do. Is it your understanding that in most cases the offer policy will be placed on the initiator orb as allow, and not be overridden for any specific object reference. Other cases might be to disallow for orb level, with allow for a few specific instances. Would it be valid to have an offer policy on the initiator orb as disallow, while having POA policys with export =allow? Bergersen, Rebecca wrote: >Comments inline. In particular, look at the bottom of my comments for a diagram that might help. > --Becky > > > >The export policy is put on POAs on the connection initiator side. They indicate what servants may used as callback object (i.e. the servants of those POAs having the export policy set to ALLOW. When the POA is created, the ones that have an Export policy of ALLOW have a BiDirId generated for its servants. > >The offer policy is put (by an override) on object references received from outside the connection initiator. Those references are to POAs (their servants) on the connection acceptor side. If the offer policy is set to ALLOW, an invocation on the object reference that has that effective policy carries an offer service context. The offer service context contains the BiDirIds of the POAs that had an export policy of ALLOW. > >Since the export policy is set only on POAs, it is a server-side policy. Since the offer policy is set on object references to a POA (its servants) on the other side of the connection, it is a client-side policy. It may also be set on the connection initiator ORB or on a thread in the connection initiator. > > > >As I've said above, the BiDirIds are for POAs sitting in the connection initiator side. These are the objects that are going to be called back from the connection acceptor side. > >Here's the picture I've been using, where CB is the callback object and OBJ is the object used by the initiator to contact the acceptor. Invocations on OBJ carry Offer service contexts containing BiDirIds of objects that the acceptor can call back. > > Connection Initiator Connection Acceptor > (offer policy) (allow policy) > +---------------+ +---------------+ > | | | | > | CB POA | | CB reference | > |(export policy)| Bidir | (allow policy)| > |( BiDirId) | connection | | > | |<----\ | | > | OBJ reference | \----->| OBJ POA | > | (offer policy)| | | > | | | | > +---------------+ +---------------+ > > > > >>Please explain your interpretation to me of what the offer policy is >>intended to do. >> >> > >The offer policy allows or disallows invocations on the object to which the policy has been applied to carry offer service contexts. If OBJ has had an offer policy override applied to it with a value of ALLOW, the effective policy set when an invocation is made on that object contains an Offer policy of ALLOW. If the value was DENY, then the effective policy set contains an Offer policy of DENY. The policy could be placed on the initiator ORB and the thread as well. However the effective policy overrides resolve themselves, that is the policy applied when an invocation is made on the object. > >If the effective policy set contains an Offer policy of ALLOW, the invocation will carry an Offer service context that contains the BiDirIds of the CB POAs that haven't already been sent to the Acceptor in previous Offers. If the effective policy set contains an Offer policy of DENY or does not contain an Offer policy, then no Offer service context will be included when the object is invoked. Thus, no BiDirIds will be transmitted in the invocation and there is no implication of bi-directionality involved in the invocation - it's just a standard GIOP Request (or whatever). > > > >>>--Becky >>> >>> >>> >>>> >>>>Issue 7315: Targets of Export and Offer Policies incompletely >>>>specified >>>>NO: While I agree that connection initiator and connection >>>>acceptor need >>>>to be used in several places where >>>>the text .client orb. or .server orb. is used (including in section >>>>5.8), this proposal is flawed. It assumes that >>>>bidirectionalOfferPolicy >>>>is a client-side policy for the connection initiator, when in >>>>fact it is >>>>a server-side policy for >>>>the conection initiator. Also in 1. the words .client (i.e. >>>>connection >>>>initiator) for some connections and a server (i.e. connection >>>>acceptor) >>>>for others:. is wrong. The words client and server should not >>>>be used in >>>>this sentence. It needs to be clarified that 2. >>>>pertains to a server-side policy at the initiator. Proposal 3. is >>>>incorrect, in that the offer policy is a server-side policy >>>>at the connection initiator orb. The existing text in the >>>>draft adopted >>>>spec is already to be confused, in that it states >>>>object references received by the client, but this >>>>.clarification. in 3. >>>>makes things worse, since it the offer policy is a >>>> >>>> >>server-side policy >> >> >>>>at the connection initiator orb.is severely flawed. >>>>This is related to issue 7351 >>>> >>>> After you answer these new questions, I will reconsider my vote for this one. Tom Rutt ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_005_01C449A6.DB944986" Subject: RE: Tom Rutt Vote on Firewall FTF Vote 4 Date: Thu, 3 Jun 2004 16:10:47 -0400 Message-ID: <7ED3E4E1953E8C43BE701691ABB717DA07264A@amereast-ems2.boston.amer.iona.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tom Rutt Vote on Firewall FTF Vote 4 Thread-Index: AcRJoEuO4xDkSHcjR5Knn8dsio2H6gAAoHOQ From: "Bergersen, Rebecca" To: "Tom Rutt" Cc: "Bergersen, Rebecca" Hi, Tom! To answer a couple of you questions, I believe that there would be two common scenarios for using the Offer Policy: 1. Most of the object references in a component on the initiator could be used to initiate a bidirectional connection or be used to transmit BiDirIds. To accomplish this, an Offer policy with a value of ALLOW would be placed on the connection initiator ORB and those objects that are NOT allowed to be used for the bidirectional protocol would have an individual override placed on them with an Offer policy with a value of DENY. 2. Most, but not all, of the object references in a component on the initiator would NOT be used to initiate a bidirectional connection or be used to transmit BiDirIds. To accomplish this, either an Offer Policy with a value of DENY would be placed on the connection initiator ORB or no Offer policy would be placed on the connection initiator ORB. The effect is the same, though placing an Offer with DENY on the ORB makes the program's intentions more explicit. Those object references that ARE used to convey an Offer service context would have an Offer policy with a value of ALLOW placed on them using an override. In both cases, and I think scenario #2 is probably the most common, there are only a few placements of the Offer policy. I've also answered your other points inline. By the way, it's all right with me to put this thread on the list any time. Since the diagram seemed to clear things up for you, the email containing that should probably be the head of the thread. --Becky > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Thursday, June 03, 2004 3:23 PM > To: Bergersen, Rebecca > Subject: Re: Tom Rutt Vote on Firewall FTF Vote 4 > > > Becky: > > Please lets take this discussion to the list soon. > > Well I never got your interpretation (which makes sense to me > given the > diagram and explanation) > from evaluating and reading the spec over the years. > > If this is the intent of the spec, the diagram you show and the > paragraphs below needs to go into the spec > to make this clear. > > I never dreamt in my foggiest dreams that a policy would have to > explicitly be put on every > object reference in the connection initiator to every object on the > connection acceptor . It wouldn't. Since it's a client-side Policy, it can be placed on the connection initiator ORB and all of the objects would inherit it in their effective policy sets. There's no need to put the policy on every object reference. >I actually read the text (given the > confusion of > "client orb" being used) as being an overide per > initiator's object servants to the POA level policy on that > initator. > This seemed confusing to me, > but a viable thing to do. > > Is it your understanding that in most cases the offer policy will be > placed on the initiator orb as allow, and > not be overridden for any specific object reference. Discussed above. > > Other cases might be to disallow for orb level, with allow for a few > specific instances. Discussed above. > > Would it be valid to have an offer policy on the initiator orb as > disallow, while having POA policys with export =allow? Sure. The Offer policy governs the inclusion of an Offer Service Context on an invocation. The ORB could have a general Offer policy of DENY and a couple of object references to POAs on the the Acceptor side could have that Offer policy overriden with a value of ALLOW. The POAs could have Export policies with a value of ALLOW. Their BiDirIds would only be transmitted when one of the objects with an Offer value of ALLOW is invoked. Invocations on other object references would not carry an Offer Service Context since their effective policy set would have an Offer policy with a value of DENY inherited from the ORB. If no object references override that value, the BiDirIds that were generated for the POAs with an Export policy of ALLOW are simply never transmitted. > > > > Bergersen, Rebecca wrote: > > >Comments inline. In particular, look at the bottom of my > comments for a diagram that might help. > > --Becky > > > > > > > >The export policy is put on POAs on the connection initiator > side. They indicate what servants may used as callback > object (i.e. the servants of those POAs having the export > policy set to ALLOW. When the POA is created, the ones that > have an Export policy of ALLOW have a BiDirId generated for > its servants. > > > >The offer policy is put (by an override) on object > references received from outside the connection initiator. > Those references are to POAs (their servants) on the > connection acceptor side. If the offer policy is set to > ALLOW, an invocation on the object reference that has that > effective policy carries an offer service context. The offer > service context contains the BiDirIds of the POAs that had an > export policy of ALLOW. > > > >Since the export policy is set only on POAs, it is a > server-side policy. Since the offer policy is set on object > references to a POA (its servants) on the other side of the > connection, it is a client-side policy. It may also be set > on the connection initiator ORB or on a thread in the > connection initiator. > > > > > > > >As I've said above, the BiDirIds are for POAs sitting in the > connection initiator side. These are the objects that are > going to be called back from the connection acceptor side. > > > >Here's the picture I've been using, where CB is the callback > object and OBJ is the object used by the initiator to contact > the acceptor. Invocations on OBJ carry Offer service > contexts containing BiDirIds of objects that the acceptor can > call back. > > > > Connection Initiator Connection Acceptor > > (offer policy) (allow policy) > > +---------------+ +---------------+ > > | | | | > > | CB POA | | CB reference | > > |(export policy)| Bidir | (allow policy)| > > |( BiDirId) | connection | | > > | |<----\ | | > > | OBJ reference | \----->| OBJ POA | > > | (offer policy)| | | > > | | | | > > +---------------+ +---------------+ > > > > > > > > > >>Please explain your interpretation to me of what the offer > policy is > >>intended to do. > >> > >> > > > >The offer policy allows or disallows invocations on the > object to which the policy has been applied to carry offer > service contexts. If OBJ has had an offer policy override > applied to it with a value of ALLOW, the effective policy set > when an invocation is made on that object contains an Offer > policy of ALLOW. If the value was DENY, then the effective > policy set contains an Offer policy of DENY. The policy > could be placed on the initiator ORB and the thread as well. > However the effective policy overrides resolve themselves, > that is the policy applied when an invocation is made on the object. > > > >If the effective policy set contains an Offer policy of > ALLOW, the invocation will carry an Offer service context > that contains the BiDirIds of the CB POAs that haven't > already been sent to the Acceptor in previous Offers. If the > effective policy set contains an Offer policy of DENY or does > not contain an Offer policy, then no Offer service context > will be included when the object is invoked. Thus, no > BiDirIds will be transmitted in the invocation and there is > no implication of bi-directionality involved in the > invocation - it's just a standard GIOP Request (or whatever). > > > > > > > >>>--Becky > >>> > >>> > >>> > >>>> > >>>>Issue 7315: Targets of Export and Offer Policies incompletely > >>>>specified > >>>>NO: While I agree that connection initiator and connection > >>>>acceptor need > >>>>to be used in several places where > >>>>the text .client orb. or .server orb. is used (including > in section > >>>>5.8), this proposal is flawed. It assumes that > >>>>bidirectionalOfferPolicy > >>>>is a client-side policy for the connection initiator, when in > >>>>fact it is > >>>>a server-side policy for > >>>>the conection initiator. Also in 1. the words .client (i.e. > >>>>connection > >>>>initiator) for some connections and a server (i.e. connection > >>>>acceptor) > >>>>for others:. is wrong. The words client and server should not > >>>>be used in > >>>>this sentence. It needs to be clarified that 2. > >>>>pertains to a server-side policy at the initiator. Proposal 3. is > >>>>incorrect, in that the offer policy is a server-side policy > >>>>at the connection initiator orb. The existing text in the > >>>>draft adopted > >>>>spec is already to be confused, in that it states > >>>>object references received by the client, but this > >>>>.clarification. in 3. > >>>>makes things worse, since it the offer policy is a > >>>> > >>>> > >>server-side policy > >> > >> > >>>>at the connection initiator orb.is severely flawed. > >>>>This is related to issue 7351 > >>>> > >>>> > After you answer these new questions, I will reconsider my > vote for this one. > > Tom Rutt > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_006_01C449A7.CDF25696" Subject: RE: Tom Rutt Vote on Firewall FTF Vote 4 Date: Thu, 3 Jun 2004 16:17:33 -0400 Message-ID: <7ED3E4E1953E8C43BE701691ABB717DA0728AC@amereast-ems2.boston.amer.iona.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tom Rutt Vote on Firewall FTF Vote 4 Thread-Index: AcRJoEuO4xDkSHcjR5Knn8dsio2H6gAAoHOQAAET5YA= From: "Bergersen, Rebecca" To: "Bergersen, Rebecca" , "Tom Rutt" Whoops - I noticed an ambiguity in my explanation: > > Would it be valid to have an offer policy on the initiator orb as > > disallow, while having POA policys with export =allow? > > Sure. The Offer policy governs the inclusion of an Offer > Service Context on an invocation. The ORB could have a > general Offer policy of DENY and a couple of object > references to POAs on the the Acceptor side could have that > Offer policy overriden with a value of ALLOW. The POAs could > have Export policies with a value of ALLOW. I meant "The POAs" ON THE CONNECTION INITIATOR SIDE "could have Export policies with a value of ALLOW." I wasn't referring to the POAs in the previous sentence that live on the connection acceptor side. Sorry. I'm trying to type too fast. --Becky > -----Original Message----- > From: Bergersen, Rebecca > Sent: Thursday, June 03, 2004 4:11 PM > To: 'Tom Rutt' > Cc: Bergersen, Rebecca > Subject: RE: Tom Rutt Vote on Firewall FTF Vote 4 > > > Hi, Tom! > > To answer a couple of you questions, I believe that there > would be two common scenarios for using the Offer Policy: > > 1. Most of the object references in a component on the > initiator could be used to initiate a bidirectional > connection or be used to transmit BiDirIds. To accomplish > this, an Offer policy with a value of ALLOW would be placed > on the connection initiator ORB and those objects that are > NOT allowed to be used for the bidirectional protocol would > have an individual override placed on them with an Offer > policy with a value of DENY. > > 2. Most, but not all, of the object references in a component > on the initiator would NOT be used to initiate a > bidirectional connection or be used to transmit BiDirIds. To > accomplish this, either an Offer Policy with a value of DENY > would be placed on the connection initiator ORB or no Offer > policy would be placed on the connection initiator ORB. The > effect is the same, though placing an Offer with DENY on the > ORB makes the program's intentions more explicit. Those > object references that ARE used to convey an Offer service > context would have an Offer policy with a value of ALLOW > placed on them using an override. > > In both cases, and I think scenario #2 is probably the most > common, there are only a few placements of the Offer policy. > > I've also answered your other points inline. > > By the way, it's all right with me to put this thread on the > list any time. Since the diagram seemed to clear things up > for you, the email containing that should probably be the > head of the thread. > > --Becky > > > -----Original Message----- > > From: Tom Rutt [mailto:tom@coastin.com] > > Sent: Thursday, June 03, 2004 3:23 PM > > To: Bergersen, Rebecca > > Subject: Re: Tom Rutt Vote on Firewall FTF Vote 4 > > > > > > Becky: > > > > Please lets take this discussion to the list soon. > > > > Well I never got your interpretation (which makes sense to me > > given the > > diagram and explanation) > > from evaluating and reading the spec over the years. > > > > If this is the intent of the spec, the diagram you show and the > > paragraphs below needs to go into the spec > > to make this clear. > > > > I never dreamt in my foggiest dreams that a policy would have to > > explicitly be put on every > > object reference in the connection initiator to every object on the > > connection acceptor . > > It wouldn't. Since it's a client-side Policy, it can be > placed on the connection initiator ORB and all of the objects > would inherit it in their effective policy sets. There's no > need to put the policy on every object reference. > > >I actually read the text (given the > > confusion of > > "client orb" being used) as being an overide per > > initiator's object servants to the POA level policy on that > > initator. > > This seemed confusing to me, > > but a viable thing to do. > > > > Is it your understanding that in most cases the offer > policy will be > > placed on the initiator orb as allow, and > > not be overridden for any specific object reference. > > Discussed above. > > > > > Other cases might be to disallow for orb level, with allow > for a few > > specific instances. > > Discussed above. > > > > > Would it be valid to have an offer policy on the initiator orb as > > disallow, while having POA policys with export =allow? > > Sure. The Offer policy governs the inclusion of an Offer > Service Context on an invocation. The ORB could have a > general Offer policy of DENY and a couple of object > references to POAs on the the Acceptor side could have that > Offer policy overriden with a value of ALLOW. The POAs could > have Export policies with a value of ALLOW. Their BiDirIds > would only be transmitted when one of the objects with an > Offer value of ALLOW is invoked. Invocations on other object > references would not carry an Offer Service Context since > their effective policy set would have an Offer policy with a > value of DENY inherited from the ORB. If no object > references override that value, the BiDirIds that were > generated for the POAs with an Export policy of ALLOW are > simply never transmitted. > > > > > > > > > Bergersen, Rebecca wrote: > > > > >Comments inline. In particular, look at the bottom of my > > comments for a diagram that might help. > > > --Becky > > > > > > > > > > > >The export policy is put on POAs on the connection initiator > > side. They indicate what servants may used as callback > > object (i.e. the servants of those POAs having the export > > policy set to ALLOW. When the POA is created, the ones that > > have an Export policy of ALLOW have a BiDirId generated for > > its servants. > > > > > >The offer policy is put (by an override) on object > > references received from outside the connection initiator. > > Those references are to POAs (their servants) on the > > connection acceptor side. If the offer policy is set to > > ALLOW, an invocation on the object reference that has that > > effective policy carries an offer service context. The offer > > service context contains the BiDirIds of the POAs that had an > > export policy of ALLOW. > > > > > >Since the export policy is set only on POAs, it is a > > server-side policy. Since the offer policy is set on object > > references to a POA (its servants) on the other side of the > > connection, it is a client-side policy. It may also be set > > on the connection initiator ORB or on a thread in the > > connection initiator. > > > > > > > > > > > >As I've said above, the BiDirIds are for POAs sitting in the > > connection initiator side. These are the objects that are > > going to be called back from the connection acceptor side. > > > > > >Here's the picture I've been using, where CB is the callback > > object and OBJ is the object used by the initiator to contact > > the acceptor. Invocations on OBJ carry Offer service > > contexts containing BiDirIds of objects that the acceptor can > > call back. > > > > > > Connection Initiator Connection Acceptor > > > (offer policy) (allow policy) > > > +---------------+ +---------------+ > > > | | | | > > > | CB POA | | CB reference | > > > |(export policy)| Bidir | (allow policy)| > > > |( BiDirId) | connection | | > > > | |<----\ | | > > > | OBJ reference | \----->| OBJ POA | > > > | (offer policy)| | | > > > | | | | > > > +---------------+ +---------------+ > > > > > > > > > > > > > > >>Please explain your interpretation to me of what the offer > > policy is > > >>intended to do. > > >> > > >> > > > > > >The offer policy allows or disallows invocations on the > > object to which the policy has been applied to carry offer > > service contexts. If OBJ has had an offer policy override > > applied to it with a value of ALLOW, the effective policy set > > when an invocation is made on that object contains an Offer > > policy of ALLOW. If the value was DENY, then the effective > > policy set contains an Offer policy of DENY. The policy > > could be placed on the initiator ORB and the thread as well. > > However the effective policy overrides resolve themselves, > > that is the policy applied when an invocation is made on > the object. > > > > > >If the effective policy set contains an Offer policy of > > ALLOW, the invocation will carry an Offer service context > > that contains the BiDirIds of the CB POAs that haven't > > already been sent to the Acceptor in previous Offers. If the > > effective policy set contains an Offer policy of DENY or does > > not contain an Offer policy, then no Offer service context > > will be included when the object is invoked. Thus, no > > BiDirIds will be transmitted in the invocation and there is > > no implication of bi-directionality involved in the > > invocation - it's just a standard GIOP Request (or whatever). > > > > > > > > > > > >>>--Becky > > >>> > > >>> > > >>> > > >>>> > > >>>>Issue 7315: Targets of Export and Offer Policies incompletely > > >>>>specified > > >>>>NO: While I agree that connection initiator and connection > > >>>>acceptor need > > >>>>to be used in several places where > > >>>>the text .client orb. or .server orb. is used (including > > in section > > >>>>5.8), this proposal is flawed. It assumes that > > >>>>bidirectionalOfferPolicy > > >>>>is a client-side policy for the connection initiator, when in > > >>>>fact it is > > >>>>a server-side policy for > > >>>>the conection initiator. Also in 1. the words .client (i.e. > > >>>>connection > > >>>>initiator) for some connections and a server (i.e. connection > > >>>>acceptor) > > >>>>for others:. is wrong. The words client and server should not > > >>>>be used in > > >>>>this sentence. It needs to be clarified that 2. > > >>>>pertains to a server-side policy at the initiator. > Proposal 3. is > > >>>>incorrect, in that the offer policy is a server-side policy > > >>>>at the connection initiator orb. The existing text in the > > >>>>draft adopted > > >>>>spec is already to be confused, in that it states > > >>>>object references received by the client, but this > > >>>>.clarification. in 3. > > >>>>makes things worse, since it the offer policy is a > > >>>> > > >>>> > > >>server-side policy > > >> > > >> > > >>>>at the connection initiator orb.is severely flawed. > > >>>>This is related to issue 7351 > > >>>> > > >>>> > > After you answer these new questions, I will reconsider my > > vote for this one. > > > > Tom Rutt > > ---------------------------------------------------- > > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > > > > > > Date: Thu, 03 Jun 2004 19:03:43 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 I think that there are minor problems with proposal 1 from 7314, once it was explained by Becky. I think that the major concern is in Issue 7351 which needs discussion. I never quite realized (because I got the object side wrong for the policy) that one could have a different offer policy for two object references served by the same server host/port. The issue in 7351 is important: It is also related to "what is bidir connection" issue. In early bidir, the bidir context had to be sent on the first message on a transport connection. Thus is was simple, a bidir connection is one which had it negotiated at setup time. With this new protocol, bidir offers can be sent at any time after connection setup. A connection can be set up for one hour, then all of a suddent the connection initiator can send a bidir Offer which, if accepted, makes it a bidir connection. However there might already be objects which have offer policy = deny which have been invoked on that connection. By the wording in the spec: " A BidirectionalOfferPolicy of ALLOW indicates that the Connection Initiator may send a BI_DIR_GIOP_OFFER service context containing the BiDirID.s of the objects in POAs with a BidirectionalExportPolicy of ALLOW. An object reference with a effective BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional connection. If the ORB BidirectionalOfferPolicy is DENY, and the policy has not been overridden for a specific object or thread, then no bi-directional connections can be negotiated by the connection initiator ORB. " for the global level offer policy at orb level Allow means the initiator CAN send bidir Offers, and deny means it cannot. All of a sudden for the object reference level the emphasis changes to DEFY meaning that a bidir connection (what is that?) cannot be used to invoke on that reference. For consistency and simplicity, in all cases DENY should mean you do not send bidir offers in service contexts sent with a request to that object. Tom Rutt ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Thu, 03 Jun 2004 19:21:31 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Tom Rutt CC: "Bergersen, Rebecca" , firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion I commend Becky for trying to resolve some of the more fundamental issues, however I have come to realize that I do not have the committment of time to work in the short time frame we have before this FTF times out, to do the spec justice. There are major problems with the spec which need fixes to be agreed on. The original bidir giop was simple, and its main flaw was it allowed the initiator to spoof object reference that it did not actually create. Well the draft adopted spec bidir giop is a huge complicated mess, which is not clear meets the goal of disallowing spoofing in all cases. We now have the ability for any giop connection to "turn into" a bidir connection anytime during its life. This would seem to be a nightmare to implement, even if we did work out the bugs. So I am declaring that I do not have time to work on fixing this spec within the next three weeks. I say we stop beating a dying horse, and let it rest in peace. Tom Rutt Tom Rutt wrote: I think that there are minor problems with proposal 1 from 7314, once it was explained by Becky. I think that the major concern is in Issue 7351 which needs discussion. I never quite realized (because I got the object side wrong for the policy) that one could have a different offer policy for two object references served by the same server host/port. The issue in 7351 is important: It is also related to "what is bidir connection" issue. In early bidir, the bidir context had to be sent on the first message on a transport connection. Thus is was simple, a bidir connection is one which had it negotiated at setup time. With this new protocol, bidir offers can be sent at any time after connection setup. A connection can be set up for one hour, then all of a suddent the connection initiator can send a bidir Offer which, if accepted, makes it a bidir connection. However there might already be objects which have offer policy = deny which have been invoked on that connection. By the wording in the spec: " A BidirectionalOfferPolicy of ALLOW indicates that the Connection Initiator may send a BI_DIR_GIOP_OFFER service context containing the BiDirID.s of the objects in POAs with a BidirectionalExportPolicy of ALLOW. An object reference with a effective BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional connection. If the ORB BidirectionalOfferPolicy is DENY, and the policy has not been overridden for a specific object or thread, then no bi-directional connections can be negotiated by the connection initiator ORB. " for the global level offer policy at orb level Allow means the initiator CAN send bidir Offers, and deny means it cannot. All of a sudden for the object reference level the emphasis changes to DEFY meaning that a bidir connection (what is that?) cannot be used to invoke on that reference. For consistency and simplicity, in all cases DENY should mean you do not send bidir offers in service contexts sent with a request to that object. Tom Rutt ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Thu, 3 Jun 2004 19:22:10 -0400 (EDT) From: Polar Humenn To: Tom Rutt Cc: "Bergersen, Rebecca" , firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 On Thu, 3 Jun 2004, Tom Rutt wrote: > [snip] > for the global level offer policy at orb level Allow means the initiator > CAN send bidir Offers, and deny > means it cannot. All of a sudden for the object reference level the > emphasis changes to DEFY meaning that ^^^^ I'm sure that was a slip of the fingers, but it rings somewhat true, doesn't it. :) > a bidir connection (what is that?) cannot be used to invoke on that > reference. > > For consistency and simplicity, in all cases DENY should mean you do not > send bidir offers in service contexts sent with a request to that object. What of offers sent on NegotiationSession messages, behind that object references back? Does having DENY on an object reference only mean that it offers cannot be sent in GIOP Requests to that particular object? What "real" purpose (assuming "DENY" is originally for reasons of security) does that serve, if the offers can be sent in other requests, or in NegotiationSession messages? -Polar > Tom Rutt > > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Date: Thu, 3 Jun 2004 19:40:29 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Thread-Index: AcRJwamlctrdMJ3+QE6MLD9xdvgQzAAAHzCg From: "Bergersen, Rebecca" To: "Polar Humenn" , "Tom Rutt" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i53Npdun005578 See the bottom of Polar's query... --Becky > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, June 03, 2004 7:22 PM > To: Tom Rutt > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy > discussion with Tom > Rutt - Re: Ballot 4 > > > On Thu, 3 Jun 2004, Tom Rutt wrote: > > > [snip] > > > for the global level offer policy at orb level Allow means > the initiator > > CAN send bidir Offers, and deny > > means it cannot. All of a sudden for the object reference level the > > emphasis changes to DEFY meaning that > ^^^^ > > I'm sure that was a slip of the fingers, but it rings somewhat true, > doesn't it. :) > > > a bidir connection (what is that?) cannot be used to invoke on that > > reference. > > > > For consistency and simplicity, in all cases DENY should > mean you do not > > send bidir offers in service contexts sent with a request > to that object. > > What of offers sent on NegotiationSession messages, behind that object > references back? Does having DENY on an object reference only > mean that it > offers cannot be sent in GIOP Requests to that particular object? What > "real" purpose (assuming "DENY" is originally for reasons of security) > does that serve, if the offers can be sent in other requests, or in > NegotiationSession messages? > > -Polar I'm just guessing, but I think the scenario the folks who wrote this had in mind was having a BidirectionalOfferPolicy of DENY placed on the connection initiator ORB and then overriding it with a value of ALLOW on selected object references. Thus, most invocations on objects would not contain an Offer Service Context. What I think they were trying to do was filter what invocations contain Offers, not what offers are made. This would have an effect of the creation of new bidirectional connections but it would have no effect on existing ones. So, new BiDirIds could be transmitted over existing BiDir connections using a NegotiateSession message without any invocation being made. However, the bidirectionality of connections would be initiated only through an invocation. At least, that's what I *think* they were thinking. --Becky > > > > > > Tom Rutt > > > > ---------------------------------------------------- > > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Date: Thu, 3 Jun 2004 19:49:11 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Thread-Index: AcRJvw+jXwo16AGDRJePcR29wn6J7QAAnaNQAADO+BA= From: "Bergersen, Rebecca" To: "Bergersen, Rebecca" , "Tom Rutt" Cc: Hi! I've attached a draft of Ballot 5 which discusses and rephrases the resolutions for issues 7315 and 7351. Would you take a look at it provide your opinion, please? If it is more acceptable than what is in Ballot 4, then we'll remove the two issues from ballot 4 and issue the ballot 5. Note - it isn't issued yet - it's only open for discussion. --Becky > -----Original Message----- > From: Bergersen, Rebecca > Sent: Thursday, June 03, 2004 7:23 PM > To: Tom Rutt > Cc: firewall-traversal-ftf@omg.org > Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy > discussion with Tom > Rutt - Re: Ballot 4 > > > I think you meant minor problems with proposal 1 from 7315, > didn't you Tom? Not 7314. > > --Becky > > > -----Original Message----- > > From: Tom Rutt [mailto:tom@coastin.com] > > Sent: Thursday, June 03, 2004 7:04 PM > > To: Bergersen, Rebecca > > Cc: firewall-traversal-ftf@omg.org > > Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy > > discussion with Tom > > Rutt - Re: Ballot 4 > > > > > > I think that there are minor problems with proposal 1 from > > 7314, once it > > was explained by Becky. > > > > I think that the major concern is in Issue 7351 which needs > > discussion. > > > > I never quite realized (because I got the object side wrong for the > > policy) that one could have a different > > offer policy for two object references served by the same > > server host/port. > > > > > > The issue in 7351 is important: > > > > It is also related to "what is bidir connection" issue. > > > > In early bidir, the bidir context had to be sent on the first > > message on > > a transport connection. Thus is was simple, > > a bidir connection is one which had it negotiated at setup time. > > > > With this new protocol, bidir offers can be sent at any time after > > connection setup. > > > > A connection can be set up for one hour, then all of a suddent the > > connection initiator can send > > a bidir Offer which, if accepted, makes it a bidir > > connection. However > > there might already be > > objects which have offer policy = deny which have been > > invoked on that > > connection. By the wording > > in the spec: > > > > " > > A BidirectionalOfferPolicy of ALLOW indicates that the Connection > > Initiator may send a BI_DIR_GIOP_OFFER service context > containing the > > BiDirID.s of the objects in POAs with a > BidirectionalExportPolicy of > > ALLOW. An object reference with a effective > > BidirectionalOfferPolicy of > > DENY must not be invoked over a bi-directional connection. > If the ORB > > BidirectionalOfferPolicy is DENY, and the policy has not been > > overridden > > for a specific object or thread, then no bi-directional > > connections can > > be negotiated by the connection initiator ORB. > > " > > > > for the global level offer policy at orb level Allow means > > the initiator > > CAN send bidir Offers, and deny > > means it cannot. All of a sudden for the object reference > level the > > emphasis changes to DEFY meaning that > > a bidir connection (what is that?) cannot be used to invoke on that > > reference. > > > > For consistency and simplicity, in all cases DENY should mean > > you do not > > send bidir offers in service contexts sent with a request to > > that object. > > > > Tom Rutt > > > > ---------------------------------------------------- > > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > > > > > > ballot_5.htm Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy discussion Date: Thu, 3 Jun 2004 20:14:44 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FIREWALL FTF - OFFER and EXPORT Policy discussion Thread-Index: AcRJwZIcsCGatE7BSc6AjyWa4hpOuQABHkWw From: "Bergersen, Rebecca" To: "Tom Rutt" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i540PFun005773 You know I'm going to try to talk you out of this, Tom! :-) Bear with me, I'll keep it short. 1. The final report and all convenience specs must be sent to Andrew by June 11th. That's only one week from now. Actually, the time limit is shorter than that since I need time to draft the report and edit the specs. Next Tuesday is still the deadline, three business days from now, not three weeks. I think we can talk through the confusion fairly quickly, like you and I did this afternoon. We may come up against a show-stopper, but I think we should continue to try over the next very few days. It's only until Tuesday. 2. To address the point you raise, the fact that a connection was used for unidirectional Requests, etc. and then later changes to bi-directional is safe and trivial for the ORB to manage. If there were objects with Offer=DENY invoked over that connection before, they didn't carry any Offer service contexts. That means their invocations did not initiate the establishment of a bidirectional connection and they did not carry any BiDirIds. Their invocation had no effect on bidirectionality. If the connection later becomes bidirectional and they are invoked over it again, there would still be no effect - they would still not carry an offer service context or BiDirIds. It would be a simple invocation, a Request or whatever. These are objects that have been designated as not participating in the bidirectional protocol, though the connection is still available for them to use since they have no effect on it. That's it. Told you it would be short. :-) --Becky > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Thursday, June 03, 2004 7:22 PM > To: Tom Rutt > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion > > > I commend Becky for trying to resolve some of the more fundamental > issues, however I have come > to realize that I do not have the committment of time to work in the > short time frame we have before > this FTF times out, to do the spec justice. > > There are major problems with the spec which need fixes to be > agreed on. > > The original bidir giop was simple, and its main flaw was it > allowed the > initiator to spoof object reference > that it did not actually create. > > Well the draft adopted spec bidir giop is a huge complicated > mess, which > is not clear meets the goal of > disallowing spoofing in all cases. We now have the ability > for any giop > connection to "turn into" a bidir > connection anytime during its life. This would seem to be a > nightmare > to implement, even if we did > work out the bugs. > > So I am declaring that I do not have time to work on fixing this spec > within the next three weeks. > > I say we stop beating a dying horse, and let it rest in peace. > > Tom Rutt > > > Tom Rutt wrote: > > > I think that there are minor problems with proposal 1 from > 7314, once > > it was explained by Becky. > > > > I think that the major concern is in Issue 7351 which needs > discussion. > > > > I never quite realized (because I got the object side wrong for the > > policy) that one could have a different > > offer policy for two object references served by the same server > > host/port. > > > > > > The issue in 7351 is important: > > > > It is also related to "what is bidir connection" issue. > > > > In early bidir, the bidir context had to be sent on the > first message > > on a transport connection. Thus is was simple, > > a bidir connection is one which had it negotiated at setup time. > > > > With this new protocol, bidir offers can be sent at any time after > > connection setup. > > > > A connection can be set up for one hour, then all of a suddent the > > connection initiator can send > > a bidir Offer which, if accepted, makes it a bidir connection. > > However there might already be > > objects which have offer policy = deny which have been > invoked on that > > connection. By the wording > > in the spec: > > > > " > > A BidirectionalOfferPolicy of ALLOW indicates that the Connection > > Initiator may send a BI_DIR_GIOP_OFFER service context > containing the > > BiDirID.s of the objects in POAs with a > BidirectionalExportPolicy of > > ALLOW. An object reference with a effective > BidirectionalOfferPolicy > > of DENY must not be invoked over a bi-directional > connection. If the > > ORB BidirectionalOfferPolicy is DENY, and the policy has not been > > overridden for a specific object or thread, then no bi-directional > > connections can be negotiated by the connection initiator ORB. > > " > > > > for the global level offer policy at orb level Allow means the > > initiator CAN send bidir Offers, and deny > > means it cannot. All of a sudden for the object reference > level the > > emphasis changes to DEFY meaning that > > a bidir connection (what is that?) cannot be used to invoke on that > > reference. > > > > For consistency and simplicity, in all cases DENY should > mean you do > > not send bidir offers in service contexts sent with a > request to that > > object. > > > > Tom Rutt > > > > ---------------------------------------------------- > > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > Date: Thu, 03 Jun 2004 20:57:47 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 This is much better, however the figure did not make it in the HTML, please resend with a pdf for the figure to show. However, I noticed you already changed this to resolve the issue 7351 by changing the behaviour for the object overide on offer policy. I think, based on polar's latest email, we need further discussion on that change. We may need more changes. Tom Rutt Bergersen, Rebecca wrote: Hi! I've attached a draft of Ballot 5 which discusses and rephrases the resolutions for issues 7315 and 7351. Would you take a look at it provide your opinion, please? If it is more acceptable than what is in Ballot 4, then we'll remove the two issues from ballot 4 and issue the ballot 5. Note - it isn't issued yet - it's only open for discussion. --Becky -----Original Message----- From: Bergersen, Rebecca Sent: Thursday, June 03, 2004 7:23 PM To: Tom Rutt Cc: firewall-traversal-ftf@omg.org Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 I think you meant minor problems with proposal 1 from 7315, didn't you Tom? Not 7314. --Becky -----Original Message----- From: Tom Rutt [mailto:tom@coastin.com] Sent: Thursday, June 03, 2004 7:04 PM To: Bergersen, Rebecca Cc: firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 I think that there are minor problems with proposal 1 from 7314, once it was explained by Becky. I think that the major concern is in Issue 7351 which needs discussion. I never quite realized (because I got the object side wrong for the policy) that one could have a different offer policy for two object references served by the same server host/port. The issue in 7351 is important: It is also related to "what is bidir connection" issue. In early bidir, the bidir context had to be sent on the first message on a transport connection. Thus is was simple, a bidir connection is one which had it negotiated at setup time. With this new protocol, bidir offers can be sent at any time after connection setup. A connection can be set up for one hour, then all of a suddent the connection initiator can send a bidir Offer which, if accepted, makes it a bidir connection. However there might already be objects which have offer policy = deny which have been invoked on that connection. By the wording in the spec: " A BidirectionalOfferPolicy of ALLOW indicates that the Connection Initiator may send a BI_DIR_GIOP_OFFER service context containing the BiDirID.s of the objects in POAs with a BidirectionalExportPolicy of ALLOW. An object reference with a effective BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional connection. If the ORB BidirectionalOfferPolicy is DENY, and the policy has not been overridden for a specific object or thread, then no bi-directional connections can be negotiated by the connection initiator ORB. " for the global level offer policy at orb level Allow means the initiator CAN send bidir Offers, and deny means it cannot. All of a sudden for the object reference level the emphasis changes to DEFY meaning that a bidir connection (what is that?) cannot be used to invoke on that reference. For consistency and simplicity, in all cases DENY should mean you do not send bidir offers in service contexts sent with a request to that object. Tom Rutt ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 ------------------------------------------------------------------------ Issue 7315: Targets of Export and Offer Policies incompletely specified (firewall-traversal-ftf) /Click here for this issue's archive./ *Source:* IONA (Ms. Rebecca Bergersen, rebecca.bergersen@iona.com rebbecab@iona.com ) *Nature:* Uncategorized Issue *Severity:* *Summary:* PROBLEM: The target (ORB, POA, object, thread) of the Export and Offer policies and the side of the connection involved is incompletely specified. RECOMMENDATION: Define the two sides of a connection as the connection 'Initiator' and connection 'Acceptor'. The usual terms of 'client' (Initiator) and 'server' (Acceptor) become confusing in a bi-directional situation. Given those terms for each side, specify that the Export and Offer policies are used on the Initiator side. Specify that the Export policy may be applied to the ORB, the POA and/or to the thread. Specify that the Offer policy can be applied to the Initiator ORB, to a reference in the Initiator for an object in the Acceptor, or to a thread in the Initiator ORB. *Resolution:* The terms Connection Initiator and Connection Acceptor shall be explained in the spec and used in place of .client. and .server. in appropriate contexts. Identify the BidirectionalExportPolicy as a server-side policy that is applied to POAs on the Connection Initiator side of a connection. Identify the BidirectionalOfferPolicy as a client-side policy applied on the connection initiator side of a connection. Identify the BidirectionalAcceptPolicy as a client-side policy applied on the connection acceptor side of a connection. *Revised Text:* 1. Section 15.9, Bi-directional GIOP policy: Insert a new paragraph immediately before the existing paragraph two (not counting IDL): The management of bi-directional GIOP policies is completely compliant with the policy management defined in sections 4.9.1 (Client Side Policy Management) and 4.9.2 (Server Side Policy Management). It is stated in those sections that, on the client side, policies may be applied at ORB, thread and Object level; on the server side, policy management is handled by associating Policy objects with a POA. This spec follows those dicta. However, when connections may be used bi-directionally, as indicated in the diagram above, the connection initiator is the client for objects on POAs in the connection accepter, and is the server for objects on its own POAs. Likewise, the connection acceptor is the server for its own objects, and the client for objects on the POAs of the connection initiator. To allay this confusion, the terms .Connection Initiator. and .Connection Acceptor. will be used rather than .client. and .server.. 2. Section 15.9, existing paragraph two (not counting IDL): Replace the first three sentences with: An ORB on the connection initiator side of a bi-directional connection may contain objects that it wishes to have called-back over the connection. To identify such objects, a server-side BidirectionalExportPolicy is applied to a POA on the connection initiator side (CB POA in the diagram above) using the PortableServer::POA::create_POA operation. If the BidirectionalExportPolicy value of the POA is ALLOW, then the objects managed by that POA are allowed to be called back via a bi-directional connection. Therefore, when opening a bi-directional connection, the Connection Initiator ORB is allowed to send to the Connection Acceptor, in the BI_DIR_GIOP IOP::ServiceContext, the BiDirId associated with the objects in that POA. 3. Section 15.9: replace existing paragraph three (not counting IDL) with the following: A client-side BidirectionalOfferPolicy can be applied to a Connection Initiator ORB, to a thread in that ORB, and to specific object references received by the connection initiator ORB (InvObj in the diagram above), thereby overriding any system defaults or values set at the ORB or thread levels. A BidirectionalOfferPolicy of ALLOW indicates that the Connection Initiator may send a BI_DIR_GIOP_OFFER service context containing the BiDirID.s of the objects in POAs with a BidirectionalExportPolicy of ALLOW. An object reference with a effective BidirectionalOfferPolicy of DENY shall not send a BI_DIR_GIOP_OFFER service context when it is invoked. If the ORB BidirectionalOfferPolicy is DENY, and the policy has not been overridden for a specific object or thread, then no bi-directional connections can be negotiated by the connection initiator ORB. 4. Section 15.9: replace existing paragraph four (not counting IDL) with the following: A client-side BidirectionalAcceptPolicy can be applied to a connection acceptor ORB, to a thread in that ORB, and to specific object references received by the Connection Acceptor (CB Reference in the diagram above), overriding any system defaults or values set at the ORB or thread levels. A BidirectionalAcceptPolicy of ALLOW indicates that the Connection Acceptor ORB may accept and use any connections that a Connection Initiator has offered as bi-directional. This policy can be overridden for specific objects (e.g., CB Reference) in which case those objects shall not be invoked over a bi-directional connection. A BidirectionalAcceptPolicy of DENY placed on the Connection Acceptor ORB indicates that the Connection Acceptor ORB must not accept any offers of bi-directional connections, but may invoke on objects which have this policy overridden by a BidirectionalAcceptPolicy with a value of ACCEPT. *Actions taken:* May 6, 2004: received issue Issue 7351: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY (firewall-traversal-ftf) /Click here for this issue's archive./ *Source:* Syracuse University (Mr. C. Joncheng Kuo, ckuo01@syr.edu ) *Nature:* Uncategorized Issue *Severity:* *Summary:* Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue. The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around. For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection. There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference. On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and *effective* BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction? *Discussion:* The text of the issue confuses the objects and connection sides. The third paragraph of Section 15.9, Bi-directional GIOP Policy, unequivocally states: .A BidirectionalOfferPolicy can be applied to a /client/ ORB, and it can be overridden for specific object references received by the /client/ ORB.. [Italics added for clarification.] The .*effective* BidirectionalOfferPolicy. of an object is not relevant to the connection acceptor side of a bi-directional connection. It is used and evaluated only on the connection initiator side to determine if an object may be used to offer a set of BiDirIds to the connection acceptor side. It is not used or evaluated for any other purpose. However, on the Connection Initiator side, the spec switches from talking about placing a BI_DIR_GIOP_OFFER service context on an invocation if the effective BidirectionalOfferPolicy for the reference being invoked is ALLOW (i.e. offering a set of BiDirIds) to saying that if the value is DENY, the object may not be invoked over a bi-directional connection. The focus shifts from object and invocation to connection. The BidirectionalOfferPolicy is intended to control the sending of BI_DIR_GIOP_OFFER service contexts. Invoking on an object with an effective Offer policy of DENY is not disallowed. It.s merely an invocation (a Request) that doesn.t carry an Offer service context. Whether that is sent over a bi-directional connection or a unidirectional connection is irrelevant. It would have the same effect (possibly a no-op) in either case. The spec should be modified to say that an invocation on an object reference in the Connection Initiator with an effective BidirectionalOfferPolicy of DENY shall not carry a BI_DIR_GIOP_OFFER service context. This change is reflected in step three of the text changes in the resolution for issue 7315, above. In particular the sentence .An object reference with a effective BidirectionalOfferPolicy of DENY shall not send a BI_DIR_GIOP_OFFER service context when it is invoked. replaces the earlier text that discussed connections. This issue should be closed as a duplicate since its resolution is handled in issue 7315. *Resolution:* Closed as duplicate of 7315. *Revised Text:* *Actions taken:* May 11, 2004: received issue -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Date: Fri, 4 Jun 2004 10:09:10 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Thread-Index: AcRJzwFUkGpZJCsrSLq0QHsjOC7XYQAbmX7Q From: "Bergersen, Rebecca" To: "Tom Rutt" Cc: Here you go... --Becky > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Thursday, June 03, 2004 8:58 PM > To: Bergersen, Rebecca > Cc: firewall-traversal-ftf@omg.org > Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy > discussion with Tom > Rutt - Re: Ballot 4 > > > This is much better, however the figure did not make it in the HTML, > please resend with a pdf for the figure > to show. > > However, I noticed you already changed this to resolve the > issue 7351 by > changing the behaviour for the > object overide on offer policy. > > I think, based on polar's latest email, we need further discussion on > that change. We may need more changes. > > Tom Rutt > > Bergersen, Rebecca wrote: > > >Hi! > > > >I've attached a draft of Ballot 5 which discusses and > rephrases the resolutions for issues 7315 and 7351. Would > you take a look at it provide your opinion, please? If it is > more acceptable than what is in Ballot 4, then we'll remove > the two issues from ballot 4 and issue the ballot 5. Note - > it isn't issued yet - it's only open for discussion. > > > > --Becky > > > > > > > >>-----Original Message----- > >>From: Bergersen, Rebecca > >>Sent: Thursday, June 03, 2004 7:23 PM > >>To: Tom Rutt > >>Cc: firewall-traversal-ftf@omg.org > >>Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy > >>discussion with Tom > >>Rutt - Re: Ballot 4 > >> > >> > >>I think you meant minor problems with proposal 1 from 7315, > >>didn't you Tom? Not 7314. > >> > >> --Becky > >> > >> > >> > >>>-----Original Message----- > >>>From: Tom Rutt [mailto:tom@coastin.com] > >>>Sent: Thursday, June 03, 2004 7:04 PM > >>>To: Bergersen, Rebecca > >>>Cc: firewall-traversal-ftf@omg.org > >>>Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy > >>>discussion with Tom > >>>Rutt - Re: Ballot 4 > >>> > >>> > >>>I think that there are minor problems with proposal 1 from > >>>7314, once it > >>>was explained by Becky. > >>> > >>>I think that the major concern is in Issue 7351 which needs > >>>discussion. > >>> > >>>I never quite realized (because I got the object side > wrong for the > >>>policy) that one could have a different > >>>offer policy for two object references served by the same > >>>server host/port. > >>> > >>> > >>>The issue in 7351 is important: > >>> > >>>It is also related to "what is bidir connection" issue. > >>> > >>>In early bidir, the bidir context had to be sent on the first > >>>message on > >>>a transport connection. Thus is was simple, > >>>a bidir connection is one which had it negotiated at setup time. > >>> > >>>With this new protocol, bidir offers can be sent at any time after > >>>connection setup. > >>> > >>>A connection can be set up for one hour, then all of a suddent the > >>>connection initiator can send > >>>a bidir Offer which, if accepted, makes it a bidir > >>>connection. However > >>>there might already be > >>>objects which have offer policy = deny which have been > >>>invoked on that > >>>connection. By the wording > >>>in the spec: > >>> > >>>" > >>>A BidirectionalOfferPolicy of ALLOW indicates that the Connection > >>>Initiator may send a BI_DIR_GIOP_OFFER service context > >>> > >>> > >>containing the > >> > >> > >>>BiDirID.s of the objects in POAs with a > >>> > >>> > >>BidirectionalExportPolicy of > >> > >> > >>>ALLOW. An object reference with a effective > >>>BidirectionalOfferPolicy of > >>>DENY must not be invoked over a bi-directional connection. > >>> > >>> > >>If the ORB > >> > >> > >>>BidirectionalOfferPolicy is DENY, and the policy has not been > >>>overridden > >>>for a specific object or thread, then no bi-directional > >>>connections can > >>>be negotiated by the connection initiator ORB. > >>>" > >>> > >>>for the global level offer policy at orb level Allow means > >>>the initiator > >>>CAN send bidir Offers, and deny > >>>means it cannot. All of a sudden for the object reference > >>> > >>> > >>level the > >> > >> > >>>emphasis changes to DEFY meaning that > >>>a bidir connection (what is that?) cannot be used to > invoke on that > >>>reference. > >>> > >>>For consistency and simplicity, in all cases DENY should mean > >>>you do not > >>>send bidir offers in service contexts sent with a request to > >>>that object. > >>> > >>>Tom Rutt > >>> > >>>---------------------------------------------------- > >>>Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > >>>Tel: +1 732 801 5744 Fax: +1 732 774 5133 > >>> > >>> > >>> > >>> > >>> > >>> > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > > > Issue 7315: Targets of Export and Offer Policies incompletely > > specified (firewall-traversal-ftf) > > > > /Click here for > this issue's > > archive./ > > *Source:* IONA (Ms. Rebecca Bergersen, rebecca.bergersen@iona.com > > rebbecab@iona.com > > ) > > *Nature:* Uncategorized Issue > > *Severity:* > > *Summary:* > > > >PROBLEM: > > > >The target (ORB, POA, object, thread) of the Export and > Offer policies and the side of the connection involved is > incompletely specified. > > > > > > > >RECOMMENDATION: > > > >Define the two sides of a connection as the connection > 'Initiator' and connection 'Acceptor'. The usual terms of > 'client' (Initiator) and 'server' (Acceptor) become confusing > in a bi-directional situation. Given those terms for each > side, specify that the Export and Offer policies are used on > the Initiator side. Specify that the Export policy may be > applied to the ORB, the POA and/or to the thread. Specify > that the Offer policy can be applied to the Initiator ORB, to > a reference in the Initiator for an object in the Acceptor, > or to a thread in the Initiator ORB. > > > > > > *Resolution:* > > > > The terms Connection Initiator and Connection Acceptor shall be > > explained in the spec and used in place of .client. and .server. in > > appropriate contexts. Identify the BidirectionalExportPolicy as a > > server-side policy that is applied to POAs on the > Connection Initiator > > side of a connection. Identify the BidirectionalOfferPolicy as a > > client-side policy applied on the connection initiator side of a > > connection. Identify the BidirectionalAcceptPolicy as a > client-side > > policy applied on the connection acceptor side of a connection. > > > > > > *Revised Text:* > > > > 1. Section 15.9, Bi-directional GIOP policy: Insert a new > > paragraph immediately before the existing paragraph two > (not counting > > IDL): > > > > > > > > The management of bi-directional GIOP policies is > completely compliant > > with the policy management defined in sections 4.9.1 (Client Side > > Policy Management) and 4.9.2 (Server Side Policy > Management). It is > > stated in those sections that, on the client side, policies may be > > applied at ORB, thread and Object level; on the server side, policy > > management is handled by associating Policy objects with a > POA. This > > spec follows those dicta. However, when connections may be used > > bi-directionally, as indicated in the diagram above, the connection > > initiator is the client for objects on POAs in the connection > > accepter, and is the server for objects on its own POAs. Likewise, > > the connection acceptor is the server for its own objects, and the > > client for objects on the POAs of the connection initiator. > To allay > > this confusion, the terms .Connection Initiator. and .Connection > > Acceptor. will be used rather than .client. and .server.. > > > > 2. Section 15.9, existing paragraph two (not counting IDL): > > Replace the first three sentences with: > > > > An ORB on the connection initiator side of a bi-directional > connection > > may contain objects that it wishes to have called-back over the > > connection. To identify such objects, a server-side > > BidirectionalExportPolicy is applied to a POA on the connection > > initiator side (CB POA in the diagram above) using the > > PortableServer::POA::create_POA operation. If the > > BidirectionalExportPolicy value of the POA is ALLOW, then > the objects > > managed by that POA are allowed to be called back via a > bi-directional > > connection. Therefore, when opening a bi-directional > connection, the > > Connection Initiator ORB is allowed to send to the Connection > > Acceptor, in the BI_DIR_GIOP IOP::ServiceContext, the BiDirId > > associated with the objects in that POA. > > > > 3. Section 15.9: replace existing paragraph three (not > counting > > IDL) with the following: > > > > A client-side BidirectionalOfferPolicy can be applied to a > Connection > > Initiator ORB, to a thread in that ORB, and to specific object > > references received by the connection initiator ORB (InvObj in the > > diagram above), thereby overriding any system defaults or > values set > > at the ORB or thread levels. A BidirectionalOfferPolicy of ALLOW > > indicates that the Connection Initiator may send a > BI_DIR_GIOP_OFFER > > service context containing the BiDirID.s of the objects in > POAs with a > > BidirectionalExportPolicy of ALLOW. An object reference with a > > effective BidirectionalOfferPolicy of DENY shall not send a > > BI_DIR_GIOP_OFFER service context when it is invoked. If the ORB > > BidirectionalOfferPolicy is DENY, and the policy has not been > > overridden for a specific object or thread, then no bi-directional > > connections can be negotiated by the connection initiator ORB. > > > > 4. Section 15.9: replace existing paragraph four (not counting > > IDL) with the following: > > > > A client-side BidirectionalAcceptPolicy can be applied to a > connection > > acceptor ORB, to a thread in that ORB, and to specific object > > references received by the Connection Acceptor (CB Reference in the > > diagram above), overriding any system defaults or values set at the > > ORB or thread levels. A BidirectionalAcceptPolicy of ALLOW > indicates > > that the Connection Acceptor ORB may accept and use any connections > > that a Connection Initiator has offered as bi-directional. > This policy > > can be overridden for specific objects (e.g., CB Reference) > in which > > case those objects shall not be invoked over a bi-directional > > connection. A BidirectionalAcceptPolicy of DENY placed on the > > Connection Acceptor ORB indicates that the Connection Acceptor ORB > > must not accept any offers of bi-directional connections, but may > > invoke on objects which have this policy overridden by a > > BidirectionalAcceptPolicy with a value of ACCEPT. > > > > > > > > > > *Actions taken:* > > May 6, 2004: received issue > > > > > > > > > > > > > > Issue 7351: Limitation and ambiguity in the use of > > BidirectionalOfferPolicy of DENY (firewall-traversal-ftf) > > > > /Click here for > this issue's > > archive./ > > *Source:* Syracuse University (Mr. C. Joncheng Kuo, ckuo01@syr.edu > > ) > > *Nature:* Uncategorized Issue > > *Severity:* > > *Summary:* > > > >Part of this issue has been surfaced in the discussions over > the mail list. I now file it as an issue. > > > > > > > > > > > >The Bi-directional GIOP spec says, "An object reference with > a BidirectionalOfferPolicy of DENY must not be invoked over a > bi-directional connection." Satisfying this policy > requirement does not close some potential limitation and > ambiguity when other policies or policy instances are around. > > > > > > > > > > > >For example, at the connection initiator side, we may have > two object references one of which has > BidirectionalOfferPolicy of DENY and the other has > BidirectionalOfferPolicy of ALLOW. If these two object > references point to the same server, according to spec, we > need two connections to the server: one is bi-directional and > one is not. However, having a non-bi-directional connection > doesn't mean much. For invocations on the object reference > with the DENY policy, the server side can always callback > using the other bi-directional connection. > > > > > > > >There is an argument (by Brian Niebuhr) saying that it's not > realistic to both trust and not trust the same server. > However, in practice, it's not always possible to tell > whether two object references point to the same server or > not. Furthermore, the client may decide whether or not to > trust the server of an object reference depending on reasons > other than the information about the server. For example, the > client may decide to use BidirectionalOfferPolicy of ALLOW or > DENY according to the source of an object reference. > > > > > > > > > > > >On the other hand, at the connection acceptor side, things > become a little more interesting. For an object reference > with BidirectionalAcceptPolicy of ALLOW and *effective* > BidirectionalOfferPolicy of DENY (e.g., the default policy on > that ORB), what shall be the proper behavior of the ORB? > According to the BidirectionalAcceptPolicy, "the ORB may > accept and use any connections that a client has offered as > bi-directional." However, shall we let the > BidirectionalOfferPolicy of DENY prohibits the use of such a > bi-directional connection? Or shall we allow the use of such > a bi-directional connection because it's in the "reverse" direction? > > > > > > > > *Discussion:* > > > > The text of the issue confuses the objects and connection > sides. The > > third paragraph of Section 15.9, Bi-directional GIOP Policy, > > unequivocally states: .A BidirectionalOfferPolicy can be > applied to a > > /client/ ORB, and it can be overridden for specific object > references > > received by the /client/ ORB.. [Italics added for > clarification.] The > > .*effective* BidirectionalOfferPolicy. of an object is not > relevant to > > the connection acceptor side of a bi-directional connection. It is > > used and evaluated only on the connection initiator side to > determine > > if an object may be used to offer a set of BiDirIds to the > connection > > acceptor side. It is not used or evaluated for any other purpose. > > > > > > > > However, on the Connection Initiator side, the spec switches from > > talking about placing a BI_DIR_GIOP_OFFER service context on an > > invocation if the effective BidirectionalOfferPolicy for the > > reference being invoked is ALLOW (i.e. offering a set of > BiDirIds) to > > saying that if the value is DENY, the object may not be > invoked over a > > bi-directional connection. The focus shifts from object and > > invocation to connection. The BidirectionalOfferPolicy is > intended to > > control the sending of BI_DIR_GIOP_OFFER service contexts. > Invoking > > on an object with an effective Offer policy of DENY is not > > disallowed. It.s merely an invocation (a Request) that > doesn.t carry > > an Offer service context. Whether that is sent over a > bi-directional > > connection or a unidirectional connection is irrelevant. It would > > have the same effect (possibly a no-op) in either case. The spec > > should be modified to say that an invocation on an object > reference in > > the Connection Initiator with an effective > BidirectionalOfferPolicy of > > DENY shall not carry a BI_DIR_GIOP_OFFER service context. > > > > > > > > This change is reflected in step three of the text changes in the > > resolution for issue 7315, above. In particular the sentence .An > > object reference with a effective BidirectionalOfferPolicy of DENY > > shall not send a BI_DIR_GIOP_OFFER service context when it > is invoked. > > replaces the earlier text that discussed connections. This issue > > should be closed as a duplicate since its resolution is handled in > > issue 7315. > > > > > > *Resolution:* > > > > Closed as duplicate of 7315. > > > > > > *Revised Text:* > > *Actions taken:* > > May 11, 2004: received issue > > > > > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > ballot_5.pdf Date: Fri, 04 Jun 2004 12:17:05 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Jishnu Mukerji CC: "Bergersen, Rebecca" , firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Whatever initiates the transport connection. It is an ORB. Tom Rutt Jishnu Mukerji wrote: Bergersen, Rebecca wrote: Here you go... --Becky In "However, when connections may be used bi-directionally, as indicated in the diagram above, the connection initiator is the client for objects on POAs in the connection accepter, and is the server for objects on its own POAs. Likewise, the connection acceptor is the server for its own objects, and the client for objects on the POAs of the connection initiator." What sort of things are connection initiator and a connection acceptor? An ORB? A thread? I guess I am a bit lost. Jishnu. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Fri, 04 Jun 2004 14:35:53 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: "Bergersen, Rebecca" Cc: Tom Rutt , firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Bergersen, Rebecca wrote: Hi! Invoking on an object can establish a new connection, possibly bidirectional, while just transmitting an Offer over existing bidirectional connections does not establish any new ones. So, having an Offer policy of DENY on an object would prevent a bidirectional connection from being established when an object is invoked. If the policy's value was ACCEPT and a new connection needed to be created to handle the invocation, that connection could be established as bidirectional. Likewise, if a unidirectional connection existed that would be used for the invocation, it could become bidirectional by the inclusion of the Offer service context in the invocation. --Becky But before doing so wouldn't you have to make sure first that there was no other series of invocations running on that connection from an object reference that has DENY in it? It seems to me that if any object reference for which an invocations is running through a connection has a DENY that should prevent the connection from becoming bi-directional at any point in time, no? Or am I so confused that I am just whistling in the wind? Somehow I am having great difficulty keeping the state-diagram of the lifecycle of a connection straight in my mind, but that may just be me and my overloaded brain. Jishnu. Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Date: Fri, 4 Jun 2004 15:20:05 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Thread-Index: AcRKZO7OLYr2j0MuQNKZJXJKur6d7AAA1gSA From: "Bergersen, Rebecca" To: "Jishnu Mukerji" Cc: "Tom Rutt" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i54JQ9un017199 Actually, that's the way our implementation works. If there's an invocation with Offer=DENY run through the connection, invocations with Offer=ALLOW can't use that connection. A new one would have to be set up. But that's just us - there's nothing in the standard that explicitly defines that constraint. --Becky > -----Original Message----- > From: Jishnu Mukerji [mailto:jishnu@hp.com] > Sent: Friday, June 04, 2004 2:36 PM > To: Bergersen, Rebecca > Cc: Tom Rutt; firewall-traversal-ftf@omg.org > Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy > discussion with Tom > Rutt - Re: Ballot 4 > > > Bergersen, Rebecca wrote: > > >Hi! > > > >Invoking on an object can establish a new connection, > possibly bidirectional, while just transmitting an Offer over > existing bidirectional connections does not establish any new > ones. So, having an Offer policy of DENY on an object would > prevent a bidirectional connection from being established > when an object is invoked. If the policy's value was ACCEPT > and a new connection needed to be created to handle the > invocation, that connection could be established as > bidirectional. Likewise, if a unidirectional connection > existed that would be used for the invocation, it could > become bidirectional by the inclusion of the > >Offer service context in the invocation. > > > > --Becky > > > > > But before doing so wouldn't you have to make sure first that > there was > no other series of invocations running on that connection > from an object > reference that has DENY in it? It seems to me that if any object > reference for which an invocations is running through a > connection has a > DENY that should prevent the connection from becoming > bi-directional at > any point in time, no? Or am I so confused that I am just > whistling in > the wind? > > Somehow I am having great difficulty keeping the state-diagram of the > lifecycle of a connection straight in my mind, but that may > just be me > and my overloaded brain. > > Jishnu. > > Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Date: Fri, 4 Jun 2004 15:32:03 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Thread-Index: AcRKZO7OLYr2j0MuQNKZJXJKur6d7AABD+XA From: "Bergersen, Rebecca" To: "Jishnu Mukerji" Cc: "Tom Rutt" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i54JZxun017387 Yes, you'd have to first make sure that an invocation from an object with an Offer=DENY hadn't run through the connection. That would imply that it would be better to NOT put an explicit BidirectionalOfferPolicy of DENY on the ORB and then override it for specific objects. Rather, just override the specific objects that you want to invoke on in order to set up bidirectional connections and/or transmit BiDirIds. The Offer Policy wouldn't figure into the use of the other objects. They could use a BiDir connection or a unidirectional one, even ones with invocations from objects with Offer=DENY running through them (so long as all else is equal - security constraints match, etc.) --Becky > -----Original Message----- > From: Jishnu Mukerji [mailto:jishnu@hp.com] > Sent: Friday, June 04, 2004 2:36 PM > To: Bergersen, Rebecca > Cc: Tom Rutt; firewall-traversal-ftf@omg.org > Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy > discussion with Tom > Rutt - Re: Ballot 4 > > > Bergersen, Rebecca wrote: > > >Hi! > > > >Invoking on an object can establish a new connection, > possibly bidirectional, while just transmitting an Offer over > existing bidirectional connections does not establish any new > ones. So, having an Offer policy of DENY on an object would > prevent a bidirectional connection from being established > when an object is invoked. If the policy's value was ACCEPT > and a new connection needed to be created to handle the > invocation, that connection could be established as > bidirectional. Likewise, if a unidirectional connection > existed that would be used for the invocation, it could > become bidirectional by the inclusion of the > >Offer service context in the invocation. > > > > --Becky > > > > > But before doing so wouldn't you have to make sure first that > there was > no other series of invocations running on that connection > from an object > reference that has DENY in it? It seems to me that if any object > reference for which an invocations is running through a > connection has a > DENY that should prevent the connection from becoming > bi-directional at > any point in time, no? Or am I so confused that I am just > whistling in > the wind? > > Somehow I am having great difficulty keeping the state-diagram of the > lifecycle of a connection straight in my mind, but that may > just be me > and my overloaded brain. > > Jishnu. > > Date: Fri, 04 Jun 2004 17:54:57 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en CC: Jishnu Mukerji , firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 But what good is the protection if the initiating orb can send bidir IDs on negotiate context messages which are not directed to any object reference? My reading of the spec makes me think the negotiate session may be sent at any time on the connection. Is this true? Bergersen, Rebecca wrote: Hi! Invoking on an object can establish a new connection, possibly bidirectional, while just transmitting an Offer over existing bidirectional connections does not establish any new ones. So, having an Offer policy of DENY on an object would prevent a bidirectional connection from being established when an object is invoked. If the policy's value was ACCEPT and a new connection needed to be created to handle the invocation, that connection could be established as bidirectional. Likewise, if a unidirectional connection existed that would be used for the invocation, it could become bidirectional by the inclusion of the Offer service context in the invocation. --Becky -----Original Message----- From: Tom Rutt [mailto:tom@coastin.com] Sent: Friday, June 04, 2004 12:22 PM To: Jishnu Mukerji Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 We have to discuss this with Issue 7315, which Polar had the following comment on: " What of offers sent on NegotiationSession messages, behind that object references back? Does having DENY on an object reference only mean that it offers cannot be sent in GIOP Requests to that particular object? What "real" purpose (assuming "DENY" is originally for reasons of security) does that serve, if the offers can be sent in other requests, or in NegotiationSession messages? -Polar " the text cited below by Jishnu only relates to sending the bidir offer on a request message? what good is this object specific offer policy overide if the orb can send the bidir offer on a negotiate context message which has no Object reference as target? This offer policy makes sense only at the orb level, it seems to be useless at the object reference overide level. Can someone show a use case where the object level overide of offer policy makes sense? Tom Rutt Jishnu Mukerji wrote: Bergersen, Rebecca wrote: Here you go... --Becky In "However, when connections may be used bi-directionally, as indicated in the diagram above, the connection initiator is the client for objects on POAs in the connection accepter, and is the server for objects on its own POAs. Likewise, the connection acceptor is the server for its own objects, and the client for objects on the POAs of the connection initiator." What sort of things are connection initiator and a connection acceptor? An ORB? A thread? I guess I am a bit lost. Jishnu. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Fri, 04 Jun 2004 18:55:36 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en CC: Jishnu Mukerji , firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 This is very complex: If we want this house of cards to exist, it better have strict rules. We need to define what is Bidir. This could also satisfy the other Issue on when is a connection bidir I propose giop connections have one of three states: CouldBecomeBiDir CannotBecomBiDir BiDir Lets try some tentative rules: 1) A connection starts out with the state, CouldBecomeBidir 2) antime a service context with a bidir Offer is sent by the initiator over that connection, its state moves to BiDir for the life of that connectionl 3) if the Offer policy at initiator orb level is DENY, then that orb will never send bidir Offers and the state of its connecitons will always be CouldBecomeBidir, unless the DENY is overidden for one or more object references held by the initiator orb.. 4) When the orb level offer policy is ALLOW, if any objectRef which has client offer policy of DENY is invoked on by the initator: a) That invocation can only be carried on a connection which has state CouldBecomeBidir, or CannotBecomeBidir. b) after if the invocation on this DENY object, the connection takes the state of CannotBecomeBidir 5) When the orb level offer policy is DENY, if any object ref has client offer policy of ALLOW, an invocation on that object cannot be carried on a connection which has state CannotBecomeBidir. Any connection with state CouldBecomeBidir or, BiDir can be used to invoke on that reference, after which the state of the connnection permanantly becomes BiDir. This could be made to work, but does it accomplish what we are trying to do. What are the security implications for keeping some acceptor orb object references invocable over bidir connections, while others are not? I am not sure if this complexity is warranted. What is the use case for this complicated state machine? Tom Rutt Bergersen, Rebecca wrote: Yes, you'd have to first make sure that an invocation from an object with an Offer=DENY hadn't run through the connection. That would imply that it would be better to NOT put an explicit BidirectionalOfferPolicy of DENY on the ORB and then override it for specific objects. Rather, just override the specific objects that you want to invoke on in order to set up bidirectional connections and/or transmit BiDirIds. The Offer Policy wouldn't figure into the use of the other objects. They could use a BiDir connection or a unidirectional one, even ones with invocations from objects with Offer=DENY running through them (so long as all else is equal - security constraints match, etc.) --Becky -----Original Message----- From: Jishnu Mukerji [mailto:jishnu@hp.com] Sent: Friday, June 04, 2004 2:36 PM To: Bergersen, Rebecca Cc: Tom Rutt; firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 Bergersen, Rebecca wrote: Hi! Invoking on an object can establish a new connection, possibly bidirectional, while just transmitting an Offer over existing bidirectional connections does not establish any new ones. So, having an Offer policy of DENY on an object would prevent a bidirectional connection from being established when an object is invoked. If the policy's value was ACCEPT and a new connection needed to be created to handle the invocation, that connection could be established as bidirectional. Likewise, if a unidirectional connection existed that would be used for the invocation, it could become bidirectional by the inclusion of the Offer service context in the invocation. --Becky But before doing so wouldn't you have to make sure first that there was no other series of invocations running on that connection from an object reference that has DENY in it? It seems to me that if any object reference for which an invocations is running through a connection has a DENY that should prevent the connection from becoming bi-directional at any point in time, no? Or am I so confused that I am just whistling in the wind? Somehow I am having great difficulty keeping the state-diagram of the lifecycle of a connection straight in my mind, but that may just be me and my overloaded brain. Jishnu. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133