Issue 2461: question re BiDir IIOP (firewall-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: I am having difficulty understanding the intended use of BiDirPolicy::BidirectionalPolicy. This is described (in section 15.9) as a POA policy to be passed to create_POA. That section also says that both client and server must have the policy with the value of BOTH for bi-directional communication to take place. My problem is that I don"t see how this policy applies to a particular POA. Once bi-directional communication has been negotiated on a connection, it applies to any request targetted at the negotiated address(es), regardless of what POA is the recipient of the request. Nor is it tied to the lifetime of a particular POA. And, what is supposed to happen if one POA has the policy with value BOTH, and another POA has the policy with value NORMAL? Resolution: :BidirectionalPolicy. This is described (in section 15.9) as Revised Text: Actions taken: February 19, 1999: received issue March 22, 2000: closed issue Discussion: End of Annotations:===== Date: Fri, 19 Feb 1999 09:39:57 -0500 From: Paul H Kyzivat Organization: NobleNet To: CORE RTF , interop@omg.org Subject: question re BiDir IIOP I am not sure if this is an issue or a question, or who is responsible for it... I am having difficulty understanding the intended use of BiDirPolicy::BidirectionalPolicy. This is described (in section 15.9) as a POA policy to be passed to create_POA. That section also says that both client and server must have the policy with the value of BOTH for bi-directional communication to take place. My problem is that I don't see how this policy applies to a particular POA. Once bi-directional communication has been negotiated on a connection, it applies to any request targetted at the negotiated address(es), regardless of what POA is the recipient of the request. Nor is it tied to the lifetime of a particular POA. And, what is supposed to happen if one POA has the policy with value BOTH, and another POA has the policy with value NORMAL? My suspicion is that this should be an ORB level policy, assigned to the ORB's PolicyManager, rather than a POA policy. I also have a related question regarding section 15.8.1. It states: "If a client has not set up any mechanism for traditional-style callbacks using a listening socket, then the port entry in its IOR must be set to the outgoing connection's local port. ... The port in the BI_DIR_IIOP structure must match this value." This presents some interesting problems: - suppose I create a reference, and then pass it to two different servers, in each case over a BiDir connection. Am I supposed to marshal the same reference with a different address on each connection? - if I do this, and subsequently the connection is dropped, is the server holding my address supposed to know to invalidate it? Once the connection is dropped, the OS may reassign the port for another purpose. If the server holding the reference then tries to establish a new connection, it may get the wrong server. But it doesn't know the address is special and should be tied to the life of the connection. - what should happen if I attempt to pass the reference over a connection where BiDir support has not been successfully negotiated? In the absence of a durable address, it seems that the reference should only be permitted to be marshalled on a connection that has negotiated BiDir support. - what is the orb supposed to do if the reference is passed to object_to_string? Should this be an error? What error? What about marshalling into an encapsulation? From: "Martin Chapman" To: "Paul H Kyzivat" , "CORE RTF" , Subject: RE: question re BiDir IIOP Date: Fri, 19 Feb 1999 15:59:11 -0000 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal paul, bidiriiop was done in the firewall spec. I have cached out that spec in my head, so need a little time to rethink this. However, it's not clear to me if this should be done in the core/interop rtf or the firewall rtf - Tom do you have a view on this. Martin. > -----Original Message----- > From: Paul H Kyzivat [mailto:paulk@noblenet.com] > Sent: 19 February 1999 14:40 > To: CORE RTF; interop@omg.org > Subject: question re BiDir IIOP > > > I am not sure if this is an issue or a question, or who is > responsible > for it... > > I am having difficulty understanding the intended use of > BiDirPolicy::BidirectionalPolicy. This is described (in section > 15.9) as > a POA policy to be passed to create_POA. That section also says that > both client and server must have the policy with the value of BOTH > for > bi-directional communication to take place. > > My problem is that I don't see how this policy applies to a > particular > POA. Once bi-directional communication has been negotiated on a > connection, it applies to any request targetted at the negotiated > address(es), regardless of what POA is the recipient of the > request. Nor > is it tied to the lifetime of a particular POA. And, what is > supposed to > happen if one POA has the policy with value BOTH, and another POA > has > the policy with value NORMAL? > > My suspicion is that this should be an ORB level policy, assigned to > the > ORB's PolicyManager, rather than a POA policy. > > I also have a related question regarding section 15.8.1. It states: > "If a client has not set up any mechanism for traditional-style > callbacks using a listening socket, then the port entry in its IOR > must > be set to the outgoing connection's local port. ... The port in the > BI_DIR_IIOP structure must match this value." > > This presents some interesting problems: > > - suppose I create a reference, and then pass it to two different > servers, in each case over a BiDir connection. Am I supposed to > marshal the same reference with a different address on each > connection? > > - if I do this, and subsequently the connection is dropped, is the > server holding my address supposed to know to invalidate it? > Once the connection is dropped, the OS may reassign the port for > another purpose. If the server holding the reference then tries > to establish a new connection, it may get the wrong server. But > it doesn't know the address is special and should be tied to the > life of the connection. > > - what should happen if I attempt to pass the reference over a > connection where BiDir support has not been successfully > negotiated? In the absence of a durable address, it seems > that the reference should only be permitted to be marshalled > on a connection that has negotiated BiDir support. > > - what is the orb supposed to do if the reference is passed to > object_to_string? Should this be an error? What error? What > about marshalling into an encapsulation? Sender: jis@fpk.hp.com Date: Fri, 19 Feb 1999 11:40:39 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Martin Chapman CC: Paul H Kyzivat , CORE RTF , interop@omg.org Subject: Re: question re BiDir IIOP References: <000601be5c20$ca3f2f80$c4f43ccf@chaplin.dublin.iona.ie> > paul, > > bidiriiop was done in the firewall spec. I have cached out that spec > in my > head, so need a little time to rethink this. However, it's not clear > to me > if this should be done in the core/interop rtf or the firewall rtf - > Tom do > you have a view on this. > > Martin. Ah, yet another one of these logisitical nightmares, where the text is controlled by one RTF but the semantics of the text is controlled by another.:-) The process that I am trying to put in place between Core RTF and Interop RTF is that when there is a Core RTF issue that impacts the Interop chapter, I do an issue resolution in the Core RTF with full proposed text changes etc. even for the interop chapter and send that proposed text over to the Interop RTF with a recommendation to accept it there. This works for non-controversial things. For controversial things it is going to be an interesting trip though.:-) Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Fri, 19 Feb 1999 17:22:07 -0500 From: Paul H Kyzivat Organization: NobleNet To: issues@omg.org CC: firewall_rtf@omg.org Subject: Question re BiDir IIOP (Juergen - I was told this should be directed to the firewall_rtf.) Two questions/issues regarding BiDirectional IIOP: (1) I am having difficulty understanding the intended use of BiDirPolicy::BidirectionalPolicy. This is described (in section 15.9) as a POA policy to be passed to create_POA. That section also says that both client and server must have the policy with the value of BOTH for bi-directional communication to take place. My problem is that I don't see how this policy applies to a particular POA. Once bi-directional communication has been negotiated on a connection, it applies to any request targetted at the negotiated address(es), regardless of what POA is the recipient of the request. Nor is it tied to the lifetime of a particular POA. And, what is supposed to happen if one POA has the policy with value BOTH, and another POA has the policy with value NORMAL? My suspicion is that this should be an ORB level policy, assigned to the ORB's PolicyManager, rather than a POA policy. (2) Section 15.8.1. It states: "If a client has not set up any mechanism for traditional-style callbacks using a listening socket, then the port entry in its IOR must be set to the outgoing connection's local port. ... The port in the BI_DIR_IIOP structure must match this value." This presents some interesting problems: - suppose I create a reference, and then pass it to two different servers, in each case over a BiDir connection. Am I supposed to marshal the same reference with a different address on each connection? - if I do this, and subsequently the connection is dropped, is the server holding my address supposed to know to invalidate it? Once the connection is dropped, the OS may reassign the port for another purpose. If the server holding the reference then tries to establish a new connection, it may get the wrong server. But it doesn't know the address is special and should be tied to the life of the connection. - what should happen if I attempt to pass the reference over a connection where BiDir support has not been successfully negotiated? In the absence of a durable address, it seems that the reference should only be permitted to be marshalled on a connection that has negotiated BiDir support. - what is the orb supposed to do if the reference is passed to object_to_string? Should this be an error? What error? What about marshalling into an encapsulation? Date: Mon, 22 Feb 1999 16:35:04 PST Sender: Bill Janssen From: Bill Janssen To: CORE RTF , interop@omg.org, Paul H Kyzivat Subject: Re: question re BiDir IIOP References: <36CD77BD.F3E3DC39@noblenet.com> The first issue is Core; the second is Interop, IMO. Bill Date: Thu, 06 May 1999 10:07:18 +0100 From: Owen Rees To: OMG Issues , OMG Firewall RTF , OMG interop RTF Subject: Issue 2461 should move to interop from firewall Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline Issue 2461: question re BiDir IIOP Given Jishnu's point about Bi-Directional GIOP being in Chapter 15, and Interop controlling this chapter, I think issue 2461 belongs there. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Date: Thu, 06 May 1999 14:27:22 +0100 From: Owen Rees To: Paul H Kyzivat , Martin Chapman cc: jon@floorboard.com, Bill Janssen , Polar Humenn , Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Issue 2461 (was Re: Bi-Directional GIOP: which connections may be used?) Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline --On 06 May 1999, 08:08 -0400 Paul H Kyzivat wrote: > I posted another issue on more or less the same point several months > ago, but have yet to get a response to it. That issue explains > problems > with associating this mechanism with a POA, along similar lines to > what > Jonathan has posted. That was issue 2461. As I understand it, the main point of that issue was that making BiDir a POA policy does not seem to fit. It is the ORB that establishes and uses outgoing connections, and which must decide whether or not to send a BiDirIIOPServiceContext, and with which ListenPoints. If there is more than one POA, and they have different policies, and the (IIOP) references they create contain the same host:post, how is the ORB to decide what to do? As I see it, issue 2461 is about what a client may do to cause its outgoing connections to be used bi-directionally. Issue 2633 (which connection) is about what a server may do on its incoming connections when it is about to make an invocation. Issue 2634 (masquerade) is about whether or not a server can trust ListenPoint data received on an incoming connection. Perhaps the problem is that there are (at least) two policy decisions to make, but only one mechanism provided to make them. There should be a 'client' policy to control whether or not to send a BiDirIIOPServiceContext in a request on an outgoing connection. There should also be 'server' policy to control whether or not to use the existing connection to make an invocation if the 'client' has made the offer. This may or may not be affected by the policy of the POA which deals with a request which has a BiDirIIOPServiceContext. > > Paul > > Martin Chapman wrote: >> >> My you lot have been busy overnight! >> I'll reply to Owen's original mail next, but this was (i think ) an >> easy one >> to answer >> >> > -----Original Message----- >> > From: jon@floorboard.com [mailto:jon@floorboard.com] >> > Sent: 06 May 1999 00:01 >> > To: Bill Janssen >> > Cc: Polar Humenn; Sastry Malladi; Owen Rees; OMG Firewall RTF; >> > interop@omg.org; secsig@omg.org >> > Subject: Re: Bi-Directional GIOP: which connections may be used? >> > >> > >> > Bill Janssen wrote: >> > > >> > > Excerpts from direct: 5-May-99 Re: Bi-Directional GIOP: wh.. >> Jonathan >> > > Biggar@floorboa (1016*) >> > > >> > > > BiDir GIOP also does this, since the client must explicitly >> > transmit the >> > > > "listening point" service context to the server before BiDir >> > GIOP can be >> > > > activated. >> > > >> > > How does the application control this send? >> > >> > The client is supposed to set it with a Policy object, but the spec >> > doesn't exactly say where... I guess it's time to send another >> issue. >> >> The Policy is set on the callback object's POA, from Section 5.2: >> >> In the absence of a BidirectionalPolicy being passed in the >> PortableServer::POA::create_POA operation, a POA will assume a >> policy >> value of NORMAL. >> >> A client and a server ORB must each have a BidirectionalPolicy >> with a value >> of BOTH for bi-directional communication to take place. >> >> > >> > -- >> > Jon Biggar >> > Floorboard Software >> > jon@floorboard.com >> > jon@biggar.org >> > Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Reply-To: From: "Martin Chapman" To: Subject: issue 2461 Date: Tue, 7 Dec 1999 17:00:08 -0000 Message-ID: <002601bf40d4$8439fb20$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3Q*!!dIT!!Up3e9S\9!! I've been thinking about the BidDir POA policy issue (#2461), and want to run this by y'all. Ideally, I think you need three distinct policies - one to indicate that an object may be invoked using bidir (i.e. its address may be included in a bidir service context), one to indicate that a connection could be used bi-directionally (i.e. bidir service context is permitted to be transmitted), and one policy to say whether to actually use the bi-dir connection to invoke an object. the first would look something like: (ignore style guide issues at this stage) enum usemode { NORMALONLY, BIDIRONLY, EITHER} interface InvokeMode: CORBA::Policy { readonly attribute usemode the_mode; }; Scope - ORB, POA - affects what addresses could be put in a bi-dir service context. NORMALONLY means object can only be invoked using standard GIOP - its address should never appear in a bidir service context BIDIRONLY means object can only be invoked on the "reverse" of a connection (e.g. for browsers) EITHER means the orb decsides through other means. The second, something like: enum connmode {NORMAL, BIDIR} interface ConnectionMode: CORBA::Policy { readonly attribute connmode the_mode; }; Scope - ORB, thread, object - affects whether the bidir service context could be transmitted on a connection or not NORMAL means open/use standard GIOP connections (bidir service context never sent on connection) BIDIR means open/use a bidir connection (i.e. bidir service context may be sent over such a connection, which may contain listen point info for objects created with an invokemode of bidironly or either ) The third policy, something like: interface reverseInvokeMode{ readonly attribute usemode the_mode; }; Scope - ORB, thread, object - affects whether you should invoke an object using the bi-dir (reverse) connection. NORMAL Means do not use bidir to talk to "client" side object(s) BIDIRONLY means only use bidir to talk to the "client" side object(s) EITHER same as before. Comments? Martin. From: Paul Kyzivat To: "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: Issue 2461 Date: Mon, 20 Dec 1999 18:34:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: +*b!!5Y^!!bR'!!NSY!! > From: Martin Chapman [mailto:mchapman@iona.com] > I have *drafted* a resolution text to 2461 (the POA policy issues). > I sure I don't have to ask for comments on this one:-) Right you are! I still have a problem with the InvokeMode policy value of BIDIRONLY. The text specifies "A BidirectionalUseMode of BIDIRONLY states that the objects within the scope of this policy can only be invoked on the reverse of a connection." But this is clearly not the case - nothing prevents someone holding this reference from attempting to establish a connection to the address and invoke on it. There is nothing in IORs created by POAs with this policy to indicate there is a problem with doing this. What error should a caller expect in this case? Paul P.S. I will be on vacation until the end of the year, and ignoring my mail, except that sometime this week I will make one more pass looking for critical votes due. Date: Tue, 21 Dec 1999 09:19:42 +0000 From: Owen Rees To: Paul Kyzivat , "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: Issue 2461 Message-ID: <875177442.945767982@ews-proj-2.hpl.hp.com> In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140274@bos1.noblenet.com> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 4:bd99(a!!#8"e9=eM!! --On 20 December 1999, 18:34 -0500 Paul Kyzivat wrote: >> From: Martin Chapman [mailto:mchapman@iona.com] > >> I have *drafted* a resolution text to 2461 (the POA policy issues). >> I sure I don't have to ask for comments on this one:-) I think it looks a lot better. > > Right you are! > > I still have a problem with the InvokeMode policy value of > BIDIRONLY. The > text specifies "A BidirectionalUseMode of BIDIRONLY states that the > objects within the scope of this policy can only be invoked on the > reverse > of a connection." But this is clearly not the case - nothing > prevents > someone holding this reference from attempting to establish a > connection > to the address and invoke on it. There is nothing in IORs created by > POAs > with this policy to indicate there is a problem with doing > this. What > error should a caller expect in this case? That assumes that the 'address' in the IOR is something to which you can connect in the normal way. If the matching of host name in a listen_point with the host part of the 'address' in an IOR is exact string match only, you can use a string that is not the name of any host when the policy is BIDIRONLY. One advantage of doing this is that the recipient of the listen_point can tell at once that the sender is not trying to capture invocations that ought to go to a known host in the normal way. Using a probabilitically unique id can reduce the chance of having your callbacks stolen by some other bi-dir client too. If both ends play this game properly, this reduces the masquerade problem to something we can probably live with. Ideally the necessary constraints should be standardised if we want to support this since both ends have to participate. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Reply-To: From: "Martin Chapman" To: "Owen Rees" , "Paul Kyzivat" , Subject: RE: Issue 2461 Date: Tue, 21 Dec 1999 12:36:51 -0000 Message-ID: <000301bf4bb0$0e7c07c0$b201020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <875177442.945767982@ews-proj-2.hpl.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Jngd9Y+S!!WP+e9X64!! > -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: 21 December 1999 09:20 > To: Paul Kyzivat; 'mchapman@iona.com'; firewall-rtf@omg.org > Subject: RE: Issue 2461 > > > --On 20 December 1999, 18:34 -0500 Paul Kyzivat > wrote: > > >> From: Martin Chapman [mailto:mchapman@iona.com] > > > >> I have *drafted* a resolution text to 2461 (the POA policy > issues). > >> I sure I don't have to ask for comments on this one:-) > > I think it looks a lot better. > > > > > Right you are! > > > > I still have a problem with the InvokeMode policy value of > BIDIRONLY. The > > text specifies "A BidirectionalUseMode of BIDIRONLY states that > the > > objects within the scope of this policy can only be invoked on > the reverse > > of a connection." But this is clearly not the case - nothing > prevents > > someone holding this reference from attempting to establish a > connection > > to the address and invoke on it. There is nothing in IORs > created by POAs > > with this policy to indicate there is a problem with doing > this. What > > error should a caller expect in this case? > > That assumes that the 'address' in the IOR is something to which you > can > connect in the normal way. If the matching of host name in a > listen_point > with the host part of the 'address' in an IOR is exact string match > only, > you can use a string that is not the name of any host when the > policy is > BIDIRONLY. One advantage of doing this is that the recipient of the > listen_point can tell at once that the sender is not trying to > capture > invocations that ought to go to a known host in the normal > way. Using a > probabilitically unique id can reduce the chance of having your > callbacks > stolen by some other bi-dir client too. If both ends play this game > properly, this reduces the masquerade problem to something we can > probably > live with. > > Ideally the necessary constraints should be standardised if we want > to > support this since both ends have to participate. Good idea. What sort of constraints do you have in mind? I'm off for Christams holidays now and back on 4th Jan. I'll have a think on this and get a revised proposal out by 6th Jan. we can then call for a vote to terminate 12th jan (during Mesa) which will then give me a couple of days to get the report together by the deadline on the 14th. Martin. From: Paul Kyzivat To: "'Owen Rees'" , Paul Kyzivat , "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: Issue 2461 Date: Wed, 22 Dec 1999 17:21:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 7FK!!oLX!!go?e9Zn]d9 I have been thinking more about this. I think there needs to be something in the IOR that permits the user of that IOR to know whether it is acceptable to use it normally, bidirectionally, or both. The best approach that I have come up with is a fairly large change. It would consist of a new bidir profile in the IOR, containing an identifier that is also then passed in a bidir service context. The orb would be responsible for assigning a unique identifier for the purpose. When it is acceptable for an ior to be used either normally or bidirectionally, it would contain two profiles. Sadly, this would require not only adding the definition of a new profile, but it would also require a new (or revised) service context, since the existing one is specific to IIOP. I think this would eliminate many of the confusing problems. Thoughts? Paul > -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: Tuesday, December 21, 1999 4:20 AM > To: Paul Kyzivat; 'mchapman@iona.com'; firewall-rtf@omg.org > Subject: RE: Issue 2461 > > > --On 20 December 1999, 18:34 -0500 Paul Kyzivat > wrote: > > >> From: Martin Chapman [mailto:mchapman@iona.com] > > > >> I have *drafted* a resolution text to 2461 (the POA policy > issues). > >> I sure I don't have to ask for comments on this one:-) > > I think it looks a lot better. > > > > > Right you are! > > > > I still have a problem with the InvokeMode policy value of > BIDIRONLY. The > > text specifies "A BidirectionalUseMode of BIDIRONLY states that > the > > objects within the scope of this policy can only be invoked > on the reverse > > of a connection." But this is clearly not the case - > nothing prevents > > someone holding this reference from attempting to establish > a connection > > to the address and invoke on it. There is nothing in IORs > created by POAs > > with this policy to indicate there is a problem with doing > this. What > > error should a caller expect in this case? > > That assumes that the 'address' in the IOR is something to > which you can > connect in the normal way. If the matching of host name in a > listen_point > with the host part of the 'address' in an IOR is exact string > match only, > you can use a string that is not the name of any host when > the policy is > BIDIRONLY. One advantage of doing this is that the recipient of the > listen_point can tell at once that the sender is not trying to > capture > invocations that ought to go to a known host in the normal > way. Using a > probabilitically unique id can reduce the chance of having > your callbacks > stolen by some other bi-dir client too. If both ends play this game > properly, this reduces the masquerade problem to something we > can probably > live with. > > Ideally the necessary constraints should be standardised if we want > to > support this since both ends have to participate. > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > X-Authentication-Warning: marcy.adiron.com: polar owned process doing > -bs Date: Wed, 22 Dec 1999 18:37:20 -0500 (EST) From: Polar Humenn To: Paul Kyzivat cc: "'Owen Rees'" , "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: Issue 2461 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA914027D@bos1.noblenet.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-427817617-219883283-945905840=:154" X-UIDL: Mk-e9kXg!!:?'e9~l/!! On Wed, 22 Dec 1999, Paul Kyzivat wrote: > I have been thinking more about this. > > I think there needs to be something in the IOR that permits the user > of that > IOR to know whether it is acceptable to use it normally, > bidirectionally, or > both. > > The best approach that I have come up with is a fairly large change. > It would consist of a new bidir profile in the IOR, containing an > identifier > that is also then passed in a bidir service context. The orb would > be > responsible for assigning a unique identifier for the purpose. When > it is > acceptable for an ior to be used either normally or bidirectionally, > it > would contain two profiles. Paul, this sounds like something like I proposed before in an earlier message (see attached). It would seem that this approach is the only way it makes sense. And will not ignore SECIOP either. > Sadly, this would require not only adding the definition of a new profile, > but it would also require a new (or revised) service context, since the > existing one is specific to IIOP. I don't think it would require a whole new profile, but a tagged component and a new service context. > I think this would eliminate many of the confusing problems. > Thoughts? Can we do that much in this RTF with that amount of time? cheers, -Polar > Paul > > > -----Original Message----- > > From: Owen Rees [mailto:owen_rees@hp.com] > > Sent: Tuesday, December 21, 1999 4:20 AM > > To: Paul Kyzivat; 'mchapman@iona.com'; firewall-rtf@omg.org > > Subject: RE: Issue 2461 > > > > > > --On 20 December 1999, 18:34 -0500 Paul Kyzivat > > wrote: > > > > >> From: Martin Chapman [mailto:mchapman@iona.com] > > > > > >> I have *drafted* a resolution text to 2461 (the POA policy > issues). > > >> I sure I don't have to ask for comments on this one:-) > > > > I think it looks a lot better. > > > > > > > > Right you are! > > > > > > I still have a problem with the InvokeMode policy value of > > BIDIRONLY. The > > > text specifies "A BidirectionalUseMode of BIDIRONLY states that > the > > > objects within the scope of this policy can only be invoked > > on the reverse > > > of a connection." But this is clearly not the case - > > nothing prevents > > > someone holding this reference from attempting to establish > > a connection > > > to the address and invoke on it. There is nothing in IORs > > created by POAs > > > with this policy to indicate there is a problem with doing > > this. What > > > error should a caller expect in this case? > > > > That assumes that the 'address' in the IOR is something to > > which you can > > connect in the normal way. If the matching of host name in a > > listen_point > > with the host part of the 'address' in an IOR is exact string > > match only, > > you can use a string that is not the name of any host when > > the policy is > > BIDIRONLY. One advantage of doing this is that the recipient of > the > > listen_point can tell at once that the sender is not trying to > capture > > invocations that ought to go to a known host in the normal > > way. Using a > > probabilitically unique id can reduce the chance of having > > your callbacks > > stolen by some other bi-dir client too. If both ends play this > game > > properly, this reduces the masquerade problem to something we > > can probably > > live with. > > > > Ideally the necessary constraints should be standardised if we > want to > > support this since both ends have to participate. > > > > Regards, > > Owen Rees > > Hewlett Packard Laboratories, Bristol, UK > > tel: +44 117 312 9439 fax: +44 117 312 9285 > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com [] x Reply-To: From: "Martin Chapman" To: "Paul Kyzivat" , "'Owen Rees'" , Subject: RE: Issue 2461 Date: Thu, 23 Dec 1999 09:13:52 -0000 Message-ID: <001901bf4d26$07c1ca60$1d8578d4@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA914027D@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /E,e9=N/!!8\hd9pKmd9 I think you are right in that this is the correct architecture. I'm not sure though that is in the scope of an RTF to do such a change, plus I don't think we have the time in this RTF. A new tag component and service context requires a rev to giop, so it may be better to hand over bi-dir to the interop rtf or wait for the so called hypothetical "giop v2" rfp. I think the policies I proposed (wording aside) would work with your achitecture so at least we can make a small step. Martin. > -----Original Message----- > From: Paul Kyzivat [mailto:paulk@roguewave.com] > Sent: 22 December 1999 22:21 > To: 'Owen Rees'; Paul Kyzivat; 'mchapman@iona.com'; > firewall-rtf@omg.org > Subject: RE: Issue 2461 > > > I have been thinking more about this. > > I think there needs to be something in the IOR that permits the > user of that > IOR to know whether it is acceptable to use it normally, > bidirectionally, or > both. > > The best approach that I have come up with is a fairly large change. > It would consist of a new bidir profile in the IOR, containing an > identifier > that is also then passed in a bidir service context. The orb would > be > responsible for assigning a unique identifier for the purpose. When > it is > acceptable for an ior to be used either normally or bidirectionally, > it > would contain two profiles. > > Sadly, this would require not only adding the definition of a new > profile, > but it would also require a new (or revised) service context, since > the > existing one is specific to IIOP. > > I think this would eliminate many of the confusing problems. > > Thoughts? > > Paul > > > -----Original Message----- > > From: Owen Rees [mailto:owen_rees@hp.com] > > Sent: Tuesday, December 21, 1999 4:20 AM > > To: Paul Kyzivat; 'mchapman@iona.com'; firewall-rtf@omg.org > > Subject: RE: Issue 2461 > > > > > > --On 20 December 1999, 18:34 -0500 Paul Kyzivat > > wrote: > > > > >> From: Martin Chapman [mailto:mchapman@iona.com] > > > > > >> I have *drafted* a resolution text to 2461 (the POA policy > issues). > > >> I sure I don't have to ask for comments on this one:-) > > > > I think it looks a lot better. > > > > > > > > Right you are! > > > > > > I still have a problem with the InvokeMode policy value of > > BIDIRONLY. The > > > text specifies "A BidirectionalUseMode of BIDIRONLY states that > the > > > objects within the scope of this policy can only be invoked > > on the reverse > > > of a connection." But this is clearly not the case - > > nothing prevents > > > someone holding this reference from attempting to establish > > a connection > > > to the address and invoke on it. There is nothing in IORs > > created by POAs > > > with this policy to indicate there is a problem with doing > > this. What > > > error should a caller expect in this case? > > > > That assumes that the 'address' in the IOR is something to > > which you can > > connect in the normal way. If the matching of host name in a > > listen_point > > with the host part of the 'address' in an IOR is exact string > > match only, > > you can use a string that is not the name of any host when > > the policy is > > BIDIRONLY. One advantage of doing this is that the recipient of > the > > listen_point can tell at once that the sender is not trying to > capture > > invocations that ought to go to a known host in the normal > > way. Using a > > probabilitically unique id can reduce the chance of having > > your callbacks > > stolen by some other bi-dir client too. If both ends play this > game > > properly, this reduces the masquerade problem to something we > > can probably > > live with. > > > > Ideally the necessary constraints should be standardised if we > want to > > support this since both ends have to participate. > > > > Regards, > > Owen Rees > > Hewlett Packard Laboratories, Bristol, UK > > tel: +44 117 312 9439 fax: +44 117 312 9285 > > > Date: Thu, 23 Dec 1999 09:15:06 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "'Owen Rees'" , "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: Re: Issue 2461 References: <9B164B713EE9D211B6DC0090273CEEA914027D@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *!,e9LT'!!* > I have been thinking more about this. > > I think there needs to be something in the IOR that permits the user > of that > IOR to know whether it is acceptable to use it normally, > bidirectionally, or > both. > > The best approach that I have come up with is a fairly large change. > It would consist of a new bidir profile in the IOR, containing an > identifier > that is also then passed in a bidir service context. The orb would > be > responsible for assigning a unique identifier for the purpose. When > it is > acceptable for an ior to be used either normally or bidirectionally, > it > would contain two profiles. > > Sadly, this would require not only adding the definition of a new > profile, > but it would also require a new (or revised) service context, since > the > existing one is specific to IIOP. > > I think this would eliminate many of the confusing problems. > > Thoughts? > > Paul > > > -----Original Message----- > > From: Owen Rees [mailto:owen_rees@hp.com] > > Sent: Tuesday, December 21, 1999 4:20 AM > > To: Paul Kyzivat; 'mchapman@iona.com'; firewall-rtf@omg.org > > Subject: RE: Issue 2461 > > > > > > --On 20 December 1999, 18:34 -0500 Paul Kyzivat > > wrote: > > > > >> From: Martin Chapman [mailto:mchapman@iona.com] > > > > > >> I have *drafted* a resolution text to 2461 (the POA policy > issues). > > >> I sure I don't have to ask for comments on this one:-) > > > > I think it looks a lot better. > > > > > > > > Right you are! > > > > > > I still have a problem with the InvokeMode policy value of > > BIDIRONLY. The > > > text specifies "A BidirectionalUseMode of BIDIRONLY states that > the > > > objects within the scope of this policy can only be invoked > > on the reverse > > > of a connection." But this is clearly not the case - > > nothing prevents > > > someone holding this reference from attempting to establish > > a connection > > > to the address and invoke on it. There is nothing in IORs > > created by POAs > > > with this policy to indicate there is a problem with doing > > this. What > > > error should a caller expect in this case? > > > > That assumes that the 'address' in the IOR is something to > > which you can > > connect in the normal way. If the matching of host name in a > > listen_point > > with the host part of the 'address' in an IOR is exact string > > match only, > > you can use a string that is not the name of any host when > > the policy is > > BIDIRONLY. One advantage of doing this is that the recipient of > the > > listen_point can tell at once that the sender is not trying to > capture > > invocations that ought to go to a known host in the normal > > way. Using a > > probabilitically unique id can reduce the chance of having > > your callbacks > > stolen by some other bi-dir client too. If both ends play this > game > > properly, this reduces the masquerade problem to something we > > can probably > > live with. > > > > Ideally the necessary constraints should be standardised if we > want to > > support this since both ends have to participate. > > > > Regards, > > Owen Rees > > Hewlett Packard Laboratories, Bristol, UK > > tel: +44 117 312 9439 fax: +44 117 312 9285 > > From: Paul Kyzivat To: "'Bob Kukura'" , Paul Kyzivat > Cc: "'Owen Rees'" , "'mchapman@iona.com'" , firewall-rtf@omg.org Subject: RE: Issue 2461 Date: Mon, 3 Jan 2000 12:35:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: DmG!!O28!!1#B!!~pcd9 Bob, I think you are probably right that TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS profiles are sufficient, with the addition of something like a TAG_BIDIR_GIOP_ID component. However, using the TAG_BIDIR_GIOP_ID component for identification rather than a TCP/IP host and port will at least require either a change to the BiDir service context or the addition of another alternative service context. The good news in this, as you suggest, is that no other service contexts will be needed for other GIOP based protocols. While I realize there are problems with timing and scope of FTFs, this seems to me like a change that should be made sooner, rather than later. There are too many ugly issues with using the host/port as a unique id for bidir. Paul > -----Original Message----- > From: Bob Kukura [mailto:kukura@iona.com] > Sent: Thursday, December 23, 1999 9:15 AM > To: Paul Kyzivat > Cc: 'Owen Rees'; 'mchapman@iona.com'; firewall-rtf@omg.org > Subject: Re: Issue 2461 > > > Paul, > > I may have missed this in earlier discussion, but can you explain > why > you feel a new profile is needed? Is this simply for the case where > bi-dir is allowed but normal IIOP isn't? > > Instead of defining a new profile, I'd suggest defining bidir in > terms > of IOR components, and then using the TAG_INTERNET_IOP profile when > normal IIOP is allowed, and the TAG_MULTIPLE_COMPONENTS profile when > normal IIOP is not allowed. In the first case, the > object_key and GIOP > version come from the members of the profile body structure, just > like > with normal GIOP. In the second case, I'd recommend using > the existing > TAG_COMPLETE_OBJECT_KEY component for the object key, and adding a > TAG_GIOP_VERSION component that specifies the GIOP version. In both > cases, a TAG_BIDIR_GIOP_ID component or something like that would be > included to identify what connection to use. The nice thing > about this > approach is that it also works for any other GIOP based protocol one > wishes to add, without causing grotesque expansion of the IORs. > > Also, I think I mostly disagree with Martin's statement that > a new GIOP > version is required whenever new components are added. The > component > and service_context aspects of the interoperability architecture > were > designed to allow features to be easily added without > breaking users of > the protocol not aware of those features. Remember, IOR profiles > advertising higher minor versions of GIOP 1.x are required to work > for > clients that are only aware of lower minor versions, so these added > components really can't break anything for existing versions. I > think > the only real issue here is the silly "droppable" thing, where ORBs > technically can drop components that they did not think belong in > the > advertised version. I don't know of any ORB that does this, and > consider it a "quality of implementation" thing. Again, any > components > added in GIOP 1.3 could be dropped by GIOP 1.2 ORBs, which is > really no > different than GIOP 1.2 ORBs dropping components added to GIOP 1.2 > without incrementing the minor version number. > > Finally, I'm not expressing an opinion as to whether any IOR info is > needed for bi-directional GIOP, since I haven't really been > following > that discussion. My point is simply that if additional IOR info is > needed, that requirement should be easily accommodated by the > interoperability architecture without requiring either a new > profile or > a new GIOP version. > > -Bob From: Paul Kyzivat To: "'mchapman@iona.com'" , Paul Kyzivat , "'Owen Rees'" , firewall-rtf@omg.org Subject: RE: Issue 2461 Date: Mon, 3 Jan 2000 13:41:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: %ei!!me+e9/o-!!W>=!! Martin, I remain concerned about the number of ugly issues that arise from the use of a (possibly bogus) host/port as a unique identifier when associating IORs with bidir connections. I would like to find a way to get this right, sooner rather than later. Certainly we need to consider the scope implications, but this clearly seems to me to be a defect that ought to be fixable via the RTF process, either in Firewall or in Interop. If need be, I would rather leave this issue open to be considered in the next round. It would be possible to arrive at a desired solution, vote on it, and issue an interim report for approval at the Denver meeting, so it wouldn't lose too much time. Paul > -----Original Message----- > From: Martin Chapman [mailto:mchapman@iona.com] > Sent: Thursday, December 23, 1999 4:14 AM > To: Paul Kyzivat; 'Owen Rees'; firewall-rtf@omg.org > Subject: RE: Issue 2461 > > > I think you are right in that this is the correct > architecture. I'm not sure though that is in the scope of an RTF > to do such a change, plus I don't think we have the time in this > RTF. > A new tag component and service context > requires a rev to giop, so it may be better to hand over bi-dir to > the > interop rtf or wait for the so called hypothetical "giop v2" > rfp. I think the policies I proposed (wording aside) would work with > your achitecture so at least we can make a small step. > > Martin.