RE: TRP Error Handling Spec Draft

["Burdett, David" <david.burdett@commerceone.com>]

Chris said ...

>>>This establishes a nice DoS attack potential which is why I firmly
believe that it IS something which you want to agree to in advance
between the parties.<<<

I agree. Although actually I think there is a similar, but worse, DoS attack
that we won't be able to easily avoid. As the following use case describes
...

In this use case on party is sending ebXML messages to another without a
prior TPA (see my second use case on party discovery for the full
explanation). In this use case:
1. A buyer is sending a purchase order to a supplier that should result in
...
2. The supplier sending a purchase order response back to the buyer, and
later ...
3. The supplier sending the goods to the buyer.

This is a common method of wanting to do business.

The Denial of Service attack would consist of a rogue server setting up
programs (along the lines of the recent "ping" attack on AOL & Yahoo and
others) that sent purchase order requests rapidly to the same supplier. If
the buyers are set up on a publicly available registry then getting buyer
information should be easy to do so generating different Purchase Order
documents from different buyers would be easy.

Now I propose that we do not want to prevent spontaneous e-commerce
therefore the only way I see to get around this problem is for the recipient
of a message to validate its authenticity by checking a digital signature on
the document.

Now if we are checking signatures to get around this problem then we should
be able to assume that the ErrorLogLocn is valid and therefore should be
processed.

David



-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Thursday, August 31, 2000 4:19 PM
To: ebXML Transport (E-mail)
Subject: Re: TRP Error Handling Spec Draft


Marty/David,

See below.

Chris

David Burdett wrote:
> 
> I think it is best if it goes in the header, since not recognizing the TPA
> id might be the error you are trying to report ;)
> 
> David
> 
> -----Original Message-----
> From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
> Sent: Wednesday, August 30, 2000 8:04 AM
> To: David Burdett
> Cc: ebXML Transport (E-mail)
> Subject: RE: TRP Error Handling Spec Draft
> 
> David,
> 
> When I got down to the end of my comments, it occurred to me that if the
> specification defined the format and content of the error information but
> limited itself to saying that the information should be logged such that
> both parties could have access to it, that would be a good thing. I think
I
> was more worried about how to fit the error messages into the protocol,
> where they should be directed to, etc., than about the contents of the
> messages.
> 
> ErrorLogLocn could go in the ebxml header, to define the location to which
> a message about an error detected by a recipient should be sent.
> Alternatively, it could go in the partner profile and TPA.  I guess in
this
> case, the ebxml header makes more sense since it isn't an item that
> requires agreement.

This establishes a nice DoS attack potential which is why I firmly
believe that it IS something which you want to agree to in advance
between the parties.

> 
> Regards,
> Marty
> 
>
****************************************************************************
> *********
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
>
****************************************************************************
> *********
> 
> David Burdett <david.burdett@commerceone.com> on 08/28/2000 05:27:23 PM
> 
> To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> cc:
> Subject:  RE: TRP Error Handling Spec Draft
> 
> Marty
> 
> We do want to keep it simple, however the S/390 environment where
> everything
> was under IBM's control is different from the ebXML envronment where the
> operating environment will by much more anarchical. So let's look at some
> of
> the issues ...
> 
> 1. Development by many different vendors - if a vendor is not told what
> errors his software is generating he won't fix them at all or not until
> much
> later.
> 2. Used by SME's and the mega-corporation - this means that we need a way
> for SME's to easily report their problems and get them fixed.
> 
> We actually thought about this when developing IOTP and one of the things
> we
> included was an "ErrorLogNetLocn" (see below) for an extract from the
spec.
> The ideas was that you could specify a URL where errors found in the
> messages sent by a company could be sent to that company so that could fix
> them. In theory, this log location should only occur during testing as all
> software as we know is bug free in production ;)
> 
> David
> ==============
> Extract from IOTP spoec ...
> ErrorLogNetLocn     Optional. This contains the net location that
Consumers
> should send IOTP Messages that contain Error Blocks with an Error
Component
> with the Severity attribute set to either:
> o HardError,
> o Warning but the Consumer decides to not continue with the transaction
> o TransientError and the transaction has subsequently timed out.
> This attribute:
> o must not be present when TradingRole is set to Consumer role,
> o must be present when TradingRole is set to Merchant, PaymentHandler or
> DeliveryHandler.
> The content of this attribute is dependent on the Transport Mechanism see
> the Transport Mechanism Supplement.
> The ErrorLogNetLocn can be used to send error messages to the software
> company or some other Organisation responsible for fixing problems in the
> software which sent the incoming message. See section 7.21.1 Error
> Processing Guidelines for more details.
> 
> -----Original Message-----
> From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
> Sent: Sunday, August 27, 2000 3:40 PM
> To: David Burdett
> Cc: ebXML Transport (E-mail)
> Subject: Re: TRP Error Handling Spec Draft
> 
> This proposal is well thought-out and well described.
> 
> My concerns mainly relate to the KISS principle.  Is this a level of
> complexity and detail that is really needed?  An alternative at the far
> other end of the spectrum is to simply log everything and rely on
> out-of-band communications for the messaging service instance which
> received the message in error to notify the messaging service instance
> which sent it.
> 
> When I was working with the IBM Poughkeepsie architecture team on the
S/390
> fiber optic channels, we accumulated a long list of errors which we wanted
> reported in a response message.  The I/O engineers then informed us that
> they were not going to analyze all this information.  Rather, they would
> log the error condition and take the most drastic recovery action (called
> connection recovery) whatever the error condition.  The recovery action is
> simply to terminate the logical and physical connections between the
> channel and I/O device and let software retry. The principle they were
> operating on was KISS.  They said that ecovery function is the most
> difficult to test and debug.
> 
> 2.1.2 Types of errors
> 
> Line 21 (2nd bullet, 3rd subbullet):  Please add "of a previously sent
> message" to the end of the line.
> 
> Following line 21:  What about a category of "an error in a document which
> is reporting an error"?
> 
> 2.1.3 When to Generate Error Messages
> 
> Line 30 (1st para.):   Please change "message in error" to "received
> message".
> 
> Line 30 (1st para.):  Please change "a URL to send the message" to "an
> address to send the message".  If the communication protocol is other than
> HTTP, the address won't be a URL.
> 
> NOTE:  The IBM tpaML proposal covers only retries of transport timeout
> errors and business-level errors.  Business-level errors are reported to
> the sending application using <ExceptionResponse> and a corresponding
> action at the other partner which receives the exception response.
> 
> NOTE:  It is not clear where the errors covered in the error-handling
> proposal should be reported to.  They are conditions presumably caused by
> the sending message service instance and detected by the receiving message
> service instance.  We will need to define some kind of "catcher" for the
> error messages and define what the catcher is supposed to do.
> 
> 2.2 .1 Communication Protocol Errors
> 
> Line 55 (Editor's note): The KISS principle applies here.  I suggest
> retrying communication-level errors at the communication level and
> reporting all unrecoverable conditions to one place rather than defining a
> unique recovery for each communication-level error.  Aside from
simplifying
> the implementation, it will avoid the need to track the other standards
for
> additional error codes.  I speculate that the function to which these
> conditions are reported will simply log them and process all of them the
> same way.
> 
> 2.2.2.1  Identifying the Error Reporting Location
> 
> 1st paragraph, line 63:  Please change "a URL" to "a communication
> address".  The communication protocol will not necessarily be HTTP.
> 
> Line 65, by reference:  The TPAId is always in the ebXML message header
> 
> Line 66, by value:  Please replace "the URL" by "the communication
> address".
> 
> Line 66, by value:  A header error will make the value of such a tag
> untrustworthy.  I suggest that we limit ourselves to "by reference" and
> "implicitly".
> 
> Line 74-76 ("Even if the message in error..."): Determining the error
> reporting location is not a problem with either "by reference" or
> "implicitly".
> 
> 2.2.2.2  Error Reporting Location is Identified
> 
> Line 80-82 (Editor note): For communication errors, replacing an
> acknowledgment message by an error message is OK (example:  HTTP). If the
> message is sent at the messaging service level, it is not clear where the
> error message should go.  Possibilities are:
> 
>    All the way to the application (e.g. the exception response message in
>    tpaML).
>    Some messaging service management function that we haven't yet
>    considered.  I believe that this is the preferable approach for errors
>    in the header and envelope.
> 
> 2.2.2.3  Error Reporting Location not Identified
> 
> Line 84-86 (1st para.):  This is reporting the error at the transport
> level.
> 
> Line 87, editor's note:  Specifying rules to apply to each transport
> requires defining the layer of function that invokes the transport
> protocol.
> 
> Lines 90-91 (If a suitable return address is not identified):  This is my
> preferred approach for error processing in general.  If we define a
> messaging service management function, then the error information could be
> sent to the management function at the sender and logged there, as well as
> being logged at the recipient messaging service management function.
> 
> 2.2.3 Transient Errors
> 
> Line 92 (title):  Please change the title to "Recoverable Errors"  and use
> the term "Recoverable"  instead of "transient" throughout.  "Recoverable"
> means that retry is recommended.  "Transient" means that the error did not
> recur, which can only be known after the retry succeeds.
> 
> Lines 105-106 ("If the ebXML messaging Services is unable to respond..."):
> If the messaging service is unable to respond within the timeout period,
it
> is probably unable to send the message which says it is unable to respond.
> 
> Line 107 (determining the timeout period):  The TPA is one place to
specify
> the timeouts.
> 
> 2.3.2  ebXML Error Document
> 
> Lines 136-137 (Editor's note, list item 2): Since correcting the errors
> will require human intervention, logging the error condition should be
> sufficient.  As noted above, the sender needs to be notified of the error
> condition.  This notification could be outside the scope of the
> specification.  Alternatively, the error message structure defined here
> could be used for that purpose as long as it is sent to a management
> function at the sender and does not require executing a protocol to
> evaluate the error message as part of the exchange of messages between the
> parties.
> 
> Line 139-40 (list item 4):  I completely agree.
> 
> 2.3.5 ebXML Error Document Type Definition
> 
> Lines 256-258 (Editor's note): Standard practice that I am familiar with
is
> to terminate the operation on the first error detected and report only
that
> error.
> 
> 2.4.2  Non-XML Document ERrors
> 
> Lines 330 (MsgTooLarge), 332 (MIMEError), 333 (MimePartMiss), and 336
> (MimePartUnx):  These conditions appear to be application-level errors.
> These could be reported directly to the sending application using a
> mechanism like <ExceptionResponse> as defined in the tpaML proposal.
> 
> Regards,
> Marty
>
****************************************************************************
> 
> *********
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
>
****************************************************************************
> 
> *********
> 
> David Burdett <david.burdett@commerceone.com> on 08/18/2000 08:17:19 PM
> 
> To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> cc:
> Subject:  TRP Error Handling Spec Draft
> 
> Folks
> 
> I attach some light reading for the weekend. Alternatively called, the TRP
> Error Handling draft spec version 01 ;)
> 
> David
>  <<ebXML TRP Error Handling draft 01.doc>>  <<ebXML TRP Error Handling
> draft
> 01.pdf>>
> 
> Product Management, CommerceOne
> 4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
> Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903