Richard, You said,
> We anticipate that most deployment cases will not generate huge maps and > hence it should be fine. > A year ago, when I realized that full cost maps can get very large, I asked the group how many PIDs they expected ALTO servers to provide. 10's, 100's, 1000's., .? No one answered that question. Just in case, I extended the Alcatel-Lucent ALTO server and client to handle several thousand PIDs, but it took some effort. Remember that protocols have a way of scaling up far past their designer's original expectations. For example, I'm old enough to remember when IPV4 addresses seemed infinite. (I'm also old enough to have used keypunches and card decks and IBM System 360s, but that's another issue.) So think carefully about what would happen if the number of PIDs grows beyond our wildest dreams. Because it might! I certainly agree that the protocol should not define limits. But I think the protocol should allow an ALTO server to define & impose its own limits, and communicate those limits to clients. So here's my suggestion for how the ALTO protocol could support implementation-defined limits: 1) Make full cost-maps optional, instead of required. 2) For filtered cost map requests, add an optional IRD capability giving the server's limit on the number of source/destination pairs allowed per request. 3) Add a "Request Too Large" ALTO error code in case a client exceeds that limit. Comments, suggestions? - Wendy Roome > Date: Mon, 18 Mar 2013 15:31:43 -0400 > From: "Y. Richard Yang" <y...@cs.yale.edu> > Subject: Re: [alto] Security problem: DoS attacks via overload > Message-ID: > <CANUuoLqjWLOB7w9Hhz3u1rMgM36-q=c55i=rNEbGHzU=xdt...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > 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 > >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
