May I throw a dose of caution in this debate about host identifiers formats?
Many transition mechanisms rely on encoding information in the 64 bit host identifier. This is of course a tempting design point, because it diminishes the amount of state that servers have to keep. For example, Teredo encodes mapped port numbers and IPv4 addresses in the host identifiers, so Teredo servers can be stateless. ISATAP uses a similar mechanism, and a number of proposals follow the same design. But the gain, the reduction of server load, comes at a cost. I am guilty, I did it with Teredo, but I still would like to encourage designers of new protocols to consider the downside of these "structured identifiers" encoding when they consider new approaches. Structured host identifiers are incompatible with cryptographically generated addresses, as used in SEND and proposed in SHIM6. We can argue that SEND is a local protocol, and that the use of SEND can be decided on a subnet basis. However, cryptographically binding addresses to public keys has huge potential, not just inside subnets. Think about secure mobility, secure re-homing, opportunistic IPSEC, and other kinds of end-to-end security. Standardizing structured identifiers breaks that. Structured identifiers are not compatible with privacy address extensions. Moreover, embedding addresses in identifiers discloses information that would otherwise have remained hidden behind the NAT and the firewall. The IPv4 address encoded in the host identifier is passed to third parties, stored in server logs. The third parties now have access to the local addresses used inside the corporation. They can analyze subnet structure. At a minimum, this should be a privacy concern. Combining embedded addresses with stateless servers opens the door to various kind of denial of service attacks. We analyzed several such attacks in the security analysis of Teredo, but the attacks are not specific to Teredo. The attacks derive from the stateless nature of the transition mechanism. A transition router, relay or gateway will receive a packet, extract the IPv4 next hop from the structured identifier, and blindly relay the packet towards that next hop, whether that next hop participates in the transition scheme or not. Based on that, attackers can build denial of service attacks, can hide their tracks in reflection attacks, can spoof addresses. The alternative is obviously to leave the identifier unstructured, and to require transition servers to maintain the required mapping state. For example, if I had to redesign Teredo today, I would require servers to maintain tables of mapping between the Teredo hosts that they serve and the corresponding mapped addresses. This would increase the cost of servers somewhat, but it would improve security and privacy aspects of the protocol. The same could easily be done for ISATAP, letting routers use a variation of non-multicast neighbor discovery to enable traffic. I would like to encourage designers of new transition schemes to study that alternative. Leave the host identifier unstructured, or maybe use SEND as a structure. Keep the transition state in a transition server. Use caching to increase reliability and diminish server load. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
