Issue 7318: How many BI_DIR_GIOP_OFFER service contexts are allowed (firewall-traversal-ftf) Source: Syracuse University (Mr. C. Joncheng Kuo, joncheng_kuo(at)bristol.com) Nature: Uncategorized Issue Severity: Summary: The Bidirectional GIOP spec does not specify how many BI_DIR_GIOP_OFFER service contexts are allowed in a NegotiateSession or Request. If only one such service context is allowed, it shall be stated clearly. Besides, because each BI_DIR_GIOP_OFFER service context can contain only either strong or weak BiDirIds (but not both), if there are both strong and weak BiDirIds on the ORB, the ORB has to use at least two GIOP messages to send them all. If we allow multiple BI_DIR_GIOP_OFFER service contexts in one message, we'll have a problem in matching BI_DIR_GIOP_ACCEPT service contexts to these offers because there is no sequencing on offers and accepts. Resolution: Revised Text: Actions taken: May 6, 2004: received issue Discussion: End of Annotations:===== Date: Thu, 06 May 2004 20:01:22 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: issues@omg.org CC: firewall-traversal-ftf@omg.org Subject: Firewall Issue: How many BI_DIR_GIOP_OFFER service contexts are allowed in a GIOP message? X-Virus-Scanned: Symantec AntiVirus Scan Engine The Bidirectional GIOP spec does not specify how many BI_DIR_GIOP_OFFER service contexts are allowed in a NegotiateSession or Request. If only one such service context is allowed, it shall be stated clearly. Besides, because each BI_DIR_GIOP_OFFER service context can contain only either strong or weak BiDirIds (but not both), if there are both strong and weak BiDirIds on the ORB, the ORB has to use at least two GIOP messages to send them all. If we allow multiple BI_DIR_GIOP_OFFER service contexts in one message, we'll have a problem in matching BI_DIR_GIOP_ACCEPT service contexts to these offers because there is no sequencing on offers and accepts. Joncheng Kuo Syracuse University Subject: RE: Firewall Issue: How many BI_DIR_GIOP_OFFER service contexts are allowed in a GIOP message? Date: Fri, 7 May 2004 10:20:37 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: How many BI_DIR_GIOP_OFFER service contexts are allowed in a GIOP message? Thread-Index: AcQzxssnSaRh2gJjQlq+tJIjyROW8gAdqBQA From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i47EPIFh012730 The BiDirError Accept value should be sufficient without needing to sequence offers and accepts. The accept value is either an acceptance or a failure. There's no concern over acceptances, so the failures are the only interesting part in this situation. Unsupported implies that it doesn't matter what offers might have been made - bidir simply isn't supported. Weak failed means the weak BiDirIds weren't supported; Strong means a challenge failed and you are being told the connection is about to be dropped. Where's the ambiguity? --Rebecca > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Thursday, May 06, 2004 8:01 PM > To: issues@omg.org > Cc: firewall-traversal-ftf@omg.org > Subject: Firewall Issue: How many BI_DIR_GIOP_OFFER service > contexts are > allowed in a GIOP message? > > > The Bidirectional GIOP spec does not specify how many > BI_DIR_GIOP_OFFER > service contexts are allowed in a NegotiateSession or Request. > > If only one such service context is allowed, it shall be > stated clearly. > Besides, because each BI_DIR_GIOP_OFFER service context can > contain only > either strong or weak BiDirIds (but not both), if there are > both strong > and weak BiDirIds on the ORB, the ORB has to use at least two GIOP > messages to send them all. > > If we allow multiple BI_DIR_GIOP_OFFER service contexts in > one message, > we'll have a problem in matching BI_DIR_GIOP_ACCEPT service > contexts to > these offers because there is no sequencing on offers and accepts. > > Joncheng Kuo > Syracuse University > > > > > Date: Fri, 7 May 2004 10:44:33 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: Joncheng Kuo , firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: How many BI_DIR_GIOP_OFFER service contexts are allowed in a GIOP message? On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > The BiDirError Accept value should be sufficient without needing to > sequence offers and accepts. The accept value is either an acceptance > or a failure. There's no concern over acceptances, so the failures are > the only interesting part in this situation. Unsupported implies that > it doesn't matter what offers might have been made - bidir simply isn't > supported. Weak failed means the weak BiDirIds weren't supported; Hmmmm, does WeakFailed mean weak BiDirIds aren't supported at all, as if the machinery doesn't exit? Or does it mean at least weak offer wasn't relevant? I had thought it was the latter? Maybe the the identifier is misnamed? I think its pretty set that you must send an "Accept" for every valid offer. Now, from your description above, it would seem to me that you could get many accepts on Weak and Strong offers. Then one WeakFailed bacially kills all the pending requests under the Weak Offers that were accepted? This is acceptable? > Strong means a challenge failed and you are being told the connection is > about to be dropped. Where's the ambiguity? In this case, one bad apple spoils the whole buch of girls. You could have pending requests in both directions. Furthermore, if you are talking security, of which this specification is supposed to be about, there is no provision for revoking the key, even if the challege technically succeeds. This practice is fairly standard in any public-key situation, and the whole reason there exists a PKI, and its totally ignored in this specification. -Polar > --Rebecca > > > -----Original Message----- > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > Sent: Thursday, May 06, 2004 8:01 PM > > To: issues@omg.org > > Cc: firewall-traversal-ftf@omg.org > > Subject: Firewall Issue: How many BI_DIR_GIOP_OFFER service > > contexts are > > allowed in a GIOP message? > > > > > > The Bidirectional GIOP spec does not specify how many > > BI_DIR_GIOP_OFFER > > service contexts are allowed in a NegotiateSession or Request. > > > > If only one such service context is allowed, it shall be > > stated clearly. > > Besides, because each BI_DIR_GIOP_OFFER service context can > > contain only > > either strong or weak BiDirIds (but not both), if there are > > both strong > > and weak BiDirIds on the ORB, the ORB has to use at least two GIOP > > messages to send them all. > > > > If we allow multiple BI_DIR_GIOP_OFFER service contexts in > > one message, > > we'll have a problem in matching BI_DIR_GIOP_ACCEPT service > > contexts to > > these offers because there is no sequencing on offers and accepts. > > > > Joncheng Kuo > > Syracuse University > > > > > > > > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Firewall Issue: How many BI_DIR_GIOP_OFFER service contexts are allowed in a GIOP message? Date: Fri, 7 May 2004 14:29:36 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: How many BI_DIR_GIOP_OFFER service contexts are allowed in a GIOP message? Thread-Index: AcQ0QdbYjFJYVoIzR0q1JNFYQ2uyFAAGrf9g From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: "Joncheng Kuo" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i47IVNFh018631 Inlined comments... > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Friday, May 07, 2004 10:45 AM > To: Bergersen, Rebecca > Cc: Joncheng Kuo; firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: How many BI_DIR_GIOP_OFFER > service contexts > are allowed in a GIOP message? > > > > On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > > > > The BiDirError Accept value should be sufficient without needing to > > sequence offers and accepts. The accept value is either an > acceptance > > or a failure. There's no concern over acceptances, so the > failures are > > the only interesting part in this situation. Unsupported > implies that > > it doesn't matter what offers might have been made - bidir > simply isn't > > supported. Weak failed means the weak BiDirIds weren't supported; > > Hmmmm, does WeakFailed mean weak BiDirIds aren't supported at > all, as if > the machinery doesn't exit? Or does it mean at least weak offer wasn't > relevant? I had thought it was the latter? Maybe the the identifier is > misnamed? > Since there is an 'unsupported' value that can be be returned, I think your conclusion that WaekFailed might mean unsupported is wrong. A WeakFailed simply means the server (connection acceptor) isn't accepting a weak BiDirId. Maybe the server wants everything to use strong IDs for security reasons. > I think its pretty set that you must send an "Accept" for every valid > offer. > I'm not sure what you mean by 'valid'. As I said above, a particular server may only 'accept' strong BiDirIds. In that case, it would think that the only acceptable offers were those that contained strong IDs. It wouldn't 'accept' offers that contained weak bidirids - it would return a BI_DIR_GIOP_ACCEPT context containing a BI_DIR_WEAK_FAILED value. The client can give up or it can try strong IDs. > Now, from your description above, it would seem to me that > you could get > many accepts on Weak and Strong offers. Then one WeakFailed > bacially kills > all the pending requests under the Weak Offers that were accepted? > > This is acceptable? > I think it's acceptable because I think the combination of events you posit is highly unlikely to occur in a real-world application. I see clients and servers as being more integrated - the client isn't just an arbitrary program that decides to use some service in a random manner. And the server is most likely to be treating all BiDir connections for a particular application in the same way - all will be weak or all will be strong. Can you provide a common use-case where a server for a particular application will accept a number of offers containing weak bidirids and then reject one? > > > Strong means a challenge failed and you are being told the > connection is > > about to be dropped. Where's the ambiguity? > > In this case, one bad apple spoils the whole buch of girls. > > You could have pending requests in both directions. > > Furthermore, if you are talking security, of which this > specification is > supposed to be about, there is no provision for revoking the > key, even if > the challege technically succeeds. This practice is fairly > standard in > any public-key situation, and the whole reason there exists a > PKI, and its > totally ignored in this specification. > > -Polar > > > --Rebecca > > > > > -----Original Message----- > > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > > Sent: Thursday, May 06, 2004 8:01 PM > > > To: issues@omg.org > > > Cc: firewall-traversal-ftf@omg.org > > > Subject: Firewall Issue: How many BI_DIR_GIOP_OFFER service > > > contexts are > > > allowed in a GIOP message? > > > > > > > > > The Bidirectional GIOP spec does not specify how many > > > BI_DIR_GIOP_OFFER > > > service contexts are allowed in a NegotiateSession or Request. > > > > > > If only one such service context is allowed, it shall be > > > stated clearly. > > > Besides, because each BI_DIR_GIOP_OFFER service context can > > > contain only > > > either strong or weak BiDirIds (but not both), if there are > > > both strong > > > and weak BiDirIds on the ORB, the ORB has to use at least two GIOP > > > messages to send them all. > > > > > > If we allow multiple BI_DIR_GIOP_OFFER service contexts in > > > one message, > > > we'll have a problem in matching BI_DIR_GIOP_ACCEPT service > > > contexts to > > > these offers because there is no sequencing on offers and accepts. > > > > > > Joncheng Kuo > > > Syracuse University > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > 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, 7 May 2004 15:02:13 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: How many BI_DIR_GIOP_OFFER service contexts are allowed in a GIOP message? On Fri, 7 May 2004, Bergersen, Rebecca wrote: > Since there is an 'unsupported' value that can be be returned, I think > your conclusion that WaekFailed might mean unsupported is wrong. A > WeakFailed simply means the server (connection acceptor) isn't accepting > a weak BiDirId. Maybe the server wants everything to use strong IDs for > security reasons. Maybe? That's an excellent thing for a protocol to say. :( So, you do mean that a weak id failed, so that any weak ids that were "accepted" are now defunct. Pending requests and all. Horse hockey. > > I think its pretty set that you must send an "Accept" for every valid > > offer. > > I'm not sure what you mean by 'valid'. Ug. That would be any offer the client may believe is accepted, which is when that clients gets a corresponding BI_DIR_GIOP_ACCEPT NO_ERROR message. That happens in both the Strong or Weak Offers. > As I said above, a particular server may only 'accept' strong BiDirIds. No, the specification implies that each OFFER must be responded to with a BI_DIR_GIOP_ACCEPT message. > In that case, it would think that the only acceptable offers were those > that contained strong IDs. It wouldn't 'accept' offers that contained > weak bidirids - it would return a BI_DIR_GIOP_ACCEPT context containing > a BI_DIR_WEAK_FAILED value. The client can give up or it can try strong > IDs. But any id's that were accepted are now defunct? Especially ids with pending GIOP requests? What happens to those? > I think it's acceptable because I think the combination of events you > posit is highly unlikely to occur in a real-world application. This one really gets me. It's borderline insulting. No, excuse me, it *IS* insulting. Do you have a definition of a "real-world" application? Something that runs on a Microsoft platform? Some IT server running an accounting program in an office? Somewhat common, maybe, "real-world", who friggin cares? I've been involved with high performance throughput multi-billion object servers and the million clients to go with them, and they must be built with security and integrity. I say don't ruin the underlying standard that supports that characteristic just for one of these "real-world" applications, turning GIOP into a friggin web server. Have a good weekend, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Firewall Issue: How many BI_DIR_GIOP_OFFER service contexts are allowed in a GIOP message? Date: Fri, 7 May 2004 15:14:49 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: How many BI_DIR_GIOP_OFFER service contexts are allowed in a GIOP message? Thread-Index: AcQ0ZejMfxkzfu/LQ/6jqkzY3HFoQgAAKBxg From: "Bergersen, Rebecca" To: "Polar Humenn" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i47JRVFh019876 comments inlined > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Friday, May 07, 2004 3:02 PM > To: firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: How many BI_DIR_GIOP_OFFER > service contexts > are allowed in a GIOP message? > > > On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > > Since there is an 'unsupported' value that can be be > returned, I think > > your conclusion that WaekFailed might mean unsupported is wrong. A > > WeakFailed simply means the server (connection acceptor) > isn't accepting > > a weak BiDirId. Maybe the server wants everything to use > strong IDs for > > security reasons. > > Maybe? That's an excellent thing for a protocol to say. :( I meant 'maybe the use case is that the server wants everything to use strong IDs for security reasons,' not that the protocol has a 'maybe' condition. > > So, you do mean that a weak id failed, so that any weak ids that were > "accepted" are now defunct. Pending requests and all. Horse hockey. > > > > I think its pretty set that you must send an "Accept" for > every valid > > > offer. > > > > I'm not sure what you mean by 'valid'. > > Ug. That would be any offer the client may believe is > accepted, which is > when that clients gets a corresponding BI_DIR_GIOP_ACCEPT NO_ERROR > message. That happens in both the Strong or Weak Offers. > > > As I said above, a particular server may only 'accept' > strong BiDirIds. > > No, the specification implies that each OFFER must be > responded to with a > BI_DIR_GIOP_ACCEPT message. > > > In that case, it would think that the only acceptable > offers were those > > that contained strong IDs. It wouldn't 'accept' offers > that contained > > weak bidirids - it would return a BI_DIR_GIOP_ACCEPT > context containing > > a BI_DIR_WEAK_FAILED value. The client can give up or it > can try strong > > IDs. > > But any id's that were accepted are now defunct? Especially ids with > pending GIOP requests? What happens to those? > > > I think it's acceptable because I think the combination of > events you > > posit is highly unlikely to occur in a real-world application. > > This one really gets me. It's borderline insulting. No, > excuse me, it *IS* > insulting. It certainly wasn't meant to be. My question was meant to try to understand what is an edge use-case and what is a normal one. I think you're working through all of the permutations of the protocol (which is fine) but that flattens all use-cases. I was trying to figure out if you were defining a condition which would be an edge case like your 20,000 POAs example or something more commonly occuring. > > Do you have a definition of a "real-world" application? > > Something that runs on a Microsoft platform? > Some IT server running an accounting program in an office? Somewhat > common, maybe, "real-world", who friggin cares? > > I've been involved with high performance throughput > multi-billion object > servers and the million clients to go with them, and they > must be built > with security and integrity. > > I say don't ruin the underlying standard that supports that > characteristic > just for one of these "real-world" applications, turning GIOP into a > friggin web server. > > Have a good weekend, > -Polar > > ------------------------------------------------------------------- > 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: Mon, 10 May 2004 14:56:35 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: How many BI_DIR_GIOP_OFFER service contexts are allowed in a GIOP message? On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > But any id's that were accepted are now defunct? Especially ids with > > pending GIOP requests? What happens to those? > > > > > I think it's acceptable because I think the combination of > > events you > > > posit is highly unlikely to occur in a real-world application. > > > > This one really gets me. It's borderline insulting. No, > > excuse me, it *IS* > > insulting. > > It certainly wasn't meant to be. My question was meant to try to > understand what is an edge use-case and what is a normal one. I think > you're working through all of the permutations of the protocol (which is > fine) but that flattens all use-cases. Yeah, so what? bad things will happen if you don't even think about them. Nobody really gets burned by a "feature" that is used the way it was thought of to be used. Take IRAQ for instance. > I was trying to figure out if you were defining a condition which would > be an edge case like your 20,000 POAs example or something more commonly > occuring. You know, we teach our students to pay an interminable amount of attention to edge cases. You know why? Loops don't commonly break in the middle, they break on the ends, and then havoc breaks loose. Most buffer overflow attacks are a good example of that problem. -Pola