Subject: Re: [drinks] Proposed text for Security Considerations/DOS

From: Dean Willis <[email-masked]>
Date: Thu, 5 Jul 2012 09:25:05 -0500

On Jun 28, 2012, at 10:27 AM, Cartwright, Ken wrote:

> 
> 
> SPPP allows a client to submit multiple-element or "batch" requests that may insert or otherwise affect a large amount of data with a single request. In the simplest case, the server progresses sequentially through each element in a batch, completing one and before starting the next. However, implementations may re-order request elements, parallelize them, distribute them to subprocesses, or perform other optimizations.
> 
> KJC:  While it is theoretically possible under some circumstances, suggesting that implementations can/may "re-order request elements" might be a pandora's box that we should not open. Re-ordering of request elements in a batch request is not the intended approach, and I think that in-order processing is discussed/mentioned in the doc.  So you might want to consider removing the above sentence.

Right,  the SOAP doc 6.2.1.1 Add Request text states "The elements are processed by the SPPF server in the order in which they are included in the request." However, the FRAMEWORK document doesn't seem to indicate. Could different biding have different order-execution properties? If not we may want to mandate sequential execution in the framework.

Question: How does a SOAP-binding client know whether a batch rolled back or committed-prior-to-error? Which result code is sent in each case? Does this require a-priori knowledge about the the server?

It seems like we're currently set up to return a particular 2000-class message for the failing request element, but I don't see a way to convey partial completion status. Perhaps we could use the third digit; 1 for partial-commit, 2 for roll-back?

> 
> Implementation designers must choose how to handle a mid-batch failure and decide what to do with other request elements in batch wherein one or more elements fail. Options include 1) stopping the batch with a "partial commit" wherein previously complemented request elements remain committed to the data store but elements "after" the failing element do not execute, 2) stopping the batch and rolling-back the data store to its pre-request state, and 3) continuing the batch, such that all non-failing elements complete and are committed to the data store. This is
> a complex set of alternatives, and implementors must thoroughly analyze their choices for DoS vulnerabilities.
> 
> In particular, a "stop and roll-back" choice provides a DoS opportunity. A hostile client could repeatedly issue large batch requests with one or more failing elements, causing the server to repeatedly stop and roll-back large transactions. The suggested response is to monitor clients for such failures, and take administrative action (such as blocking the user) when an excessive number of roll-vbacks is reported.
> 
> KJC:  An additional suggested response is for an implementer to set their maximum allowable XML message size, and their maximum allowable batch size at a level that they feel protects their operational instance, given the hardware sizing they have in place and the expected load and size needs that their users expect.
> 

In the SOAP binding, we have a response code 2001 Request Too Large, which parameterizes by the maximum number of request elements  supported. This doesn't let us say anything about the actual XML-size.

---

From: Dean Willis <[email-masked]>
Date: Thu, 5 Jul 2012 09:49:01 -0500

> Right,  the SOAP doc 6.2.1.1 Add Request text states "The elements are processed by the SPPF server in the order in which they are included in the request." However, the FRAMEWORK document doesn't…

I am mis-informed; the framework document does have text:

From 6.2.5.1 Batch Request Structure

   With respect to handling of error conditions, it is a matter of
   policy whether the batch operation 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 elements in
   the request at the first error and roll back any elements that had
   already been processed for that batch request.  In the "stop and
   commit" scenario the SPPF server would stop processing elements in
   the request at the first error but commit any elements that had
   already been processed for that batch request.

---

From: Dean Willis <[email-masked]>
Date: Thu, 5 Jul 2012 09:51:57 -0500

>   already been processed for that batch request.

Whoops. I'm misinformed about being mis-informed; that text is from the SOAP doc, not frmework. So the SOAP document has multiple incidents of rollback-vs-multiple commit.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 5 Jul 2012 11:29:34 -0400

I think this ended up getting moved into the SOAP doc as part of the unfortunate re-layering activity.  But isn't that the correct location for it?  I think it better belongs there than in the "Framework" document.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Thursday, July 05, 2012 10:52 AM
To: [email-masked]
Subject: Re: [drinks] Proposed text for Security Considerations/DOS

--
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: Thu, 5 Jul 2012 11:29:34 -0400

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, July 05, 2012 10:25 AM
To: Cartwright, Ken
Cc: [email-masked]
Subject: Re: [drinks] Proposed text for Security Considerations/DOS

KJC:  This again comes down to how much "how to develop software" guidance we want to put in these docs.  If you feel that the docs do not make the in-order processing requirement clear enough then feel free to make that clearer.

>
> Implementation designers must choose how to handle a mid-batch failure
> and decide what to do with other request elements in batch wherein one or more elements fail. Options include 1) stopping the batch with a "partial commit" wherein previously complemented request elements remain committed to the data store but elements "after" the failing element do not execute, 2) stopping the batch and rolling-back the data store to its pre-request state, and 3) continuing the batch, such that all non-failing elements complete and are committed to the data store. This is a complex set of alternatives, and implementors must thoroughly analyze their choices for DoS vulnerabilities.
>

KJC:  That's what I meant, too many items in the XML message.