Re: DDOS and TRP Error Handling Spec Draft

[Martin W Sachs/Watson/IBM <mwsachs@us.ibm.com>]

Consider that A sends a message to B and B's MS detects a message-level
error.

In the tpaML proposal, the error-reporting location must be at A.  The
<ExceptionResponse> tag defines an action at A which will receive the error
message.  There is no option to direct the message to a communication
address which does not belong to A.  There is also no option to dead-end
the exception message at A's messaging service, though that could be added.
Currently, tpaML assumes that if an exception response is issued, it is of
interest to the application level at A, which is the case for most of the
errors defined in David's proposal.  Of course that exception response
action could actually map to a method call in the application services
function in the B2B middleware at A.  And of course, B should also log the
error condition.  This will happen as a matter of course if both A and B
are logging all the exchanges.

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
*************************************************************************************



"Moberg, Dale" <Dale_Moberg@stercomm.com> on 09/06/2000 12:04:29 PM

To:   "'Christopher Ferris'" <chris.ferris@east.sun.com>, "Burdett, David"
      <david.burdett@commerceone.com>
cc:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Subject:  DDOS and TRP Error Handling Spec Draft



I think that if lessening the chances of a DDOS are within the scope
of TRP, it is certainly an issue for the security focused sub group.

The adversary currently is assumed to have acquired the destination URLs
for many ebXML speakers and then proceeds to go on to submit
bad data, directing error responses to some unfortunate other victim.

The intended victim's destination URL for errors is also presumed static
and known by the adversary.

While I think in general that there are far too many other ways to launch
a DDOS, I suppose it is worth thinking about what can be done to block
the adversary's approach.

1. The destination URLs can be made hard to find. This means a problem
for the Registry; the TPA template access needs to be defined.

2. The URL for an error reply can be made per message specific and
dynamically
generated so that every error gets a non-reused URL for any errors. So
even if the adversary manages to snoop out one error destination URL,
all the error responses after the first get a 404 or similar refusal.
In other words, don't reuse the error destination URL when
the DDOS threat is regarded as significant.

3. There are surely other mechanisms that will lessen the threat, including
screening submissions for HTTP authentication from ebXML request messages,
checking SSL certificates during session setup, and so on. But clearly
all these things should be addressed as part of the overall security
TRP sub workgroup. There will be a lot of opportunities potentially for
man in the middle style malaciousness as well as more standard DDOS.

I don't think that the security environment for the messaging is well
enough
defined that we can throw out useful messaging constructs based on the
alleged defects of the non-defined security apparatus.