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 <w.ro...@alcatel-lucent.com>wrote: > 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 > > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
