> On Jan 22, 2020, at 7:18 PM, Tommy Pauly <[email protected]> > wrote: > > > >> On Jan 22, 2020, at 4:08 PM, Adam Roach <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks again for the quick turn-around on this. >> >> Using your proposed 2**(Delay + 10) seems to strike an okay balance, if I'm >> understanding the situation correctly. Double-check my thinking here: the >> scope of RA reach from an attacker will be available only on a single local >> link, which deployments typically limit to on the order of 500 clients or >> so. If all 500 are triggered at the same time and smooth out their requests >> over a one-second window, we're looking at a 500 TPS load on a web server. >> That's about 25% the capacity of a relatively low-end web server (e.g., >> Apache running on an Atom 1.66), which seems small enough to avoid major >> issues. > > Yes, that sounds right to me. That limits the single burst size in response > to a given RA being sent. Each of these hosts wouldn't request again for that > PvD ID, even if RAs keep coming telling the host to update, for another ten > seconds after that. And, the limit for the number of different hostnames (for > a case in which a wildcard host exists, which presumably also has a higher > capacity) is 5 different names in the ten second period, so that limits at > 2500 TPS across all fetches to any server from a given network. >> >> So, unless one of my assumptions above is wrong, I think your proposal below >> is a good solution to the issue. I'll clear my DISCUSS when a new version of >> the draft comes out (I would propose that you wait for instructions from >> your AD about when to do so). > > Thanks! Yes, I'll wait for the go-ahead from Suresh. I appreciate your > helping to work through these important details!
Yes. I had asked Tommy to hold off on submitting a new version until after the telechat so that there is no confusion with different ADs reviewing different versions of the draft. Will work with Tommy to ensure that the agreed changes are reflected in the new submitted version. Regards Suresh
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
