Subject: Re: [alto] Security problem: DoS attacks via overload

From: Wendy Roome <[email-masked]>
Date: Mon, 18 Mar 2013 11:13:27 -0400

Section 9.1.2 says that an ALTO server MUST provide a full cost map. Full
cost maps increase as the square of the number of PIDs, so they can be
very large -- 10s, even 100's of megabytes. So if a server has a large
number of PIDs, it's trivial to overload the server by flooding it with
simple GETs.

Granted a server can defend itself by cutting off a client who issues "too
many" full cost map requests "too quickly". But that's a pain to
implement. And attacks can come from a swarm of clients, of course.

However, we could avoid that class of attack altogether by making full
cost maps optional, rather than required. And allow servers to limit the
number of source/destination pairs in a filtered request, of course.

What do you folks think about that?

Incidentally, my experience has been that a full cost-map for (say) 2000
PIDs can overwhelm standard JSON libraries. The client may need a custom
parser to handle that large a map.

	- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 18 Mar 2013 15:31:43 -0400

Hi Wendy,

Good comment. The current wording on this related issue is:
--------
13.5.  Availability of ALTO Service

13.5.1.  Risk Scenarios

   An attacker may want to disable ALTO Service as a way to disable
   network guidance to large scale applications.In particular, queries
   which can be generated with low effort but result in expensive
   workloads at the ALTO Server could be exploited for Denial-of-Service
   attacks.  For instance, a simple ALTO query with n Source Network
   Locations and m Destination Network Locations can be generated fairly
   easily but results in the computation of n*m Path Costs between pairs
   by the ALTO Server (see Section 5.2).

13.5.2.  Protection Strategies

   ALTO Provider should be cognizant of the workload at the ALTO Server
   generated by certain ALTO Queries, such as certain queries to the Map
   Service, the Map Filtering Service and the Endpoint Cost (Ranking)
   Service.  One way to limit Denial-of-Service attacks is to employ
   access control to the ALTO Server.  The ALTO Server can also indicate
   overload and reject repeated requests that can cause availability
   problems.  More advanced protection schemes such as computational
   puzzles [I-D.jennings-sip-hashcash] may be considered in an extension
   document.

   An ALTO Provider should also leverage the fact that the Map Service
   allows ALTO Servers to pre-generate maps that can be distributed to
   many ALTO Clients.
--------

We anticipate that most deployment cases will not generate huge maps and
hence it should be fine.

The idea of limiting the topology size (i.e., the number of nodes) is quite
interesting, but can be technology dependent. In the old days when the
backbone of the Internet was only kbps or Mbps, the data to represent a
small may produce a large amount of data and can be overwhelming for slow
computers to process. Hence, such a limit cannot be fixed but should be
changing as time passes by (e.g., announced in IRD). It adds complexity
that we may not want to address at this stage. What do you think?

Richard

On Mon, Mar 18, 2013 at 11:13 AM, Wendy Roome <[email-masked]>wrote:

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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 20 Mar 2013 13:23:32 +0100

>    problems.

One could also explicitly add the term "(request) rate limit"; I think that this is used e. g. to protect control plane protocols.

For instance: "One way to limit Denial-of-Service attacks is to employ access control or request rate limits to the ALTO Server."

There is probably no comprehensive DoS protection solution, though.

Michael