On Wed, 22 May 2002, Pekka Savola and Hesham Soliman (ERA) wrote: <...> >>Actually, as a side >> node, I think 2462 should be deprecated and replaced by >> 3041....please don't shoot! > >Where did I put my M16..... ;-) > >In the meantime, you might want to check out >draft-dupont-ipv6-rfc3041harmful-00.txt .. there's an omission or two, but >should be recommended reading for RFC3041 advocates :-)
Thanks for the reminder. I must have missed it somehow. Probably on vacation at the wrong moment... I've been souping up a note of my own concerning RFC3041. I'm approaching the problem from 3GPP point of view. The text below is still pretty raw. For example, it doesn't discuss countermeasures. It was inspired by draft-ietf-ipngwg-temp-v2-00.txt, which has expired, but it is also valid for RFC3041. Both claim that the proposed mechanism does not introduce any new security problems. I happen to disagree. There are enough problems to spoil the whole idea. Looking for a Sidewinder... -- Lassi ........................................ 1. Summary RFC3041 may give protection against casual observers, but it also provides new tools for competent attackers. * Filtering to protect against DoS attacks is more difficult. * The address suffix can be used as a two-way covert channel that leaks up to 128 bits per packet in either direction. * One possible item of leaked information is the global identity and configuration of the node that uses the privacy addresses (i.e. with RFC3041 you can loose more privacy than without it). 2. Packet filtering A stateless filter cannot test the lowest address bits, because being stateless it does not know which suffices are in use at any moment. Previously the stateless filter could limit subnet address scans effectively by passing only a very small set of suffices. After RFC3041 it will pass a scan of up to 2^64 addresses. If the scanned node connects using a slow PPP link (e.g. a 3GPP mobile node), the scan will block its link. Note that this problem does not concern stateful filters. RFC3041 does not recommend changing the suffix if some upper protocol layer uses the address in a stateful session (e.g. TCP). In effect, RFC3041 mandates wide deployment of stateful firewalls. 3. The suffix as a covert channel (The importance of covert channels is increasing. For example, a Trojan horse is far more dangerous with a hidden control channel than without it. And we know how easy it is to get a Trojan installed by a gullible user...) Each node along the path is forced to accept any bit combination as the suffix of the *source* address. Uplink gateways performing sanity checks have no information about which suffices are in use in the sending subnet, and can check only that the prefix is topologically correct. The sending suffix can be used as payload. The access router at the local link could detect this channel. But if the leaking node performs DAD for each new address it generates, the channel can be detected only by analysing DAD frequency. The user of the channel may limit its use to a low rate to avoid detection. (But even once per day can be useful, see below.) The return packets to the Trojan can use the source address of the correspondent node to create a two-way channel. If the attacker has control of the corresponding subnet, also the destination suffix in uplink direction can be used. If the local last hop is over PPP (e.g. a 3GPP mobile node), also downlink destination address can be used. Total covert bandwidth is 128 bits per packet, both uplink and downlink. For reference: IP telephony needs 160 bits per packet. Using the channel requires access to the IP stack of the node. The malware can be installed either as a standard part of the stack (to track users), or as a Trojan horse via some other security hole. 4. Leaking the global identity If only the identity of the user is interesting, the standardised method already provides all necessary messages. As soon as a new address has been generated, the tracker can identify it, globally and forever. The new "random" addresses are created in a deterministic manner (RFC3041 3.2.1. "When Stable Storage Is Present"). The software vendor can therefore predict every future suffix used by the node, or identify the node as soon as one suffix has been detected. Since there are about 2^64 possible suffices, the possibility of a collision is fairly low. Besides, most users won't notice if the software vendor uses a proprietary hash function that is easier to crack than MD5. The suffix sequence can be seeded using the Ethernet address *and* the serial number of the software licence, leaking even more identity information than what a single fixed address would. Both of these identifiers can be narrowed down to a rather small subset of the available namespace by guessing. The time when the node came on-line for the first time can be used as guidance. If the suffix is generated using MD5 as suggested in RFC3041, an ephemeral identity can be recovered by anyone, by brute forcing the missing 64 bits of initial state from two consecutive suffices. The processing expense is not prohibitively high, and is getting lower all the time. This works also in the "absence of stable storage" mode. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
