Hash-Based Addresses (HBA)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, shim6 mailing list <firstname.lastname@example.org>, shim6 chair <email@example.com> Subject: Protocol Action: 'Hash Based Addresses (HBA)' to Proposed Standard The IESG has approved the following document: - 'Hash Based Addresses (HBA) ' <draft-ietf-shim6-hba-05.txt> as a Proposed Standard This document is the product of the Site Multihoming by IPv6 Intermediation Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-05.txt
Technical Summary Hash Based Addresses are intended to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. Information about the multiple prefixes is included within the addresses by generating the interface identifiers of the addresses of a host as hashes of the set of available prefixes and a random number, which are then appended to the the different prefixes. The result is a set of addresses that are inherently bound together such that given one valid address out of the group, the prefix set and the random number, it is possible to determine whether another address is part of the group by computing the hash and checking against the interface identifier value. Working Group Summary The document has extensively reviewed by the Working Group and by the Security Area Directorate. The Working Group consensus was to recommend publication of this document as a Proposed Standard. Protocol Quality Jari Arkko has reviewed this specification for the IESG. There are known implementations of this specification, and there have been no implemtation experiences that have implied any further revision to this specification is required. Note to RFC Editor Please add a new subsection: 11.x.DoS attacks considerations In order to use the HBA technique, the owner of the HBA set must inform about the CGA Parameter Data Structure to its peer in order to allow the peer to verify tat the different HBAs belong to the same HBA set. Such information must then be stored by the peer to verify alternative addresses in the future. This can be a vector for DoS attacks, since the peer must commit resources (in this particular case memory) to be able to use the HBA technique for address verification. It is then possible for an attacker to launch a DoS attack by conveying HBA information to a victim, imposing the victim to use memory for storing HBA related state, and eventually running out of memory for other genuine operations. In order to prevent such attack, protocols that use the HBA technique should implement proper DoS prevention techniques. For instance, the Shim6 protocol (draft-ietf-shim6-proto] includes a 4-way handshake to establish the Shim6 context and in particular to establish the HBA-related state. In this 4-way handshake, the receiver remains stateless during the first 2 messages, while the initiator must keep state throughout the exchange of the 4 messages, so that the cost of the context establishment is higher in memory terms for the initiator (i.e. the potential attacker) than for the receiver (i.e. the potential victim). In addition to that, the 4-way handshake, prevents the usage of spoofed addresses from off-path attacker, since the initiator must be able to receive information through the address it has used as source address, enabling the tracking of the location from which the attack was launched from.