[LINK] IPv6 vs. Human Security [Was Re: smartphone privacy problems]

Mon Jan 31 11:29:53 AEDT 2011

At 10:44 +1100 31/1/11, Karl Auer wrote:
>  ... further clarification ...

Valuable though that description is, there's only one statement that 
in any way affects my criticisms.

I'm saying that, as I understand the discussion:
(1)  an IPv6-connected device is, by default, recognisable nomatter
      where on the net it may connect
(2)  this is an intentional design feature
(3)  the default may be over-ridden by a service-provider
      [That was the new information that hadn't been in previous posts:
      "the mechanism most likely to be actually used for hosts operated
      by humans does NOT expose the MAC"]
(4)  the feature's insecurity to humans may be addressed by users, but
      this involves [insert long list in my previous email], i.e.
      awareness, expertise and action that is beyond most users' capability

Engineers have obligations in relation to human safety:
https://www.ieee.org/about/corporate/governance/p7-8.html

The people responsible for that aspect of the design are in breach of 
their professional Code, and culpable.

(Yes, there are additional measures that people at risk need to use, 
such as nymising proxies, ToR and message encryption.  But they're at 
higher levels of the stack than IP.  Raising awareness of them, and 
making their use sufficiently simple is very important.  But it's 
out-of-scope of a discussion about Internet architecture as dictated 
by the design of IPv6).

______________

Roger:
>  What's more, it's easy for nation-states to criminalise the
>  obfuscation of IPv6 MAC-addresses.

Karl:
>A nation state can criminalise people using direct means - it doesn't
need to take such an oblique approach.

The pattern in oppressive states is to create tiers of crimes.

It's very useful to law enforcement agencies to have a simple and 
un-defendable charge that can be used first, thereby achieving the 
gaoling of the miscreant on-remand and without bail.

The more serious charges can then be proceeded with at leisure, with 
the miscreant unable to continue their activities from their 
confinement.  The more serious charges can eventually be dropped 
anyway, because after 2 or 3 years the suppression has had its 
desired effect.

(The same pattern has been used in 'free nations' since Sep 2001, and 
the copyright-owner supremacist movements have also used the method 
with some success).

_________________________________________________________________________

>On Mon, 2011-01-31 at 09:00 +1100, Roger Clarke wrote:
>>  But what you're saying is that IETF engineers are guilty as charged:
>
>No. Read your message again to see what you "charged" them with.
>
>>  By default, an IPv6-connected device is recognisable nomatter where
>>  on the net it may connect.
>
>"By default" is saying too much. The minimum, standard and default
>mechanism by which an IPv6-capable interface obtains a globally routable
>address is stateless automatic address configuration (SLAAC). The first
>level of SLAAC (link-local addresses) provides the *massive* benefit of
>permitting a network to be set up in the complete absence of a router.
>The second level of SLAAC, which requires a router in the network,
>provides the *massive* benefit of permitting a network to autoconfigure
>itself with globally routable addresses.
>
>As soon as you have a router in play, you have configurability, you have
>administration, and with that comes policy. It is IMHO extremely
>unlikely that SLAAC will be of interest to any network-providing entity
>beyond the setup phase. SLAAC does not provide DNS server information,
>is not logged, provides no policy control over addresses, and a few
>other things that are needed. So it is most likely that in any real
>network used by humans (as distinct from things like cluster networks,
>sensor networks and the like) that SLAAC will not be used except perhaps
>during the build phase. That is, to get initial connectivity long enough
>to configure the hosts properly.
>
>>  The onus has been placed on users to:
>>  -   realise that this has been imposed on them
>>  -   go looking for information
>>  -   learn enough to make sense of the information
>>  -   work out what to do on their devices to override the default
>>  -   do it
>>  -   remember that this workaround is safety-critical
>>  -   sustain it across generations of software and hardware
>
>The normal user will be at the very edge of a network. Everything about
>how he or she communicates has been dictated by (for example) a service
>provider or an employer. There are almost unlimited ways that those
>entities can eavesdrop, intrude, block, modify or otherwise damage the
>end user's communications. Nothing new there, and the address
>calculation mechanism (even if it is used, which is unlikely) is the
>least of the problems.
>
>>  So the world's users have been forced to get under the bonnet,
>>  because of the utter social irresponsibility of IETF engineers.
>
>Roger, you need to get a grip here. Amazingly enough, privacy is not the
>only constraint on a protocol designer. Your "utterly irresponsible IETF
>engineers" provided no less than four mechanisms that do NOT expose the
>MAC to the world. Not only that, but the mechanism most likely to be
>actually used for hosts operated by humans does NOT expose the MAC. And
>there are external mechanisms that protect even that - NAT for the
>terminally daft, proxies and similar at an organisational level, and
>systems like Tor for those who are serious about protecting themselves.
>
>>  What's more, it's easy for nation-states to criminalise the
>>  obfuscation of IPv6 MAC-addresses.
>
>A nation state can criminalise people using direct means - it doesn't
>need to take such an oblique approach.
>
>>  So IPv6 is, by design, a weapon for autocratic governments (not to
>>  mention marketers).
>
>Knives are by design a weapon for murderers. Not to mention TV cooking
>show hosts. So what do we do about the knife problem? It's endemic!
>Should I panic now?
>
>>  [The reason I'm so appalled at this is that this question arose on
>>  link a decade ago, and I'd understood from that discussion that the
>>  generation of IPv6-addresses based on the MAC was an early idea that
>>  had gone away.
>
>Nope. A decade ago, IPv6 was complete in all major respects, and people
>were already being urged to adopt/test it. Nobody bothered.
>
>>  [If it's the instruction in the RFC, and if some designs depend on
>>  it, and those designs will break if the IP-address is *not* generated
>>  in that way, then human insecurity has been built into the
>>  architecture of the Internet - and not as a result of governments
>>  getting control of it, but by engineers asleep at the wheel.]
>
>Nothing will break if addresses are not generated that way (except link
>local, but that is, well, link local). Only one other type of SLAAC
>address is calculated that way. It is a way for an interface to generate
>an address for itself in the absence of anything but a prefix, and is
>one method that a conforming IPv6 stack must implement. And, although it
>is indeed stipulated in an RFC, there is no technical penalty for not
>doing it that way - as the existence of temporary, random,
>cryptographic, static and DHCP addresses testifies.
>
>And a final note: IPv6 is not set in stone, any more than IPv4 ever was.
>If people need a change, change can be made. In this area especially, it
>is relatively easy. It won't change any installed base of course, but it
>can certainly change for desktops and servers.
>
>Regards, K.
>
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
>http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)
>
>GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
>Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
>
>
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: This is a digitally signed message part
>
>Attachment converted: Rincewind:signature 8.asc (    /    ) (006A6127)
>_______________________________________________
>Link mailing list
>Link at mailman.anu.edu.au
>http://mailman.anu.edu.au/mailman/listinfo/link

-- 
Roger Clarke                                 http://www.rogerclarke.com/

Xamax Consultancy Pty Ltd      78 Sidaway St, Chapman ACT 2611 AUSTRALIA
                    Tel: +61 2 6288 1472, and 6288 6916
mailto:Roger.Clarke at xamax.com.au                http://www.xamax.com.au/

Visiting Professor in the Cyberspace Law & Policy Centre      Uni of NSW
Visiting Professor in Computer Science    Australian National University