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

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

A bit off topic here perhaps, but:

> PS: how long to scan all of RFC1918 space... 2^24 for 10.xx, and then far
>     less than double that for the rest of 172.16 and 192.168.x.y.

Hardly any time, given that the router's IPv4 address is probably written
on its "getting started" guide. It wouldn't be hard to compile a list.
I'd try 192.168.178.1 first, 10.1.1.1 second, and so on. It always seems
to be x.x.x.1 . So you could probably do it in a matter of minutes.

I still don't think these numbers should be in the draft, because it's
easy to prove them wrong for any particular scenario.

Regards
    Brian

On 06-Jul-22 02:47, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> wrote:
>      > 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.)
> 
> So if the attacker is looking for a specific device with a known EUI, because
> they have a specific attack in mind against that device, then 4.6 hours.
> I leave some tabs open for weeks (Google calendar), but for many unusual
> ones, if you got me to open the tab just before going to bed, I might leave
> it open all night.
> 
> PS: how long to scan all of RFC1918 space... 2^24 for 10.xx, and then far
>      less than double that for the rest of 172.16 and 192.168.x.y.
> 
>      > 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).
> 
> I think that this part of the draft might become the most interesting
> argument for IPv6 for home IoT.
> 
> I was thinking that if TLS was required each time, then it would be longer,
> but no point in trying TLS if the TCP SYN does not finish.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
>