My understanding is that SeND chose different IIDs for differentprefixesbut that might be overkill. If the IID is not a function of the prefix it would enable redirection by a resourceful attacker by precomputing 2^64 public/private keys that hash to all 2^64 IIDs. If the content of the packets are encrypted the redirection would not provide access to the content; it could only be used for DoS or for gathering the content for cryptoanalysis.
There are two issues: catalog attacks and privacy implications. I have
already expressed my reservations about the privacy effects of having
unique identifiers in addresses. I would certainly not recommend that my
company ships anything like that.
sizeA while back Jari Arkko computed the amount of space needed to store 2^64 precomputed keys, and the storage space was a few buildings theof the former world trade center buildings I think.
You do not need to compute 2^64 keys to start having an effect. Suppose
that there are N users in the system, and that the bad guys have
computed a catalog of M keys. The average number of hits that a catalog
of size N will achieve is approximately NxM/2^64. There are currently at
least 500M Internet users, it is reasonable to expect some growth, so we
can set N to about 1 billion -- 2^30. This means you need M=2^34 to get
at least one hit.
That is probably less than a Terabyte of data, i.e. pretty soon a single hard disk.
Everybody should be convinced that, when it comes to cryptography, 2^64 is actually a small number. SEND alleviates this risk by cryptographically link a public key to the entire 128 bits of the address. This is NOT overkill.
-- Christian Huitema