Subject: [drinks] Thoughts on DoS issue related to "batch transactions"

From: Dean Willis <[email-masked]>
Date: Tue, 8 May 2012 10:48:26 -0500

SPPP as currently defined allows a client to send a bundle of requests to a server.

We have an open question on what to do when one of those requests fails. Options include:

1) Process the requests in the bundle sequentially, and stop the bundle when one fails.
a) Keep the completed requests, reject the remainder, and tell the client what happened. We might call this "partial sequential completion of the bundle".
b) Roll back all completed requests, returning the server to the state at which it was before the transaction started. We might call this "atomic sequential completion of the bundle".

2) Process the requests in the bundle independently, notifying the client of each failed request. We might call this "independent completion of the bundle with no guarantee of sequential processing".

We started with 1a, and I suggested 1b due to the risk of leaving the server content in an unexpected state.  Jeremy argues in favor of 1a, on the argument that rolling back a large transaction bundle is hard on a database and we might be introducing a DoS opportunity.

But it occurs to me that if we use a model like 2, then we have the potential to parallel-process requests in the bundle. This would require two things;

Req 1) Not structuring sequential dependencies in a bundle. For example, if within a a request we add A, B, and C and delete B, a sequential execution would give us a database with records A and C. Non-sequential execution might give us either a database containing A and C or a database containing A. B, and C, and an error message that says B did not exist.  Actually we don't have to NOT do this; we just have to be willing to live with either result.

Req 2) We need to be able to return multiple responses, potentially one for each transaction in the bundle.

However, what independent processing and reporting gives us is the ability to fully parallelize and distribute the requests in a bundle. That could be a huge performance game changer.

If we choose to stay with 1b, I believe that any DoS issue could be dealth with by describing the issue  (a client can DoS the server by repeatedly issuing large bundles with a single failing transaction at the end), and the mitigation  (since the server authenticates such requests, it can start denying service to an abusive client) in the security considerations section of the document.

A 1b solution also allows some parallelization of the requests subject to a sequential-dependency analysis, so I favor it as a potential improver of performance over 1a. However, the 1a solution is by far the simplest.

--
Dean

---

From: "Bhatia, Vikas" <[email-masked]>
Date: Mon, 14 May 2012 14:43:54 -0400

W.r.t the comment "If we choose to stay with 1b,..."

It is my understanding that there was general agreement on the following two points for the processing of requests in a SPP Protocol over SOAP operation:

1. Elements would be processed in the order of their occurrence in the request.
2. Option 1a ("stop and commit") or 1b ("stop and rollback") would be left to the SPPF server (as a policy decision) and *not* normatively define in the protocol document.

Following is an excerpt from the current version of SPP Protocol over SOAP document:

===================================================================================
          The elements are processed by the SPPF
        server in the order in which they are included in the request.
        With respect to handling of error conditions, it is a matter of
        policy whether the objects are processed in a "stop and
        rollback" fashion or in a "stop and commit" fashion.  In the
        "stop and rollback" scenario, the SPPF server would stop
        processing BasicObjType elements in the request at the first
        error and roll back any BasicObjType elements that had already
        been processed for that add request.  In the "stop and commit"
        scenario the SPPF server would stop processing BasicObjType
        elements in the request at the first error but commit any
        BasicObjType elements that had already been processed for that
        add request.
====================================================================================

Iow, choice is already made and I don't recall this being an open item. Let me know if I am missing something. As regards the DoS concerns, they are being (or should be) discussed as a general threat for WS API operations. Most public WS APIs are susceptible to DoS and as long as there is text in Security Considerations to inform the implementers of this threat, that imho should be good enough.

Thanks,
Vikas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Tuesday, May 08, 2012 11:48 AM
To: [email-masked]
Subject: [drinks] Thoughts on DoS issue related to "batch transactions"

--
Dean

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 15 May 2012 09:24:58 -0400

That is correct Vikas.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Vikas
Sent: Monday, May 14, 2012 2:44 PM
To: Dean Willis; [email-masked]
Subject: Re: [drinks] Thoughts on DoS issue related to "batch transactions"

Thanks,
Vikas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Tuesday, May 08, 2012 11:48 AM
To: [email-masked]
Subject: [drinks] Thoughts on DoS issue related to "batch transactions"

--
Dean

This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.