RE: Different Levels of Reliable Messaging

RE: Different Levels of Reliable MessagingDavid,

I'm not suggesting that XMLP be dependent on WS Security. I am merely
suggesting that XMLP allow for a "return signature" to be encapsulated in
the ack message. XMLP doesn't have to say how it is generated, only what is
generated and where it goes. And even if XMLP must specify how it is
generated, in my understanding that would require support for XML-Sig, which
is a W3C recommendation, so definitely something that XMLP could consider.

arkin

   -----Original Message-----
  From: Burdett, David [mailto:david.burdett@commerceone.com]
  Sent: Tuesday, December 17, 2002 12:38 PM
  To: 'Assaf Arkin'; Burdett, David; Cutler, Roger (RogerCutler); Ricky Ho;
www-ws-arch@w3.org
  Subject: RE: Different Levels of Reliable Messaging


  Assaf

  I agree with everything you say, except that you wouldn't always want to
do authentication, non-repudiation etc. Therefore it should be a layer on
top.

  I also think that there a real "layering" issues here, that have not been
completely thought through. Some of the questions are:
  1. Should you make XMLP dependent on WS Security which I think you are
suggesting. I don't think so, especially as XMLP is a W3C activity and WS
Security is from OASIS
  2. I don't think that non-repudiation of receipt is distriincly separate
from reliable messaging although they have the need for the same
functionality i.e. acknowledgement messages
  3. If we realize that there are overlaps between these different areas,
how should they be handled, for example:
    a) Put everything into one spec, acknowledgement messages,
authentication, reliable messaging, XMLP, etc
    b) Have separate specs - but then which ones should they be and who
should develop them and how do you work out which ones should be used in
combination.

  Thoughts?

  David

    -----Original Message-----
    From: Assaf Arkin [mailto:arkin@intalio.com]
    Sent: Monday, December 16, 2002 11:06 AM
    To: Burdett, David; Cutler, Roger (RogerCutler); Ricky Ho;
www-ws-arch@w3.org
    Subject: RE: Different Levels of Reliable Messaging


    David,

    That's a good question.

    When you receive a message that is digitally signed you would want to
acknowledge the message with a copy of that signature, indicating your copy
is identical to the original copy, and futher sign that acknowledgement so
the acknowledgment does not get modified en route. That is something that
XML-Sig gives you and can be done directly at the XMLP level.

    Beyond that you do want to validate that the sender is authentic, that
the sender can send you such messages, that the portions of the message that
need to be signed by the sender are indeed signed by the sender (as opposed
to an intermediary), etc. That is something an RM could (and IMHO should)
do, and WS-Security does offer all the information required to achieve that.

    Even if the RM performs all these security checks, I still believe it
should only pose one requirement on XMLP and that is the ability to send
back an ack that includes the relevant signature to indicate that the
received message is an identical copy to the sent message. Everything else
would indeed be done at a higher level and could indeed leverage applicable
specifications, such as WS-Security.

    arkin



      Assaf

      You wrote ...

      >>>However, if you want to prevent the message that is sent from being
modified by some intermediary (accidentally, or intentionally, e.g. an
attacker) you would sign the message. In that case, the acknowledgment
should include not just the message, but also a reciprocal signature to
confirm the message content was not changed en route.<<<

      This sounds like Non-Repduiation of Receipt (NNR) - which I agree you
need.

      Now is this something that a Reliable Messaging Group should do, or
the WS Security group in OASIS perhaps ;)

      David





      -----Original Message-----
      From: Assaf Arkin [mailto:arkin@intalio.com]
      Sent: Saturday, December 14, 2002 2:06 PM
      To: Cutler, Roger (RogerCutler); Ricky Ho; Burdett, David; Burdett,
      David; www-ws-arch@w3.org
      Subject: RE: Different Levels of Reliable Messaging




      > How about, however, "I got the message and it has not been altered
from
      > what you sent".  This is, of course, enabled by digital signatures
and I
      > think it is a reasonable part of the "ack" mechanism, as then would
be,
      > "I got the message but it is NOT what you sent".

      Roger,

      I one word: yes.

      If you can confirm that a message was recieved not just by it's
identifier
      but also by its contents you significantly improve the reliability of
the
      protocol.

      Typically we use reliable protocols, such as TCP that ensure the
message
      sent is exactly the message received, and TCP uses a simple signature
      mechanism to confirm that fact (CRC if I remember correctly).

      However, if you want to prevent the message that is sent from being
modified
      by some intermediary (accidentally, or intentionally, e.g. an
attacker) you
      would sign the message. In that case, the acknowledgment should
include not
      just the message, but also a reciprocal signature to confirm the
message
      content was not changed en route.

      arkin

      >
      > -----Original Message-----
      > From: Ricky Ho [mailto:riho@cisco.com]
      > Sent: Friday, December 13, 2002 8:13 PM
      > To: Burdett, David; Burdett, David; www-ws-arch@w3.org
      > Subject: RE: Different Levels of Reliable Messaging
      >
      >
      >
      > Thanks David, see my followup questions (embedded)
      >
      >
      > >The "ack" doesn't need to be per-message based.  I can send an ack
for
      > >a bunch of message (of course, sequence number is used).
<DB>Agreed,
      > >but now you are adding in an extra level of complexity (sequence
      > >number) that often won't be needed. What I would suggest is that
you
      > >split this into another two levels: 1. Sequencing Support. This is
a
      > >protocol, built on top of reliable messaging that ensures that
messages
      >
      > >arrive in the sequence they were sent. 2. Reduced Frequency
      > >Acknowledgement Messages. You could then vary the reliable
messaging
      > >protocol so that a request for an acknowledgement is every so many
      > >messages and if it is not received, then corrective action is
taken.
      > ></DB>
      >
      > <Ricky>
      > I was presuming that sequence ordering to be part of reliable
      > messaging.  Seems like you consider this as a separate layer.
</Ricky>
      >
      >
      > >The "time expiry" is unreliable because clocks may be unsync.
      > ><DB>Absolutely right.
      > >
      > >The "cheap", but as you say inaccurate way to do this is to set and
      > >compare "expires at" using a local system clock. The fact that it
is an
      >
      > >approximation to the true time is often not a big issue especially
if
      > >you are doing end-to-end acks where the time between sending a
message
      > >and when it expires is long compared to the clock accuracy (e.g. a
      > >day). Even so, it is probably good practice that Reliable Messaging
      > >solutions take this uncertainty in the accuracy of the time into
      > >account and extend the "expires at" to some time beyond the nominal
      > >expiry time.
      > >
      > >If time accuracy is *fairly* critical, then the sender and receiver
of
      > >a message SHOULD agree to keep their clocks accurate using, for
      > >example, protocols such as the Network Time Protocol. If accuracy
is
      > >*really* critical then you can include in the message the accuracy
to
      > >which the system at the destination MUST keep its clocks. If the
system
      >
      > >does not keep its clocks accurate or cannot keep them accurate
enough,
      > >then the destination should reject the message and not process
it.</DB>
      >
      > <Ricky>
      > Maybe I misunderstood the purpose of expiration time.  I guess your
      > purpose
      > of time expiry mechanism is for reducing the "in-doubt" condition.
So
      > if A
      > send a message to B which is valid within T minutes.  And A doesn't
      > receive
      > an ACK from B.  So A keep resending but still doesn't get back the
ACK
      > after (T+10) minutes.  Can A at this point simply gives up and
conclude
      > that the message is undelivered ?  All I try to say that "A cannot
draw
      > that conclusion".  Sorry, I agree this is irrelevant with the clock
sync
      >
      > problem.
      > So I see the expiration time is purely an application level semantic
      > (e.g.
      > you send a bid response which is valid within one day).  I don't see
      > what
      > role the expiration time play at the RM level.  I must be missing
      > something
      > here.
      > </Ricky>
      >
      >
      > >I don't think there should be a step 4 in LEVEL 3.  Step 3 should
say
      > >"Have you receive the message ?  If not, forget the message
afterwards"
      >
      > ><DB>I don't think you can always say this. For example if you want
to
      > >place an order and there is only one supplier, then even if you
message
      >
      > >failed, you might want to resend it if the connection became
available
      > >later. In this case, the conent/payload/body of the message might
be
      > >identical but in other ways it was a completely new message.</DB>
      >
      > <Ricky>
      > What I'm trying to prevent is the situation that the request message
      > arrives the receiver after the query (so the receiver respond: "I
      > haven't
      > got it"), but before the "forget message" get there.  In this case,
the
      > message has been delivered, but the sender think it hasn't.
      >
      > Going back to your example, you should send a query to the supplier
      > "Have
      > you receive my purchase order with message id=12345 ?  if you
haven't,
      > ignore that message if it arrives later".
      > If you get back an answer "NO", resend your same purchase order with
a
      > new
      > message id=98765.
      >
      > However, if you send a separate "forgot" message after you receive a
      > "NO".  Then it is possible that the receiver get 2 purchase order
(one
      > with
      > message id = 12345 and the other with id = 98765).
      > </Ricky>
      >
      >
      > >I think LEVEL 5 should be done at the transaction layer, below
      > >choreography, but above reliable messaging.  Using some
      > >2-phase-interaction style like BTP. <DB>Quite possibly. The problem
      > >with two phase commit is the action you take when you geet a
failure
      > >(i.e. a rollback) may not always the right one and often it can be
      > >impossible to do. For example, if you want to roll back a payment,
but
      > >the payment has already gone to the bank, then its to late. You
have to
      >
      > >do a reversal, or refund instead. Both of these would leave a trace
in
      > >the records of what happened.</DB>
      >
      > <Ricky>
      > Of course, you can always handle exception at the application level,
      > which
      > can recovered from a partial failure situation is a very application
      > specific manner.  However, this can complicates the application flow
      > because it mixes the normal flow with exception handling logic under
      > different failure scenario.
      >
      > The beauty of transaction processing is that application can
encapsulate
      >
      > multiple activities within a transaction block and safely assume
      > everything
      > will automatically undone.  In other words, the application doesn't
need
      > to
      > worry about all failure situations.
      >
      > Lets look at a simple case where A is sending a "money transfer
request"
      > to
      > B, which sends a "money deposit request" to C as well as another
"money
      > withdrawal request" to D.  Let me illustrate the flow based on a
2-phase
      >
      > handshaking.
      >
      > 1) A sends "transfer" to B, and wait for "Prepared-ACK-transfer"
from B
      > 2) B sends "deposit" to C, and wait for "Prepared-ACK-deposit" from
C
      > 3) B sends "withdrawal" to D and wait for "Prepared-ACK-withdrawal"
from
      > D
      > 4) After B got back all the "Prepared-ACK" from C and D, it send
back
      > the
      > "Prepared-ACK-transfer" to A
      >
      > 5) A sends "commit" to B, and wait for "Commited-ACK-transfer" from
B
      > 6) B sends "commit" to C, and wait for "Commited-ACK-deposit" from C
      > 7) B sends "commit" to D and wait for "Commited-ACK-withdrawal" from
D
      > 8) After B got back all the "Commit-ACK" from C and D, it send back
the
      > "Commited-ACK-transfer" to A
      >
      > </Ricky>
      >
      > By the way, you have raised some very good points David !
      >
      > Best regards,
      > Ricky
      >
      >
      >