Issue 7202: Negotiate Session Message Issues (firewall-traversal-ftf) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: If a service context negotiation fails by way of the NegotiateSession message in either direction. how does the sender (client or servers side) get an indication back to the sender? Resolution: Revised Text: Actions taken: March 22, 2004: received issue Discussion: End of Annotations:===== Date: Mon, 22 Mar 2004 08:16:16 -0500 (EST) From: Polar Humenn To: firewall-traversal-ftf@omg.org, issues@omg.org Subject: Negotiate Session Message Issues If a service context negotiation fails by way of the NegotiateSession message in either direction. how does the sender (client or servers side) get an indication back to the sender? Date: Wed, 7 Apr 2004 14:18:21 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: Tom Rutt , firewall-traversal-ftf@omg.org Subject: RE: Negotiate Session Message Issues On Tue, 6 Apr 2004, Bergersen, Rebecca wrote: > > The question is, is the BI_DIR_GIOP_ACCEPT an ACK for a particular > > BI_DIR_GIOP_OFFER. If so, then there must be an explicit sequential > > ordering to each BI_DIR_OFFER. > > > > That's how I read it. It's an ordered protocol. You initiate the > offer. You wait for an ACK. Okay, a bit inefficient, but have it that way. > > This basically means that one offer can hold up the > > affirmations of any > > subsequent ones. Is that really what we want? Maybe so. > > It doesn't hold up affirmations on other connections - only the > connection waiting for the ACK. Obviously, I wasn't talking about affirmations on other connections. > > Also, if one particular BIDirId fails in a BI_DIR_GIOP_Offer, > > that would > > mean they all fail. If that is the case, then how does the > > ORB know which > > one, maybe, to retry? > > It's not the particular BiDirId that fails, it is the connection. The > errors are connection-wide: NO_SUPPORT = no support for BiDir GIOP at > all, WEAK_FAILED = server will not accept weak client IDs, STRONG_FAILED > = client failed challenge and server will not make bidir invocations > over that channel. The client knows what challenge was just made over > the channel, so it knows what BiDirId is a problem. Then one bad offer shuts down the whole connection. Surely, the client client may send a BI_DIR_OFFER with 20,000 offers in it. The client must receive a BI_DIR_CHALLENGE with the 20,000 offers in it. Then the client returns a BI_DIR_RESPONSE with the 20,000 offer responses in it. Then the server states STRONG_FAILED. So, the client knows challenge was just made over the channel, could be one or all 20,000 of them that failed. We just assume that all of them failed. However, according to the spec at this momment, we could have 20,000 previous offers already set up, and this one just killed the connection, with potential pending Requests and Replies. Is that what you want? > > I suppose you could go one at a time after that? > > > > > >The STRONG_FAILED case seems to state that the > > verification failed, which > > > >means that ONLY one strong offer has to fail for the > > connection to be > > > >rendered useless. And this indication can come after some > > have already > > > >been set up and used! > > > > > > > >The next paragraph states that if the strong failed, the > > client might make > > > >a weak offer. So, multiple OFFERs can come down the channel. > > > > > > The last paragraph in section 15.8.1 says: The action taken by the > client ORB when receiving a BI_DIR_GIOP_ACCEPT is undefined. Because the > client ORB will not necessarily have any outstanding invocations to > notify of the error, the client ORB might take action to correct the > error. For instance, if the client receives the BI_DIR_WEAK_FAILED > error, the client might attempt another BI_DIR_GIOP_OFFER using strong > identification if available. However, in most cases the client ORB will > only be able to optionally log the error or otherwise notify the user of > the error in a proprietary manner. The result is that multiple offers are allowed on the channel, they are processed one BI_DIR_OFFER at a time. They could be intermixed with Weak and Strong offers. One STRONG_FAILED BI_DIR_ACCEPT and the entire channel has to shut down? That seems to contradict this paragraph, that the behavior is undefined. I don't mind the client side being undefined, but the server side will not allow any more offers after a STRONG_FAILED. I think that needs to be fixed. > > > >Being that Weak and Strong are mixed in the same > > BI_DIR_GIOP_OFFER service > > > >context, BI_DIR_CHALLENGE and BI_DIR_RESPONSE messages may > > be delivered > > > >separately. What happens if some Weak offers are refused, > > yet others > > > >succeed? Which BiIds doe the ACCEPT message apply to? > > > > > > The accept is for the entire connection. Given that, I wouldn't mix and > match ID types within the same offer. But, it is allowed if you want to > do it. I thought the ACCEPT was for the Corresponding BI_DIR_OFFER? > > > >Finally, being that BI_DIR_OFFER messages can be > > multiplexed over GIOP > > > >Requests/Replies and NegotiationSession messages at the > > whim of the ORBs, > > > >which BI_DIR_OFFER messages does each BI_DIR_ACCEPT > > message apply to? > > Any failure is for every BiDirId offered over that connection. I answered my own question on that one, which is that they are ordered OFFER/ACCEPT. However, I don't understand your answer. If any failure is for every BiDirId offered over that connection, and the connection has been running for days, and then all of a sudden the client sends a BI_DIR_OFFER that gets a STRONG_FAILED, and the entire connection is shutdown? With potentially many pending requests? Is that what you want? > > > This only occurs if multiple unacked BI_DIR_OFFER messages > > are sent on > > > the same transport connection. > > > Would disallowing sending a second offer until getting the > > reply from > > > the first fix the problem you describe? > > > > Not really. I imagine an ORB can keep track of the sequence of > > BI_DIR_OFFERS and keep track of the corresponding BI_DIR_ACCEPTs. But > > still the problem remains, if multiple BiDirIds are included in the > > BI_DIR_OFFER and a WEAK or STRONG FAILED is sent back in the > > BI_DIR_ACCEPT, are all the offers considered invalid? > > > > Yep. Think of the implications of that statement. > > Also, the spec is worded in such a way that if the you get a > > ACCEPT with > > WEAK FAILED the server doesn't support weak offers (period). > > And if you > > get a STRONG FAILED, authentication failed, but the result > > says that the > > connection doesn't support bi-directional at all. > > > > That contradicts the statements that if you get a STRONG > > FAILED you can > > try Weak Offers after that. > > Actually, that's not what the spec says. It says if a WEAK fails you > can try a STRONG, not vice versa. See the last paragraph of 15.8.1, > quoted above. What about the case where the ORB supports Weak cases, just not one of the BiDirIds you're sending? Then you go into the lengthy process of opening connections, and trying each one? -Polar > > > > > Cheers, > > -Polar > > > > > > > >This protocol needs to be overhauled. > > > > > > > >Don't you agree? > > > > > > > >-Polar > > > > > > > > > > > > > > > > > > > >>If the server is willing to use connections bidirectionally, > > > >>possibly pending verification of BiDirIds, then the > > server will indicate > > > >>BI_DIR_NO_ERROR. Additionally, there are some conditions > > under which a > > > >>server ORB knows that it will not accept a client ORB's > > bi-directional > > > >>connection offer. For instance, a server ORB might not > > implement making > > > >>invocations over a bi-directional connection, or the > > server might only > > > >>accept strong client identification and the client makes weak > > > >>BI_DIR_GIOP_OFFERs. In those cases, the server ORB must > > respond with a > > > >>BI_DIR_GIOP_ACCEPT service context in the corresponding > > GIOP Reply or > > > >>NegotiateSession message. The BI_DIR_GIOP_ACCEPT service > > context can > > > >>also be used to indicate to the client that the challenge/response > > > >>identity verification failed for one or more BiDirIds. The > > > >>BI_DIR_GIOP_ACCEPT service context is defined below. > > > >> > > > >>module GIOP { > > > >>typedef unsigned short BiDirError; > > > >>const BiDirError BI_DIR_NO_ERROR = 0; > > > >>const BiDirError BI_DIR_UNSUPPORTED = 1; > > > >>const BiDirError BI_DIR_WEAK_FAILED = 2; > > > >>const BiDirError BI_DIR_STRONG_FAILED = 3; > > > >>// The BI_DIR_GIOP_ACCEPT service context contains a > > > >>// BiDirError value indicating any errors encountered. > > > >>const IOP::ServiceId BI_DIR_GIOP_ACCEPT = xx; // OMG Allocated > > > >>}; > > > >> > > > >>The value BI_DIR_UNSUPPORTED indicates that the server > > does not support > > > >>the use of bi-directional GIOP at all. The value > > BI_DIR_WEAK_FAILED > > > >>indicates that the server will not accept weak client > > identification. > > > >>The value BI_DIR_STRONG_FAILED indicates that the client > > failed the > > > >>challenge response and the server will not make bi-directional > > > >>invocations over that connection. > > > >> > > > >>The action taken by the client ORB when receiving a > > BI_DIR_GIOP_ACCEPT > > > >>is undefined. Because the client ORB will not necessarily have any > > > >>outstanding invocations to notify of the error, the > > client ORB might > > > >>take action to correct the error. For instance, if the > > client receives > > > >>the BI_DIR_WEAK_FAILED error, the client might attempt another > > > >>BI_DIR_GIOP_OFFER using strong identification if > > available. However, in > > > >>most cases the client ORB will only be able to optionally > > log the error > > > >>or otherwise notify the user of the error in a proprietary manner. > > > >> > > > >> > > > >> > > > > > > > >------------------------------------------------------------------- > > > >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 > > > > > > > > > > > > > > > > > > -- > > > ---------------------------------------------------- > > > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > > > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- 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: Thu, 08 Apr 2004 16:09:51 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: Polar Humenn , firewall-traversal-ftf@omg.org Subject: Re: Negotiate Session Message Issues Polar Humenn wrote: On Tue, 6 Apr 2004, Bergersen, Rebecca wrote: But still the problem remains, if multiple BiDirIds are included in the BI_DIR_OFFER and a WEAK or STRONG FAILED is sent back in the BI_DIR_ACCEPT, are all the offers considered invalid? Yep. Think of the implications of that statement. One implication that I can think of is as follows. Suppose a client sets up a POA with Weak BiDirId and makes an invocation. The server allows only Strong BiDirIds, so the server sends back a WEAK_FAILED. The client then sets up another POA with Strong BiDirId and makes another invocation. According to the spec, the server may accept the second, strong offer, assuming the verification succeeds. Right? If so, the communication sequence goes like the following: C ---(Weak OFFER)--> S C <--(WEAK_FAIL)--- S C ---(Strong OFFER)--> S C <--(NO_ERROR)--- S Now, if the client uses two different threads for each of setting up a POA and making an invocation. The the communication sequence may become like: C ---(Weak OFFER)--> S C ---(Strong OFFER)--> S C <--(WEAK_FAIL)--- S C <--(NO_ERROR)--- S >From the interpretation of the spec at the beginning of this mail, one WEAK_FAIL shall fail all BiDir OFFERs sent. Thus, no bi-directional GIOP was allowed in the above two invocations. This interpretation leads to the following problems. There is no guarantee that a client using Strong OFFER to invoke a server allowing Strong BiDirIds will succeed. Furthermore, the behavior of the above invocation is not deterministic. The client, making a Strong OFFER, may or may not succeed depending on whether there are some Weak OFFERs proceeding the Strong OFFER (and not yet answered). Am I right? Joncheng Date: Fri, 09 Apr 2004 08:42:55 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: Polar Humenn , firewall-traversal-ftf@omg.org Subject: Re: Negotiate Session Message Issues X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: [Bergersen, Rebecca] As I interpret it, a WEAK_FAIL applies to the BiDirIds on a single connection. Why would you make a weak offer followed by a strong offer on the same connection before receiving any response? That feels like a programming error. A client application does know about connections, it knows only object references and how to invoke these object references. Whether two object references are using the same GIOP connection is known only to the client ORB, but not client applications. Thus, in my example, all the client application knows is that it has two object references each of which needs bi-directional GIOP. One of the them uses Strong BiDirId and the other uses Weak BiDirId. You can think about it as follows. Client Side Server Side ------------------ ------------- obj1Ref -------------(cltObj1 BiDirId)---> obj1 cltObj1--POA(Weak) obj2Ref -------------(cltObj2 BiDirId)---> obj2 cltObj2--POA(Strong) If these two object references are using the same GIOP connection and the client runs these two invocations on two different threads, it is possible that the BI_DIR_GIOP_OFFER and BI_DIR_GIOP_ACCEPT of these two invocations are mixed in sequence unless your client ORB enforces a policy that disallow sending a GIOP Request to a connection until all previous invocations on that connection are back (GIOP Reply received). Mixing GIOP Requests and Replies are allowed in uni-directional GIOP. A client application doesn't really know how its invocations on object references are conducted by its ORB. It only knows that its invocations will be conducted properly by its ORB. One of the purposes of the CORBA spec is to define a standard environment in which we can write client and server applications in a standard way and expect a consistent behavior. The complexity of underlying things such as GIOP is left for the spec writers and implementors, not application writers. A spec writer needs to think about it in two different conceptual levels: one is in the application programming level and the other is in the protocol or API level. Besides, a spec writer might sometimes have to pay attention to how a protocol or API can possibly be implemented too. Cheers, Joncheng smime.p7s Subject: RE: Negotiate Session Message Issues Date: Fri, 9 Apr 2004 11:49:09 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Negotiate Session Message Issues Thread-Index: AcQdpX6D7L1E0DWNS32d9uGaMDq0oQAAxsxQACbgaKA= From: "Bergersen, Rebecca" To: "Bergersen, Rebecca" , "Joncheng Kuo" Cc: "Polar Humenn" , Hi! This has been an interesting discussion. However this is an FTF with a deadline. This issue was begun after the issue deadline passed. It didn't actually follow any of the standards for issues - there was no issue statement, no suggested resolution and it was not posted, though that isn't the fault of any of the FTF members. Additionally, while the concern is real and the discussion valuable, the issue isn't strictly relevant to an FTF. An FTF is supposed to clarify vague text and fix bugs that make a spec unimplementable. The fact that a failure/rejection of a strong BiDirId offer causes the connection to be not used by the server and hence any already accepted BiDirIds on that connection are also then rejected is defined clearly in the spec. It is implementable. You disagree with the design; you don't like the behavior that is specified. That's fair, but it isn't the job of an FTF to change a design that the MARS Platform Task Force was informed about and agreed to, that the Architecture Board agreed to, and that the Platform Technical Committee and the Business Committee agreed to, unless necessary to make the spec implementable. That's not to say that your comments aren't valid concerns. I think, at this stage, the best we can do is to make it clear in the text of the spec what the implications are of rejecting a strong BiDirId offer and emphasize the statement that the spec already makes in Section 15.8.4: "... in order to provide true protection of security sensitive objects, the CORBA security service should be utilized." So, I'd like to resolve the issue by adding the following at the end of the third paragraph in section 15.8.4: "However, the rejection of an offer of a strong BiDirId causes the connection to be rendered unusable by the server. BiDirIds that were accepted and possibly used over that connection prior to the rejection will no longer be accessible over that connection, though they will continue to be with any other connections over which they have been accepted. Applications need to consider this behavior in their design." Secondly, remove the word "However," from the first sentence of the fourth paragraph of section 15.8.4, since it's used in the previous sentence. As I said, I think your concerns are valid. I think an RTF can work out a technique for managing rejections so they don't have such an all-encompassing effect of accepted BiDirIds on the same connection. For example, the rejection could return the BiDirIds that are offensive and accept ones that aren't and the connection might continue to use ones that have already been accepted. The effects of that would have to be explored before putting it in the standard - an issue that should be done in an RTF. Another option might be to simply disallow use of strong BiDirIds and challenges. If an application wants security, it should use the security service or CSIV2 or SSL or some such, as the spec indicates. I'm sure there are other options as well. --Rebecca -----Original Message----- From: Bergersen, Rebecca Sent: Thursday, April 08, 2004 4:34 PM To: Joncheng Kuo Cc: Polar Humenn; firewall-traversal-ftf@omg.org Subject: RE: Negotiate Session Message Issues comments inline -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Thursday, April 08, 2004 4:10 PM To: Bergersen, Rebecca Cc: Polar Humenn; firewall-traversal-ftf@omg.org Subject: Re: Negotiate Session Message Issues Polar Humenn wrote: On Tue, 6 Apr 2004, Bergersen, Rebecca wrote: But still the problem remains, if multiple BiDirIds are included in the BI_DIR_OFFER and a WEAK or STRONG FAILED is sent back in the BI_DIR_ACCEPT, are all the offers considered invalid? Yep. Think of the implications of that statement. One implication that I can think of is as follows. Suppose a client sets up a POA with Weak BiDirId and makes an invocation. The server allows only Strong BiDirIds, so the server sends back a WEAK_FAILED. The client then sets up another POA with Strong BiDirId and makes another invocation. According to the spec, the server may accept the second, strong offer, assuming the verification succeeds. Right? If so, the communication sequence goes like the following: C ---(Weak OFFER)--> S C <--(WEAK_FAIL)--- S C ---(Strong OFFER)--> S C <--(NO_ERROR)--- S Now, if the client uses two different threads for each of setting up a POA and making an invocation. The the communication sequence may become like: C ---(Weak OFFER)--> S C ---(Strong OFFER)--> S C <--(WEAK_FAIL)--- S C <--(NO_ERROR)--- S From the interpretation of the spec at the beginning of this mail, one WEAK_FAIL shall fail all BiDir OFFERs sent. Thus, no bi-directional GIOP was allowed in the above two invocations. This interpretation leads to the following problems. There is no guarantee that a client using Strong OFFER to invoke a server allowing Strong BiDirIds will succeed. Furthermore, the behavior of the above invocation is not deterministic. The client, making a Strong OFFER, may or may not succeed depending on whether there are some Weak OFFERs proceeding the Strong OFFER (and not yet answered). Am I right? Joncheng [Bergersen, Rebecca] As I interpret it, a WEAK_FAIL applies to the BiDirIds on a single connection. Why would you make a weak offer followed by a strong offer on the same connection before receiving any response? That feels like a programming error. Subject: RE: Negotiate Session Message Issues Date: Fri, 9 Apr 2004 12:00:43 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Negotiate Session Message Issues Thread-Index: AcQeMDTxkezbay9rSA+NIXDmfMyzEgAG0xag From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: "Polar Humenn" , But the application can simply manage which BiDirIds are used on which connections. For example, it sets up the POAs that require weak BiDirIds; then it establishes the connections for them, with appropriate offers. Then it sets up the POAs that require strong BiDirIds... etc. It's up to the app to make sure it doesn't mix strong and weak BiDirIds over the same connection. We could point this out in the spec, if you think that's necessary. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Friday, April 09, 2004 8:43 AM To: Bergersen, Rebecca Cc: Polar Humenn; firewall-traversal-ftf@omg.org Subject: Re: Negotiate Session Message Issues Bergersen, Rebecca wrote: [Bergersen, Rebecca] As I interpret it, a WEAK_FAIL applies to the BiDirIds on a single connection. Why would you make a weak offer followed by a strong offer on the same connection before receiving any response? That feels like a programming error. A client application does know about connections, it knows only object references and how to invoke these object references. Whether two object references are using the same GIOP connection is known only to the client ORB, but not client applications. Thus, in my example, all the client application knows is that it has two object references each of which needs bi-directional GIOP. One of the them uses Strong BiDirId and the other uses Weak BiDirId. You can think about it as follows. Client Side Server Side ------------------ ------------- obj1Ref -------------(cltObj1 BiDirId)---> obj1 cltObj1--POA(Weak) obj2Ref -------------(cltObj2 BiDirId)---> obj2 cltObj2--POA(Strong) If these two object references are using the same GIOP connection and the client runs these two invocations on two different threads, it is possible that the BI_DIR_GIOP_OFFER and BI_DIR_GIOP_ACCEPT of these two invocations are mixed in sequence unless your client ORB enforces a policy that disallow sending a GIOP Request to a connection until all previous invocations on that connection are back (GIOP Reply received). Mixing GIOP Requests and Replies are allowed in uni-directional GIOP. A client application doesn't really know how its invocations on object references are conducted by its ORB. It only knows that its invocations will be conducted properly by its ORB. One of the purposes of the CORBA spec is to define a standard environment in which we can write client and server applications in a standard way and expect a consistent behavior. The complexity of underlying things such as GIOP is left for the spec writers and implementors, not application writers. A spec writer needs to think about it in two different conceptual levels: one is in the application programming level and the other is in the protocol or API level. Besides, a spec writer might sometimes have to pay attention to how a protocol or API can possibly be implemented too. Cheers, Joncheng Date: Tue, 6 Apr 2004 09:17:09 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: firewall-traversal-ftf@omg.org, issues@omg.org Subject: RE: Negotiate Session Message Issues Albeit answered out of context with the other questions in this issue not yet assigned a number, this protocol needs to be overhauled. Comments inline. On Wed, 24 Mar 2004, Bergersen, Rebecca wrote: > > Answer inline... > > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Monday, March 22, 2004 8:16 AM > > To: firewall-traversal-ftf@omg.org; issues@omg.org > > Subject: Negotiate Session Message Issues > > > > > > > > If a service context negotiation fails by way of the NegotiateSession > > message in either direction. how does the sender (client or > > servers side) > > get an indication back to the sender? > > > > At the end of section 15.8.1 in the revised GIOP chapter, starting on page 15-62, the following paragraphs describe the protocol: > > "When the server receives a BI_DIR_GIOP_OFFER context it must send back > a BI_DIR_GIOP_ACCEPT context in both the strong and weak identification > cases. Is this a "shall", a "should" or a best effort? The server could, in fact, be asking for "user" intervention about whether to accept sending requests over this connection or even for a particular offer, which might take some time, and might not get replied to at all. Furthermore, this message seems like it could arrive at any time after any BI_DIR_OFFER message! Even after many BI_DIR_OFFERs are applied for, such as with your "5 at a time" case. The STRONG_FAILED case seems to state that the verification failed, which means that ONLY one strong offer has to fail for the connection to be rendered useless. And this indication can come after some have already been set up and used! The next paragraph states that if the strong failed, the client might make a weak offer. So, multiple OFFERs can come down the channel. Being that Weak and Strong are mixed in the same BI_DIR_GIOP_OFFER service context, BI_DIR_CHALLENGE and BI_DIR_RESPONSE messages may be delivered separately. What happens if some Weak offers are refused, yet others succeed? Which BiIds doe the ACCEPT message apply to? Finally, being that BI_DIR_OFFER messages can be multiplexed over GIOP Requests/Replies and NegotiationSession messages at the whim of the ORBs, which BI_DIR_OFFER messages does each BI_DIR_ACCEPT message apply to? This protocol needs to be overhauled. Don't you agree? -Polar > If the server is willing to use connections bidirectionally, > possibly pending verification of BiDirIds, then the server will indicate > BI_DIR_NO_ERROR. Additionally, there are some conditions under which a > server ORB knows that it will not accept a client ORB's bi-directional > connection offer. For instance, a server ORB might not implement making > invocations over a bi-directional connection, or the server might only > accept strong client identification and the client makes weak > BI_DIR_GIOP_OFFERs. In those cases, the server ORB must respond with a > BI_DIR_GIOP_ACCEPT service context in the corresponding GIOP Reply or > NegotiateSession message. The BI_DIR_GIOP_ACCEPT service context can > also be used to indicate to the client that the challenge/response > identity verification failed for one or more BiDirIds. The > BI_DIR_GIOP_ACCEPT service context is defined below. > > module GIOP { > typedef unsigned short BiDirError; > const BiDirError BI_DIR_NO_ERROR = 0; > const BiDirError BI_DIR_UNSUPPORTED = 1; > const BiDirError BI_DIR_WEAK_FAILED = 2; > const BiDirError BI_DIR_STRONG_FAILED = 3; > // The BI_DIR_GIOP_ACCEPT service context contains a > // BiDirError value indicating any errors encountered. > const IOP::ServiceId BI_DIR_GIOP_ACCEPT = xx; // OMG Allocated > }; > > The value BI_DIR_UNSUPPORTED indicates that the server does not support > the use of bi-directional GIOP at all. The value BI_DIR_WEAK_FAILED > indicates that the server will not accept weak client identification. > The value BI_DIR_STRONG_FAILED indicates that the client failed the > challenge response and the server will not make bi-directional > invocations over that connection. > > The action taken by the client ORB when receiving a BI_DIR_GIOP_ACCEPT > is undefined. Because the client ORB will not necessarily have any > outstanding invocations to notify of the error, the client ORB might > take action to correct the error. For instance, if the client receives > the BI_DIR_WEAK_FAILED error, the client might attempt another > BI_DIR_GIOP_OFFER using strong identification if available. However, in > most cases the client ORB will only be able to optionally log the error > or otherwise notify the user of the error in a proprietary manner. > ------------------------------------------------------------------- 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: Tue, 6 Apr 2004 12:57:59 -0400 (EDT) From: Polar Humenn To: Tom Rutt Cc: "Bergersen, Rebecca" , firewall-traversal-ftf@omg.org Subject: Re: Negotiate Session Message Issues On Tue, 6 Apr 2004, Tom Rutt wrote: > >Is this a "shall", a "should" or a best effort? The server could, in fact, > >be asking for "user" intervention about whether to accept sending requests > >over this connection or even for a particular offer, which might take some > >time, and might not get replied to at all. > > > > > What is ambiguous about "it must send back a BI_DIR_GIOP_ACCEPT context" > In your example the response will be delayed, but I do not understand > the problem. > > > >Furthermore, this message seems like it could arrive at any time after any > >BI_DIR_OFFER message! Even after many BI_DIR_OFFERs are applied for, such > >as with your "5 at a time" case. > > > > > Are you saying that more than one unacked BI_DIR_OFFER being sent on the > same transport connection > causes the problem? The question is, is the BI_DIR_GIOP_ACCEPT an ACK for a particular BI_DIR_GIOP_OFFER. If so, then there must be an explicit sequential ordering to each BI_DIR_OFFER. This basically means that one offer can hold up the affirmations of any subsequent ones. Is that really what we want? Maybe so. Also, if one particular BIDirId fails in a BI_DIR_GIOP_Offer, that would mean they all fail. If that is the case, then how does the ORB know which one, maybe, to retry? I suppose you could go one at a time after that? > >The STRONG_FAILED case seems to state that the verification failed, which > >means that ONLY one strong offer has to fail for the connection to be > >rendered useless. And this indication can come after some have already > >been set up and used! > > > >The next paragraph states that if the strong failed, the client might make > >a weak offer. So, multiple OFFERs can come down the channel. > > > >Being that Weak and Strong are mixed in the same BI_DIR_GIOP_OFFER service > >context, BI_DIR_CHALLENGE and BI_DIR_RESPONSE messages may be delivered > >separately. What happens if some Weak offers are refused, yet others > >succeed? Which BiIds doe the ACCEPT message apply to? > > > >Finally, being that BI_DIR_OFFER messages can be multiplexed over GIOP > >Requests/Replies and NegotiationSession messages at the whim of the ORBs, > >which BI_DIR_OFFER messages does each BI_DIR_ACCEPT message apply to? > > > > > This only occurs if multiple unacked BI_DIR_OFFER messages are sent on > the same transport connection. > Would disallowing sending a second offer until getting the reply from > the first fix the problem you describe? Not really. I imagine an ORB can keep track of the sequence of BI_DIR_OFFERS and keep track of the corresponding BI_DIR_ACCEPTs. But still the problem remains, if multiple BiDirIds are included in the BI_DIR_OFFER and a WEAK or STRONG FAILED is sent back in the BI_DIR_ACCEPT, are all the offers considered invalid? Also, the spec is worded in such a way that if the you get a ACCEPT with WEAK FAILED the server doesn't support weak offers (period). And if you get a STRONG FAILED, authentication failed, but the result says that the connection doesn't support bi-directional at all. That contradicts the statements that if you get a STRONG FAILED you can try Weak Offers after that. Cheers, -Polar > >This protocol needs to be overhauled. > > > >Don't you agree? > > > >-Polar > > > > > > > > > >>If the server is willing to use connections bidirectionally, > >>possibly pending verification of BiDirIds, then the server will indicate > >>BI_DIR_NO_ERROR. Additionally, there are some conditions under which a > >>server ORB knows that it will not accept a client ORB's bi-directional > >>connection offer. For instance, a server ORB might not implement making > >>invocations over a bi-directional connection, or the server might only > >>accept strong client identification and the client makes weak > >>BI_DIR_GIOP_OFFERs. In those cases, the server ORB must respond with a > >>BI_DIR_GIOP_ACCEPT service context in the corresponding GIOP Reply or > >>NegotiateSession message. The BI_DIR_GIOP_ACCEPT service context can > >>also be used to indicate to the client that the challenge/response > >>identity verification failed for one or more BiDirIds. The > >>BI_DIR_GIOP_ACCEPT service context is defined below. > >> > >>module GIOP { > >>typedef unsigned short BiDirError; > >>const BiDirError BI_DIR_NO_ERROR = 0; > >>const BiDirError BI_DIR_UNSUPPORTED = 1; > >>const BiDirError BI_DIR_WEAK_FAILED = 2; > >>const BiDirError BI_DIR_STRONG_FAILED = 3; > >>// The BI_DIR_GIOP_ACCEPT service context contains a > >>// BiDirError value indicating any errors encountered. > >>const IOP::ServiceId BI_DIR_GIOP_ACCEPT = xx; // OMG Allocated > >>}; > >> > >>The value BI_DIR_UNSUPPORTED indicates that the server does not support > >>the use of bi-directional GIOP at all. The value BI_DIR_WEAK_FAILED > >>indicates that the server will not accept weak client identification. > >>The value BI_DIR_STRONG_FAILED indicates that the client failed the > >>challenge response and the server will not make bi-directional > >>invocations over that connection. > >> > >>The action taken by the client ORB when receiving a BI_DIR_GIOP_ACCEPT > >>is undefined. Because the client ORB will not necessarily have any > >>outstanding invocations to notify of the error, the client ORB might > >>take action to correct the error. For instance, if the client receives > >>the BI_DIR_WEAK_FAILED error, the client might attempt another > >>BI_DIR_GIOP_OFFER using strong identification if available. However, in > >>most cases the client ORB will only be able to optionally log the error > >>or otherwise notify the user of the error in a proprietary manner. > >> > >> > >> > > > >------------------------------------------------------------------- > >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 > > > > > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: Negotiate Session Message Issues Date: Tue, 6 Apr 2004 18:06:44 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Negotiate Session Message Issues Thread-Index: AcQb+MksxeUlBv98R8aahsrxyi5vOwAJkSeQ From: "Bergersen, Rebecca" To: "Polar Humenn" , "Tom Rutt" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i36M8Qqq008106 Comments inline. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Tuesday, April 06, 2004 12:58 PM > To: Tom Rutt > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: Re: Negotiate Session Message Issues > > > On Tue, 6 Apr 2004, Tom Rutt wrote: > > > >Is this a "shall", a "should" or a best effort? The server > could, in fact, > > >be asking for "user" intervention about whether to accept > sending requests > > >over this connection or even for a particular offer, which > might take some > > >time, and might not get replied to at all. > > > > > > > > What is ambiguous about "it must send back a > BI_DIR_GIOP_ACCEPT context" > > In your example the response will be delayed, but I do not > understand > > the problem. > > > > > > >Furthermore, this message seems like it could arrive at > any time after any > > >BI_DIR_OFFER message! Even after many BI_DIR_OFFERs are > applied for, such > > >as with your "5 at a time" case. > > > > > > > > Are you saying that more than one unacked BI_DIR_OFFER > being sent on the > > same transport connection > > causes the problem? > > The question is, is the BI_DIR_GIOP_ACCEPT an ACK for a particular > BI_DIR_GIOP_OFFER. If so, then there must be an explicit sequential > ordering to each BI_DIR_OFFER. > That's how I read it. It's an ordered protocol. You initiate the offer. You wait for an ACK. > This basically means that one offer can hold up the > affirmations of any > subsequent ones. Is that really what we want? Maybe so. It doesn't hold up affirmations on other connections - only the connection waiting for the ACK. > > Also, if one particular BIDirId fails in a BI_DIR_GIOP_Offer, > that would > mean they all fail. If that is the case, then how does the > ORB know which > one, maybe, to retry? It's not the particular BiDirId that fails, it is the connection. The errors are connection-wide: NO_SUPPORT = no support for BiDir GIOP at all, WEAK_FAILED = server will not accept weak client IDs, STRONG_FAILED = client failed challenge and server will not make bidir invocations over that channel. The client knows what challenge was just made over the channel, so it knows what BiDirId is a problem. > > I suppose you could go one at a time after that? > > > >The STRONG_FAILED case seems to state that the > verification failed, which > > >means that ONLY one strong offer has to fail for the > connection to be > > >rendered useless. And this indication can come after some > have already > > >been set up and used! > > > > > >The next paragraph states that if the strong failed, the > client might make > > >a weak offer. So, multiple OFFERs can come down the channel. > > > The last paragraph in section 15.8.1 says: The action taken by the client ORB when receiving a BI_DIR_GIOP_ACCEPT is undefined. Because the client ORB will not necessarily have any outstanding invocations to notify of the error, the client ORB might take action to correct the error. For instance, if the client receives the BI_DIR_WEAK_FAILED error, the client might attempt another BI_DIR_GIOP_OFFER using strong identification if available. However, in most cases the client ORB will only be able to optionally log the error or otherwise notify the user of the error in a proprietary manner. > > >Being that Weak and Strong are mixed in the same > BI_DIR_GIOP_OFFER service > > >context, BI_DIR_CHALLENGE and BI_DIR_RESPONSE messages may > be delivered > > >separately. What happens if some Weak offers are refused, > yet others > > >succeed? Which BiIds doe the ACCEPT message apply to? > > > The accept is for the entire connection. Given that, I wouldn't mix and match ID types within the same offer. But, it is allowed if you want to do it. > > >Finally, being that BI_DIR_OFFER messages can be > multiplexed over GIOP > > >Requests/Replies and NegotiationSession messages at the > whim of the ORBs, > > >which BI_DIR_OFFER messages does each BI_DIR_ACCEPT > message apply to? Any failure is for every BiDirId offered over that connection. > > > > > > > > This only occurs if multiple unacked BI_DIR_OFFER messages > are sent on > > the same transport connection. > > Would disallowing sending a second offer until getting the > reply from > > the first fix the problem you describe? > > Not really. I imagine an ORB can keep track of the sequence of > BI_DIR_OFFERS and keep track of the corresponding BI_DIR_ACCEPTs. But > still the problem remains, if multiple BiDirIds are included in the > BI_DIR_OFFER and a WEAK or STRONG FAILED is sent back in the > BI_DIR_ACCEPT, are all the offers considered invalid? > Yep. > Also, the spec is worded in such a way that if the you get a > ACCEPT with > WEAK FAILED the server doesn't support weak offers (period). > And if you > get a STRONG FAILED, authentication failed, but the result > says that the > connection doesn't support bi-directional at all. > > That contradicts the statements that if you get a STRONG > FAILED you can > try Weak Offers after that. Actually, that's not what the spec says. It says if a WEAK fails you can try a STRONG, not vice versa. See the last paragraph of 15.8.1, quoted above. > > Cheers, > -Polar > > > > >This protocol needs to be overhauled. > > > > > >Don't you agree? > > > > > >-Polar > > > > > > > > > > > > > > >>If the server is willing to use connections bidirectionally, > > >>possibly pending verification of BiDirIds, then the > server will indicate > > >>BI_DIR_NO_ERROR. Additionally, there are some conditions > under which a > > >>server ORB knows that it will not accept a client ORB's > bi-directional > > >>connection offer. For instance, a server ORB might not > implement making > > >>invocations over a bi-directional connection, or the > server might only > > >>accept strong client identification and the client makes weak > > >>BI_DIR_GIOP_OFFERs. In those cases, the server ORB must > respond with a > > >>BI_DIR_GIOP_ACCEPT service context in the corresponding > GIOP Reply or > > >>NegotiateSession message. The BI_DIR_GIOP_ACCEPT service > context can > > >>also be used to indicate to the client that the challenge/response > > >>identity verification failed for one or more BiDirIds. The > > >>BI_DIR_GIOP_ACCEPT service context is defined below. > > >> > > >>module GIOP { > > >>typedef unsigned short BiDirError; > > >>const BiDirError BI_DIR_NO_ERROR = 0; > > >>const BiDirError BI_DIR_UNSUPPORTED = 1; > > >>const BiDirError BI_DIR_WEAK_FAILED = 2; > > >>const BiDirError BI_DIR_STRONG_FAILED = 3; > > >>// The BI_DIR_GIOP_ACCEPT service context contains a > > >>// BiDirError value indicating any errors encountered. > > >>const IOP::ServiceId BI_DIR_GIOP_ACCEPT = xx; // OMG Allocated > > >>}; > > >> > > >>The value BI_DIR_UNSUPPORTED indicates that the server > does not support > > >>the use of bi-directional GIOP at all. The value > BI_DIR_WEAK_FAILED > > >>indicates that the server will not accept weak client > identification. > > >>The value BI_DIR_STRONG_FAILED indicates that the client > failed the > > >>challenge response and the server will not make bi-directional > > >>invocations over that connection. > > >> > > >>The action taken by the client ORB when receiving a > BI_DIR_GIOP_ACCEPT > > >>is undefined. Because the client ORB will not necessarily have any > > >>outstanding invocations to notify of the error, the > client ORB might > > >>take action to correct the error. For instance, if the > client receives > > >>the BI_DIR_WEAK_FAILED error, the client might attempt another > > >>BI_DIR_GIOP_OFFER using strong identification if > available. However, in > > >>most cases the client ORB will only be able to optionally > log the error > > >>or otherwise notify the user of the error in a proprietary manner. > > >> > > >> > > >> > > > > > >------------------------------------------------------------------- > > >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 > > > > > > > > > > > > > -- > > ---------------------------------------------------- > > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > Date: Mon, 12 Apr 2004 09:42:17 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: Joncheng Kuo , firewall-traversal-ftf@omg.org Subject: RE: Negotiate Session Message Issues On Thu, 8 Apr 2004, Bergersen, Rebecca wrote: > [Bergersen, Rebecca] As I interpret it, a WEAK_FAIL applies to the > BiDirIds on a single connection. Why would you make a weak offer > followed by a strong offer on the same connection before receiving any > response? That's not the question with PROTOCOLS. You're just setting up a huge space for interoperability failures. > That feels like a programming error. It "feels" like a programming error? That's what we want our specs to do, is give us a "good feeling" that we are doing something correctly. Give me mine, with a pina-colada, and some California-hippie-community-based therapy. ------------------------------------------------------------------- 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, 12 Apr 2004 09:50:43 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: Joncheng Kuo , firewall-traversal-ftf@omg.org Subject: RE: Negotiate Session Message Issues On Fri, 9 Apr 2004, Bergersen, Rebecca wrote: > But the application can simply manage which BiDirIds are used on which > connections. For example, it sets up the POAs that require weak > BiDirIds; then it establishes the connections for them, with > appropriate offers. Then it sets up the POAs that require strong > BiDirIds... etc. It's up to the app to make sure it doesn't mix strong > and weak BiDirIds over the same connection. We could point this out in > the spec, if you think that's necessary. Oh gawd, not again. And "how?" may I ask, does the "app" "make sure it doesn't mix strong and week BiDirIds over the same connection"? -Polar > > --Rebecca > > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Friday, April 09, 2004 8:43 AM > To: Bergersen, Rebecca > Cc: Polar Humenn; firewall-traversal-ftf@omg.org > Subject: Re: Negotiate Session Message Issues > > > Bergersen, Rebecca wrote: > > > [Bergersen, Rebecca] As I interpret it, a WEAK_FAIL applies to the > BiDirIds on a single connection. Why would you make a weak offer > followed by a strong offer on the same connection before receiving any > response? That feels like a programming error. > > > A client application does know about connections, it knows only object > references and how to invoke these object references. Whether two object > references are using the same GIOP connection is known only to the > client ORB, but not client applications. > > Thus, in my example, all the client application knows is that it has two > object references each of which needs bi-directional GIOP. One of the > them uses Strong BiDirId and the other uses Weak BiDirId. You can think > about it as follows. > > Client Side Server Side > > ------------------ ------------- > > obj1Ref -------------(cltObj1 BiDirId)---> obj1 > > cltObj1--POA(Weak) > > > > obj2Ref -------------(cltObj2 BiDirId)---> obj2 > > cltObj2--POA(Strong) > If these two object references are using the same GIOP connection and > the client runs these two invocations on two different threads, it is > possible that the BI_DIR_GIOP_OFFER and BI_DIR_GIOP_ACCEPT of these two > invocations are mixed in sequence unless your client ORB enforces a > policy that disallow sending a GIOP Request to a connection until all > previous invocations on that connection are back (GIOP Reply received). > Mixing GIOP Requests and Replies are allowed in uni-directional GIOP. > > A client application doesn't really know how its invocations on object > references are conducted by its ORB. It only knows that its invocations > will be conducted properly by its ORB. One of the purposes of the CORBA > spec is to define a standard environment in which we can write client > and server applications in a standard way and expect a consistent > behavior. The complexity of underlying things such as GIOP is left for > the spec writers and implementors, not application writers. A spec > writer needs to think about it in two different conceptual levels: one > is in the application programming level and the other is in the protocol > or API level. Besides, a spec writer might sometimes have to pay > attention to how a protocol or API can possibly be implemented too. > > Cheers, > Joncheng > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100