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

From: Dean Willis <[email-masked]>
Date: Thu, 28 Jun 2012 10:07:51 -0500

I think David asked me to put together some text for the DoS considerations that we discussed on-list. This would go into the mandatory Security Considerations section.

Here's a starting point:

X.X.1 Denial of Service Issues

Guidance on Denial-of-Service (DoS) issues in general is given in RFC 4732, "Internet Denial of Service Considerations", which also gives a general vocabulary for describing the DoS issue.

SPPP is a high-level client-server protocol that can be implemented on lower-level mechanisms such as remote procedure call and web-service API protocols. As such, it inherits any Denial-of-Service issues inherent to the specific lower-level mechanism used for any implementation of SPPP.  SPPP also has its own set of higher-level exposures that are likely to be independent of lower-layer mechanism choices.

X.X.1.1 DoS Issues Inherited from Transport Mechanism

SPPP implementation is in general dependent on the selection and implementation of a lower-level transport protocol and a binding between that protocol and SPPP. The archetypal SPPP implementation uses XML (http://www.w3.org/TR/xml/) representation in a SOAP (http://www.w3.org/TR/soap/) request/response framework over HTTP (RFC 2616), and probably also uses TLS (RFC 5246) for on-the wire data integrity and participant authentication, and might use HTTP Digest authentication (RFC 2069). The typical deployment scenario for SPPP is to have servers in a managed facility, and therefor techniques such as Network Ingress Filtering (RFC 2827) are generally applicable. In short, any DoS mechanism affecting a typical HTTP implementation would affect such an SPPP implementation, and the mitigation tools for HTTP in general also therefore apply to SPPP.

SPPP does not directly specify an authentication mechanism, instead relying on the lower-level transport protocol to provide for authentication. In general, authentication is an expensive operation, and one apparent attack vector is to flood an SPPP server with repeated requests for authentication, thereby exhausting its resources. SPPP implementations SHOULD therefore be prepared to handle authentication floods, perhaps by noting repeated failed login requests from a given source address and blocking that source address.

X.X.2.2 DoS Issues Specific to SPPP

The primary defense mechanism against DoS within SPPP is authentication. Implementations MUST tightly control access to the SPPP service, SHOULD implement DoS and other policy control screening, and MAY employ a variety of policy violation reporting and response measures such as automatic blocking of specific users and alerting of operations personnel. In short, the primary SPPP response to DoS-like activity by a user is to block that user or subject their actions to additional review.

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

---

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 28 Jun 2012 11:27:06 -0400

Sounds good...  A couple minor comments suggested in-line below.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Thursday, June 28, 2012 11:08 AM
To: [email-masked]
Subject: [drinks] Proposed text for Security Considerations/DOS

Here's a starting point:

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.

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:  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.

_______________________________________________
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.