Issue 7356: when is a connection a "bi-directional connection"? (firewall-traversal-ftf) Source: Real-Time Innovations (Mr. Dave Stringer, dstringer(at)rti.com) Nature: Uncategorized Issue Severity: Summary: The discussion on when to send BiDirIds over connections is floundering. In part, I think this is due to a lack of precision in our thinking (and more importantly in the adopted firewall spec we are working from). When does a GIOP connection become bi-directional? The implementation of the connection-initiator protocol engine must know this. Before this event it has to treat a GIOP Request message as a protocol error and after the event it has to dispatch the request. There seems to be an assumption (or more than one) that there is a relationship between an Object Reference (i.e. the programming language artefact representing CORBA::Object) and a GIOP connection. Whilst it is true that an implementation of the CORBA spec will provide a relationship (else an invocation cannot result in a GIOP Request message) the particular relationship was left to ORB implementers to provide for flexibility of implementation. Specifically, such a relationship is not prescribed in the CORBA specification (nor should it be). I suggest it would be dangerous to define a GIOP connection to change state when an Object Reference that (in some ill-defined way) "points to" a server that is the target of that connection, undergoes a policy change (i.e. its BiDir Offer policy is set to Allow). Instead, a GIOP connection presumably becomes bi-directional when an invocation on an Object Reference, with an effective Offer Policy of Allow, results in a Request message being sent over that connection. The specification must be explicit over which event causes the connection to become bi-directional. Also, can a connection cease to be bi-directional? For example if either the Object Reference invoked above or the POA with "Export = Allow" are destroyed. Again this would appear to be fraught with problems, leading to the assumption that the GIOP connection, once bi-directional, remains bi-directional until it is closed. Lastly, the closing of idle connections and the subsequent re-connection has hitherto been a matter for ORB implementers (Messaging::RebindPolicy not withstanding). This is unfortunate as an application won't be aware of the ORB having conserved resources in this way and the ORB should not be expected to provide session semantics that span multiple tcp connections (this is currently stated in the description of NegotiateSession). Resolution: Revised Text: Actions taken: May 18, 2004: received issue Discussion: End of Annotations:===== ubject: when is a connection a "bi-directional connection"? Date: Tue, 18 May 2004 11:50:22 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: when is a connection a "bi-directional connection"? Thread-Index: AcQ9CSGLhwvkXdQtRGS3XpTRGGM6FA== From: "Dave Stringer" To: Cc: X-OriginalArrivalTime: 18 May 2004 18:50:22.0939 (UTC) FILETIME=[F992B2B0:01C43D08] The discussion on when to send BiDirIds over connections is floundering. In part, I think this is due to a lack of precision in our thinking (and more importantly in the adopted firewall spec we are working from). When does a GIOP connection become bi-directional? The implementation of the connection-initiator protocol engine must know this. Before this event it has to treat a GIOP Request message as a protocol error and after the event it has to dispatch the request. There seems to be an assumption (or more than one) that there is a relationship between an Object Reference (i.e. the programming language artefact representing CORBA::Object) and a GIOP connection. Whilst it is true that an implementation of the CORBA spec will provide a relationship (else an invocation cannot result in a GIOP Request message) the particular relationship was left to ORB implementers to provide for flexibility of implementation. Specifically, such a relationship is not prescribed in the CORBA specification (nor should it be). I suggest it would be dangerous to define a GIOP connection to change state when an Object Reference that (in some ill-defined way) "points to" a server that is the target of that connection, undergoes a policy change (i.e. its BiDir Offer policy is set to Allow). Instead, a GIOP connection presumably becomes bi-directional when an invocation on an Object Reference, with an effective Offer Policy of Allow, results in a Request message being sent over that connection. The specification must be explicit over which event causes the connection to become bi-directional. Also, can a connection cease to be bi-directional? For example if either the Object Reference invoked above or the POA with "Export = Allow" are destroyed. Again this would appear to be fraught with problems, leading to the assumption that the GIOP connection, once bi-directional, remains bi-directional until it is closed. Lastly, the closing of idle connections and the subsequent re-connection has hitherto been a matter for ORB implementers (Messaging::RebindPolicy not withstanding). This is unfortunate as an application won't be aware of the ORB having conserved resources in this way and the ORB should not be expected to provide session semantics that span multiple tcp connections (this is currently Subject: RE: issue 7356 -- Firewall Traversal FTF issue Date: Tue, 18 May 2004 18:46:16 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7356 -- Firewall Traversal FTF issue Thread-Index: AcQ9ILJwqXSZ33kaRtiEsMX5O2aJFwAAv8eQ From: "Bergersen, Rebecca" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4IMm8un000500 Comments inline... --Rebecca > -----Original Message----- > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: Tuesday, May 18, 2004 5:27 PM > To: issues@omg.org; firewall-traversal-ftf@omg.org > Subject: issue 7356 -- Firewall Traversal FTF issue > > > This is issue #7356 > > when is a connection a "bi-directional connection"? > > The discussion on when to send BiDirIds over connections is > floundering. > In part, I think this is due to a lack of precision in our > thinking (and more > importantly in the adopted firewall spec we are working from). > > When does a GIOP connection become bi-directional? The implementation > of the connection-initiator protocol engine must know this. > Before this > event it has to treat a GIOP Request message as a protocol > error and after > the event it has to dispatch the request. My understanding is that bi-directionality is affirmed when the connection acceptor sends a BI_DIR_GIOP_ACCEPT service context to the connection initiator that has a value of BI_DIR_NO_ERROR. The setup period begins with the OFFER and ends with ACCEPT of NO_ERROR. > > There seems to be an assumption (or more than one) that there is a > relationship between an Object Reference (i.e. the > programming language > artefact representing CORBA::Object) and a GIOP connection. > > Whilst it is true that an implementation of the CORBA spec > will provide a > relationship (else an invocation cannot result in a GIOP > Request message) > the particular relationship was left to ORB implementers to > provide for > flexibility of implementation. Specifically, such a > relationship is not > prescribed > in the CORBA specification (nor should it be). > > I suggest it would be dangerous to define a GIOP connection > to change state > when an Object Reference that (in some ill-defined way) > "points to" a server > that is the target of that connection, undergoes a policy > change (i.e. its > BiDir > Offer policy is set to Allow). I never read the spec that way. I agree that merely associating a policy with an object reference should not cause a state change in a connection. > > Instead, a GIOP connection presumably becomes bi-directional when an > invocation on an Object Reference, with an effective Offer > Policy of Allow, > results > in a Request message being sent over that connection. > I would say not even then. It becomes bi-directional when an ACCEPT service context with a value of NO_ERROR is sent from the connection acceptor to the connection initiator. However, there is a period when a negotiation may take place and the connection is used in a bi-directional manner - when a NEGOTIATE_SESSION service context with a BI_DIR_GIOP_CHALLENGE is sent to the connection initiator. Since the connection initiator sent the OFFER in the first place, it must be ready to receive messages back. (Just as an aside, a CHALLENGE may be sent after the ACCEPT with NO_ERROR has been issued.) It is, finally, up to the connection acceptor to decide whether the connection is bi-directional. > The specification must be explicit over which event causes > the connection to > become bi-directional. > Agreed. Do you agree that it should be the sending of a BI_DIR_GIOP_ACCEPT service context with a value of BI_DIR_NO_ERROR? > Also, can a connection cease to be bi-directional? For > example if either the > Object Reference invoked above or the POA with "Export = > Allow" are destroyed. > Again this would appear to be fraught with problems, leading > to the assumption > that the GIOP connection, once bi-directional, remains > bi-directional until > it is > closed. I would say that it happens when a BI_DIR_GIOP_ACCEPT service context is sent that does NOT have a value of BI_DIR_NO_ERROR. Since a CHALLENGE can be sent at any time, so can an ACCEPT service context. I don't think either the invoked object reference or a POA with export=allowed being destroyed would cause the connection to become uni-directional - that's too tight a relationship between an object and a connection. Additionally, even if either or both of those objects are destroyed, other invocation objects or POAs with BiDirIds might be associated with the connection. > > Lastly, the closing of idle connections and the subsequent > re-connection has > hitherto been a matter for ORB implementers > (Messaging::RebindPolicy not > withstanding). This is unfortunate as an application won't be > aware of the ORB > having conserved resources in this way and the ORB should not > be expected to > provide session semantics that span multiple tcp connections (this is > currently > stated in the description of NegotiateSession). Right. This is a difficulty that should be pointed out and its implications discussed in the spec. > > > ================================= > Jürgen Boldt > Director, Member Services > > Object Management Group > 250 First Avenue, Suite 100 > Needham, MA 02494 > > Tel. +1 781 444 0404 ext. 132 > Fax: +1 781 444 0320 > email: juergen@omg.org > www www.omg.org > > ================================ > Subject: RE: issue 7356 -- Firewall Traversal FTF issue Date: Wed, 19 May 2004 12:34:00 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7356 -- Firewall Traversal FTF issue Thread-Index: AcQ9ILJwqXSZ33kaRtiEsMX5O2aJFwAAv8eQAColRQA= From: "Dave Stringer" To: "Bergersen, Rebecca" , X-OriginalArrivalTime: 19 May 2004 19:34:00.0955 (UTC) FILETIME=[3C71FCB0:01C43DD8] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4JJb7un015341 Rebecca Is it even possible to define a connection to be bi-directional as "after the acceptor has sent an ...ACCEPT(no-error) service context"? The "What BidirIds ..." thread appears to assume that BiDirIds are sent over every "bi-directional" connection. However, if a connection can only become bi-directional by responding to an offered BidirId, then BiDirIds must be sent over every connection - so that they have the chance to accept and become bi-directional. As you have agreed below, "merely associating a policy with an object reference should not cause a state change in a connection" but disagreed that an invocation on a reference with an effective Offer policy of "allow" would denote the change, I see a problem. Given your statements, it appears to be a logical consequence that every BiDirId is transmitted over every connection. Is this your understanding? Or is there another piece of the puzzle I'm missing? Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Tuesday, May 18, 2004 3:46 PM To: firewall-traversal-ftf@omg.org Subject: RE: issue 7356 -- Firewall Traversal FTF issue Comments inline... --Rebecca > -----Original Message----- > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: Tuesday, May 18, 2004 5:27 PM > To: issues@omg.org; firewall-traversal-ftf@omg.org > Subject: issue 7356 -- Firewall Traversal FTF issue > > > This is issue #7356 > > when is a connection a "bi-directional connection"? > > The discussion on when to send BiDirIds over connections is > floundering. > In part, I think this is due to a lack of precision in our > thinking (and more > importantly in the adopted firewall spec we are working from). > > When does a GIOP connection become bi-directional? The implementation > of the connection-initiator protocol engine must know this. > Before this > event it has to treat a GIOP Request message as a protocol > error and after > the event it has to dispatch the request. My understanding is that bi-directionality is affirmed when the connection acceptor sends a BI_DIR_GIOP_ACCEPT service context to the connection initiator that has a value of BI_DIR_NO_ERROR. The setup period begins with the OFFER and ends with ACCEPT of NO_ERROR. > > There seems to be an assumption (or more than one) that there is a > relationship between an Object Reference (i.e. the > programming language > artefact representing CORBA::Object) and a GIOP connection. > > Whilst it is true that an implementation of the CORBA spec > will provide a > relationship (else an invocation cannot result in a GIOP > Request message) > the particular relationship was left to ORB implementers to > provide for > flexibility of implementation. Specifically, such a > relationship is not > prescribed > in the CORBA specification (nor should it be). > > I suggest it would be dangerous to define a GIOP connection > to change state > when an Object Reference that (in some ill-defined way) > "points to" a server > that is the target of that connection, undergoes a policy > change (i.e. its > BiDir > Offer policy is set to Allow). I never read the spec that way. I agree that merely associating a policy with an object reference should not cause a state change in a connection. > > Instead, a GIOP connection presumably becomes bi-directional when an > invocation on an Object Reference, with an effective Offer > Policy of Allow, > results > in a Request message being sent over that connection. > I would say not even then. It becomes bi-directional when an ACCEPT service context with a value of NO_ERROR is sent from the connection acceptor to the connection initiator. However, there is a period when a negotiation may take place and the connection is used in a bi-directional manner - when a NEGOTIATE_SESSION service context with a BI_DIR_GIOP_CHALLENGE is sent to the connection initiator. Since the connection initiator sent the OFFER in the first place, it must be ready to receive messages back. (Just as an aside, a CHALLENGE may be sent after the ACCEPT with NO_ERROR has been issued.) It is, finally, up to the connection acceptor to decide whether the connection is bi-directional. > The specification must be explicit over which event causes > the connection to > become bi-directional. > Agreed. Do you agree that it should be the sending of a BI_DIR_GIOP_ACCEPT service context with a value of BI_DIR_NO_ERROR? > Also, can a connection cease to be bi-directional? For > example if either the > Object Reference invoked above or the POA with "Export = > Allow" are destroyed. > Again this would appear to be fraught with problems, leading > to the assumption > that the GIOP connection, once bi-directional, remains > bi-directional until > it is > closed. I would say that it happens when a BI_DIR_GIOP_ACCEPT service context is sent that does NOT have a value of BI_DIR_NO_ERROR. Since a CHALLENGE can be sent at any time, so can an ACCEPT service context. I don't think either the invoked object reference or a POA with export=allowed being destroyed would cause the connection to become uni-directional - that's too tight a relationship between an object and a connection. Additionally, even if either or both of those objects are destroyed, other invocation objects or POAs with BiDirIds might be associated with the connection. > > Lastly, the closing of idle connections and the subsequent > re-connection has > hitherto been a matter for ORB implementers > (Messaging::RebindPolicy not > withstanding). This is unfortunate as an application won't be > aware of the ORB > having conserved resources in this way and the ORB should not > be expected to > provide session semantics that span multiple tcp connections (this is > currently > stated in the description of NegotiateSession). Right. This is a difficulty that should be pointed out and its implications discussed in the spec. > > > ================================= > Jürgen Boldt > Director, Member Services > > Object Management Group > 250 First Avenue, Suite 100 > Needham, MA 02494 > > Tel. +1 781 444 0404 ext. 132 > Fax: +1 781 444 0320 > email: juergen@omg.org > www www.omg.org > > ================================ > > Subject: RE: issue 7356 -- Firewall Traversal FTF issue Date: Wed, 19 May 2004 20:44:16 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7356 -- Firewall Traversal FTF issue Thread-Index: AcQ9ILJwqXSZ33kaRtiEsMX5O2aJFwAAv8eQAColRQAADVwLQA== From: "Bergersen, Rebecca" To: "Dave Stringer" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4K0kJun018110 > -----Original Message----- > From: Dave Stringer [mailto:Dave.Stringer@borland.com] > Sent: Wednesday, May 19, 2004 3:34 PM > To: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: RE: issue 7356 -- Firewall Traversal FTF issue > > > Rebecca > > Is it even possible to define a connection to be bi-directional > as "after the acceptor has sent an ...ACCEPT(no-error) service > context"? > > The "What BidirIds ..." thread appears to assume that BiDirIds > are sent over every "bi-directional" connection. However, if a > connection can only become bi-directional by responding to an > offered BidirId, then BiDirIds must be sent over every connection > - so that they have the chance to accept and become bi-directional. Right! > > As you have agreed below, "merely associating a policy with an > object reference should not cause a state change in a connection" > but disagreed that an invocation on a reference with an effective > Offer policy of "allow" would denote the change, I see a problem. The invocation merely starts the setup protocol. At that point the client (connection initiator) must be prepared to accept NegotiateSession messages back from the connection acceptor - the Accept is one such, but so is the Challenge. A loose interpretation would also allow Queries. So, from the point of view of the connection initiator, the connection may be used bi-directionally. However, the Accept is the only real cue to the connection initiator that the connection has been accepted by the connection acceptor as bi-directional. As I read the spec, that's why the setup period has an end. The connection may be used bi-directionally before the Accept is received, but only for continuing to establish the protocol (i.e. the challenge/response). Where do you see a problem? Would you prefer that the connection be considered bi-directional as soon as the connection initiator makes an offer? > > Given your statements, it appears to be a logical consequence > that every BiDirId is transmitted over every connection. Is this > your understanding? Or is there another piece of the puzzle I'm > missing? That's my understanding. > > Dave > > > > > -----Original Message----- > From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] > Sent: Tuesday, May 18, 2004 3:46 PM > To: firewall-traversal-ftf@omg.org > Subject: RE: issue 7356 -- Firewall Traversal FTF issue > > > > Comments inline... > --Rebecca > > > -----Original Message----- > > From: Juergen Boldt [mailto:juergen@omg.org] > > Sent: Tuesday, May 18, 2004 5:27 PM > > To: issues@omg.org; firewall-traversal-ftf@omg.org > > Subject: issue 7356 -- Firewall Traversal FTF issue > > > > > > This is issue #7356 > > > > when is a connection a "bi-directional connection"? > > > > The discussion on when to send BiDirIds over connections is > > floundering. > > In part, I think this is due to a lack of precision in our > > thinking (and more > > importantly in the adopted firewall spec we are working from). > > > > When does a GIOP connection become bi-directional? The > implementation > > of the connection-initiator protocol engine must know this. > > Before this > > event it has to treat a GIOP Request message as a protocol > > error and after > > the event it has to dispatch the request. > > My understanding is that bi-directionality is affirmed when > the connection acceptor sends a BI_DIR_GIOP_ACCEPT service > context to the connection initiator that has a value of > BI_DIR_NO_ERROR. The setup period begins with the OFFER and > ends with ACCEPT of NO_ERROR. > > > > > There seems to be an assumption (or more than one) that there is a > > relationship between an Object Reference (i.e. the > > programming language > > artefact representing CORBA::Object) and a GIOP connection. > > > > Whilst it is true that an implementation of the CORBA spec > > will provide a > > relationship (else an invocation cannot result in a GIOP > > Request message) > > the particular relationship was left to ORB implementers to > > provide for > > flexibility of implementation. Specifically, such a > > relationship is not > > prescribed > > in the CORBA specification (nor should it be). > > > > I suggest it would be dangerous to define a GIOP connection > > to change state > > when an Object Reference that (in some ill-defined way) > > "points to" a server > > that is the target of that connection, undergoes a policy > > change (i.e. its > > BiDir > > Offer policy is set to Allow). > > I never read the spec that way. I agree that merely > associating a policy with an object reference should not > cause a state change in a connection. > > > > > Instead, a GIOP connection presumably becomes bi-directional when an > > invocation on an Object Reference, with an effective Offer > > Policy of Allow, > > results > > in a Request message being sent over that connection. > > > > I would say not even then. It becomes bi-directional when an > ACCEPT service context with a value of NO_ERROR is sent from > the connection acceptor to the connection initiator. > However, there is a period when a negotiation may take place > and the connection is used in a bi-directional manner - when > a NEGOTIATE_SESSION service context with a > BI_DIR_GIOP_CHALLENGE is sent to the connection initiator. > Since the connection initiator sent the OFFER in the first > place, it must be ready to receive messages back. (Just as > an aside, a CHALLENGE may be sent after the ACCEPT with > NO_ERROR has been issued.) It is, finally, up to the > connection acceptor to decide whether the connection is > bi-directional. > > > > The specification must be explicit over which event causes > > the connection to > > become bi-directional. > > > > Agreed. Do you agree that it should be the sending of a > BI_DIR_GIOP_ACCEPT service context with a value of BI_DIR_NO_ERROR? > > > Also, can a connection cease to be bi-directional? For > > example if either the > > Object Reference invoked above or the POA with "Export = > > Allow" are destroyed. > > Again this would appear to be fraught with problems, leading > > to the assumption > > that the GIOP connection, once bi-directional, remains > > bi-directional until > > it is > > closed. > > I would say that it happens when a BI_DIR_GIOP_ACCEPT service > context is sent that does NOT have a value of > BI_DIR_NO_ERROR. Since a CHALLENGE can be sent at any time, > so can an ACCEPT service context. I don't think either the > invoked object reference or a POA with export=allowed being > destroyed would cause the connection to become > uni-directional - that's too tight a relationship between an > object and a connection. Additionally, even if either or > both of those objects are destroyed, other invocation objects > or POAs with BiDirIds might be associated with the connection. > > > > > Lastly, the closing of idle connections and the subsequent > > re-connection has > > hitherto been a matter for ORB implementers > > (Messaging::RebindPolicy not > > withstanding). This is unfortunate as an application won't be > > aware of the ORB > > having conserved resources in this way and the ORB should not > > be expected to > > provide session semantics that span multiple tcp > connections (this is > > currently > > stated in the description of NegotiateSession). > > Right. This is a difficulty that should be pointed out and > its implications discussed in the spec. > > > > > > > ================================= > > Jürgen Boldt > > Director, Member Services > > > > Object Management Group > > 250 First Avenue, Suite 100 > > Needham, MA 02494 > > > > Tel. +1 781 444 0404 ext. 132 > > Fax: +1 781 444 0320 > > email: juergen@omg.org > > www www.omg.org > > > > ================================ > > > > From: webmaster@omg.org Date: 03 Jun 2004 20:12:17 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Oliver Sims Company: Open-IT Limited mailFrom: oliver@open-it.co.uk Notification: Yes Specification: UML2 Superstructure Section: Components FormalNumber: ptc/03-08-02 Version: 1 RevisionDate: 08/00/2003 Page: 133 Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 2.0.40209) Description The Components chapter of the UML2 Superstructure spec does not specify what component generalization/specialization means. Is it intended that this be left unspecified? If not, then I propose the semantics described in a paper I wrote on this subject prior to the spec being adopted. The paper suggested an approach that is consistent with substitutability semantics, and should also be able to be made to work with most if not all component technologies. I'd be happy to email the paper to anyone interested. Date: Mon, 07 Jun 2004 13:36:49 -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: Dave Stringer CC: "Bergersen, Rebecca" , firewall-traversal-ftf@omg.org Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 My understanding is that vote 5 is not yet underway. The discussion on 7356, or when is connectino Bidir, has to be agreed, with all its ripples onto the other issues, before the next ballot should go out. Tom Rutt This is my understanding Dave Stringer wrote: Rebecca Can you clarify the status of ballot 5? Is it officially in-progress? What is the date by which votes should be cast? What is the significance of the continuing discussion on these issues? Thanks, Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Friday, June 04, 2004 7:09 AM To: Tom Rutt Cc: firewall-traversal-ftf@omg.org Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy discussion with Tom Rutt - Re: Ballot 4 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 -- ---------------------------------------------------- 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: Mon, 7 Jun 2004 14:06:14 -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: AcRMthbbrjsMMREDR9igxT3JH7AieAAA3isA From: "Bergersen, Rebecca" To: "Tom Rutt" , "Dave Stringer" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i57IARun010703 Hi, Dave! Yes, ballot 5 is NOT underway. I put it out as a draft for people's comments only. Tom's discussion of 7356 and his discussion in the other thread ("Analysis of issues resolution for Firewall") needs to be worked out before Ballot 5 goes out. It does look like there will be a ballot 5 early this week, but with some different questions than I proposed. --Rebecca > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Monday, June 07, 2004 1:37 PM > To: Dave Stringer > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: Re: FIREWALL FTF - OFFER and EXPORT Policy > discussion with Tom > Rutt - Re: Ballot 4 > > > My understanding is that vote 5 is not yet underway. > > The discussion on 7356, or when is connectino Bidir, has to > be agreed, > with all its > ripples onto the other issues, before the next ballot should go out. > > Tom Rutt > > This is my understanding > > Dave Stringer wrote: > > >Rebecca > > > >Can you clarify the status of ballot 5? > >Is it officially in-progress? > >What is the date by which votes should be cast? > >What is the significance of the continuing discussion on > these issues? > > > >Thanks, > >Dave > > > > > > > > > >-----Original Message----- > >From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] > >Sent: Friday, June 04, 2004 7:09 AM > >To: Tom Rutt > >Cc: firewall-traversal-ftf@omg.org > >Subject: RE: FIREWALL FTF - OFFER and EXPORT Policy > discussion with Tom > >Rutt - Re: Ballot 4 > > > > > > > >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 > >> > >> > >> > >> > >> > >> > > > > > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > stated in the description of NegotiateSession). Date: Mon, 07 Jun 2004 12:23:20 -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: Tom Rutt Cc: firewall-traversal-ftf@omg.org, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Tom Rutt wrote: Upon a detailed analysis of the issues (attached) I now think that they are resolvable in a short amount of time, if people are willing. Issue 7353, 7356, and 7315 need further discussion. The proposed resolution for 7356 needs a little more work. The attached document contains my proposed modified version based on Tom's proposal. Basically we need to cover all cases for ORB level, thread level and object reference level overrides for all possible states of the connection. Jishnu. My changes are in bold italic: Proposed resolution for Issue 7356: GIOP 1.4 connections have one of three states: CouldBecomeBiDir CannotBecomBiDir BiDir Rules: 1) A connection starts out with the state, CouldBecomeBidir 2) anytime 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 connection. Such an offer can be sent only if the connection over which it is sent is either in the CouldBecomeBiDir or BiDir state. 3) if the Offer policy at initiator orb level is DENY, then that orb will never send bidir Offers and the state of its connections will always be CouldBecomeBidir, unless a) the orb level DENY is overridden by ALLOW for one or more object references or one or more thread used for an invocation over the connection by the initiator orb. In that case a bidir Offer will be sent provided the state of the connection is CouldBecomeBiDir or BiDir. b) the orb level DENY is overridden by DENY for one or more object references or one or more thread used for an invocation over the connection by the initiator orb. In that case the invocation will be initiated provided the state of the connection is CouldBecomeBiDir or CannotBecomeBiDir and the state of the connection shall become CannotBecomeBiDir. 4) When the orb level offer policy is ALLOW, if any object reference which has client offer policy of DENY is invoked on by the initator or the thread used for the invocation has client offer policy of DENY, that invocation can only be carried on a connection which has state CouldBecomeBidir, or CannotBecomeBidir and after the invocation is initiated, the connection takes the state of CannotBecomeBidir 5) if any object reference or thread used in an invocation 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 using that thread, after which the state of the connnection permanantly becomes BiDir. Date: Mon, 07 Jun 2004 12:44:23 -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: firewall-traversal-ftf@omg.org, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall I like Jishnu's proposal Jishnu Mukerji wrote: Tom Rutt wrote: Upon a detailed analysis of the issues (attached) I now think that they are resolvable in a short amount of time, if people are willing. Issue 7353, 7356, and 7315 need further discussion. The proposed resolution for 7356 needs a little more work. The attached document contains my proposed modified version based on Tom's proposal. Basically we need to cover all cases for ORB level, thread level and object reference level overrides for all possible states of the connection. Jishnu. ------------------------------------------------------------------------ My changes are in bold italic: Proposed resolution for Issue 7356: GIOP 1.4 connections have one of three states: * CouldBecomeBiDir * CannotBecomBiDir * BiDir Rules: 1) A connection starts out with the state, CouldBecomeBidir 2) anytime 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 connection. Such an offer can be sent only if the connection over which it is sent is either in the CouldBecomeBiDir or BiDir state. 3) if the Offer policy at initiator orb level is DENY, then that orb will never send bidir Offers and the state of its connections will always be CouldBecomeBidir, unless a) the orb level DENY is overridden by ALLOW for one or more object references or one or more thread used for an invocation over the connection by the initiator orb. In that case a bidir Offer will be sent provided the state of the connection is CouldBecomeBiDir or BiDir. b) the orb level DENY is overridden by DENY for one or more object references or one or more thread used for an invocation over the connection by the initiator orb. In that case the invocation will be initiated provided the state of the connection is CouldBecomeBiDir or CannotBecomeBiDir and the state of the connection shall become CannotBecomeBiDir. 4) When the orb level offer policy is ALLOW, if any object reference which has client offer policy of DENY is invoked on by the initator or the thread used for the invocation has client offer policy of DENY, that invocation can only be carried on a connection which has state CouldBecomeBidir, or CannotBecomeBidir and after the invocation is initiated, the connection takes the state of CannotBecomeBidir 5) if any object reference or thread used in an invocation 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 using that thread, after which the state of the connnection permanantly becomes BiDir. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Mon, 07 Jun 2004 13:04:01 -0400 From: "Robert A. Kukura" User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Jishnu Mukerji , Tom Rutt , firewall-traversal-ftf@omg.org CC: Andrew Watson Subject: Re: Analysis of issue resolutions for firewall X-SPAM: 0.00 I'm not on the FTF and have not been following this discussion in detail, but would strongly recommend NOT trying to specify behavior of policies in terms of where they are applied (ORB, thread, object, and POA levels). Instead, please specify behavior in terms of the effective policy value for an object invocation (client-side) or a POA (server-side), and leave the policy precedence rules as defined currently in CORBA for all policies. The rules that determine the policy in effect for a client invocation or for a POA are well-defined, are consistent across all policy types, and are easy to understand. I don't think anyone (vendors or users) would benefit from having these rules vary depending on the policy type. In case there is any confusion about these rules, my usual explanation of them is: client-side - Object reference level has precedence over thread level, which has precedence over ORB level. server-side - POA level has precedence over ORB level. In my opinion, any attempt to deviate from or modify these rules for a specific Policy type should require compelling justification. Consistent precedence rules are much easier for users to understand; and allow the ORB implementation to handle policy resolution generically, which reduces bugs and bloat. Is there any reason why the intended bi-dir semantics cannot be defined in terms of the effective policy values for client invocations and for POAs? -Bob Jishnu Mukerji wrote: Tom Rutt wrote: Upon a detailed analysis of the issues (attached) I now think that they are resolvable in a short amount of time, if people are willing. Issue 7353, 7356, and 7315 need further discussion. The proposed resolution for 7356 needs a little more work. The attached document contains my proposed modified version based on Tom's proposal. Basically we need to cover all cases for ORB level, thread level and object reference level overrides for all possible states of the connection. Jishnu. -------------------------------------------------------------------------------- My changes are in bold italic: Proposed resolution for Issue 7356: GIOP 1.4 connections have one of three states: CouldBecomeBiDir CannotBecomBiDir BiDir Rules: 1) A connection starts out with the state, CouldBecomeBidir 2) anytime 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 connection. Such an offer can be sent only if the connection over which it is sent is either in the CouldBecomeBiDir or BiDir state. 3) if the Offer policy at initiator orb level is DENY, then that orb will never send bidir Offers and the state of its connections will always be CouldBecomeBidir, unless a) the orb level DENY is overridden by ALLOW for one or more object references or one or more thread used for an invocation over the connection by the initiator orb. In that case a bidir Offer will be sent provided the state of the connection is CouldBecomeBiDir or BiDir. b) the orb level DENY is overridden by DENY for one or more object references or one or more thread used for an invocation over the connection by the initiator orb. In that case the invocation will be initiated provided the state of the connection is CouldBecomeBiDir or CannotBecomeBiDir and the state of the connection shall become CannotBecomeBiDir. 4) When the orb level offer policy is ALLOW, if any object reference which has client offer policy of DENY is invoked on by the initator or the thread used for the invocation has client offer policy of DENY, that invocation can only be carried on a connection which has state CouldBecomeBidir, or CannotBecomeBidir and after the invocation is initiated, the connection takes the state of CannotBecomeBidir 5) if any object reference or thread used in an invocation 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 using that thread, after which the state of the connnection permanantly becomes BiDir. Date: Mon, 07 Jun 2004 13:15:03 -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: "Robert A. Kukura" CC: Jishnu Mukerji , firewall-traversal-ftf@omg.org, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Bob: These rules are for the state of the connection ,not the policy. I am pretty sure that the overide principles for effective policyare in tact, however the state of the connection depends on what happens based on the effective policy and invocations on that connection. The current firewall spec is unclear on that. Tom Rutt Robert A. Kukura wrote: I'm not on the FTF and have not been following this discussion in detail, but would strongly recommend NOT trying to specify behavior of policies in terms of where they are applied (ORB, thread, object, and POA levels). Instead, please specify behavior in terms of the /*effective */policy value for an object invocation (client-side) or a POA (server-side), and leave the policy precedence rules as defined currently in CORBA for all policies. The rules that determine the policy in effect for a client invocation or for a POA are well-defined, are consistent across all policy types, and are easy to understand. I don't think anyone (vendors or users) would benefit from having these rules vary depending on the policy type. In case there is any confusion about these rules, my usual explanation of them is: * client-side - Object reference level has precedence over thread level, which has precedence over ORB level. * server-side - POA level has precedence over ORB level. In my opinion, any attempt to deviate from or modify these rules for a specific Policy type should require compelling justification. Consistent precedence rules are much easier for users to understand; and allow the ORB implementation to handle policy resolution generically, which reduces bugs and bloat. Is there any reason why the intended bi-dir semantics cannot be defined in terms of the effective policy values for client invocations and for POAs? -Bob Jishnu Mukerji wrote: Tom Rutt wrote: Upon a detailed analysis of the issues (attached) I now think that they are resolvable in a short amount of time, if people are willing. Issue 7353, 7356, and 7315 need further discussion. The proposed resolution for 7356 needs a little more work. The attached document contains my proposed modified version based on Tom's proposal. Basically we need to cover all cases for ORB level, thread level and object reference level overrides for all possible states of the connection. Jishnu. ------------------------------------------------------------------------ My changes are in bold italic: Proposed resolution for Issue 7356: GIOP 1.4 connections have one of three states: * CouldBecomeBiDir * CannotBecomBiDir * BiDir Rules: 1) A connection starts out with the state, CouldBecomeBidir 2) anytime 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 connection. Such an offer can be sent only if the connection over which it is sent is either in the CouldBecomeBiDir or BiDir state. 3) if the Offer policy at initiator orb level is DENY, then that orb will never send bidir Offers and the state of its connections will always be CouldBecomeBidir, unless a) the orb level DENY is overridden by ALLOW for one or more object references or one or more thread used for an invocation over the connection by the initiator orb. In that case a bidir Offer will be sent provided the state of the connection is CouldBecomeBiDir or BiDir. b) the orb level DENY is overridden by DENY for one or more object references or one or more thread used for an invocation over the connection by the initiator orb. In that case the invocation will be initiated provided the state of the connection is CouldBecomeBiDir or CannotBecomeBiDir and the state of the connection shall become CannotBecomeBiDir. 4) When the orb level offer policy is ALLOW, if any object reference which has client offer policy of DENY is invoked on by the initator or the thread used for the invocation has client offer policy of DENY, that invocation can only be carried on a connection which has state CouldBecomeBidir, or CannotBecomeBidir and after the invocation is initiated, the connection takes the state of CannotBecomeBidir 5) if any object reference or thread used in an invocation 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 using that thread, after which the state of the connnection permanantly becomes BiDir. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Subject: RE: Analysis of issue resolutions for firewall Date: Mon, 7 Jun 2004 13:44:19 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Analysis of issue resolutions for firewall Thread-Index: AcRMrfaMNM0u98cBSiuP3xKbWZ4m4AACDa6A From: "Bergersen, Rebecca" To: "Jishnu Mukerji" , "Tom Rutt" Cc: , "Andrew Watson" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i57HmVun010197 Tom, Jishnu - What these rules do not touch on is the creation of a new connection. Do you mean to imply that the establishment of all BiDir connections must be over existing connections? Secondly, while I agree with your modifications to Tom's proposal, Jishnu, do you really mean what you stated for 3b: "the orb level DENY is overridden by DENY for one or more object references ..."? Don't you mean the orb level DENY is overridden by ACCEPT? --Becky > -----Original Message----- > From: Jishnu Mukerji [mailto:jishnu@hp.com] > Sent: Monday, June 07, 2004 12:23 PM > To: Tom Rutt > Cc: firewall-traversal-ftf@omg.org; Andrew Watson > Subject: Re: Analysis of issue resolutions for firewall > > > Tom Rutt wrote: > > > Upon a detailed analysis of the issues (attached) I now think that > > they are resolvable > > in a short amount of time, if people are willing. > > > > Issue 7353, 7356, and 7315 need further discussion. > > > > > The proposed resolution for 7356 needs a little more work. > The attached > document contains my proposed modified version based on Tom's > proposal. > Basically we need to cover all cases for ORB level, thread level and > object reference level overrides for all possible states of > the connection. > > Jishnu. > > Subject: RE: Analysis of issue resolutions for firewall Date: Mon, 7 Jun 2004 10:56:03 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Analysis of issue resolutions for firewall Thread-Index: AcRMrfaMNM0u98cBSiuP3xKbWZ4m4AACDa6AAABWs2A= From: "Dave Stringer" To: "Bergersen, Rebecca" , "Jishnu Mukerji" , "Tom Rutt" Cc: , "Andrew Watson" X-OriginalArrivalTime: 07 Jun 2004 17:56:04.0329 (UTC) FILETIME=[B38D4590:01C44CB8] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i57I27un010512 Rebecca As far as the architecture of the *specification* (i.e. CORBA, A=Architecture) is concerned, I think rules that touch on connections - especially side-effects of API interactions like invoking an operation - have a profound significance to the exisiting principal that connection management is left to the implementation. Such rules may well have a profound impact on the architectire of an CORBA implementation. I think this is rather late in the day to be getting into this stuff. An "available" specification is supposed to have been implemented. Aspects of this specification clearly cannot have been implemented as they haven't been defined yet. These issues should have been sorted out in the earlier stages of the FTF so that claims to have implemented them would then be credible. Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, June 07, 2004 10:44 AM To: Jishnu Mukerji; Tom Rutt Cc: firewall-traversal-ftf@omg.org; Andrew Watson Subject: RE: Analysis of issue resolutions for firewall Tom, Jishnu - What these rules do not touch on is the creation of a new connection. Do you mean to imply that the establishment of all BiDir connections must be over existing connections? Date: Mon, 07 Jun 2004 13:59: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: "Robert A. Kukura" Cc: Tom Rutt , firewall-traversal-ftf@omg.org, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Bob, Good point. The added complication is what happens in NegotiateSession messages which can apparently occur spontaneously in the absence of explicit invocation on a specific object reference. I am still curious about whether the thread policy of the thread that is used for sending the NegotiateSession message overrides the ORB level ALLOW/DENY policy... What we effectively need to specify is a few state tables, e.g. at the initiator end when an invocation takes place over a object reference then: Connection state Effective policy Action CouldBecomeBiDir ALLOW Offer BiDir in invocation and if OK state -> BiDir CouldBecomeBiDir DENY do invocation and state -> CannotBecomeBiDir BiDir ALLOW Offer BiDir and do invocation BiDir DENY Invocation not allowed CannotBecomeBiDir ALLOW Invocation not allowed CannotBecomeBiDir DENY Invocation OK Or something of that sort together with the invariant rules: 1. If state is BiDir it cannot change to CannotBecomeBiDir or CouldBecomeBiDir 2. If state is CannotBecomeBiDir it cannot change to BiDir or CouldBecomeBiDir A similar table is needed for the NegotiateSession message from the initiator end and also one for the other end. Frankly my head starts spinning when I try to get all this straightened out and I really don;t have the time to work out the details of this. But the specification is quite ambiguous without these state tables I think. Jishnu. Robert A. Kukura wrote: I'm not on the FTF and have not been following this discussion in detail, but would strongly recommend NOT trying to specify behavior of policies in terms of where they are applied (ORB, thread, object, and POA levels). Instead, please specify behavior in terms of the /*effective */policy value for an object invocation (client-side) or a POA (server-side), and leave the policy precedence rules as defined currently in CORBA for all policies. The rules that determine the policy in effect for a client invocation or for a POA are well-defined, are consistent across all policy types, and are easy to understand. I don't think anyone (vendors or users) would benefit from having these rules vary depending on the policy type. In case there is any confusion about these rules, my usual explanation of them is: * client-side - Object reference level has precedence over thread level, which has precedence over ORB level. * server-side - POA level has precedence over ORB level. In my opinion, any attempt to deviate from or modify these rules for a specific Policy type should require compelling justification. Consistent precedence rules are much easier for users to understand; and allow the ORB implementation to handle policy resolution generically, which reduces bugs and bloat. Is there any reason why the intended bi-dir semantics cannot be defined in terms of the effective policy values for client invocations and for POAs? -Bob Jishnu Mukerji wrote: Tom Rutt wrote: Upon a detailed analysis of the issues (attached) I now think that they are resolvable in a short amount of time, if people are willing. Issue 7353, 7356, and 7315 need further discussion. The proposed resolution for 7356 needs a little more work. The attached document contains my proposed modified version based on Tom's proposal. Basically we need to cover all cases for ORB level, thread level and object reference level overrides for all possible states of the connection. Jishnu. ------------------------------------------------------------------------ My changes are in bold italic: Proposed resolution for Issue 7356: GIOP 1.4 connections have one of three states: * CouldBecomeBiDir * CannotBecomBiDir * BiDir Rules: 1) A connection starts out with the state, CouldBecomeBidir 2) anytime 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 connection. Such an offer can be sent only if the connection over which it is sent is either in the CouldBecomeBiDir or BiDir state. 3) if the Offer policy at initiator orb level is DENY, then that orb will never send bidir Offers and the state of its connections will always be CouldBecomeBidir, unless a) the orb level DENY is overridden by ALLOW for one or more object references or one or more thread used for an invocation over the connection by the initiator orb. In that case a bidir Offer will be sent provided the state of the connection is CouldBecomeBiDir or BiDir. b) the orb level DENY is overridden by DENY for one or more object references or one or more thread used for an invocation over the connection by the initiator orb. In that case the invocation will be initiated provided the state of the connection is CouldBecomeBiDir or CannotBecomeBiDir and the state of the connection shall become CannotBecomeBiDir. 4) When the orb level offer policy is ALLOW, if any object reference which has client offer policy of DENY is invoked on by the initator or the thread used for the invocation has client offer policy of DENY, that invocation can only be carried on a connection which has state CouldBecomeBidir, or CannotBecomeBidir and after the invocation is initiated, the connection takes the state of CannotBecomeBidir 5) if any object reference or thread used in an invocation 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 using that thread, after which the state of the connnection permanantly becomes BiDir. -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Management Software Organization Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Date: Mon, 07 Jun 2004 14:03:57 -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, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Bergersen, Rebecca wrote: Tom, Jishnu - What these rules do not touch on is the creation of a new connection. Do you mean to imply that the establishment of all BiDir connections must be over existing connections? Secondly, while I agree with your modifications to Tom's proposal, Jishnu, do you really mean what you stated for 3b: "the orb level DENY is overridden by DENY for one or more object references ..."? Don't you mean the orb level DENY is overridden by ACCEPT? --Becky I am not quite sure. The bottom line is that Tom's proposal has just scratched the surface. We need state tables for invocation message and NegotiateSession message for both the initiator and the other end. I was just trying to figure out what those would look like. As usual I might have got the initiator and the other end mixed up. Just goes to show the poor state of the specification and also the overloaded state of my mind. :) Jishnu. -----Original Message----- From: Jishnu Mukerji [mailto:jishnu@hp.com] Sent: Monday, June 07, 2004 12:23 PM To: Tom Rutt Cc: firewall-traversal-ftf@omg.org; Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Tom Rutt wrote: Upon a detailed analysis of the issues (attached) I now think that they are resolvable in a short amount of time, if people are willing. Issue 7353, 7356, and 7315 need further discussion. The proposed resolution for 7356 needs a little more work. The attached document contains my proposed modified version based on Tom's proposal. Basically we need to cover all cases for ORB level, thread level and object reference level overrides for all possible states of the connection. Jishnu. -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Management Software Organization Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Date: Mon, 07 Jun 2004 14:09:32 -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, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Bergersen, Rebecca wrote: Tom, Jishnu - What these rules do not touch on is the creation of a new connection. Do you mean to imply that the establishment of all BiDir connections must be over existing connections? Creation of a connection IMHO is an orthogonal issue for specifying the BiDir protocol state machine. All that one needs to say is that all connections are created in the state CanBecomeBiDir at both ends. Then the BiDir state issue reduces to one of establishment of BiDir connection over existing connections. After that you launch off the protocol state machines at both ends of the connection following the state transitions caused by specific events subject to the invariants specified. Frankly, I am quite dubious about being able to complete this. Jishnu. Date: Mon, 07 Jun 2004 17:40:01 -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, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Comments Inline Jishnu Mukerji wrote: Bergersen, Rebecca wrote: Tom, Jishnu - What these rules do not touch on is the creation of a new connection. Do you mean to imply that the establishment of all BiDir connections must be over existing connections? Creation of a connection IMHO is an orthogonal issue for specifying the BiDir protocol state machine. All that one needs to say is that all connections are created in the state CanBecomeBiDir at both ends. Then the BiDir state issue reduces to one of establishment of BiDir connection over existing connections. I agree After that you launch off the protocol state machines at both ends of the connection following the state transitions caused by specific events subject to the invariants specified. As Dave S stated, the state of this connection changes based on invocations of particular object references over that connection. This is a nightmare for connection managment, which needs to be justified. I am not sure the Bidir Security requirments are helped by this. All that happens is the initator starts a new connection with Bidir offer in Negotiate Session message, and it gets thru to the server. So what is the big deal about keeping that object reference with Deny on another more restricted connection. Are these rules, now that they have been clarified, warranted, or even useful? Tom Rutt Frankly, I am quite dubious about being able to complete this. Jishnu. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Mon, 07 Jun 2004 17:40:01 -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, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Comments Inline Jishnu Mukerji wrote: Bergersen, Rebecca wrote: Tom, Jishnu - What these rules do not touch on is the creation of a new connection. Do you mean to imply that the establishment of all BiDir connections must be over existing connections? Creation of a connection IMHO is an orthogonal issue for specifying the BiDir protocol state machine. All that one needs to say is that all connections are created in the state CanBecomeBiDir at both ends. Then the BiDir state issue reduces to one of establishment of BiDir connection over existing connections. I agree After that you launch off the protocol state machines at both ends of the connection following the state transitions caused by specific events subject to the invariants specified. As Dave S stated, the state of this connection changes based on invocations of particular object references over that connection. This is a nightmare for connection managment, which needs to be justified. I am not sure the Bidir Security requirments are helped by this. All that happens is the initator starts a new connection with Bidir offer in Negotiate Session message, and it gets thru to the server. So what is the big deal about keeping that object reference with Deny on another more restricted connection. Are these rules, now that they have been clarified, warranted, or even useful? Tom Rutt Frankly, I am quite dubious about being able to complete this. Jishnu. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Subject: RE: Analysis of issue resolutions for firewall Date: Mon, 7 Jun 2004 17:52:43 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Analysis of issue resolutions for firewall Thread-Index: AcRMu3C4SWpR6A7ETySfApQK5MGrMAAHiLjw From: "Bergersen, Rebecca" To: "Jishnu Mukerji" , "Robert A. Kukura" Cc: "Tom Rutt" , , "Andrew Watson" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i57Luwun014489 Hi! I've attached state charts for the connection acceptor side. My head hurts. --Becky > -----Original Message----- > From: Jishnu Mukerji [mailto:jishnu@hp.com] > Sent: Monday, June 07, 2004 2:00 PM > To: Robert A. Kukura > Cc: Tom Rutt; firewall-traversal-ftf@omg.org; Andrew Watson > Subject: Re: Analysis of issue resolutions for firewall > > > Bob, > > Good point. The added complication is what happens in > NegotiateSession > messages which can apparently occur spontaneously in the absence of > explicit invocation on a specific object reference. I am > still curious > about whether the thread policy of the thread that is used > for sending > the NegotiateSession message overrides the ORB level > ALLOW/DENY policy... > > What we effectively need to specify is a few state tables, > e.g. at the > initiator end when an invocation takes place over a object > reference then: > > Connection state Effective policy Action > > CouldBecomeBiDir ALLOW Offer BiDir in > invocation and > > if > OK state -> BiDir > > CouldBecomeBiDir DENY do invocation and > > state -> CannotBecomeBiDir > > BiDir ALLOW > Offer BiDir and > do invocation > > BiDir DENY > Invocation > not allowed > > CannotBecomeBiDir ALLOW Invocation not allowed > > CannotBecomeBiDir DENY Invocation OK > > Or something of that sort together with the invariant rules: > > 1. If state is BiDir it cannot change to CannotBecomeBiDir or > CouldBecomeBiDir > 2. If state is CannotBecomeBiDir it cannot change to BiDir or > CouldBecomeBiDir > > A similar table is needed for the NegotiateSession message from the > initiator end and also one for the other end. > > Frankly my head starts spinning when I try to get all this > straightened > out and I really don;t have the time to work out the details of this. > But the specification is quite ambiguous without these state > tables I think. > > Jishnu. > > > Robert A. Kukura wrote: > > > I'm not on the FTF and have not been following this discussion in > > detail, but would strongly recommend NOT trying to specify > behavior of > > policies in terms of where they are applied (ORB, thread, > object, and > > POA levels). Instead, please specify behavior in terms of the > > /*effective */policy value for an object invocation > (client-side) or a > > POA (server-side), and leave the policy precedence rules as defined > > currently in CORBA for all policies. The rules that determine the > > policy in effect for a client invocation or for a POA are > > well-defined, are consistent across all policy types, and > are easy to > > understand. I don't think anyone (vendors or users) would > benefit from > > having these rules vary depending on the policy type. > > > > In case there is any confusion about these rules, my usual > explanation > > of them is: > > > > * client-side - Object reference level has precedence > over thread > > level, which has precedence over ORB level. > > * server-side - POA level has precedence over ORB level. > > > > In my opinion, any attempt to deviate from or modify these > rules for a > > specific Policy type should require compelling justification. > > Consistent precedence rules are much easier for users to > understand; > > and allow the ORB implementation to handle policy resolution > > generically, which reduces bugs and bloat. > > > > Is there any reason why the intended bi-dir semantics cannot be > > defined in terms of the effective policy values for client > invocations > > and for POAs? > > > > -Bob > > > > Jishnu Mukerji wrote: > > > >> Tom Rutt wrote: > >> > >>> Upon a detailed analysis of the issues (attached) I now > think that > >>> they are resolvable > >>> in a short amount of time, if people are willing. > >>> > >>> Issue 7353, 7356, and 7315 need further discussion. > >>> > >>> > >> The proposed resolution for 7356 needs a little more work. The > >> attached document contains my proposed modified version based on > >> Tom's proposal. Basically we need to cover all cases for > ORB level, > >> thread level and object reference level overrides for all possible > >> states of the connection. > >> > >> Jishnu. > >> > >> > >> > -------------------------------------------------------------- > ---------- > >> > >> My changes are in bold italic: > >> > >> Proposed resolution for Issue 7356: > >> > >> GIOP 1.4 connections have one of three states: > >> > >> * CouldBecomeBiDir > >> * CannotBecomBiDir > >> * BiDir > >> > >> Rules: > >> > >> 1) A connection starts out with the state, CouldBecomeBidir > >> > >> 2) anytime 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 connection. Such an offer can be sent only if the > connection > >> over which it is sent is either in the CouldBecomeBiDir or > BiDir state. > >> > >> 3) if the Offer policy at initiator orb level is DENY, > then that orb > >> will never send bidir Offers and the state of its connections will > >> always be CouldBecomeBidir, unless > >> > >> a) the orb level DENY is overridden by ALLOW for one or > more object > >> references or one or more thread used for an invocation over the > >> connection by the initiator orb. In that case a bidir > Offer will be > >> sent provided the state of the connection is > CouldBecomeBiDir or BiDir. > >> > >> b) the orb level DENY is overridden by DENY for one or more object > >> references or one or more thread used for an invocation over the > >> connection by the initiator orb. In that case the > invocation will be > >> initiated provided the state of the connection is > CouldBecomeBiDir or > >> CannotBecomeBiDir and the state of the connection shall become > >> CannotBecomeBiDir. > >> > >> 4) When the orb level offer policy is ALLOW, if any object > reference > >> which has client offer policy of DENY is invoked on by the > initator > >> or the thread used for the invocation has client offer policy of > >> DENY, that invocation can only be carried on a connection > which has > >> state CouldBecomeBidir, or CannotBecomeBidir and after the > invocation > >> is initiated, the connection takes the state of CannotBecomeBidir > >> > >> 5) if any object reference or thread used in an invocation > 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 using that thread, after which the state of the > connnection > >> permanantly becomes BiDir. > >> > >> > >> > >> > > > -- > Jishnu Mukerji > Senior Systems Architect 1001 Frontier Road, Suite 300 > Technology Office Bridgewater NJ 08807, USA > Management Software Organization Tel: +1 908 243 8924 > Hewlett-Packard Company Fax: +1 908 243 8850 > mailto: jishnu@hp.com > > > Date: Mon, 07 Jun 2004 18:06: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 To: Tom Rutt CC: Jishnu Mukerji , "Bergersen, Rebecca" , firewall-traversal-ftf@omg.org, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Take the example: Initiator ORB A has allow offer policy, object ref B1 (which is served by acceptor ORB B) overrides offer policy to Deny. - Now all these rules will ensure is that no invocation on object B1 will occur on a Bidir connection. However if any non overrideden object on B was invoked, it would cause a Bidir connection to be given to the acceptor to use for its heart's content. What is the security feature here? Take another example: Initiator ORB A has DENY offer policy, object ref B2 (which is served by acceptor ORB B) overrides offer policy to ACCEPT. - Now all these rules will ensure is that invocation on object B2 will occur on a Bidir connection, while all non overriden object reference served by ORB B will be restricted to CannotBecomeBidir Connection.. Again , this single bidir connection resulting from an invocation on B2 by the initiator gives the acceptor a Bidir connection to use to its hearts content. What security feature is served by this behaviour? Tom Rutt Tom Rutt wrote: Comments Inline Jishnu Mukerji wrote: Bergersen, Rebecca wrote: Tom, Jishnu - What these rules do not touch on is the creation of a new connection. Do you mean to imply that the establishment of all BiDir connections must be over existing connections? Creation of a connection IMHO is an orthogonal issue for specifying the BiDir protocol state machine. All that one needs to say is that all connections are created in the state CanBecomeBiDir at both ends. Then the BiDir state issue reduces to one of establishment of BiDir connection over existing connections. I agree After that you launch off the protocol state machines at both ends of the connection following the state transitions caused by specific events subject to the invariants specified. As Dave S stated, the state of this connection changes based on invocations of particular object references over that connection. This is a nightmare for connection managment, which needs to be justified. I am not sure the Bidir Security requirments are helped by this. All that happens is the initator starts a new connection with Bidir offer in Negotiate Session message, and it gets thru to the server. So what is the big deal about keeping that object reference with Deny on another more restricted connection. Are these rules, now that they have been clarified, warranted, or even useful? Tom Rutt Frankly, I am quite dubious about being able to complete this. Jishnu. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Subject: RE: Analysis of issue resolutions for firewall Date: Mon, 7 Jun 2004 18:12:44 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Analysis of issue resolutions for firewall Thread-Index: AcRM2AZiH4v5XwtjSyu97jcCHgCowQAA5LzQ From: "Bergersen, Rebecca" To: "Tom Rutt" , "Jishnu Mukerji" Cc: , "Andrew Watson" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i57MGwun014621 Comments inline --Becky > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Monday, June 07, 2004 5:40 PM > To: Jishnu Mukerji > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org; Andrew Watson > Subject: Re: Analysis of issue resolutions for firewall > > > Comments Inline > > Jishnu Mukerji wrote: > > > Bergersen, Rebecca wrote: > > > >> Tom, Jishnu - > >> > >> What these rules do not touch on is the creation of a new > >> connection. Do you mean to imply that the establishment > of all BiDir > >> connections must be over existing connections? > >> > >> > > > > Creation of a connection IMHO is an orthogonal issue for specifying > > the BiDir protocol state machine. All that one needs to say is that > > all connections are created in the state CanBecomeBiDir at > both ends. > > Then the BiDir state issue reduces to one of establishment of BiDir > > connection over existing connections. > > I agree > > > > > After that you launch off the protocol state machines at > both ends of > > the connection following the state transitions caused by specific > > events subject to the invariants specified. > > As Dave S stated, the state of this connection changes based on > invocations of particular object references > over that connection. This is a nightmare for connection managment, > which needs to be justified. > > I am not sure the Bidir Security requirments are helped by this. All > that happens is the initator starts a new > connection with Bidir offer in Negotiate Session message, and it gets > thru to the server. So what is the big deal > about keeping that object reference with Deny on another more > restricted > connection. > >From an app's point of view, the only thing that allows a new connection to be created is invocation on an object. Even then, the app has no direct control except to keep it from happening. If the object has an effective policy of Offer=DENY, then no new connection will be created. As far as I can tell, the only time a new connection would be created is when there is no acceptable connection available to (re)use and the effective policy on the object being invoked is Offer=ALLOW. > Are these rules, now that they have been clarified, > warranted, or even > useful? > > Tom Rutt > > > > > Frankly, I am quite dubious about being able to complete this. > > > > Jishnu. > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > Date: Mon, 07 Jun 2004 18:17:30 -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: Tom Rutt Cc: "Bergersen, Rebecca" , firewall-traversal-ftf@omg.org, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Tom Rutt wrote: Comments Inline Jishnu Mukerji wrote: Bergersen, Rebecca wrote: Tom, Jishnu - What these rules do not touch on is the creation of a new connection. Do you mean to imply that the establishment of all BiDir connections must be over existing connections? Creation of a connection IMHO is an orthogonal issue for specifying the BiDir protocol state machine. All that one needs to say is that all connections are created in the state CanBecomeBiDir at both ends. Then the BiDir state issue reduces to one of establishment of BiDir connection over existing connections. I agree After that you launch off the protocol state machines at both ends of the connection following the state transitions caused by specific events subject to the invariants specified. As Dave S stated, the state of this connection changes based on invocations of particular object references over that connection. This is a nightmare for connection managment, which needs to be justified. I am not sure the Bidir Security requirments are helped by this. All that happens is the initator starts a new connection with Bidir offer in Negotiate Session message, and it gets thru to the server. So what is the big deal about keeping that object reference with Deny on another more restricted connection. Are these rules, now that they have been clarified, warranted, or even useful? Tom Rutt Actually, I am not particularly enamored of this set of rules. It is possible to come up with a simpler set of rules. But we need to nail down some internally and mutually consistent set of rules in the specification and standard. A simplified way of doing things might be (as Tom suggests) to setup the connection with the right level of BiDir based on the first invocation on that connection and let connection type then be frozen for the life of the connection. If there is the requirement to do an invocation with another sort of BiDir then setup a new connection with that sort of BiDir etc. But then that removes certain possibilities of connection reuse. The tradeoff as usual is between protocol complexity and level of reuse of facilities. As long as one of the modes of the connection is "no session negotiated" :) I am perfectly happy with any other baroque schemes that anyone comes up with for the other cases as long as they are fully specified. Jishnu. Subject: RE: Analysis of issue resolutions for firewall Date: Mon, 7 Jun 2004 18:49:25 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Analysis of issue resolutions for firewall Thread-Index: AcRMu3C4SWpR6A7ETySfApQK5MGrMAAJhtlg From: "Bergersen, Rebecca" To: "Jishnu Mukerji" , "Robert A. Kukura" Cc: "Tom Rutt" , , "Andrew Watson" The state charts for the requestor side are attached. (really ;-) --Becky > -----Original Message----- > From: Jishnu Mukerji [mailto:jishnu@hp.com] > Sent: Monday, June 07, 2004 2:00 PM > To: Robert A. Kukura > Cc: Tom Rutt; firewall-traversal-ftf@omg.org; Andrew Watson > Subject: Re: Analysis of issue resolutions for firewall > > > Bob, > > Good point. The added complication is what happens in > NegotiateSession > messages which can apparently occur spontaneously in the absence of > explicit invocation on a specific object reference. I am > still curious > about whether the thread policy of the thread that is used > for sending > the NegotiateSession message overrides the ORB level > ALLOW/DENY policy... > > What we effectively need to specify is a few state tables, > e.g. at the > initiator end when an invocation takes place over a object > reference then: > > Connection state Effective policy Action > > CouldBecomeBiDir ALLOW Offer BiDir in > invocation and > > if > OK state -> BiDir > > CouldBecomeBiDir DENY do invocation and > > state -> CannotBecomeBiDir > > BiDir ALLOW > Offer BiDir and > do invocation > > BiDir DENY > Invocation > not allowed > > CannotBecomeBiDir ALLOW Invocation not allowed > > CannotBecomeBiDir DENY Invocation OK > > Or something of that sort together with the invariant rules: > > 1. If state is BiDir it cannot change to CannotBecomeBiDir or > CouldBecomeBiDir > 2. If state is CannotBecomeBiDir it cannot change to BiDir or > CouldBecomeBiDir > > A similar table is needed for the NegotiateSession message from the > initiator end and also one for the other end. > > Frankly my head starts spinning when I try to get all this > straightened > out and I really don;t have the time to work out the details of this. > But the specification is quite ambiguous without these state > tables I think. > > Jishnu. > > > Robert A. Kukura wrote: > > > I'm not on the FTF and have not been following this discussion in > > detail, but would strongly recommend NOT trying to specify > behavior of > > policies in terms of where they are applied (ORB, thread, > object, and > > POA levels). Instead, please specify behavior in terms of the > > /*effective */policy value for an object invocation > (client-side) or a > > POA (server-side), and leave the policy precedence rules as defined > > currently in CORBA for all policies. The rules that determine the > > policy in effect for a client invocation or for a POA are > > well-defined, are consistent across all policy types, and > are easy to > > understand. I don't think anyone (vendors or users) would > benefit from > > having these rules vary depending on the policy type. > > > > In case there is any confusion about these rules, my usual > explanation > > of them is: > > > > * client-side - Object reference level has precedence > over thread > > level, which has precedence over ORB level. > > * server-side - POA level has precedence over ORB level. > > > > In my opinion, any attempt to deviate from or modify these > rules for a > > specific Policy type should require compelling justification. > > Consistent precedence rules are much easier for users to > understand; > > and allow the ORB implementation to handle policy resolution > > generically, which reduces bugs and bloat. > > > > Is there any reason why the intended bi-dir semantics cannot be > > defined in terms of the effective policy values for client > invocations > > and for POAs? > > > > -Bob > > > > Jishnu Mukerji wrote: > > > >> Tom Rutt wrote: > >> > >>> Upon a detailed analysis of the issues (attached) I now > think that > >>> they are resolvable > >>> in a short amount of time, if people are willing. > >>> > >>> Issue 7353, 7356, and 7315 need further discussion. > >>> > >>> > >> The proposed resolution for 7356 needs a little more work. The > >> attached document contains my proposed modified version based on > >> Tom's proposal. Basically we need to cover all cases for > ORB level, > >> thread level and object reference level overrides for all possible > >> states of the connection. > >> > >> Jishnu. > >> > >> > >> > -------------------------------------------------------------- > ---------- > >> > >> My changes are in bold italic: > >> > >> Proposed resolution for Issue 7356: > >> > >> GIOP 1.4 connections have one of three states: > >> > >> * CouldBecomeBiDir > >> * CannotBecomBiDir > >> * BiDir > >> > >> Rules: > >> > >> 1) A connection starts out with the state, CouldBecomeBidir > >> > >> 2) anytime 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 connection. Such an offer can be sent only if the > connection > >> over which it is sent is either in the CouldBecomeBiDir or > BiDir state. > >> > >> 3) if the Offer policy at initiator orb level is DENY, > then that orb > >> will never send bidir Offers and the state of its connections will > >> always be CouldBecomeBidir, unless > >> > >> a) the orb level DENY is overridden by ALLOW for one or > more object > >> references or one or more thread used for an invocation over the > >> connection by the initiator orb. In that case a bidir > Offer will be > >> sent provided the state of the connection is > CouldBecomeBiDir or BiDir. > >> > >> b) the orb level DENY is overridden by DENY for one or more object > >> references or one or more thread used for an invocation over the > >> connection by the initiator orb. In that case the > invocation will be > >> initiated provided the state of the connection is > CouldBecomeBiDir or > >> CannotBecomeBiDir and the state of the connection shall become > >> CannotBecomeBiDir. > >> > >> 4) When the orb level offer policy is ALLOW, if any object > reference > >> which has client offer policy of DENY is invoked on by the > initator > >> or the thread used for the invocation has client offer policy of > >> DENY, that invocation can only be carried on a connection > which has > >> state CouldBecomeBidir, or CannotBecomeBidir and after the > invocation > >> is initiated, the connection takes the state of CannotBecomeBidir > >> > >> 5) if any object reference or thread used in an invocation > 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 using that thread, after which the state of the > connnection > >> permanantly becomes BiDir. > >> > >> > >> > >> > > > -- > Jishnu Mukerji > Senior Systems Architect 1001 Frontier Road, Suite 300 > Technology Office Bridgewater NJ 08807, USA > Management Software Organization Tel: +1 908 243 8924 > Hewlett-Packard Company Fax: +1 908 243 8850 > mailto: jishnu@hp.com > > > requestor_states.txt Date: Mon, 07 Jun 2004 19:03:00 -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: Jishnu Mukerji , firewall-traversal-ftf@omg.org, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Bergersen, Rebecca wrote: Comments inline --Becky As Dave S stated, the state of this connection changes based on invocations of particular object references over that connection. This is a nightmare for connection managment, which needs to be justified. I am not sure the Bidir Security requirments are helped by this. All that happens is the initator starts a new connection with Bidir offer in Negotiate Session message, and it gets thru to the server. So what is the big deal about keeping that object reference with Deny on another more restricted connection. From an app's point of view, the only thing that allows a new connection to be created is invocation on an object. Even then, the app has no direct control except to keep it from happening. If the object has an effective policy of Offer=DENY, then no new connection will be created. As far as I can tell, the only time a new connection would be created is when there is no acceptable connection available to (re)use and the effective policy on the object being invoked is Offer=ALLOW. I am confused by this statement. Offer policy of DENY on the object reference only means that a new "Cannot become Bidir" connection is established by the Connection Initator to use for that and other objects which have DENY offer policy enabled. Are these rules, now that they have been clarified, warranted, or even useful? Tom Rutt Frankly, I am quite dubious about being able to complete this. 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 Subject: RE: Analysis of issue resolutions for firewall Date: Mon, 7 Jun 2004 19:16:28 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Analysis of issue resolutions for firewall Thread-Index: AcRM451r1hkfxn8mQzCenCaGhy98YwAANl+A From: "Bergersen, Rebecca" To: "Tom Rutt" Cc: "Jishnu Mukerji" , , "Andrew Watson" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i57NKgun014933 Inline... > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Monday, June 07, 2004 7:03 PM > To: Bergersen, Rebecca > Cc: Jishnu Mukerji; firewall-traversal-ftf@omg.org; Andrew Watson > Subject: Re: Analysis of issue resolutions for firewall > > > > > Bergersen, Rebecca wrote: > > >Comments inline > > > > --Becky > > > > > > > >> > >>As Dave S stated, the state of this connection changes based on > >>invocations of particular object references > >>over that connection. This is a nightmare for connection > managment, > >>which needs to be justified. > >> > >>I am not sure the Bidir Security requirments are helped by > this. All > >>that happens is the initator starts a new > >>connection with Bidir offer in Negotiate Session message, > and it gets > >>thru to the server. So what is the big deal > >>about keeping that object reference with Deny on another more > >>restricted > >>connection. > >> > >> > >> > > > >>From an app's point of view, the only thing that allows a > new connection to be created is invocation on an object. > Even then, the app has no direct control except to keep it > from happening. If the object has an effective policy of > Offer=DENY, then no new connection will be created. As far > as I can tell, the only time a new connection would be > created is when there is no acceptable connection available > to (re)use and the effective policy on the object being > invoked is Offer=ALLOW. > > > > > I am confused by this statement. Offer policy of DENY on the object > reference only means that > a new "Cannot become Bidir" connection is established by the > Connection > Initator to use for that > and other objects which have DENY offer policy enabled. Why would a NEW "Cannot become BiDir" connection be established if there isn't one already? If a unidirectional connection is available, why not label it as "Cannot become BiDir" and just use it? All other policies being equal (security, etc.), this doesn't change anything for non-bi-directional invocations that might have already been using the connection. However, I would agree that a new connection is created if there isn't a unidirectional connection already in existance that could be used. > > > > > > > >>Are these rules, now that they have been clarified, > >>warranted, or even > >>useful? > >> > >>Tom Rutt > >> > >> > >> > >>>Frankly, I am quite dubious about being able to complete this. > >>> > >>>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: Mon, 07 Jun 2004 20:26:12 -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, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall another way to fix is to not allow object ref level overide of offer policy. It should only be a switch at the orb or thread level (this is much simpler) Tom Rutt Jishnu Mukerji wrote: Tom Rutt wrote: Comments Inline Jishnu Mukerji wrote: Bergersen, Rebecca wrote: Tom, Jishnu - What these rules do not touch on is the creation of a new connection. Do you mean to imply that the establishment of all BiDir connections must be over existing connections? Creation of a connection IMHO is an orthogonal issue for specifying the BiDir protocol state machine. All that one needs to say is that all connections are created in the state CanBecomeBiDir at both ends. Then the BiDir state issue reduces to one of establishment of BiDir connection over existing connections. I agree After that you launch off the protocol state machines at both ends of the connection following the state transitions caused by specific events subject to the invariants specified. As Dave S stated, the state of this connection changes based on invocations of particular object references over that connection. This is a nightmare for connection managment, which needs to be justified. I am not sure the Bidir Security requirments are helped by this. All that happens is the initator starts a new connection with Bidir offer in Negotiate Session message, and it gets thru to the server. So what is the big deal about keeping that object reference with Deny on another more restricted connection. Are these rules, now that they have been clarified, warranted, or even useful? Tom Rutt Actually, I am not particularly enamored of this set of rules. It is possible to come up with a simpler set of rules. But we need to nail down some internally and mutually consistent set of rules in the specification and standard. A simplified way of doing things might be (as Tom suggests) to setup the connection with the right level of BiDir based on the first invocation on that connection and let connection type then be frozen for the life of the connection. If there is the requirement to do an invocation with another sort of BiDir then setup a new connection with that sort of BiDir etc. But then that removes certain possibilities of connection reuse. The tradeoff as usual is between protocol complexity and level of reuse of facilities. As long as one of the modes of the connection is "no session negotiated" :) I am perfectly happy with any other baroque schemes that anyone comes up with for the other cases as long as they are fully specified. Jishnu. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Mon, 07 Jun 2004 20:36:52 -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: Jishnu Mukerji , firewall-traversal-ftf@omg.org, Andrew Watson Subject: Re: Analysis of issue resolutions for firewall Bergersen, Rebecca wrote: Inline... From an app's point of view, the only thing that allows a new connection to be created is invocation on an object. Even then, the app has no direct control except to keep it from happening. If the object has an effective policy of Offer=DENY, then no new connection will be created. As far as I can tell, the only time a new connection would be created is when there is no acceptable connection available to (re)use and the effective policy on the object being invoked is Offer=ALLOW. I am confused by this statement. Offer policy of DENY on the object reference only means that a new "Cannot become Bidir" connection is established by the Connection Initator to use for that and other objects which have DENY offer policy enabled. Why would a NEW "Cannot become BiDir" connection be established if there isn't one already? If a unidirectional connection is available, why not label it as "Cannot become BiDir" and just use it? All other policies being equal (security, etc.), this doesn't change anything for non-bi-directional invocations that might have already been using the connection. However, I would agree that a new connection is created if there isn't a unidirectional connection already in existance that could be used. What is a unidirectional connection? I would like to differentiate :canBecomeBidir, from cannotBecomeBidir. If the offer policy id DENY for an oref, then it cannot go on a BIDIR state connection, and whether or not the Initiator orb wants to use a connection which was CanBecomeBidir before the invocation, it is CannotBecomeBidir after. The point is in the case of orb level policy of ALLOW, with object ref overide for DENY, will result in two types of connection being set up, one type which is cannotBeBidir and the other type which is Bidir (for the orefs which were not overriden and have effective offer policy of ALLOW) -- ---------------------------------------------------- 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 -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Subject: RE: Analysis of issue resolutions for firewall Date: Tue, 8 Jun 2004 10:42:28 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Analysis of issue resolutions for firewall Thread-Index: AcRM8LwCKAqFectjQb+RLMW9RGMcdgAdcB4g From: "Bergersen, Rebecca" To: "Tom Rutt" Cc: "Jishnu Mukerji" , , "Andrew Watson" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i58Ekmun021034 > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Monday, June 07, 2004 8:37 PM > To: Bergersen, Rebecca > Cc: Jishnu Mukerji; firewall-traversal-ftf@omg.org; Andrew Watson > Subject: Re: Analysis of issue resolutions for firewall > > > > > Bergersen, Rebecca wrote: > > >Inline... > > > > > > > >>>> > >>>> > >>>>From an app's point of view, the only thing that allows a > >>> > >>> > >>new connection to be created is invocation on an object. > >>Even then, the app has no direct control except to keep it > >>from happening. If the object has an effective policy of > >>Offer=DENY, then no new connection will be created. As far > >>as I can tell, the only time a new connection would be > >>created is when there is no acceptable connection available > >>to (re)use and the effective policy on the object being > >>invoked is Offer=ALLOW. > >> > >> > >>> > >>> > >>> > >>> > >>I am confused by this statement. Offer policy of DENY on > the object > >>reference only means that > >>a new "Cannot become Bidir" connection is established by the > >>Connection > >>Initator to use for that > >>and other objects which have DENY offer policy enabled. > >> > >> > > > >Why would a NEW "Cannot become BiDir" connection be > established if there isn't one already? If a unidirectional > connection is available, why not label it as "Cannot become > BiDir" and just use it? All other policies being equal > (security, etc.), this doesn't change anything for > non-bi-directional invocations that might have already been > using the connection. > > > >However, I would agree that a new connection is created if > there isn't a unidirectional connection already in existance > that could be used. > > > > > What is a unidirectional connection? > A plain old ordinary everyday normal GIOP connection. Invocations go oneway only over it, from initiator to acceptor. > I would like to differentiate :canBecomeBidir, from > cannotBecomeBidir. > If the offer policy id DENY for > an oref, then it cannot go on a BIDIR state connection, and > whether or > not the Initiator orb wants to > use a connection which was CanBecomeBidir before the > invocation, it is > CannotBecomeBidir after. > > The point is in the case of orb level policy of ALLOW, with > object ref > overide for DENY, will result > in two types of connection being set up, one type which is > cannotBeBidir > and the other type which is Bidir (for > the orefs which were not overriden and have effective offer > policy of ALLOW) > Okay - I have no problem with this. > > > > > > > >> > >> > >>>>> > >>>>> > >>>>-- > >>>>---------------------------------------------------- > >>>>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 > >> > >> > >> > >> > >> > >> > > > > > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > >