Well, frankly, in general your list looks like a made-up set of automatically generated marketing buzzwords, sometimes completely unclear or unrelated to cyberattacks ("direct" anyone?). However, the author of the said report claims to have taken the list from Akamai, which probably gives us a clue to what "origin error attack" means.
Akamai is a CDN provider. Though the paper is dedicated to DDoS attacks, and Akamai DDoS Mitigation is technically completely unrelated to Akamai CDN network1, it's still the same company, at least in terms of PR and marketing activities.
Here's a short summary of CDN terminology. A content delivery network consists of edge servers – devices which serve a content to clients (e.g. Web browsers). The content an edge server maintains is retrieved from an origin server and distributed to all edge servers, or a subset of them, in a way specific to the particular CDN. An origin server is the server (operated by a customer of the CDN) which is hosting the original content, the latter being then copied, cached and distributed by a content delivery network.
In case of a cache miss, i.e. when a request is received for a piece of content which is missing on an edge server, the latter requests the content from the origin server. An origin error is the message returned to a browser by an edge server in case there's no such content available both in the edge server cache and on the origin server, under most normal conditions2, together with a
404 "Not Found" HTTP status code.
A typical (botnet based) application layer DDoS attack towards an HTTP application may have little3 impact on the availability of the said application in case all the Web resources requested by a botnet are cached by a CDN, and the latter is powerful enough to handle all the requests from the botnet. However, an attacker may choose to request only those resources from the CDN which are guaranteed to be absent on the origin server (e.g. random resources from a non-existent directory). This way, all the requests from a botnet would result in cache misses, and would all be simply proxied to the origin server which hosts the HTTP application, rendering it unavailable for legitimate users due to heavy load.
It is more or less suitable to call this method an "origin error attack" if anyone wants to give it a name.
A modification of such an attack is requesting resources that do exist both on edge and origin servers, with a random query string, e.g. https://example.com/?jhd=370 instead of simply https://example.com/. Some CDNs treat such a request as a cache miss and forward it to the origin server, as HTTP specification suggests. Others can be configured to strip query strings when a static content is requested, or deny such requests at all. Thus such an attack method, while being rather efficient against a dynamic Web site, might impose little impact on a static one.
Update (26.03.2020): there's now a conference proceedings paper which describes the attack in more detail.
1 Akamai Technologies maintains its Internet presence as autonomous system 20940. Akamai DDoS Mitigation (formerly Prolexic) is AS 32787. Akamai Technologies has acquired Prolexic in February 2014, however, as of March 2020, former Prolexic network seems to be still only loosely related to the main Akamai network:
- Peering policies and locations available for peering are completely different for CDN and DDoSM networks;
- Routing policies for CDN and DDoSM are also completely different.
404 status code is returned in case the edge server is able to reach the origin server, but the origin server itself responds with the
404 status code. In case the origin server is unreachable or doesn't respond to requests,
502 Bad Gateway and
504 Gateway Timeout status codes are often returned, respectively.
3 In case all pages of an application are cached by a CDN, a DDoS attack may still have an impact on the application's availability, but the impact is limited to the infrastructure issues, for example, DNS server performance in case the botnet nodes resolve the name of the victim themselves, or OCSP server performance in case bots are built on top of headless browser instances, and so on.