Issue 7353: use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous (firewall-traversal-ftf) Source: Real-Time Innovations (Mr. Dave Stringer, dstringer(at)rti.com) Nature: Uncategorized Issue Severity: Summary: ptc/04-04-06 section 15.9.1 (top of page 15-67) states: 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. What happens if an ACCEPT service context is not returned? Either immediately or ever? Can a connection initiator, having sent an OFFER SC, send any further GIOP messages over that connection prior to receiving the ACCEPT SC? Should a connection initiator, having sent an OFFER SC but not having received an ACCEPT SC, accept a Request (i.e in the reverse direction) on that connection? a) for an object whose POA's BiDirId has been offered and accepted? b) for an object whose POA's BiDirId has been offered but a corresponding ACCEPT has not yet been received? c) for an object whose POA's BiDirId has been offered and accepted only over a different connection (to that over which the Request arrives)? d) for an object whose POA has a BiDirId but it hasn't yet been offered? e) for any object (e.g. one whose POA doesn't have a BiDirId)? If an OFFER SC is sent on a Request message, can the corresponding ACCEPT SC be carried on any GIOP message from the connection acceptor? a) the associated Response b) a Response not associated with the Request c) a NegotiateSession message d) a Request message for an object whose POA's BiDirId has already been negotiated If an OFFER SC is sent on a NegotiateSession message, can the corresponding ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or must it come over a NegotiateSession message? If two POAs (with EXPORT policy) are created and their BiDirIds are sent separately in OFFER SCs on separate messages over a given connection, is a subsequently received ACCEPT SC deemed to relate to one or to both of the offered BiDirIds? Since I assume that a connection is effectively promoted to BiDir once the first ACCEPT SC (indicating no error) is received. What is the point of insisting that the connection acceptor "must" send additional ACCEPT SC? In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a GIOP Request message from the connection acceptor would imply that the connection acceptor has accepted the BiDirId. It would seem that the ACCEPT(no error variant) SC is completely superfluous. Given the ambiguities in the protocol, it seems likely that an implementation may find the real-world interactions to have broken its model of the protocol. What should a GIOP protocol machine do in such a situation? If the connection initiator deems that the OFFER-ACCEPT protocol has gone wrong should it be required to close the connection? As there is no correlation between OFFER SCs and ACCEPT SCs, on a given connection, does an ACCEPT (indicating an error) imply that the connection is in an indeterminate state and should be closed? If a connection is to be closed due to an error in the OFFER-ACCEPT protocol do the normal rules regarding outstanding invocations apply? Do they apply for both directions? Resolution: Revised Text: Actions taken: May 13, 2004: received issue Discussion: End of Annotations:===== ubject: use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous Date: Thu, 13 May 2004 15:14:03 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous Thread-Index: AcQ5N76aoaiKmejASDKzNtUxFD3Hww== From: "Dave Stringer" To: Cc: X-OriginalArrivalTime: 13 May 2004 22:14:03.0399 (UTC) FILETIME=[99782970:01C43937] ptc/04-04-06 section 15.9.1 (top of page 15-67) states: 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. What happens if an ACCEPT service context is not returned? Either immediately or ever? Can a connection initiator, having sent an OFFER SC, send any further GIOP messages over that connection prior to receiving the ACCEPT SC? Should a connection initiator, having sent an OFFER SC but not having received an ACCEPT SC, accept a Request (i.e in the reverse direction) on that connection? a) for an object whose POA's BiDirId has been offered and accepted? b) for an object whose POA's BiDirId has been offered but a corresponding ACCEPT has not yet been received? c) for an object whose POA's BiDirId has been offered and accepted only over a different connection (to that over which the Request arrives)? d) for an object whose POA has a BiDirId but it hasn't yet been offered? e) for any object (e.g. one whose POA doesn't have a BiDirId)? If an OFFER SC is sent on a Request message, can the corresponding ACCEPT SC be carried on any GIOP message from the connection acceptor? a) the associated Response b) a Response not associated with the Request c) a NegotiateSession message d) a Request message for an object whose POA's BiDirId has already been negotiated If an OFFER SC is sent on a NegotiateSession message, can the corresponding ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or must it come over a NegotiateSession message? If two POAs (with EXPORT policy) are created and their BiDirIds are sent separately in OFFER SCs on separate messages over a given connection, is a subsequently received ACCEPT SC deemed to relate to one or to both of the offered BiDirIds? Since I assume that a connection is effectively promoted to BiDir once the first ACCEPT SC (indicating no error) is received. What is the point of insisting that the connection acceptor "must" send additional ACCEPT SC? In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a GIOP Request message from the connection acceptor would imply that the connection acceptor has accepted the BiDirId. It would seem that the ACCEPT(no error variant) SC is completely superfluous. Given the ambiguities in the protocol, it seems likely that an implementation may find the real-world interactions to have broken its model of the protocol. What should a GIOP protocol machine do in such a situation? If the connection initiator deems that the OFFER-ACCEPT protocol has gone wrong should it be required to close the connection? As there is no correlation between OFFER SCs and ACCEPT SCs, on a given connection, does an ACCEPT (indicating an error) imply that the connection is in an indeterminate state and should be closed? If a connection is to be closed due to an error in the OFFER-ACCEPT protocol do the normal rules regarding outstanding invocations apply? Do they apply for both directions? Date: Fri, 14 May 2004 13:00:59 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Dave Stringer Cc: firewall-traversal-ftf@omg.org Subject: Re: use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous Whatever it does, it has to be able to handle a situation where the server is a GIOP 1.4 server and has chosen not to implement the optional BiDir functionality. Such a server should be able to continue to function as a simple 1.4 server (i.e. with no BiDir) This implies that absence of participation in the BiDir handshake cannot cause non-BiDir communication to stop working. Jishnu. Dave Stringer wrote: ptc/04-04-06 section 15.9.1 (top of page 15-67) states: 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. What happens if an ACCEPT service context is not returned? Either immediately or ever? Can a connection initiator, having sent an OFFER SC, send any further GIOP messages over that connection prior to receiving the ACCEPT SC? Should a connection initiator, having sent an OFFER SC but not having received an ACCEPT SC, accept a Request (i.e in the reverse direction) on that connection? a) for an object whose POA's BiDirId has been offered and accepted? b) for an object whose POA's BiDirId has been offered but a corresponding ACCEPT has not yet been received? c) for an object whose POA's BiDirId has been offered and accepted only over a different connection (to that over which the Request arrives)? d) for an object whose POA has a BiDirId but it hasn't yet been offered? e) for any object (e.g. one whose POA doesn't have a BiDirId)? If an OFFER SC is sent on a Request message, can the corresponding ACCEPT SC be carried on any GIOP message from the connection acceptor? a) the associated Response b) a Response not associated with the Request c) a NegotiateSession message d) a Request message for an object whose POA's BiDirId has already been negotiated If an OFFER SC is sent on a NegotiateSession message, can the corresponding ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or must it come over a NegotiateSession message? If two POAs (with EXPORT policy) are created and their BiDirIds are sent separately in OFFER SCs on separate messages over a given connection, is a subsequently received ACCEPT SC deemed to relate to one or to both of the offered BiDirIds? Since I assume that a connection is effectively promoted to BiDir once the first ACCEPT SC (indicating no error) is received. What is the point of insisting that the connection acceptor "must" send additional ACCEPT SC? In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a GIOP Request message from the connection acceptor would imply that the connection acceptor has accepted the BiDirId. It would seem that the ACCEPT(no error variant) SC is completely superfluous. Given the ambiguities in the protocol, it seems likely that an implementation may find the real-world interactions to have broken its model of the protocol. What should a GIOP protocol machine do in such a situation? If the connection initiator deems that the OFFER-ACCEPT protocol has gone wrong should it be required to close the connection? As there is no correlation between OFFER SCs and ACCEPT SCs, on a given connection, does an ACCEPT (indicating an error) imply that the connection is in an indeterminate state and should be closed? If a connection is to be closed due to an error in the OFFER-ACCEPT protocol do the normal rules regarding outstanding invocations apply? Do they apply for both directions? -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Management Software Organization Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Date: Fri, 14 May 2004 13:36:52 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: Re: use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous On Fri, 14 May 2004, Jishnu Mukerji wrote: > Whatever it does, it has to be able to handle a situation where the > server is a GIOP 1.4 server and has chosen not to implement the optional > BiDir functionality. You, know, we keep stressing this point about optionality. However, where in this specification does it say that BiDir or (Firewall Traversal for that matter, i.e. NegotiateSession) is optional? -Polar > Such a server should be able to continue to > function as a simple 1.4 server (i.e. with no BiDir) This implies that > absence of participation in the BiDir handshake cannot cause non-BiDir > communication to stop working. > > Jishnu. > > Dave Stringer wrote: > > > ptc/04-04-06 section 15.9.1 (top of page 15-67) states: > > > > 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. > > > > What happens if an ACCEPT service context is not returned? Either > > immediately > > or ever? > > > > Can a connection initiator, having sent an OFFER SC, send any further > > GIOP > > messages over that connection prior to receiving the ACCEPT SC? > > > > Should a connection initiator, having sent an OFFER SC but not having > > received > > an ACCEPT SC, accept a Request (i.e in the reverse direction) on that > > connection? > > a) for an object whose POA's BiDirId has been offered and accepted? > > b) for an object whose POA's BiDirId has been offered but a > > corresponding > > ACCEPT has not yet been received? > > c) for an object whose POA's BiDirId has been offered and accepted > > only over a > > different connection (to that over which the Request arrives)? > > d) for an object whose POA has a BiDirId but it hasn't yet been offered? > > e) for any object (e.g. one whose POA doesn't have a BiDirId)? > > > > If an OFFER SC is sent on a Request message, can the corresponding ACCEPT > > SC be carried on any GIOP message from the connection acceptor? > > a) the associated Response > > b) a Response not associated with the Request > > c) a NegotiateSession message > > d) a Request message for an object whose POA's BiDirId has already been > > negotiated > > > > If an OFFER SC is sent on a NegotiateSession message, can the > > corresponding > > ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or > > must it come over a NegotiateSession message? > > > > If two POAs (with EXPORT policy) are created and their BiDirIds are > > sent separately > > in OFFER SCs on separate messages over a given connection, is a > > subsequently > > received ACCEPT SC deemed to relate to one or to both of the offered > > BiDirIds? > > > > Since I assume that a connection is effectively promoted to BiDir once > > the first > > ACCEPT SC (indicating no error) is received. What is the point of > > insisting that > > the connection acceptor "must" send additional ACCEPT SC? > > > > In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a > > GIOP Request > > message from the connection acceptor would imply that the connection > > acceptor > > has accepted the BiDirId. It would seem that the ACCEPT(no error > > variant) SC is > > completely superfluous. > > > > Given the ambiguities in the protocol, it seems likely that an > > implementation may > > find the real-world interactions to have broken its model of the > > protocol. What should > > a GIOP protocol machine do in such a situation? > > > > If the connection initiator deems that the OFFER-ACCEPT protocol has > > gone wrong > > should it be required to close the connection? > > > > As there is no correlation between OFFER SCs and ACCEPT SCs, on a given > > connection, does an ACCEPT (indicating an error) imply that the > > connection is > > in an indeterminate state and should be closed? > > > > If a connection is to be closed due to an error in the OFFER-ACCEPT > > protocol do > > the normal rules regarding outstanding invocations apply? Do they > > apply for both > > directions? > > > > -- > Jishnu Mukerji > Senior Systems Architect 1001 Frontier Road, Suite 300 > Technology Office Bridgewater NJ 08807, USA > Management Software Organization Tel: +1 908 243 8924 > Hewlett-Packard Company Fax: +1 908 243 8850 > mailto: jishnu@hp.com > > ------------------------------------------------------------------- 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: use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous Date: Fri, 14 May 2004 14:55:33 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous Thread-Index: AcQ52i7E8XEwIB0vQFyNBnWyON6t1QAChaIA From: "Bergersen, Rebecca" To: "Polar Humenn" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4EIwoun028503 The "Conformance and CORBA Changes" section of the Firewall Chapter says "Section 1.10 is optional, as is implementation of bi-directional GIOP." This is not entirely accurate, however, as the Firewall chapter has been renumbered and there is no longer a section 1.10! I found nothing in the GIOP chapter that indicated that BiDir GIOP was optional. Words indicating its optionality should be added to Chapter 15 and the Firewall chapter should be fixed, pointing to whatever used to be section 1.10. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Friday, May 14, 2004 1:37 PM > To: firewall-traversal-ftf@omg.org > Subject: Re: use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous > > > On Fri, 14 May 2004, Jishnu Mukerji wrote: > > > Whatever it does, it has to be able to handle a situation where the > > server is a GIOP 1.4 server and has chosen not to implement > the optional > > BiDir functionality. > > You, know, we keep stressing this point about optionality. > However, where > in this specification does it say that BiDir or (Firewall > Traversal for > that matter, i.e. NegotiateSession) is optional? > > -Polar > > > > Such a server should be able to continue to > > function as a simple 1.4 server (i.e. with no BiDir) This > implies that > > absence of participation in the BiDir handshake cannot > cause non-BiDir > > communication to stop working. > > > > Jishnu. > > > > Dave Stringer wrote: > > > > > ptc/04-04-06 section 15.9.1 (top of page 15-67) states: > > > > > > 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. > > > > > > What happens if an ACCEPT service context is not returned? Either > > > immediately > > > or ever? > > > > > > Can a connection initiator, having sent an OFFER SC, send > any further > > > GIOP > > > messages over that connection prior to receiving the ACCEPT SC? > > > > > > Should a connection initiator, having sent an OFFER SC > but not having > > > received > > > an ACCEPT SC, accept a Request (i.e in the reverse > direction) on that > > > connection? > > > a) for an object whose POA's BiDirId has been offered > and accepted? > > > b) for an object whose POA's BiDirId has been offered but a > > > corresponding > > > ACCEPT has not yet been received? > > > c) for an object whose POA's BiDirId has been offered > and accepted > > > only over a > > > different connection (to that over which the > Request arrives)? > > > d) for an object whose POA has a BiDirId but it hasn't > yet been offered? > > > e) for any object (e.g. one whose POA doesn't have a BiDirId)? > > > > > > If an OFFER SC is sent on a Request message, can the > corresponding ACCEPT > > > SC be carried on any GIOP message from the connection acceptor? > > > a) the associated Response > > > b) a Response not associated with the Request > > > c) a NegotiateSession message > > > d) a Request message for an object whose POA's BiDirId > has already been > > > negotiated > > > > > > If an OFFER SC is sent on a NegotiateSession message, can the > > > corresponding > > > ACCEPT SC come piggy-backed on any GIOP message (that can > carry SCs) or > > > must it come over a NegotiateSession message? > > > > > > If two POAs (with EXPORT policy) are created and their > BiDirIds are > > > sent separately > > > in OFFER SCs on separate messages over a given connection, is a > > > subsequently > > > received ACCEPT SC deemed to relate to one or to both of > the offered > > > BiDirIds? > > > > > > Since I assume that a connection is effectively promoted > to BiDir once > > > the first > > > ACCEPT SC (indicating no error) is received. What is the point of > > > insisting that > > > the connection acceptor "must" send additional ACCEPT SC? > > > > > > In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a > > > GIOP Request > > > message from the connection acceptor would imply that the > connection > > > acceptor > > > has accepted the BiDirId. It would seem that the ACCEPT(no error > > > variant) SC is > > > completely superfluous. > > > > > > Given the ambiguities in the protocol, it seems likely that an > > > implementation may > > > find the real-world interactions to have broken its model of the > > > protocol. What should > > > a GIOP protocol machine do in such a situation? > > > > > > If the connection initiator deems that the OFFER-ACCEPT > protocol has > > > gone wrong > > > should it be required to close the connection? > > > > > > As there is no correlation between OFFER SCs and ACCEPT > SCs, on a given > > > connection, does an ACCEPT (indicating an error) imply that the > > > connection is > > > in an indeterminate state and should be closed? > > > > > > If a connection is to be closed due to an error in the > OFFER-ACCEPT > > > protocol do > > > the normal rules regarding outstanding invocations apply? Do they > > > apply for both > > > directions? > > > > > > > > -- > > Jishnu Mukerji > > Senior Systems Architect 1001 Frontier Road, Suite 300 > > Technology Office Bridgewater NJ 08807, USA > > Management Software Organization Tel: +1 908 243 8924 > > Hewlett-Packard Company Fax: +1 908 243 8850 > > mailto: jishnu@hp.com > > > > > > ------------------------------------------------------------------- > 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, 14 May 2004 15:34:40 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Polar Humenn Cc: firewall-traversal-ftf@omg.org Subject: Re: use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous Polar Humenn wrote: On Fri, 14 May 2004, Jishnu Mukerji wrote: Whatever it does, it has to be able to handle a situation where the server is a GIOP 1.4 server and has chosen not to implement the optional BiDir functionality. You, know, we keep stressing this point about optionality. However, where in this specification does it say that BiDir or (Firewall Traversal for that matter, i.e. NegotiateSession) is optional? -Polar It says so clearly in the adopted specification section 6 last sentence of the first paragraph which reads: "Section 4.10 is optional, as is implementation of bi-directional GIOP.". Section 4.10 BTW was the section titled "Implications of Secure Transport", and for the life of me I can't figure out what the implications of that being optional are. But the part about BiDir GIOP being optional seems to be pretty clear. Unfortunately, the adopted specification was of remarkably and unusually poor quality in its clarity.:-( Anyhow in moving things around to the various documents the contents of that sentence got dropped somewhere. The issue of impact on performance of plain old GIOP engines due to the necessity to respond to various BiDir offers was brought up both in the TF and the AB by several people when this was adopted and that is why that additional optionality was added. So what we need to do is rescue the "Implementation of BiDir GIOP is optional" and place them near the beginning of section 15.9. In addition we should clarify what this means..... e.g. an implementation of GIOP 1.4 that does not implement BiDir GIOP is allowed to ignore without running afoul of the standard The general practice in the past has been that for any new specifications that are adopted impacting the Core, unless it is specifically adopted with a statement saying that it is mandatory, it is assumed to be optional.. I think Firewall falls in this category. Jishnu.