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

Of course, if you try to attack an 802.15.4 network this way, it will
definitely be noticed, if only in the sense that your lights will stop
being controllable. But there you're going to have to guess the prefix of
the 802.15.4 network, so that's not a very likely attack anyway.

On Tue, Jul 5, 2022 at 7:47 AM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Brian E Carpenter <brian.e.carpenter@gmail.com> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>