Re: Scripting attacks [was Next step for draft-ietf-6man-rfc6874bis]

[Brian E Carpenter <[e-mail]>]

I need to back off a bit on what I said below. I've now learnt even more about running asynchronous threads in parallel in Javascript, and there seem to be hidden resource limits. If my script sets off too many HTTP transacations in parallel, the valid [http://fe80::xxxx] fails anyway and the script can't find its target. I have to leave about 1000ms between HTTP GETs for the script to work, which means a maximum scan rate of once per second.

However, somebody who understands Javascript handles asynchronous operations might be able to do better.

IMHO none of this changes the conclusions of the draft.

Regards
     Brian Carpenter

On 05-Jul-22 12:11, Brian E Carpenter wrote:
> On 30-Jun-22 12:06, Carsten Bormann wrote:
>> On 30. Jun 2022, at 02:03, Ted Lemon <[e-mail]> wrote:
>>>
>>> Of course, many browsers will, at this point, notify the user that "a tab is consuming a lot of power”.
>>
>> But are even 1000 parallel threads, each mostly waiting for 3500 ms, consuming a lot of power?
> 
> I couldn't leave it alone, so I learnt a bit more Javascript and figured out how to launch an arbitrary number of threads in parallel (which is surprisingly easy, but stopping them once launched is harder). A few hundred in parallel doesn't even heat the CPU enough for the fan to come on. At around a million, the fan is going like crazy and Firefox is clearly going to fill memory soon, and in fact cannot even shut down the tab where the threads are running. In any case, as Carsten pointed out, because of the need for a timeout, parallelism makes a big difference.
> 
> The sweet spot seems to be about several thousand threads, which is impressive. I estimate from my observations that a carefully designed script could scan about 1000 addresses per second, without alarming the user that something was going on. That would amount to 585 million years to scan a 64 bit space, *but* only 4.6 hours to scan a 24 bit space. (All based on my very ordinary Windows laptop and home network.)
> 
> That's interesting, because it means that there is no realistic risk if using a random 64 bit interface identifier, but a real exposure if using a Modified EUI, since many of the bits are guessable, as discussed in RFC 7707. The numbers above are clearly specific to a particular scenario, but we will mention this point in the draft (update coming very soon).
> 
> Regards
>       Brian