RFC 7401
Host Identity Protocol Version 2 (HIPv2)
Pages: 128
Proposed Standard
→ Errata
Obsoletes: 5201
Updated by: 8002 9374
Proposed Standard
→ Errata
Obsoletes: 5201
Updated by: 8002 9374
Part 2 of 5 – Pages 12 to 38
4. Protocol Overview
This section is a simplified overview of the HIP protocol operation, and does not contain all the details of the packet formats or the packet processing steps. Sections 5 and 6 describe in more detail the packet formats and packet processing steps, respectively, and are normative in case of any conflicts with this section. The protocol number 139 has been assigned by IANA to the Host Identity Protocol. The HIP payload (Section 5.1) header could be carried in every IP datagram. However, since HIP headers are relatively large (40 bytes), it is desirable to 'compress' the HIP header so that the HIP header only occurs in control packets used to establish or change HIP association state. The actual method for header 'compression' and for matching data packets with existing HIP associations (if any) is defined in separate documents, describing transport formats and methods. All HIP implementations MUST implement, at minimum, the ESP transport format for HIP [RFC7402].4.1. Creating a HIP Association
By definition, the system initiating a HIP base exchange is the Initiator, and the peer is the Responder. This distinction is typically forgotten once the base exchange completes, and either party can become the Initiator in future communications. The HIP base exchange serves to manage the establishment of state between an Initiator and a Responder. The first packet, I1, initiates the exchange, and the last three packets, R1, I2, and R2, constitute an authenticated Diffie-Hellman [DIF76] key exchange for session-key generation. In the first two packets, the hosts agree on a set of cryptographic identifiers and algorithms that are then used in and after the exchange. During the Diffie-Hellman key exchange, a piece of keying material is generated. The HIP association keys are drawn from this keying material by using a Key Derivation Function (KDF). If other cryptographic keys are needed, e.g., to be used with ESP, they are expected to be drawn from the same keying material by using the KDF. The Initiator first sends a trigger packet, I1, to the Responder. The packet contains the HIT of the Initiator and possibly the HIT of the Responder, if it is known. Moreover, the I1 packet initializes the negotiation of the Diffie-Hellman group that is used for generating the keying material. Therefore, the I1 packet contains a list of Diffie-Hellman Group IDs supported by the Initiator. Note that in some cases it may be possible to replace this trigger packet
with some other form of a trigger, in which case the protocol starts with the Responder sending the R1 packet. In such cases, another mechanism to convey the Initiator's supported DH groups (e.g., by using a default group) must be specified. The second packet, R1, starts the actual authenticated Diffie-Hellman exchange. It contains a puzzle -- a cryptographic challenge that the Initiator must solve before continuing the exchange. The level of difficulty of the puzzle can be adjusted based on the level of trust with the Initiator, the current load, or other factors. In addition, the R1 contains the Responder's Diffie-Hellman parameter and lists of cryptographic algorithms supported by the Responder. Based on these lists, the Initiator can continue, abort, or restart the base exchange with a different selection of cryptographic algorithms. Also, the R1 packet contains a signature that covers selected parts of the message. Some fields are left outside the signature to support pre-created R1s. In the I2 packet, the Initiator MUST display the solution to the received puzzle. Without a correct solution, the I2 message is discarded. The I2 packet also contains a Diffie-Hellman parameter that carries needed information for the Responder. The I2 packet is signed by the Initiator. The R2 packet acknowledges the receipt of the I2 packet and completes the base exchange. The packet is signed by the Responder.
The base exchange is illustrated below in Figure 1. The term "key" refers to the Host Identity public key, and "sig" represents a signature using such a key. The packets contain other parameters not shown in this figure. Initiator Responder I1: DH list --------------------------> select precomputed R1 R1: puzzle, DH, key, sig <------------------------- check sig remain stateless solve puzzle I2: solution, DH, {key}, sig --------------------------> compute DH check puzzle check sig R2: sig <-------------------------- check sig compute DH Figure 14.1.1. HIP Puzzle Mechanism
The purpose of the HIP puzzle mechanism is to protect the Responder from a number of denial-of-service threats. It allows the Responder to delay state creation until receiving the I2 packet. Furthermore, the puzzle allows the Responder to use a fairly cheap calculation to check that the Initiator is "sincere" in the sense that it has churned enough CPU cycles in solving the puzzle. The puzzle allows a Responder implementation to completely delay association-specific state creation until a valid I2 packet is received. An I2 packet without a valid puzzle solution can be rejected immediately once the Responder has checked the solution. The solution can be checked by computing only one hash function, and invalid solutions can be rejected before state is created, and before CPU-intensive public-key signature verification and Diffie-Hellman key generation are performed. By varying the difficulty of the puzzle, the Responder can frustrate CPU- or memory-targeted DoS attacks. The Responder can remain stateless and drop most spoofed I2 packets because puzzle calculation is based on the Initiator's Host Identity Tag. The idea is that the Responder has a (perhaps varying) number of pre-calculated R1 packets, and it selects one of these based on
the information carried in the I1 packet. When the Responder then later receives the I2 packet, it can verify that the puzzle has been solved using the Initiator's HIT. This makes it impractical for the attacker to first exchange one I1/R1 packet, and then generate a large number of spoofed I2 packets that seemingly come from different HITs. This method does not protect the Responder from an attacker that uses fixed HITs, though. Against such an attacker, a viable approach may be to create a piece of local state, and remember that the puzzle check has previously failed. See Appendix A for one possible implementation. Responder implementations SHOULD include sufficient randomness in the puzzle values so that algorithmic complexity attacks become impossible [CRO03]. The Responder can set the puzzle difficulty for the Initiator, based on its level of trust of the Initiator. Because the puzzle is not included in the signature calculation, the Responder can use pre-calculated R1 packets and include the puzzle just before sending the R1 to the Initiator. The Responder SHOULD use heuristics to determine when it is under a denial-of-service attack, and set the puzzle difficulty value #K appropriately, as explained later.4.1.2. Puzzle Exchange
The Responder starts the puzzle exchange when it receives an I1 packet. The Responder supplies a random number #I, and requires the Initiator to find a number #J. To select a proper #J, the Initiator must create the concatenation of #I, the HITs of the parties, and #J, and calculate a hash over this concatenation using the RHASH algorithm. The lowest-order #K bits of the result MUST be zeros. The value #K sets the difficulty of the puzzle. To generate a proper number #J, the Initiator will have to generate a number of #Js until one produces the hash target of zeros. The Initiator SHOULD give up after exceeding the puzzle Lifetime in the PUZZLE parameter (as described in Section 5.2.4). The Responder needs to re-create the concatenation of #I, the HITs, and the provided #J, and compute the hash once to prove that the Initiator completed its assigned task. To prevent precomputation attacks, the Responder MUST select the number #I in such a way that the Initiator cannot guess it. Furthermore, the construction MUST allow the Responder to verify that the value #I was indeed selected by it and not by the Initiator. See Appendix A for an example on how to implement this. Using the Opaque data field in the PUZZLE (see Section 5.2.4) in an ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder
can include some data in R1 that the Initiator MUST copy unmodified in the corresponding I2 packet. The Responder can use the opaque data to transfer a piece of local state information to the Initiator and back -- for example, to recognize that the I2 is a response to a previously sent R1. The Responder can generate the opaque data in various ways, e.g., using encryption or hashing with some secret, the sent #I, and possibly using other related data. With the same secret, the received #I (from the I2 packet), and the other related data (if any), the Responder can verify that it has itself sent the #I to the Initiator. The Responder MUST periodically change such a secret. It is RECOMMENDED that the Responder generates new secrets for the puzzle and new R1s once every few minutes. Furthermore, it is RECOMMENDED that the Responder is able to verify a valid puzzle solution at least Lifetime seconds after the puzzle secret has been deprecated. This time value guarantees that the puzzle is valid for at least Lifetime and at most 2 * Lifetime seconds. This limits the usability that an old, solved puzzle has to an attacker. Moreover, it avoids problems with the validity of puzzles if the lifetime is relatively short compared to the network delay and the time for solving the puzzle. The puzzle value #I and the solution #J are inputs for deriving the keying material from the Diffie-Hellman key exchange (see Section 6.5). Therefore, to ensure that the derived keying material differs, a Responder SHOULD NOT use the same puzzle #I with the same DH keys for the same Initiator twice. Such uniqueness can be achieved, for example, by using a counter as an additional input for generating #I. This counter can be increased for each processed I1 packet. The state of the counter can be transmitted in the Opaque data field in the PUZZLE (see Section 5.2.4), in an ECHO_REQUEST_SIGNED parameter (see Section 5.2.20), or in an ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need to establish state. NOTE: The protocol developers explicitly considered whether R1 should include a timestamp in order to protect the Initiator from replay attacks. The decision was to NOT include a timestamp, to avoid problems with global time synchronization. NOTE: The protocol developers explicitly considered whether a memory- bound function should be used for the puzzle instead of a CPU-bound function. The decision was to not use memory-bound functions.
4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation
The packets R1, I2, and R2 implement a standard authenticated Diffie-Hellman exchange. The Responder sends one of its public Diffie-Hellman keys and its public authentication key, i.e., its Host Identity, in R1. The signature in the R1 packet allows the Initiator to verify that the R1 has been once generated by the Responder. However, since the R1 is precomputed and therefore does not cover association-specific information in the I1 packet, it does not protect against replay attacks. Before the actual authenticated Diffie-Hellman exchange, the Initiator expresses its preference regarding its choice of the DH groups in the I1 packet. The preference is expressed as a sorted list of DH Group IDs. The I1 packet is not protected by a signature. Therefore, this list is sent in an unauthenticated way to avoid costly computations for processing the I1 packet at the Responder side. Based on the preferences of the Initiator, the Responder sends an R1 packet containing its most suitable public DH value. The Responder also attaches a list of its own preferences to the R1 to convey the basis for the DH group selection to the Initiator. This list is carried in the signed part of the R1 packet. If the choice of the DH group value in the R1 does not match the preferences of the Initiator and the Responder, the Initiator can detect that the list of DH Group IDs in the I1 was manipulated (see below for details). If none of the DH Group IDs in the I1 packet are supported by the Responder, the Responder selects the DH group most suitable for it, regardless of the Initiator's preference. It then sends the R1 containing this DH group and its list of supported DH Group IDs to the Initiator. When the Initiator receives an R1, it receives one of the Responder's public Diffie-Hellman values and the list of DH Group IDs supported by the Responder. This list is covered by the signature in the R1 packet to avoid forgery. The Initiator compares the Group ID of the public DH value in the R1 packet to the list of supported DH Group IDs in the R1 packets and to its own preferences expressed in the list of supported DH Group IDs. The Initiator continues the BEX only if the Group ID of the public DH value of the Responder is the most preferred of the IDs supported by both the Initiator and Responder. Otherwise, the communication is subject to a downgrade attack, and the Initiator MUST either restart the base exchange with a new I1 packet or abort the base exchange. If the Responder's choice of the DH group is not supported by the Initiator, the Initiator MAY abort the handshake or send a new I1 packet with a different list of supported DH groups. However, the Initiator MUST verify the
signature of the R1 packet before restarting or aborting the handshake. It MUST silently ignore the R1 packet if the signature is not valid. If the preferences regarding the DH Group ID match, the Initiator computes the Diffie-Hellman session key (Kij). The Initiator creates a HIP association using keying material from the session key (see Section 6.5) and may use the HIP association to encrypt its public authentication key, i.e., the Host Identity. The resulting I2 packet contains the Initiator's Diffie-Hellman key and its (optionally encrypted) public authentication key. The signature of the I2 message covers all parameters of the signed parameter ranges (see Section 5.2) in the packet without exceptions, as in the R1. The Responder extracts the Initiator's Diffie-Hellman public key from the I2 packet, computes the Diffie-Hellman session key, creates a corresponding HIP association, and decrypts the Initiator's public authentication key. It can then verify the signature using the authentication key. The final message, R2, completes the BEX and protects the Initiator against replay attacks, because the Responder uses the shared key from the Diffie-Hellman exchange to create a Hashed Message Authentication Code (HMAC) and also uses the private key of its Host Identity to sign the packet contents.4.1.4. HIP Replay Protection
HIP includes the following mechanisms to protect against malicious packet replays. Responders are protected against replays of I1 packets by virtue of the stateless response to I1 packets with pre-signed R1 messages. Initiators are protected against R1 replays by a monotonically increasing "R1 generation counter" included in the R1. Responders are protected against replays of forged I2 packets by the puzzle mechanism (see Section 4.1.1 above), and optional use of opaque data. Hosts are protected against replays of R2 packets and UPDATEs by use of a less expensive HMAC verification preceding the HIP signature verification. The R1 generation counter is a monotonically increasing 64-bit counter that may be initialized to any value. The scope of the counter MAY be system-wide, but there SHOULD be a separate counter for each Host Identity, if there is more than one local Host Identity. The value of this counter SHOULD be preserved across system reboots and invocations of the HIP base exchange. This counter indicates the current generation of puzzles. Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations. A system's local counter MUST be
incremented at least as often as every time old R1s cease to be valid. The local counter SHOULD never be decremented; otherwise, the host exposes its peers to the replay of previously generated, higher- numbered R1s. A host may receive more than one R1, either due to sending multiple I1 packets (see Section 6.6.1) or due to a replay of an old R1. When sending multiple I1 packets to the same host, an Initiator SHOULD wait for a small amount of time (a reasonable time may be 2 * expected RTT) after the first R1 reception to allow possibly multiple R1s to arrive, and it SHOULD respond to an R1 among the set with the largest R1 generation counter. If an Initiator is processing an R1 or has already sent an I2 packet (still waiting for the R2 packet) and it receives another R1 with a larger R1 generation counter, it MAY elect to restart R1 processing with the fresher R1, as if it were the first R1 to arrive. The R1 generation counter may roll over or may become reset. It is important for an Initiator to be robust to the loss of state about the R1 generation counter of a peer or to a reset of the peer's counter. It is recommended that, when choosing between multiple R1s, the Initiator prefer to use the R1 that corresponds to the current R1 generation counter, but that if it is unable to make progress with that R1, the Initiator may try the other R1s, beginning with the R1 packet with the highest counter.4.1.5. Refusing a HIP Base Exchange
A HIP-aware host may choose not to accept a HIP base exchange. If the host's policy is to only be an Initiator and policy allows the establishment of a HIP association with the original Initiator, it should begin its own HIP base exchange. A host MAY choose to have such a policy since only the privacy of the Initiator's HI is protected in the exchange. It should be noted that such behavior can introduce the risk of a race condition if each host's policy is to only be an Initiator, at which point the HIP base exchange will fail. If the host's policy does not permit it to enter into a HIP exchange with the Initiator, it should send an ICMP 'Destination Unreachable, Administratively Prohibited' message. A more complex HIP packet is not used here as it actually opens up more potential DoS attacks than a simple ICMP message. A HIP NOTIFY message is not used because no HIP association exists between the two hosts at that time.
4.1.6. Aborting a HIP Base Exchange
Two HIP hosts may encounter situations in which they cannot complete a HIP base exchange because of insufficient support for cryptographic algorithms, in particular the HIT Suites and DH groups. After receiving the R1 packet, the Initiator can determine whether the Responder supports the required cryptographic operations to successfully establish a HIP association. The Initiator can abort the BEX silently after receiving an R1 packet that indicates an unsupported set of algorithms. The specific conditions are described below. The R1 packet contains a signed list of HIT Suite IDs as supported by the Responder. Therefore, the Initiator can determine whether its source HIT is supported by the Responder. If the HIT Suite ID of the Initiator's HIT is not contained in the list of HIT Suites in the R1, the Initiator MAY abort the handshake silently or MAY restart the handshake with a new I1 packet that contains a source HIT supported by the Responder. During the handshake, the Initiator and the Responder agree on a single DH group. The Responder selects the DH group and its DH public value in the R1 based on the list of DH Group IDs in the I1 packet. If the Responder supports none of the DH groups requested by the Initiator, the Responder selects an arbitrary DH and replies with an R1 containing its list of supported DH Group IDs. In such a case, the Initiator receives an R1 packet containing the DH public value for an unrequested DH group and also the Responder's DH group list in the signed part of the R1 packet. At this point, the Initiator MAY abort the handshake or MAY restart the handshake by sending a new I1 packet containing a selection of DH Group IDs that is supported by the Responder.4.1.7. HIP Downgrade Protection
In a downgrade attack, an attacker attempts to unnoticeably manipulate the packets of an Initiator and/or a Responder to influence the result of the cryptographic negotiations in the BEX in its favor. As a result, the victims select weaker cryptographic algorithms than they would otherwise have selected without the attacker's interference. Downgrade attacks can only be successful if they remain undetected by the victims and the victims falsely assume a secure communication channel. In HIP, almost all packet parameters related to cryptographic negotiations are covered by signatures. These parameters cannot be directly manipulated in a downgrade attack without invalidating the signature. However, signed packets can be subject to replay attacks.
In such a replay attack, the attacker could use an old BEX packet with an outdated and weak selection of cryptographic algorithms and replay it instead of a more recent packet with a collection of stronger cryptographic algorithms. Signed packets that could be subject to this replay attack are the R1 and I2 packet. However, replayed R1 and I2 packets cannot be used to successfully establish a HIP BEX because these packets also contain the public DH values of the Initiator and the Responder. Old DH values from replayed packets lead to invalid keying material and mismatching shared secrets because the attacker is unable to derive valid keying material from the DH public keys in the R1 and cannot generate a valid HMAC and signature for a replayed I2. In contrast to the first version of HIP [RFC5201], version 2 of HIP as defined in this document begins the negotiation of the DH groups already in the first BEX packet, the I1. The I1 packet is, by intention, not protected by a signature, to avoid CPU-intensive cryptographic operations processing floods of I1 packets targeted at the Responder. Hence, the list of DH Group IDs in the I1 packet is vulnerable to forgery and manipulation. To thwart an unnoticed manipulation of the I1 packet, the Responder chooses the DH group deterministically and includes its own list of DH Group IDs in the signed part of the R1 packet. The Initiator can detect an attempted downgrade attack by comparing the list of DH Group IDs in the R1 packet to its own preferences in the I1 packet. If the choice of the DH group in the R1 packet does not equal the best match of the two lists (the highest-priority DH ID of the Responder that is present in the Initiator's DH list), the Initiator can conclude that its list in the I1 packet was altered by an attacker. In this case, the Initiator can restart or abort the BEX. As mentioned before, the detection of the downgrade attack is sufficient to prevent it.4.1.8. HIP Opportunistic Mode
It is possible to initiate a HIP BEX even if the Responder's HI (and HIT) is unknown. In this case, the initial I1 packet contains all zeros as the destination HIT. This kind of connection setup is called opportunistic mode. The Responder may have multiple HITs due to multiple supported HIT Suites. Since the Responder's HIT Suite in the opportunistic mode is not determined by the destination HIT of the I1 packet, the Responder can freely select a HIT of any HIT Suite. The complete set of HIT Suites supported by the Initiator is not known to the Responder. Therefore, the Responder SHOULD select its HIT from the same HIT Suite as the Initiator's HIT (indicated by the HIT Suite information in the OGA ID field of the Initiator's HIT) because this HIT Suite is obviously supported by the Initiator. If the Responder selects a
different HIT that is not supported by the Initiator, the Initiator
MAY restart the BEX with an I1 packet with a source HIT that is
contained in the list of the Responder's HIT Suites in the R1 packet.
Note that the Initiator cannot verify the signature of the R1 packet
if the Responder's HIT Suite is not supported. Therefore, the
Initiator MUST treat R1 packets with unsupported Responder HITs as
potentially forged and MUST NOT use any parameters from the
unverified R1 besides the HIT_SUITE_LIST. Moreover, an Initiator
that uses an unverified HIT_SUITE_LIST from an R1 packet to determine
a possible source HIT MUST verify that the HIT_SUITE_LIST in the
first unverified R1 packet matches the HIT_SUITE_LIST in the second
R1 packet for which the Initiator supports the signature algorithm.
The Initiator MUST restart the BEX with a new I1 packet for which the
algorithm was mentioned in the verifiable R1 if the two lists do not
match. This procedure is necessary to mitigate downgrade attacks.
There are both security and API issues involved with the
opportunistic mode. These issues are described in the remainder of
this section.
Given that the Responder's HI is not known by the Initiator, there
must be suitable API calls that allow the Initiator to request,
directly or indirectly, that the underlying system initiates the HIP
base exchange solely based on locators. The Responder's HI will be
tentatively available in the R1 packet, and in an authenticated form
once the R2 packet has been received and verified. Hence, the
Responder's HIT could be communicated to the application via new API
mechanisms. However, with a backwards-compatible API the application
sees only the locators used for the initial contact. Depending on
the desired semantics of the API, this can raise the following
issues:
o The actual locators may later change if an UPDATE message is used,
even if from the API perspective the association still appears to
be between two specific locators. However, the locator update is
still secure, and the association is still between the same nodes.
o Different associations between the same two locators may result in
connections to different nodes, if the implementation no longer
remembers which identifier the peer had in an earlier association.
This is possible when the peer's locator has changed for
legitimate reasons or when an attacker pretends to be a node that
has the peer's locator. Therefore, when using opportunistic mode,
HIP implementations MUST NOT place any expectation that the peer's
HI returned in the R1 message matches any HI previously seen from
that address.
If the HIP implementation and application do not have the same
understanding of what constitutes an association, this may even
happen within the same association. For instance, an
implementation may not know when HIP state can be purged for
UDP-based applications.
In addition, the following security considerations apply. The
generation counter mechanism will be less efficient in protecting
against replays of the R1 packet, given that the Responder can choose
a replay that uses an arbitrary HI, not just the one given in the I1
packet.
More importantly, the opportunistic exchange is vulnerable to
man-in-the-middle attacks, because the Initiator does not have any
public key information about the peer. To assess the impacts of this
vulnerability, we compare it to vulnerabilities in current,
non-HIP-capable communications.
An attacker on the path between the two peers can insert itself as a
man-in-the-middle by providing its own identifier to the Initiator
and then initiating another HIP association towards the Responder.
For this to be possible, the Initiator must employ opportunistic
mode, and the Responder must be configured to accept a connection
from any HIP-enabled node.
An attacker outside the path will be unable to do so, given that it
cannot respond to the messages in the base exchange.
These security properties are characteristic also of communications
in the current Internet. A client contacting a server without
employing end-to-end security may find itself talking to the server
via a man-in-the-middle, assuming again that the server is willing to
talk to anyone.
If end-to-end security is in place, then the worst that can happen in
both the opportunistic HIP and non-HIP (normal IP) cases is denial-
of-service; an entity on the path can disrupt communications, but
will be unable to successfully insert itself as a man-in-the-middle.
However, once the opportunistic exchange has successfully completed,
HIP provides confidentiality and integrity protection for the
communications, and can securely change the locators of the
endpoints.
As a result, opportunistic mode in HIP offers a "better than nothing"
security model. Initially, a base exchange authenticated in the
opportunistic mode involves a leap of faith subject to man-in-the-
middle attacks, but subsequent datagrams related to the same HIP
association cannot be compromised by a new man-in-the-middle attack. Further, if the man-in-the-middle moves away from the path of the active association, the attack would be exposed after the fact. Thus, it can be stated that opportunistic mode in HIP is at least as secure as unprotected IP-based communications.4.2. Updating a HIP Association
A HIP association between two hosts may need to be updated over time. Examples include the need to rekey expiring security associations, add new security associations, or change IP addresses associated with hosts. The UPDATE packet is used for those and other similar purposes. This document only specifies the UPDATE packet format and basic processing rules, with mandatory parameters. The actual usage is defined in separate specifications. HIP provides a general-purpose UPDATE packet, which can carry multiple HIP parameters, for updating the HIP state between two peers. The UPDATE mechanism has the following properties: UPDATE messages carry a monotonically increasing sequence number and are explicitly acknowledged by the peer. Lost UPDATEs or acknowledgments may be recovered via retransmission. Multiple UPDATE messages may be outstanding under certain circumstances. UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters, since processing UPDATE signatures alone is a potential DoS attack against intermediate systems. UPDATE packets are explicitly acknowledged by the use of an acknowledgment parameter that echoes an individual sequence number received from the peer. A single UPDATE packet may contain both a sequence number and one or more acknowledgment numbers (i.e., piggybacked acknowledgment(s) for the peer's UPDATE). The UPDATE packet is defined in Section 5.3.5.4.3. Error Processing
HIP error processing behavior depends on whether or not there exists an active HIP association. In general, if a HIP association exists between the sender and receiver of a packet causing an error condition, the receiver SHOULD respond with a NOTIFY packet. On the other hand, if there are no existing HIP associations between the sender and receiver, or the receiver cannot reasonably determine the identity of the sender, the receiver MAY respond with a suitable ICMP message; see Section 5.4 for more details.
The HIP protocol and state machine are designed to recover from one
of the parties crashing and losing its state. The following
scenarios describe the main use cases covered by the design.
No prior state between the two systems.
The system with data to send is the Initiator. The process
follows the standard four-packet base exchange, establishing
the HIP association.
The system with data to send has no state with the receiver, but
the receiver has a residual HIP association.
The system with data to send is the Initiator. The Initiator
acts as in no prior state, sending an I1 packet and receiving
an R1 packet. When the Responder receives a valid I2 packet,
the old association is 'discovered' and deleted, and the new
association is established.
The system with data to send has a HIP association, but the
receiver does not.
The system sends data on the outbound user data security
association. The receiver 'detects' the situation when it
receives a user data packet that it cannot match to any HIP
association. The receiving host MUST discard this packet.
The receiving host SHOULD send an ICMP packet, with the type
Parameter Problem, to inform the sender that the HIP
association does not exist (see Section 5.4), and it MAY
initiate a new HIP BEX. However, responding with these
optional mechanisms is implementation or policy dependent. If
the sending application doesn't expect a response, the system
could possibly send a large number of packets in this state, so
for this reason, the sending of one or more ICMP packets is
RECOMMENDED. However, any such responses MUST be rate-limited
to prevent abuse (see Section 5.4).
4.4. HIP State Machine
HIP itself has little state. In the HIP base exchange, there is an
Initiator and a Responder. Once the security associations (SAs) are
established, this distinction is lost. If the HIP state needs to be
re-established, the controlling parameters are which peer still has
state and which has a datagram to send to its peer. The following
state machine attempts to capture these processes.
The state machine is symmetric and is presented in a single system view, representing either an Initiator or a Responder. The state machine is not a full representation of the processing logic. Additional processing rules are presented in the packet definitions. Hence, both are needed to completely implement HIP. This document extends the state machine as defined in [RFC5201] and introduces a restart option to allow for the negotiation of cryptographic algorithms. The extension to the previous state machine in [RFC5201] is a transition from state I1-SENT back again to I1-SENT; namely, the restart option. An Initiator is required to restart the HIP base exchange if the Responder does not support the HIT Suite of the Initiator. In this case, the Initiator restarts the HIP base exchange by sending a new I1 packet with a source HIT supported by the Responder. Implementors must understand that the state machine, as described here, is informational. Specific implementations are free to implement the actual processing logic differently. Section 6 describes the packet processing rules in more detail. This state machine focuses on the HIP I1, R1, I2, and R2 packets only. New states and state transitions may be introduced by mechanisms in other specifications (such as mobility and multihoming).4.4.1. State Machine Terminology
Unused Association Lifetime (UAL): Implementation-specific time for which, if no packet is sent or received for this time interval, a host MAY begin to tear down an active HIP association. Maximum Segment Lifetime (MSL): Maximum time that a HIP packet is expected to spend in the network. A default value of 2 minutes has been borrowed from [RFC0793] because it is a prevailing assumption for packet lifetimes. Exchange Complete (EC): Time that the host spends at the R2-SENT state before it moves to the ESTABLISHED state. The time is n * I2 retransmission timeout, where n is about I2_RETRIES_MAX. Receive ANYOTHER: Any received packet for which no state transitions or processing rules are defined for a given state.
4.4.2. HIP States
+---------------------+---------------------------------------------+ | State | Explanation | +---------------------+---------------------------------------------+ | UNASSOCIATED | State machine start | | | | | I1-SENT | Initiating base exchange | | | | | I2-SENT | Waiting to complete base exchange | | | | | R2-SENT | Waiting to complete base exchange | | | | | ESTABLISHED | HIP association established | | | | | CLOSING | HIP association closing, no data can be | | | sent | | | | | CLOSED | HIP association closed, no data can be sent | | | | | E-FAILED | HIP base exchange failed | +---------------------+---------------------------------------------+ Table 1: HIP States
4.4.3. HIP State Processes
System behavior in state UNASSOCIATED, Table 2. +----------------------------+--------------------------------------+ | Trigger | Action | +----------------------------+--------------------------------------+ | User data to send, | Send I1 and go to I1-SENT | | requiring a new HIP | | | association | | | | | | Receive I1 | Send R1 and stay at UNASSOCIATED | | | | | Receive I2, process | If successful, send R2 and go to | | | R2-SENT | | | | | | If fail, stay at UNASSOCIATED | | | | | Receive user data for an | Optionally send ICMP as defined in | | unknown HIP association | Section 5.4 and stay at UNASSOCIATED | | | | | Receive CLOSE | Optionally send ICMP Parameter | | | Problem and stay at UNASSOCIATED | | | | | Receive ANYOTHER | Drop and stay at UNASSOCIATED | +----------------------------+--------------------------------------+ Table 2: UNASSOCIATED - Start State
System behavior in state I1-SENT, Table 3. +---------------------+---------------------------------------------+ | Trigger | Action | +---------------------+---------------------------------------------+ | Receive I1 from | If the local HIT is smaller than the peer | | Responder | HIT, drop I1 and stay at I1-SENT (see | | | Section 6.5 for HIT comparison) | | | | | | If the local HIT is greater than the peer | | | HIT, send R1 and stay at I1-SENT | | | | | Receive I2, process | If successful, send R2 and go to R2-SENT | | | | | | If fail, stay at I1-SENT | | | | | Receive R1, process | If the HIT Suite of the local HIT is not | | | supported by the peer, select supported | | | local HIT, send I1, and stay at I1-SENT | | | | | | If successful, send I2 and go to I2-SENT | | | | | | If fail, stay at I1-SENT | | | | | Receive ANYOTHER | Drop and stay at I1-SENT | | | | | Timeout | Increment trial counter | | | | | | If counter is less than I1_RETRIES_MAX, | | | send I1 and stay at I1-SENT | | | | | | If counter is greater than I1_RETRIES_MAX, | | | go to E-FAILED | +---------------------+---------------------------------------------+ Table 3: I1-SENT - Initiating the HIP Base Exchange
System behavior in state I2-SENT, Table 4. +---------------------+---------------------------------------------+ | Trigger | Action | +---------------------+---------------------------------------------+ | Receive I1 | Send R1 and stay at I2-SENT | | | | | Receive R1, process | If successful, send I2 and stay at I2-SENT | | | | | | If fail, stay at I2-SENT | | | | | Receive I2, process | If successful and local HIT is smaller than | | | the peer HIT, drop I2 and stay at I2-SENT | | | | | | If successful and local HIT is greater than | | | the peer HIT, send R2 and go to R2-SENT | | | | | | If fail, stay at I2-SENT | | | | | Receive R2, process | If successful, go to ESTABLISHED | | | | | | If fail, stay at I2-SENT | | | | | Receive CLOSE, | If successful, send CLOSE_ACK and go to | | process | CLOSED | | | | | | If fail, stay at I2-SENT | | | | | Receive ANYOTHER | Drop and stay at I2-SENT | | | | | Timeout | Increment trial counter | | | | | | If counter is less than I2_RETRIES_MAX, | | | send I2 and stay at I2-SENT | | | | | | If counter is greater than I2_RETRIES_MAX, | | | go to E-FAILED | +---------------------+---------------------------------------------+ Table 4: I2-SENT - Waiting to Finish the HIP Base Exchange
System behavior in state R2-SENT, Table 5. +------------------------+------------------------------------------+ | Trigger | Action | +------------------------+------------------------------------------+ | Receive I1 | Send R1 and stay at R2-SENT | | | | | Receive I2, process | If successful, send R2 and stay at | | | R2-SENT | | | | | | If fail, stay at R2-SENT | | | | | Receive R1 | Drop and stay at R2-SENT | | | | | Receive R2 | Drop and stay at R2-SENT | | | | | Receive data or UPDATE | Move to ESTABLISHED | | | | | Exchange Complete | Move to ESTABLISHED | | Timeout | | | | | | Receive CLOSE, process | If successful, send CLOSE_ACK and go to | | | CLOSED | | | | | | If fail, stay at ESTABLISHED | | | | | Receive CLOSE_ACK | Drop and stay at R2-SENT | | | | | Receive NOTIFY | Process and stay at R2-SENT | +------------------------+------------------------------------------+ Table 5: R2-SENT - Waiting to Finish HIP
System behavior in state ESTABLISHED, Table 6. +---------------------+---------------------------------------------+ | Trigger | Action | +---------------------+---------------------------------------------+ | Receive I1 | Send R1 and stay at ESTABLISHED | | | | | Receive I2 | Process with puzzle and possible Opaque | | | data verification | | | | | | If successful, send R2, drop old HIP | | | association, establish a new HIP | | | association, and go to R2-SENT | | | | | | If fail, stay at ESTABLISHED | | | | | Receive R1 | Drop and stay at ESTABLISHED | | | | | Receive R2 | Drop and stay at ESTABLISHED | | | | | Receive user data | Process and stay at ESTABLISHED | | for HIP association | | | | | | No packet | Send CLOSE and go to CLOSING | | sent/received | | | during UAL minutes | | | | | | Receive UPDATE | Process and stay at ESTABLISHED | | | | | Receive CLOSE, | If successful, send CLOSE_ACK and go to | | process | CLOSED | | | | | | If fail, stay at ESTABLISHED | | | | | Receive CLOSE_ACK | Drop and stay at ESTABLISHED | | | | | Receive NOTIFY | Process and stay at ESTABLISHED | +---------------------+---------------------------------------------+ Table 6: ESTABLISHED - HIP Association Established
System behavior in state CLOSING, Table 7. +----------------------------+--------------------------------------+ | Trigger | Action | +----------------------------+--------------------------------------+ | User data to send, | Send I1 and go to I1-SENT | | requires the creation of | | | another incarnation of the | | | HIP association | | | | | | Receive I1 | Send R1 and stay at CLOSING | | | | | Receive I2, process | If successful, send R2 and go to | | | R2-SENT | | | | | | If fail, stay at CLOSING | | | | | Receive R1, process | If successful, send I2 and go to | | | I2-SENT | | | | | | If fail, stay at CLOSING | | | | | Receive CLOSE, process | If successful, send CLOSE_ACK, | | | discard state, and go to CLOSED | | | | | | If fail, stay at CLOSING | | | | | Receive CLOSE_ACK, process | If successful, discard state and go | | | to UNASSOCIATED | | | | | | If fail, stay at CLOSING | | | | | Receive ANYOTHER | Drop and stay at CLOSING | | | | | Timeout | Increment timeout sum and reset | | | timer. If timeout sum is less than | | | UAL+MSL minutes, retransmit CLOSE | | | and stay at CLOSING. | | | | | | If timeout sum is greater than | | | UAL+MSL minutes, go to UNASSOCIATED | +----------------------------+--------------------------------------+ Table 7: CLOSING - HIP Association Has Not Been Used for UAL Minutes
System behavior in state CLOSED, Table 8. +----------------------------------------+--------------------------+ | Trigger | Action | +----------------------------------------+--------------------------+ | Datagram to send, requires the | Send I1 and stay at | | creation of another incarnation of the | CLOSED | | HIP association | | | | | | Receive I1 | Send R1 and stay at | | | CLOSED | | | | | Receive I2, process | If successful, send R2 | | | and go to R2-SENT | | | | | | If fail, stay at CLOSED | | | | | Receive R1, process | If successful, send I2 | | | and go to I2-SENT | | | | | | If fail, stay at CLOSED | | | | | Receive CLOSE, process | If successful, send | | | CLOSE_ACK and stay at | | | CLOSED | | | | | | If fail, stay at CLOSED | | | | | Receive CLOSE_ACK, process | If successful, discard | | | state and go to | | | UNASSOCIATED | | | | | | If fail, stay at CLOSED | | | | | Receive ANYOTHER | Drop and stay at CLOSED | | | | | Timeout (UAL+2MSL) | Discard state and go to | | | UNASSOCIATED | +----------------------------------------+--------------------------+ Table 8: CLOSED - CLOSE_ACK Sent, Resending CLOSE_ACK if Necessary
System behavior in state E-FAILED, Table 9. +-------------------------+-----------------------------------------+ | Trigger | Action | +-------------------------+-----------------------------------------+ | Wait for | Go to UNASSOCIATED. Renegotiation is | | implementation-specific | possible after moving to UNASSOCIATED | | time | state. | +-------------------------+-----------------------------------------+ Table 9: E-FAILED - HIP Failed to Establish Association with Peer4.4.4. Simplified HIP State Diagram
The following diagram (Figure 2) shows the major state transitions. Transitions based on received packets implicitly assume that the packets are successfully authenticated or processed.
+--+ +----------------------------+ recv I1, send R1 | | | | | v v | +--------------+ recv I2, send R2 | +----------------| UNASSOCIATED |----------------+ | datagram | +--+ +--------------+ | | to send, | | | Alg. not supported, | | send I1 | | | send I1 | | . v | v | | . +---------+ recv I2, send R2 | | +---->| I1-SENT |--------------------------------------+ | | | +---------+ +----------------------+ | | | | | recv R2, | recv I2, send R2 | | | | | v send I2 | v v v | | +---------+ | +---------+ | | +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ | | | +---------+ | +---------+ | | | | | |recv R2 | data or| | | | |recv R1, | | | EC timeout| | | | |send I2 +--|-----------------+ | receive I2,| | | | | | +-------------+ | send R2| | | | | +------>| ESTABLISHED |<----------+ | | | | | +-------------+ | | | | | | | | receive I2, send R2 | | | | +------------+ | +-------------------------------+ | | | | +-----------+ | | | | | no packet sent/received| +---+ | | | | | for UAL min, send CLOSE| | |timeout | | | | | v v |(UAL+MSL) | | | | | +---------+ |retransmit | | +--|----------|------------------------| CLOSING |-+CLOSE | | | | +---------+ | | | | | | | | | | +----------|-------------------------+ | | +----------------+ | | | +-----------+ +------------------|--+ | | |recv CLOSE, recv CLOSE_ACK | | | +-------------+ |send CLOSE_ACK or timeout | | | recv CLOSE, | | (UAL+MSL) | | | send CLOSE_ACK v v | | | +--------+ receive I2, send R2 | | +---------------------| CLOSED |------------------------------+ | +--------+ | ^ | | | recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | +-+ +------------------------------------+ Figure 2
4.5. User Data Considerations
4.5.1. TCP and UDP Pseudo Header Computation for User Data
When computing TCP and UDP checksums on user data packets that flow through sockets bound to HITs, the IPv6 pseudo header format [RFC2460] MUST be used, even if the actual addresses in the header of the packet are IPv4 addresses. Additionally, the HITs MUST be used in place of the IPv6 addresses in the IPv6 pseudo header. Note that the pseudo header for actual HIP payloads is computed differently; see Section 5.1.1.4.5.2. Sending Data on HIP Packets
Other documents may define how to include user data in various HIP packets. However, currently the HIP header is a terminal header, and not followed by any other headers.4.5.3. Transport Formats
The actual data transmission format, used for user data after the HIP base exchange, is not defined in this document. Such transport formats and methods are described in separate specifications. All HIP implementations MUST implement, at minimum, the ESP transport format for HIP [RFC7402]. The transport format to be chosen is negotiated in the base exchange. The Responder expresses its preference regarding the transport format in the TRANSPORT_FORMAT_LIST in the R1 packet, and the Initiator selects one transport format and adds the respective HIP parameter to the I2 packet.4.5.4. Reboot, Timeout, and Restart of HIP
Simulating a loss of state is a potential DoS attack. The following process has been crafted to manage state recovery without presenting a DoS opportunity. If a host reboots or the HIP association times out, it has lost its HIP state. If the host that lost state has a datagram to send to the peer, it simply restarts the HIP base exchange. After the base exchange has completed, the Initiator can create a new payload association and start sending data. The peer does not reset its state until it receives a valid I2 packet. If a system receives a user data packet that cannot be matched to any existing HIP association, it is possible that it has lost the state and its peer has not. It MAY send an ICMP packet with the Parameter Problem type, and with the Pointer pointing to the referred
HIP-related association information. Reacting to such traffic depends on the implementation and the environment where the implementation is used. If the host that apparently has lost its state decides to restart the HIP base exchange, it sends an I1 packet to the peer. After the base exchange has been completed successfully, the Initiator can create a new HIP association, and the peer drops its old payload associations and creates a new one.4.6. Certificate Distribution
This document does not define how to use certificates or how to transfer them between hosts. These functions are expected to be defined in a future specification, as was done for HIP version 1 (see [RFC6253]). A parameter type value, meant to be used for carrying certificates, is reserved, though: CERT, Type 768; see Section 5.2.
(page 38 continued on part 3)