7. HIP Policies
There are a number of variables that will influence the HIP base
exchanges that each host must support. All HIP implementations MUST
support more than one simultaneous HI, at least one of which SHOULD
be reserved for anonymous usage. Although anonymous HIs will be
rarely used as Responders' HIs, they will be common for Initiators.
Support for more than two HIs is RECOMMENDED.
Initiators MAY use a different HI for different Responders to provide
basic privacy. Whether such private HIs are used repeatedly with the
same Responder, and how long these HIs are used, are decided by local
policy and depend on the privacy requirements of the Initiator.
The value of #K used in the HIP R1 must be chosen with care. Values
of #K that are too high will exclude clients with weak CPUs because
these devices cannot solve the puzzle within a reasonable amount of
time. #K should only be raised if a Responder is under high load,
i.e., it cannot process all incoming HIP handshakes any more. If a
Responder is not under high load, #K SHOULD be 0.
Responders that only respond to selected Initiators require an Access
Control List (ACL), representing for which hosts they accept HIP base
exchanges, and the preferred transport format and local lifetimes.
Wildcarding SHOULD be supported for such ACLs, and also for
Responders that offer public or anonymous services.
8. Security Considerations
HIP is designed to provide secure authentication of hosts. HIP also
attempts to limit the exposure of the host to various denial-of-
service and man-in-the-middle (MitM) attacks. In doing so, HIP
itself is subject to its own DoS and MitM attacks that potentially
could be more damaging to a host's ability to conduct business as
Denial-of-service attacks often take advantage of asymmetries in the
cost of starting an association. One example of such asymmetry is
the need of a Responder to store local state while a malicious
Initiator can stay stateless. HIP makes no attempt to increase the
cost of the start of state at the Initiator, but makes an effort to
reduce the cost for the Responder. This is accomplished by having
the Responder start the 3-way exchange instead of the Initiator,
making the HIP exchange 4 packets long. In doing this, the first
packet from the Responder, R1, becomes a 'stock' packet that the
Responder MAY use many times, until some Initiator has provided a
valid response to such an R1 packet. During an I1 packet storm, the
host may reuse the same DH value also, even if some Initiator has
provided a valid response using that particular DH value. However,
such behavior is discouraged and should be avoided. Using the same
Diffie-Hellman values and random puzzle #I value has some risks.
This risk needs to be balanced against a potential storm of HIP I1
This shifting of the start of state cost to the Initiator in creating
the I2 HIP packet presents another DoS attack. The attacker can
spoof the I1 packet, and the Responder sends out the R1 HIP packet.
This could conceivably tie up the 'Initiator' with evaluating the R1
HIP packet, and creating the I2 packet. The defense against this
attack is to simply ignore any R1 packet where a corresponding I1
packet was not sent (as defined in Section 6.8, step 1).
The R1 packet is considerably larger than the I1 packet. This
asymmetry can be exploited in a reflection attack. A malicious
attacker could spoof the IP address of a victim and send a flood of
I1 messages to a powerful Responder. For each small I1 packet, the
Responder would send a larger R1 packet to the victim. The
difference in packet sizes can further amplify a flooding attack
against the victim. To avoid such reflection attacks, the Responder
SHOULD rate-limit the sending of R1 packets in general or SHOULD
rate-limit the sending of R1 packets to a specific IP address.
Floods of forged I2 packets form a second kind of DoS attack. Once
the attacking Initiator has solved the puzzle, it can send packets
with spoofed IP source addresses with either an invalid HIP signature
or invalid encrypted HIP payload (in the ENCRYPTED parameter). This
would take resources in the Responder's part to reach the point to
discover that the I2 packet cannot be completely processed. The
defense against this attack is that after N bad I2 packets with the
same puzzle solution, the Responder would discard any I2 packets that
contain the given solution. This will shut down the attack. The
attacker would have to request another R1 packet and use that to
launch a new attack. The Responder could increase the value of #K
while under attack. Keeping a list of solutions from malformed
packets requires that the Responder keeps state for these malformed
I2 packets. This state has to be kept until the R1 counter is
increased. As malformed packets are generally filtered by their
checksum before signature verification, only solutions in packets
that are forged to pass the checksum and puzzle are put into the
blacklist. In addition, a valid puzzle is required before a new list
entry is created. Hence, attackers that intend to flood the
blacklist must solve puzzles first.
A third form of DoS attack is emulating the restart of state after a
reboot of one of the peers. A restarting host would send an I1
packet to the peers, which would respond with an R1 packet even if it
were in the ESTABLISHED state. If the I1 packet were spoofed, the
resulting R1 packet would be received unexpectedly by the spoofed
host and would be dropped, as in the first case above.
A fourth form of DoS attack is emulating the closing of the HIP
association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to
explicitly signal the end of a HIP association. Because both CLOSE
and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a
connection. The presence of an additional SIGNATURE allows
middleboxes to inspect these messages and discard the associated
state (e.g., for firewalling, SPI-based NATing, etc.). However, the
optional behavior of replying to CLOSE with an ICMP Parameter Problem
packet (as described in Section 5.4.4) might allow an attacker
spoofing the source IP address to send CLOSE messages to launch
A fifth form of DoS attack is replaying R1s to cause the Initiator to
solve stale puzzles and become out of synchronization with the
Responder. The R1 generation counter is a monotonically increasing
counter designed to protect against this attack, as described in
Man-in-the-middle attacks are difficult to defend against, without
third-party authentication. A skillful MitM could easily handle all
parts of HIP, but HIP indirectly provides the following protection
from a MitM attack. If the Responder's HI is retrieved from a signed
DNS zone, a certificate, or through some other secure means, the
Initiator can use this to validate the R1 HIP packet.
Likewise, if the Initiator's HI is in a secure DNS zone, a trusted
certificate, or otherwise securely available, the Responder can
retrieve the HI (after having got the I2 HIP packet) and verify that
the HI indeed can be trusted.
The HIP "opportunistic mode" concept has been introduced in this
document, but this document does not specify what the semantics of
such a connection setup are for applications. There are certain
concerns with opportunistic mode, as discussed in Section 4.1.8.
NOTIFY messages are used only for informational purposes, and they
are unacknowledged. A HIP implementation cannot rely solely on the
information received in a NOTIFY message because the packet may have
been replayed. An implementation SHOULD NOT change any state
information purely based on a received NOTIFY message.
Since not all hosts will ever support HIP, ICMP 'Destination Protocol
Unreachable' messages are to be expected and may be used for a DoS
attack. Against an Initiator, the attack would look like the
Responder does not support HIP, but shortly after receiving the ICMP
message, the Initiator would receive a valid R1 HIP packet. Thus, to
protect against this attack, an Initiator SHOULD NOT react to an ICMP
message until a reasonable delta time to get the real Responder's R1
HIP packet. A similar attack against the Responder is more involved.
Normally, if an I1 message received by a Responder was a bogus one
sent by an attacker, the Responder may receive an ICMP message from
the IP address the R1 message was sent to. However, a sophisticated
attacker can try to take advantage of such behavior and try to break
up the HIP base exchange by sending such an ICMP message to the
Responder before the Initiator has a chance to send a valid I2
message. Hence, the Responder SHOULD NOT act on such an ICMP
message. Especially, it SHOULD NOT remove any minimal state created
when it sent the R1 HIP packet (if it did create one), but wait for
either a valid I2 HIP packet or the natural timeout (that is, if R1
packets are tracked at all). Likewise, the Initiator SHOULD ignore
any ICMP message while waiting for an R2 HIP packet, and SHOULD
delete any pending state only after a natural timeout.
9. IANA Considerations
IANA has reserved protocol number 139 for the Host Identity Protocol
and included it in the "IPv6 Extension Header Types" registry
[RFC7045] and the "Assigned Internet Protocol Numbers" registry. The
reference in both of these registries has been updated from [RFC5201]
to this specification.
The reference to the 128-bit value under the CGA Message Type
namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA"
has been changed from [RFC5201] to this specification.
The following changes to the "Host Identity Protocol (HIP)
Parameters" have been made. In many cases, the changes involved
updating the reference from [RFC5201] to this specification, but
there are some differences as outlined below. Allocation terminology
is defined in [RFC5226]; any existing references to "IETF Consensus"
can be replaced with "IETF Review" as per [RFC5226].
This document adds the value "2" to the existing registry. The
value of "1" has been left with a reference to [RFC5201].
The 7-bit Packet Type field in a HIP protocol packet describes the
type of a HIP protocol message. It is defined in Section 5.1.
All existing values referring to [RFC5201] have been updated to
refer to this specification. Other values have been left
HIT Suite ID
This specification creates a new registry for "HIT Suite ID".
This is different than the existing registry for "Suite ID", which
can be left unmodified for version 1 of the protocol ([RFC5201]).
The registry has been closed to new registrations.
The four-bit HIT Suite ID uses the OGA ID field in the ORCHID to
express the type of the HIT. This document defines three HIT
Suites (see Section 5.2.10).
The HIT Suite ID is also carried in the four higher-order bits of
the ID field in the HIT_SUITE_LIST parameter. The four
lower-order bits are reserved for future extensions of the HIT
Suite ID space beyond 16 values.
For the time being, the HIT Suite uses only four bits because
these bits have to be carried in the HIT. Using more bits for the
HIT Suite ID reduces the cryptographic strength of the HIT. HIT
Suite IDs must be allocated carefully to avoid namespace
exhaustion. Moreover, deprecated IDs should be reused after an
appropriate time span. If 15 Suite IDs (the zero value is
initially reserved) prove to be insufficient and more HIT Suite
IDs are needed concurrently, more bits can be used for the HIT
Suite ID by using one HIT Suite ID (0) to indicate that more bits
should be used. The HIT_SUITE_LIST parameter already supports
8-bit HIT Suite IDs, should longer IDs be needed. However,
RFC 7343 [RFC7343] does not presently support such an extension.
We suggest trying the rollover approach described in Appendix E
first. Possible extensions of the HIT Suite ID space to
accommodate eight bits and new HIT Suite IDs are defined through
Requests to register reused values should include a note that the
value is being reused after a deprecation period, to ensure
appropriate IETF review and approval.
The 16-bit Type field in a HIP parameter describes the type of the
parameter. It is defined in Section 5.2.1. The current values
are defined in Sections 5.2.3 through 5.2.23. The existing
"Parameter Types" registry has been updated as follows.
A new value (129) for R1_COUNTER has been introduced, with a
reference to this specification, and the existing value (128) for
R1_COUNTER has been left in place with a reference to [RFC5201].
This documents the change in value that has occurred in version 2
of this protocol. For clarity, the name for the value 128 has
been changed from "R1_COUNTER" to "R1_Counter (v1 only)".
A new value (579) for a new Parameter Type HIP_CIPHER has been
added, with reference to this specification. This Parameter Type
functionally replaces the HIP_TRANSFORM Parameter Type
(value 577), which has been left in the table with the existing
reference to [RFC5201]. For clarity, the name for the
value 577 has been changed from "HIP_TRANSFORM" to
"HIP_TRANSFORM (v1 only)".
A new value (715) for a new Parameter Type HIT_SUITE_LIST has been
added, with reference to this specification.
A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST
has been added, with reference to this specification.
The name of the HMAC Parameter Type (value 61505) has been changed
to HIP_MAC. The name of the HMAC_2 Parameter Type (value 61569)
has been changed to HIP_MAC_2. The reference has been changed to
All other Parameter Types that reference [RFC5201] have been
updated to refer to this specification, and Parameter Types that
reference other RFCs are unchanged.
The Type codes 32768 through 49151 (not 49141: a value corrected
from a previous version of this table) have been Reserved for
Private Use. Implementors SHOULD select types in a random fashion
from this range, thereby reducing the probability of collisions.
A method employing genuine randomness (such as flipping a coin)
SHOULD be used.
Where the existing ranges once stated "First Come First Served
with Specification Required", this has been changed to
The eight-bit Group ID values appear in the DIFFIE_HELLMAN
parameter and the DH_GROUP_LIST parameter and are defined in
Section 5.2.7. This registry has been updated based on the new
values specified in Section 5.2.7; values noted as being
DEPRECATED can be left in the table with reference to [RFC5201].
New values are assigned through IETF Review.
HIP Cipher ID
The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined
in Section 5.2.8. This is a new registry. New values from either
the reserved or unassigned space are assigned through IETF Review.
The four-bit DI-Type values in a HOST_ID parameter are defined in
Section 5.2.9. New values are assigned through IETF Review. All
existing values referring to [RFC5201] have been updated to refer
to this specification.
The 16-bit Algorithm values in a HOST_ID parameter are defined in
Section 5.2.9. This is a new registry. New values from either
the reserved or unassigned space are assigned through IETF Review.
ECC Curve Label
When the HI Algorithm values in a HOST_ID parameter are defined to
the values of either "ECDSA" or "ECDSA_LOW", a new registry is
needed to maintain the values for the ECC Curve Label as defined
in Section 5.2.9. This might be handled by specifying two
algorithm-specific subregistries named "ECDSA Curve Label" and
"ECDSA_LOW Curve Label". New values are to be assigned through
Notify Message Type
The 16-bit Notify Message Type values in a NOTIFICATION parameter
are defined in Section 5.2.19.
Notify Message Type values 1-10 are used for informing about
errors in packet structures, values 11-20 for informing about
problems in parameters containing cryptographic related material,
and values 21-30 for informing about problems in authentication or
packet integrity verification. Parameter numbers above 30 can be
used for informing about other types of errors or events.
The existing registration procedures have been updated as follows.
The range from 1-50 can remain as "IETF Review". The range from
51-8191 has been marked as "Specification Required". Values
8192-16383 remain as "Reserved for Private Use". Values
16384-40959 have been marked as "Specification Required". Values
40960-65535 remain as "Reserved for Private Use".
The following updates to the values have been made to the existing
registry. All existing values referring to [RFC5201] have been
updated to refer to this specification.
INVALID_HIP_TRANSFORM_CHOSEN has been renamed to
INVALID_HIP_CIPHER_CHOSEN with the same value (17).
A new value of 20 for the type UNSUPPORTED_HIT_SUITE has been
HMAC_FAILED has been renamed to HIP_MAC_FAILED with the same
SERVER_BUSY_PLEASE_RETRY has been renamed to
RESPONDER_BUSY_PLEASE_RETRY with the same value (44).
10. Differences from RFC 5201
This section summarizes the technical changes made from [RFC5201].
This section is informational, intended to help implementors of the
previous protocol version. If any text in this section contradicts
text in other portions of this specification, the text found outside
of this section should be considered normative.
This document specifies the HIP Version 2 protocol, which is not
interoperable with the HIP Version 1 protocol specified in [RFC5201].
The main technical changes are the inclusion of additional
cryptographic agility features, and an update of the mandatory and
optional algorithms, including Elliptic Curve support via the
Elliptic Curve DSA (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH)
algorithms. The mandatory cryptographic algorithm implementations
have been updated, such as replacing HMAC-SHA-1 with HMAC-SHA-256 and
the RSA/SHA-1 signature algorithm with RSASSA-PSS, and adding ECDSA
to RSA as mandatory public key types. This version of HIP is also
aligned with the ORCHID revision [RFC7343].
The following changes have been made to the protocol operation.
o Section 4.1.3 describes the new process for Diffie-Hellman group
negotiation, an aspect of cryptographic agility. The Initiator
may express a preference for the choice of a DH group in the I1
packet and may suggest multiple possible choices. The Responder
replies with a preference based on local policy and the options
provided by the Initiator. The Initiator may restart the base
exchange if the option chosen by the Responder is unsuitable
o Another aspect of cryptographic agility that has been added is the
ability to use different cryptographic hash functions to generate
the HIT. The Responder's HIT hash algorithm (RHASH) terminology
was introduced to support this. In addition, HIT Suites have been
introduced to group the set of cryptographic algorithms used
together for public key signature, hash function, and hash
truncation. The use of HIT Suites constrains the combinatorial
possibilities of algorithm selection for different functions. HIT
Suite IDs are related to the ORCHID OGA ID field ([RFC7343]).
o The puzzle mechanism has been slightly changed, in that the #I
parameter depends on the HIT hash function (RHASH) selected, and
the specification now advises against reusing the same #I value to
the same Initiator; more details are provided in Sections 4.1.2
o Section 4.1.4 was extended to cover details about R1 generation
counter rollover or reset.
o Section 4.1.6 was added to describe procedures for aborting a HIP
o Section 4.1.7 provides guidance on avoiding downgrade attacks on
the cryptographic algorithms.
o Section 4.1.8 on opportunistic mode has been updated to account
for cryptographic agility by adding HIT selection procedures.
o The HIP KEYMAT generation has been updated as described in
Section 6.5 to make the key derivation function a negotiable
aspect of the protocol.
o Packet processing for the I1, R1, and I2 packets has been updated
to account for new parameter processing.
o This specification adds a requirement that hosts MUST support
processing of ACK parameters with several SEQ sequence numbers
even when they do not support sending such parameters.
o This document now clarifies that several ECHO_REQUEST_UNSIGNED
parameters may be present in an R1 and that several ECHO_RESPONSE
parameters may be present in an I2.
o Procedures for responding to version mismatches with an ICMP
Parameter Problem have been added.
o The security considerations section (Section 8) has been updated
to remove possible attacks no longer considered applicable.
o The use of the Anonymous bit for making the sender's Host Identity
anonymous is now supported in packets other than the R1 and I2.
o Support for the use of a NULL HIP CIPHER is explicitly limited to
debugging and testing HIP and is no longer a mandatory algorithm
The following changes have been made to the parameter types and
encodings (Section 5.2).
o Four new parameter types have been added: DH_GROUP_LIST,
HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST.
o Two parameter types have been renamed: HMAC has been renamed to
HIP_MAC, and HMAC2 has been renamed to HIP_MAC_2.
o One parameter type is deprecated: HIP_TRANSFORM. Functionally, it
has been replaced by the HIP_CIPHER but with slightly different
semantics (hashes have been removed and are now determined by
o The TRANSPORT_FORMAT_LIST parameter allows transports to be
negotiated with the list instead of by their order in the
o The type code for the R1_COUNTER has been changed from 128 to 129
to reflect that it is now considered a Critical parameter and must
be echoed when present in R1.
o The PUZZLE and SOLUTION parameter lengths are now variable and
dependent on the RHASH length.
o The Diffie-Hellman Group IDs supported have been updated.
o The HOST_ID parameter now requires specification of an Algorithm.
o The NOTIFICATION parameter supports new Notify Message Type
o The HIP_SIGNATURE algorithm field has been changed from 8 bits to
16 bits to achieve alignment with the HOST_ID parameters.
o The specification clarifies that the SEQ parameter always contains
one update ID but that the ACK parameter may acknowledge several
o The restriction that only one ECHO_RESPONSE_UNSIGNED parameter
must be present in each HIP packet has been removed.
o The document creates a new type range allocation for parameters
that are only covered by a signature if a signature is present and
applies it to the newly created DH_GROUP_LIST parameter.
o The document clarifies that several NOTIFY parameters may be
present in a packet.
The following changes have been made to the packet contents
o The I1 packet now carries the Initiator's DH_GROUP_LIST.
o The R1 packet now carries the HIP_CIPHER, HIT_SUITE_LIST,
DH_GROUP_LIST, and TRANSPORT_FORMAT_LIST parameters.
o The I2 packet now carries the HIP_CIPHER and TRANSPORT_FORMAT_LIST
o This document clarifies that UPDATE packets that do not contain
either a SEQ or ACK parameter are invalid.
Appendix A. Using Responder Puzzles
As mentioned in Section 4.1.1, the Responder may delay state creation
and still reject most spoofed I2 packets by using a number of
pre-calculated R1 packets and a local selection function. This
appendix defines one possible implementation in detail. The purpose
of this appendix is to give the implementors an idea of how to
implement the mechanism. If the implementation is based on this
appendix, it MAY contain some local modification that makes an
attacker's task harder.
The Responder creates a secret value S, that it regenerates
periodically. The Responder needs to remember the two latest values
of S. Each time the S is regenerated, the R1 generation counter
value is incremented by one.
The Responder generates a pre-signed R1 packet. The signature for
pre-generated R1s must be recalculated when the Diffie-Hellman key is
recomputed or when the R1_COUNTER value changes due to S value
When the Initiator sends the I1 packet for initializing a connection,
the Responder receives the HIT and IP address from the packet, and
generates an #I value for the puzzle. The #I value is set to the
pre-signed R1 packet.
#I value calculation:
#I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n)
where n = RHASH_len
The RHASH algorithm is the same as is used to generate the
Responder's HIT value.
From an incoming I2 packet, the Responder receives the required
information to validate the puzzle: HITs, IP addresses, and the
information of the used S value from the R1_COUNTER. Using these
values, the Responder can regenerate the #I, and verify it against
the #I received in the I2 packet. If the #I values match, it can
verify the solution using #I, #J, and difficulty #K. If the #I
values do not match, the I2 is dropped.
V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K )
if V != 0, drop the packet
If the puzzle solution is correct, the #I and #J values are stored
for later use. They are used as input material when keying material
Keeping state about failed puzzle solutions depends on the
implementation. Although it is possible for the Responder not to
keep any state information, it still may do so to protect itself
against certain attacks (see Section 4.1.1).
Appendix B. Generating a Public Key Encoding from an HI
The following pseudo-code illustrates the process to generate a
public key encoding from an HI for both RSA and DSA.
The symbol ":=" denotes assignment; the symbol "+=" denotes
appending. The pseudo-function "encode_in_network_byte_order" takes
two parameters, an integer (bignum) and a length in bytes, and
returns the integer encoded into a byte string of the given length.
switch ( HI.algorithm )
buffer := encode_in_network_byte_order ( HI.RSA.e_len,
( HI.RSA.e_len > 255 ) ? 3 : 1 )
buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len )
buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len )
buffer := encode_in_network_byte_order ( HI.DSA.T , 1 )
buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 )
buffer += encode_in_network_byte_order ( HI.DSA.P , 64 +
8 * HI.DSA.T )
buffer += encode_in_network_byte_order ( HI.DSA.G , 64 +
8 * HI.DSA.T )
buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 +
8 * HI.DSA.T )
Appendix C. Example Checksums for HIP Packets
The HIP checksum for HIP packets is specified in Section 5.1.1.
Checksums for TCP and UDP packets running over HIP-enabled security
associations are specified in Section 4.5.1. The examples below use
[RFC3849] and [RFC5737] addresses, and HITs with the prefix of
2001:20 followed by zeros, followed by a decimal 1 or 2,
C.3. TCP Segment
Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets
use the IPv6 pseudo header format [RFC2460], with the HITs used in
place of the IPv6 addresses.
Sender's HIT: 2001:20::1
Receiver's HIT: 2001:20::2
Upper-Layer Packet Length: 20 0x14
Next Header: 6 0x06
Source port: 65500 0xffdc
Destination port: 22 0x0016
Sequence number: 1 0x00000001
Acknowledgment number: 0 0x00000000
Data offset: 5 0x5
Flags: SYN 0x02
Window size: 65535 0xffff
Checksum: 28586 0x6faa
Urgent pointer: 0 0x0000
Appendix D. ECDH and ECDSA 160-Bit Groups
The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits
symmetric strength. This was once considered appropriate for one
year of security. Today, these groups should be used only when the
host is not powerful enough (e.g., some embedded devices) and when
security requirements are low (e.g., long-term confidentiality is not
Appendix E. HIT Suites and HIT Generation
The HIT as an ORCHID [RFC7343] consists of three parts: A 28-bit
prefix, a 4-bit encoding of the ORCHID generation algorithm (OGA),
and a hash that includes the Host Identity and a context ID. The OGA
is an index pointing to the specific algorithm by which the public
key and the 96-bit hashed encoding are generated. The OGA is
protocol specific and is to be interpreted as defined below for all
protocols that use the same context ID as HIP. HIP groups sets of
valid combinations of signature and hash algorithms into HIT Suites.
These HIT Suites are addressed by an index, which is transmitted in
the OGA ID field of the ORCHID.
The set of used HIT Suites will be extended to counter the progress
in computation capabilities and vulnerabilities in the employed
algorithms. The intended use of the HIT Suites is to introduce a new
HIT Suite and phase out an old one before it becomes insecure. Since
the 4-bit OGA ID field only permits 15 HIT Suites to be used at the
same time (the HIT Suite with ID 0 is reserved), phased-out HIT
Suites must be reused at some point. In such a case, there will be a
rollover of the HIT Suite ID and the next newly introduced HIT Suite
will start with a lower HIT Suite index than the previously
introduced one. The rollover effectively deprecates the reused HIT
Suite. For a smooth transition, the HIT Suite should be deprecated a
considerable time before the HIT Suite index is reused.
Since the number of HIT Suites is tightly limited to 16, the HIT
Suites must be assigned carefully. Hence, sets of suitable
algorithms are grouped in a HIT Suite.
The HIT Suite of the Responder's HIT determines the RHASH and the
hash function to be used for the HMAC in HIP packets as well as the
signature algorithm family used for generating the HI. The list of
HIT Suites is defined in Table 10.
The drive to create HIP came to being after attending the MALLOC
meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman
really gave the original author, Bob Moskowitz, the assist to get HIP
beyond 5 paragraphs of ideas. It has matured considerably since the
early versions thanks to extensive input from IETFers. Most
importantly, its design goals are articulated and are different from
other efforts in this direction. Particular mention goes to the
members of the NameSpace Research Group of the IRTF. Noel Chiappa
provided valuable input at early stages of discussions about
identifier handling and Keith Moore the impetus to provide
resolvability. Steve Deering provided encouragement to keep working,
as a solid proposal can act as a proof of ideas for a research group.
Many others contributed; extensive security tips were provided by
Steve Bellovin. Rob Austein kept the DNS parts on track. Paul
Kocher taught Bob Moskowitz how to make the puzzle exchange expensive
for the Initiator to respond, but easy for the Responder to validate.
Bill Sommerfeld supplied the Birthday concept, which later evolved
into the R1 generation counter, to simplify reboot management. Erik
Nordmark supplied the CLOSE-mechanism for closing connections.
Rodney Thayer and Hugh Daniels provided extensive feedback. In the
early times of this document, John Gilmore kept Bob Moskowitz
challenged to provide something of value.
During the later stages of this document, when the editing baton was
transferred to Pekka Nikander, the input from the early implementors
was invaluable. Without having actual implementations, this document
would not be on the level it is now.
In the usual IETF fashion, a large number of people have contributed
to the actual text or ideas. The list of these people includes Jeff
Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Xin Gu, Rene
Hummen, Miika Komu, Mika Kousa, Julien Laganier, Andrew McGregor, Jan
Melen, Henrik Petander, Michael Richardson, Tim Shepard, Jorma Wall,
and Jukka Ylitalo. Our apologies to anyone whose name is missing.
Once the HIP Working Group was founded in early 2004, a number of
changes were introduced through the working group process. Most
notably, the original document was split in two, one containing the
base exchange and the other one defining how to use ESP. Some
modifications to the protocol proposed by Aura, et al. [AUR05] were
added at a later stage.
Robert Moskowitz (editor)
Oak Park, MI
Hirschmann Automation and Control
Stuttgarter Strasse 45-51
Ericsson Research NomadicLab
Phone: +358 9 299 1
Thomas R. Henderson
University of Washington
Campus Box 352500