Issue 6285: Change new GIOP Negotiate Session Message to Firewall Specific (corba-rtf) Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: Here is a small proposal for GIOP 1.4 with Firewall and Bidirectional. We would get rid of all the weird nasty service contexts and make it simplistic. The FireWall messages are only allowed before any other GIOP messages. BiDir messages can happen at any time according to their protocol. What do you think? Asside from some problems I see with BiDir offer/challenge/response correlation, it is essentially equivalent to the solution proposed in the adopted spec. module GIOP { enum MsgType_1_4{ Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment, // GIOP 1.1 addition // GIOP 1.4 additions FirewallPathRequest, // 8 FirewallPathRepsonse, // 9 BiDirOffer, // 10 BiDirChallenge, // 11 BiDirResponse // 12 }; // Firewall Traversal GIOP 1.4 struct FirewallSpec { boolean is_intelligent; IOP::TaggedComponentSeq endpoints; }; typedef sequence<FirewallSpec> FirewallPath; struct FirewallPathRequestHeader { unsigned long host_index; FirewallPath path; }; // No body follows. enum FirewallPathResponseStatusType { NO_EXCEPTION, SYSTEM_EXCEPTION }; struct FirewallPathResponseHeader{ FirewallPathResponseStatusType status; boolean connection_complete; }; // Marshalled body immediately follows // Bidirectional GIOP 1.4 // To keep this file uncomplicated we can introduce the // headers and put the marshalled bodies in a separate BiDir module // Due due some issue about the challege/response protocol for this, // there may be a need of an offer_id to correlate them. struct BiDirOfferHeader{ unsigned long offer_id; }; // Marshalled body immediately follows. struct BiDirChallengeHeader { unsigned long offer_id; }; // Marshalled body immediately follows. struct BiDirResponseHeader { unsigned long offer_id; }; // Marshalled body immediately follows. }; Resolution: Revised Text: Actions taken: October 2, 2003: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Thu, 2 Oct 2003 21:28:08 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: firewall-traversal-ftf@omg.org, corba-rtf@omg.org Subject: Change new GIOP Negotiate Session Message to Firewall Specific Here is a small proposal for GIOP 1.4 with Firewall and Bidirectional. We would get rid of all the weird nasty service contexts and make it simplistic. The FireWall messages are only allowed before any other GIOP messages. BiDir messages can happen at any time according to their protocol. What do you think? Asside from some problems I see with BiDir offer/challenge/response correlation, it is essentially equivalent to the solution proposed in the adopted spec. module GIOP { enum MsgType_1_4{ Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment, // GIOP 1.1 addition // GIOP 1.4 additions FirewallPathRequest, // 8 FirewallPathRepsonse, // 9 BiDirOffer, // 10 BiDirChallenge, // 11 BiDirResponse // 12 }; // Firewall Traversal GIOP 1.4 struct FirewallSpec { boolean is_intelligent; IOP::TaggedComponentSeq endpoints; }; typedef sequence FirewallPath; struct FirewallPathRequestHeader { unsigned long host_index; FirewallPath path; }; // No body follows. enum FirewallPathResponseStatusType { NO_EXCEPTION, SYSTEM_EXCEPTION }; struct FirewallPathResponseHeader{ FirewallPathResponseStatusType status; boolean connection_complete; }; // Marshalled body immediately follows // Bidirectional GIOP 1.4 // To keep this file uncomplicated we can introduce the // headers and put the marshalled bodies in a separate BiDir module // Due due some issue about the challege/response protocol for this, // there may be a need of an offer_id to correlate them. struct BiDirOfferHeader{ unsigned long offer_id; }; // Marshalled body immediately follows. struct BiDirChallengeHeader { unsigned long offer_id; }; // Marshalled body immediately follows. struct BiDirResponseHeader { unsigned long offer_id; }; // Marshalled body immediately follows. }; ------------------------------------------------------------------- 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 Date: Fri, 03 Oct 2003 12:09:42 -0400 From: Tom Rutt Reply-To: tom@coastin.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en To: Polar Humenn CC: firewall-traversal-ftf@omg.org, corba-rtf@omg.org Subject: Re: Change new GIOP Negotiate Session Message to Firewall Specific Polar Humenn wrote: Here is a small proposal for GIOP 1.4 with Firewall and Bidirectional. We would get rid of all the weird nasty service contexts and make it simplistic. The FireWall messages are only allowed before any other GIOP messages. BiDir messages can happen at any time according to their protocol. What do you think? Asside from some problems I see with BiDir offer/challenge/response correlation, it is essentially equivalent to the solution proposed in the adopted spec. module GIOP { enum MsgType_1_4{ Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment, // GIOP 1.1 addition // GIOP 1.4 additions FirewallPathRequest, // 8 FirewallPathRepsonse, // 9 BiDirOffer, // 10 BiDirChallenge, // 11 BiDirResponse // 12 }; The negotiate context giop message is generally usefule, and could be used to update the codset negitiaion in the future to be more dynamic. So why take it away. You really need to justify your new proposed giop messages as being fundamental to the protocol. If the service context approach and be made to work, why not use it, as it is more general mechanism. What is wrong with putting protocol elements in the service context? While I do realize that the knowledge of firewall service contexts is required for giop 1.4, their use can be negotiated away. Does your proposal keep the ability to have the reciever not accept one of these new giop requests? Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 X-Authentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Fri, 3 Oct 2003 13:48:20 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: Tom Rutt cc: firewall-traversal-ftf@omg.org, corba-rtf@omg.org Subject: Re: Change new GIOP Negotiate Session Message to Firewall Specific On Fri, 3 Oct 2003, Tom Rutt wrote: > The negotiate context giop message is generally usefule, and could be > used to update the codset negitiaion in the future to be more dynamic. > So why take it away. 2 good reasons: 1. The semantics dealing with arbitrary "future" service contexts is not well defined (at all). 1a. because of (1) you have to write all these nasty special cases dealing with each service context that shows up either in a NS message or Request messages at particular nasty times. Causing the state of the machine to be way to complex and instead of following general extensible principles, it must follow some wording in a multitude of specifications. 2. Be careful of what you wish for. Because of 1, implementation is really really hard, and chances are that if it gets off the ground at all, with only with the luck of a Mafia retiree wearing lead shoes swimming across the East River will it really be interoperable. Take it from me who is trying to implement this beast. (There are just too many unanswered problems). > You really need to justify your new proposed giop messages as being > fundamental to the protocol. Well, NS is not fundamental to the protocol. It is not well defined, hardly defined. I'd rather see a well thought out response to an RFP on this specific subject than just being a HACK that fell off a solution to a specific problem. Something like GIOP Sessions and Session interceptors would be a better way. > If the service context approach and be made to work, why not use it, as > it is more general mechanism. What is wrong with putting protocol > elements in the service context? The problem is that NS is not made to work in general (much more work is needed for that), and aside from that, from the experience of one trying to implement it (I am trying to implement, I threw up my hands in frustration because it causes a lot of state tracking problems internally in the GIOP engine). Another point, is that if we want GIOP to be Bidirectional why are we hiding it in Service contexts, like some letch in a dark corner? The service contexts (which are request related) all of a sudden, are changing my GIOP engine operation? Geezz, what a friggin hack! These things and the multitude of combinations they represent have to be treated as "special GIOP messages", each one specially. The potential for "loading" up on arbitrary Service Contexts in a Negotiation session message is ridiculous, wade through having to find the relevant ones, what if there are conflicts, etc? All that stuff is not even close to be thought about, let a lone worked out in any light fashion. If GIOP is to be Bidirectional it should be called out in the protocol, not lurking under the covers. > While I do realize that the knowledge of firewall service contexts is > required for giop 1.4, their use can be negotiated away. Does your > proposal keep the ability to have the receiver not accept one of these > new giop requests? Of course. it can. The FirewallPathRequest can only be the first message out of the hoper at that GIOP layer. Nothing happens until it is responded to. It is equivalent to the defined protocol with the NS message being sent with 1 and only one FirewallPath Service context (although it isn't called out how many others can be there as well, and what happens if conflicts arrise, etc. etc. It's just to unruly to enumerate at this time. But in answer to your question, first, you wouldn't send one of these FirewallPathRequests to anything but a 1.4 profile, which would have been the case anyway. So the server will respond accordingly, just in the same way you would process any other service context that appeared in 1.3 with a "yes" in the must support column in the interoperability chapter. Second, a 1.4 client isn't required to send one. Everything can act as normal. Am I convincing you? :) Cheers, -Polar > Tom Rutt > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com