RE: [ebxml-msg] a bi-partisan proposal

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Hello Jacques,

 

If WS-Reliability is considered as an option, could it provide end-to-end reliable messaging in situation 2 (b) too? Assuming a constraint that the reliable messaging headers must be piggy-backed with ebMS headers (assuming routing is based on these ebMS headers). When the sender knows which messages will end up at the same MSH (even if it does not know which particular MSH), it could send these messages as a group. If it does not even know this, it could use groups of cardinality one, functionality that ebMS 2.0 reliable messaging provides today. Security would be preserved too.

 

When end-to-end reliable messaging is not used, perhaps we need to consider two separate wsse:Security blocks to secure the exchange:

1: One that signs the complete SOAP with attachments message, including any WS-A and WS-RM headers, targeted at the next MSH.

2: A second header that signs (and encrypts) only the ebMS 3.0 header and all payloads, targeted at the ultimate receiver MSH.

An intermediary would remove the first wsse:Security header block and re-sign the message. The second wsse header, the ebMS 3.0 header and all payloads would be copied. In this scenario, the intermediary can forward messages in different sequences, not necessarily to the same ultimate receiving MSH, and it can even deliver some messages locally. An intermediary needs sequences to deliver to its associated endpoints and for any other intermediaries. Each intermediary is an end-point for WS-A and WS-RM processing, except for the special ACK "relaying" functionality.

 

I know proposing a second header violates the requirement that endpoints should not have to behave differently to support intermediaries, but we need to balance that against the requirement of end-to-end security. 

 

Pim

 

 

---

From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 13 February 2008 05:07
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] a bi-partisan proposal

Here is a bi-partisan proposal for a change ;-)

 

1. The core of an "Intermediary role" specification should primarily focus on such functions as store-and-forward, bridging MPCs, rules for bridging MEPs e.g. allowing a received pushed message to be pulled, etc.

- The routing function has to be assumed, but can remain unspecified, as it may depend on various header data anyway.

- the RM function can be largely ignored when specifying the above.

 

2. Reliability function: a couple of options should be specified.

 

(a) Because there will be multi-hop configurations where the Sender knows enough about the ultimate receiver endpoint so that routing is not an issue even for RM signals,  the end-to-end RM sequence should be an option. Note that this option is straightforward for conformance profiles that make use of WS-Reliability (no RM signals besides Acks). When using WS-ReliableMessaging, it will require routing support for RM signals (e.g. use of WSA, or other means TBD).

This option is the only "fully transparent" end-to-end RM (e.g. for security) and this alone justifies to support it although not possible in all multi-hop configurations dues to routing constraints. It is also very straightforward in terms of itnermediary conformance - once the routing is resolved.

 

(b) Because there will be multi-hop configurations where the routing of RM signals cannot be done e.g. to establish a stable RM sequence between two endpoint MSHs (e.g. because of too much dynamics on resolving MSHs even if partners are known, or because security issues require to "hide" a portion of the cloud) then end-to-end RM sequences cannot be established. In that case, an advanced intermediary profile will support RM sequences "bridging", so that end-to-end delivery assurance is still possible at least for "At-Least-Once", "At-Most-Once" and "Exactly-Once" delivery. This bridging can involve some Ack relaying techniques that need to be specified so as to depart as little as possible from standard RM module behavior.

 

Clearly, some multi-hop topologies might combine both (a) and (b). E.g. the I-cloud includes a "hidden" portion that has a well-known "gatekeeper" intermediary. Regardless of how many intermediaries are involved between a Sender endpoint MSH and a "hidden" ultimate Receiver MSH, it is possible to use a single RM sequence from Sender to Gatekeeper, and a single RM sequence from Gatekeeper to ultimate Receiver, while reducing the RM sequence bridging to the Gatekeeper only (all other intermediaries of the I-cloud being "transparent"). A non-transparent Gatekeeper would make sense anyway as  it is possible that the QoS on the hidden I-cloud is different (e.g. a VPN), so some Security processing may need to take place on the Gatekeeper, e.g. validating a sig on the RM headers that are removed, or removing encryption.

 

Hope that may relieve the deadlock... or provide enough wiggle room to move one step further.

 

Jacques