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?

This issue was mentioned by Dave Stringer. I now file it as an issue.

When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available.

This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection.

On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down.

If this issue is a limitation that cannot be solved easily, we should spell it out in the spec.

Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue.

The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional
connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around.

For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection.

There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference.

On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and effective BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction?

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.

The connection_complete field of the FirewallPathRespContext is under specified.

The fourth paragraph (including IDL) from the end of Section 1.5.4, Firewall Service Context, says,

“Once the connection has been established, the last intelligent firewall in the FirewallPath sends a FIREWALL_PATH_RESP service context in another NegotiateSession message.”

However, the last paragraph of this section says that, when the connection is not completely established, a FIREWALL_PATH_RESP service context with the connection_complete field of false is sent.

Furthermore, when the connection_complete field is false, the spec does not explain what are the situations that may cause incomplete connection establishment and what the client shall do for “further processing”. Shall the FIREWALL_PATH_RESP service context also contains information indicating what the client shall do?

PROBLEM:
It is not defined what happens if a non-conformant implementation receives a BiDir offer.

RECOMMENDATION:
State that a non-conformant implementation need not do anything - it may simply ignore the offer.

PROBLEM:
The target (ORB, POA, object, thread) of the Export and Offer policies and the side of the connection involved is incompletely specified.

RECOMMENDATION:
Define the two sides of a connection as the connection 'Initiator' and connection 'Acceptor'. The usual terms of 'client' (Initiator) and 'server' (Acceptor) become confusing in a bi-directional situation. Given those terms for each side, specify that the Export and Offer policies are used on the Initiator side. Specify that the Export policy may be applied to the ORB, the POA and/or to the thread. Specify that the Offer policy can be applied to the Initiator ORB, to a reference in the Initiator for an object in the Acceptor, or to a thread in the Initiator ORB.

PROBLEM:
The BiDir GIOP Document discusses three stages of connection setup, but it is unclear when each stage begins and when it ends. It is also unclear what NegotiateSession or Firewall activity can take place in each stage and what the order of processing may be.

RECOMMENDATION:
Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup):

"...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE. After the connection is setup, there is a period before the first request or locate request where we can do session setup items. I think that in that period, only Bidir contexts can be sent, NOTHING ELSE. The first request or locate request indicates the connection_established period. Again, during that period I think only the Bidir contexts should be legal. This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message."

The title of Section 1.7, End-to-End Secure Connection, is misleading. There is no end-to-end security in the firewall traversal spec. All security mechanisms described in this spec are essentially mechanisms between a client, firewalls, and a server, not end-to-end. Thus, it is susceptible to the man-in-the-middle attack.

I'm saying we should fix the problem, but the title of this section and the caption of Figure 1-4 is certainly misleading. Besids, if the firewall traversal scheme described in the spec is actually susceptible to the man-in-the-middle attack, we may want to consider stating it somewhere in the spec rather than making people have a wrong impression that it is secure

The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send all BiDirIds on an ORB to every connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of every existing bi-directional connections (before or in the next request).

The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted.

Proposed resolution:
1. Extend the choices of the value field of the BidirectionalOfferPolicy:
ALLOW_ALL – same as ALLOW now, but the implication shall be explicitely stated in the spec
ALLOW_LISTED – a list of POAs being provided in the policy
DENY – same as it now
2. Add a field to the policy to allow a sequence of POAs being specified.

PROBLEM:
The BiDir GIOP document allows all of the contexts that can be found in a GIOP query or response message to be also allowed in a NegotiateSession message. However, the interplay among these contexts is undefined. An example is the use in NegotiateSession messages of both CodeSet negotiation and BiDir connection setup. What can be used in what order is not defined.

RECOMMENDATION:
Only bi-directional GIOP and firewall contexts may be used in a NegotiateSession message in this version of GIOP. The contexts are the following:

· BI_DIR_GIOP_OFFER
· BI_DIR_GIOP_CHALLENGE
· BI_DIR_GIOP_RESPONSE
· BI_DIR_GIOP_ACCEPT
· FIREWALL_PATH
· FIREWALL_PATH_RESP

Further contexts may be added to new versions of the BiDir GIOP spec as their interplay with the existing set and the order of their use is carefully analyzed and documented. This effectively limits the scope of the problem to the bidir protocol and use by the firewall. The order and stage of processing the above contexts is discussed in another Firewall issue.

PROBLEM:
The BiDir GIOP document specifies that all BiDirIds must be randomly generated. However, persistent POAs must use the same BiDirId across sessions since they are stored in the IOR.

RECOMMENDATION:
A new policy is created (BiDirIdGenerationPolicy) that contains two fields:
field 1, the ID generation method, will take the value 'RANDOM' or the value 'REPEATABLE'
field 2, the ID type, will take the value 'STRONG' or the value 'WEAK'

The random generation method is adequately documented. The repeatable method will always generate the same BiDirId for a given POA. This effectively makes the ID a constant, but without the concern for storage. It also results in the end-user not having to deal with BiDirIds - they are handled entirely by the infrastructure.

The values for the ID type indicate whether the type of BiDirId generated is strong or weak.

This policy is placed on the client ORB and/or the POA in question.

PROBLEM:
The BiDir GIOP document does not specify the connections over which a BI_DIR_GIOP_OFFER should be sent.

RECOMMENDATION:
A BI_DIR_GIOP_OFFER will be sent over all existing bi-directional connections. If there are none, then a new connection will be established and its bidirectionality initiated.

PROBLEM:
The actions that result from the failure of a BiDir challenge are unclear.

RECOMMENDATION:
The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed.

PROBLEM:
The BiDir GIOP document does not specify which BiDirIds and how many of them are sent in a BI_DIR_GIOP_OFFER.

RECOMMENDATION:
All unoffered BiDirIds are supplied in a BI_DIR_GIOP_OFFER.

I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know.

Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client.

In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation.

obj = ...; // target
obj.invoke_target(...);

In order for the above scenario to work, I derive the following implications from the spec.

1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on all of its POAs that have EXPORT policy ALLOW must be available at the server side.

This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on each bi-directional connection will also have to transmit the BiDirId for this new POA to the server side.

2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request.

If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on every bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that allows efficient implementation, though efficiency is not always a concern for everyone.

PROBLEM:
The second paragraph on page 15-60 of the revised GIOP chapter only allows a BiDirOfferContext to be sent to a server if the ORB-level policy permits it:

"If the client ORB policy permits bi-directional use of a connection, a Request or
NegotiateSession (see MARS/04-01-01) message can be sent to the server that
contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header that
indicates that this GIOP connection is bi-directional. The BiDirOfferContext
indicates to the server that the objects with the supplied BiDirIds are available for
invocation over that connection. To determine whether an ORB may support bidirectional
GIOP, the BidirectionalOfferPolicy has been defined (see Section 15.9,
"Bi-directional GIOP policy," on page 65)."

This, however, contradicts the rest of the document, which allows the ORB-level policy to be overriden at the object level. ("A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden
for specific object references received by the client ORB." - Section 15-9, page 15-66).

Additionally, the first sentence of the above paragraph is worded in such a way that it defines a connection as bidirectional before it has accepted as such by a server.

Finally, a spurious reference to the submission document is included in the first sentence ("see MARS/04-01-01").

RECOMMENDATION:
Rephrase the paragraph as follows:

If the effective BidirectionalOfferPolicy of an object in the client is set to ALLOW, a Request or NegotiateSession message that contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header can be sent to the server, offering bi-directional use of the connection. The BiDirOfferContext indicates to the server that the objects with the supplied BiDirIds are available for invocation over that connection. To determine if bidirectional GIOP may be supported, the BidirectionalOfferPolicy has been defined (see Section 15.9, "Bi-directional GIOP policy," on page 65).

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?

Does Codeset come before/with/after BiDir negotiation?

Can Codeset come before/with Firewall Traversal in Negotiate Session
meesages?

On a connection in which BiDir is negotiated, but no Codeset
is negotiated, will the reverse direction be able to negotiate
code set?

Does Codeset get negotiated in only the other direction?
If so, will that happen in Negotiate Session meesages orRequest Messages?

Does the CodeSet get negotiated in Negotiate Session?
If so, does Codeset continue to get negotiated in Requests?

The following paragraph raises an interesting issue. If we follow this to the letter

• since it says that the new version of GIOP is not backward compatible with the
  earlier versions of GIOP, it implicitly appears to make this new GIOP version a
  new "major" version of GIOP. Clearly we need to figure out a way to avoid doing
  this, since creating GIOP version 2.0 in this way raises all sorts of other issues.

From the second paragraph on page 1-30 of the Firewall Final Adopted Spec (ptc/04-04-01):

This document supercedes the previously adopted CORBA firewall specification. In
addition, the changes to bi-directional GIOP, specified in Chapter 15, supercede the
adopted specification for bi-directional GIOP. These specifications are not backwards
compatible with the previous specifications and they are intended to make it possible
to create a functional protocol for the interoperation of ORBs and firewalls.

There seems to be a discrepancy in the changes proposed to CSIIOP and CSI modules. The draft document has identical changes to both. I think the intent of the Errata was to have only one, just switch them from CSIIOP to CSI. However, Brian's convience document doesn't show the change. Now, the draft document ptc/2004-01-01 that we are voting on has both. What to do? Should that be represented by another document, namely CSI, with it's changes, just like 2004-01-02 is? Cheers, -Polar

Yeah, I see the problem. Yet another consequence of the adopted spec changing existing spec without calling out the change in the section meant to identify changes to existing specs. So it looks like the fix involves: 1. Section 1.9.2 and 1.9.3 in ptc/04-01-01 [henceforth referred to as document A] should disappear. 2. The first half of section of document A starting from the second para of the section and upto and including the last but one paragraph on page 1-20, should be appended to Section 24.2.5 "Identity Token Format" of Chapter 24 of Core with the title (that is the CSIv2 Chapter)[henceforth referred to as document B]. Also append a row to table 24-2 with info about ITTCompundToken. 3. The IDL in section 1.9.3 of document A should be merged properly into the IDL for the CSI module that appears in section 24.9.2 document B. 4. The addition to CSIIOP IDL as it appears in Section 1.5.2 of document A should be merged appropriately into the IDL for CSIIOP in section 24.9.3 of document B. 5. In document B insert a section 24.5.1.6 "TAG_IIOP_SEC_TRANS" with a two liner explanation of what this tag is together with the IDL for it from section 1.5.2 of document A. I'd suggest that we file this as an issue and resolve it in the FTF roughly along the lines suggested above.

The BidirectionalPolicy insufficient for persistent objects.

The BidirectinoalExport Policy is a POA policy and it only has two values
of ALLOW and DENY. If it is ALLOW, then a TAG_BI_DIR_GIOP componenet
should be placed in the IOR. It is stated that the ORB must generate a
random identifier when the POA is created. However, that will not work for
persistent objects in which the BiDirectional Offer must remain constant.

Also, there is no default specified if this policy is not placed on a POA,
and no default for the RootPOA.

As I understood it, the Firewall Traversal specification was to use new
CSIv2 Compound Identity types to give the target server the complex
principal composed of the client and the authenticating firewall traversal
path. The server was to be authenticated to the client in much the same
way. This functionality appears to be missing in the specification. It is
easily fixed by returning a CSIv2 IdentityTokenSeq from a successful
firewall negotiation, specifying the backwards firewall authentication
trail from the server to the client.

The Negotiate Session message is unwieldy in that if it is used to send
service contexts, there are no general ways to govern its use other than
by special rules, all of which special cases are not accounted for in the
specification.

For example, when do you sent Bidirectional service contexts as ooposed to
firewall contexts? Can you send transaction contexts? Codesets? Codebase?
CSIv2? Can you send BiDir service contexts while firewall contexts are
being processed?

The NegotiateSession message is a single typed GIOP message that is sent
between both Client and Server to negotiation service contexts, and
further to initiate and negotiate bidirectional GIOP.

Having a single message is problematic in that a connection, once
negotiated bidirectional may have different requirements for such things
like Codesets, etc. Getting a NegotiateSession message after a
bidrectional set up, the endpoints will have difficulty discerning the
orientation of the NegotiateSession message.

At the very least NegotateSession messages should have an orientation,
much like the GIOP Request and Reply messages do.

I'm not so sure they must be correlated with a "request id", but different
message types would help. I would suggest two messages,
NegotiateSessionRequest and NegotiateSessionReply to maintain the
client-server orientation, respectively.