One document matched: draft-ietf-hip-rfc5201-bis-20.xml
<?xml version="1.0" encoding="US-ASCII" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0768 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml" >
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml" >
<!ENTITY RFC0793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml" >
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml" >
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml" >
<!ENTITY RFC2404 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2404.xml" >
<!ENTITY RFC2408 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2408.xml" >
<!ENTITY RFC2418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2418.xml" >
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml" >
<!ENTITY RFC2410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2410.xml" >
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml" >
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml" >
<!ENTITY RFC2536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2536.xml" >
<!ENTITY RFC2785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2785.xml" >
<!ENTITY RFC2898 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2898.xml" >
<!ENTITY RFC3110 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3110.xml" >
<!ENTITY RFC3447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3447.xml" >
<!ENTITY RFC3513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3513.xml" >
<!ENTITY RFC3526 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3526.xml" >
<!ENTITY RFC3602 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3602.xml" >
<!ENTITY RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml" >
<!ENTITY RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml" >
<!ENTITY RFC4282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml" >
<!ENTITY RFC5996 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml" >
<!ENTITY rfc4423-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hip-rfc4423-bis-05.xml" >
<!ENTITY RFC5903 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5903.xml" >
<!ENTITY RFC4754 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4754.xml" >
<!ENTITY RFC4868 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4868.xml" >
<!ENTITY RFC5201 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5201.xml" >
<!ENTITY RFC5201-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5201-bis.xml" >
<!ENTITY RFC5202-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5202-bis.xml" >
<!ENTITY RFC5203-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hip-rfc5203-bis-02.xml" >
<!ENTITY RFC5204-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hip-rfc5204-bis-02.xml" >
<!ENTITY RFC5205-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hip-rfc5205-bis-02.xml" >
<!ENTITY RFC5206-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hip-rfc5206-bis-06.xml" >
<!ENTITY RFC6253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6253.xml" >
<!ENTITY RFC5338 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5338.xml" >
<!ENTITY RFC5533 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5533.xml" >
<!--<!ENTITY RFC5639 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5639.xml" > brainpool ECC -->
<!ENTITY RFC5702 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5702.xml" >
<!ENTITY RFC5869 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml" >
<!ENTITY RFC6090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6090.xml" >
<!ENTITY RFC6724 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6724.xml" >
<!ENTITY RFC7045 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7045.xml" >
<!ENTITY RFC7343 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7343.xml" >
<!ENTITY FIPS197 SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.FIPS.197.2001.xml" >
<!ENTITY FIPS180-2 SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.FIPS.180-2.2002.xml" >
<!ENTITY FIPS186-3 SYSTEM "reference.FIPS.186-3.2009.xml" >
<!ENTITY NIST.800-131A.2011 SYSTEM "reference.NIST.800-131A.2011.xml" >
<!ENTITY RFC3849 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3849.xml" >
<!ENTITY RFC5737 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5737.xml" >
]>
<?rfc toc="yes" ?>
<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc docName="draft-ietf-hip-rfc5201-bis-20" category="std" obsoletes="5201" ipr="trust200902">
<front>
<title abbrev="HIPv2">
Host Identity Protocol Version 2 (HIPv2)</title>
<author initials="R." surname="Moskowitz"
fullname="Robert Moskowitz" role="editor">
<organization abbrev="Verizon">Verizon Telcom and Business
</organization>
<address>
<postal>
<street>1000 Bent Creek Blvd, Suite 200</street>
<city>Mechanicsburg</city>
<region>PA</region>
<country>USA</country>
</postal>
<email>robert.moskowitz@verizonbusiness.com</email>
</address>
</author>
<author initials="T." surname="Heer"
fullname="Tobias Heer">
<organization>Hirschmann Automation and Control</organization>
<address>
<postal>
<street>Stuttgarter Strasse 45-51</street>
<city>Neckartenzlingen</city>
<code>72654</code>
<country>Germany</country>
</postal>
<email>tobias.heer@belden.com</email>
</address>
</author>
<author initials="P." surname="Jokela"
fullname="Petri Jokela">
<organization>Ericsson Research NomadicLab</organization>
<address>
<postal>
<street />
<city>JORVAS</city>
<code>FIN-02420</code>
<country>FINLAND</country>
</postal>
<phone>+358 9 299 1</phone>
<email>petri.jokela@nomadiclab.com</email>
</address>
</author>
<author initials="T." surname="Henderson"
fullname="Thomas R. Henderson">
<organization>University of Washington</organization>
<address>
<postal>
<street>Campus Box 352500</street>
<city>Seattle</city>
<region>WA</region>
<country>USA</country>
</postal>
<email>tomhend@u.washington.edu</email>
</address>
</author>
<date month="October" year="2014" />
<area>Internet</area>
<keyword>HIP</keyword>
<abstract>
<t>
This document specifies the details of the Host Identity
Protocol (HIP). HIP allows consenting hosts to securely
establish and maintain shared IP-layer state, allowing
separation of the identifier and locator roles of IP addresses,
thereby enabling continuity of communications across IP address
changes. HIP is based on a Diffie-Hellman key
exchange, using public key identifiers from a new Host Identity
namespace for mutual peer authentication. The protocol is
designed to be resistant to denial-of-service (DoS) and
man-in-the-middle (MitM) attacks. When used together with
another suitable security protocol, such as the Encapsulated
Security Payload (ESP), it provides integrity protection and
optional encryption for upper-layer protocols, such as TCP and
UDP.
</t>
<t>
This document obsoletes RFC 5201 and addresses the concerns
raised by the IESG, particularly that of crypto agility. It
also incorporates lessons learned from the implementations of
RFC 5201.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document specifies the details of the Host Identity Protocol
(HIP). A high-level description of the protocol and the
underlying architectural thinking is available in the separate
<xref target="I-D.ietf-hip-rfc4423-bis">HIP architecture description</xref>.
Briefly, the HIP architecture proposes an alternative to the
dual use of IP addresses as "locators" (routing labels) and
"identifiers" (endpoint, or host, identifiers). In HIP, public
cryptographic keys, of a public/private key pair, are used as
Host Identifiers, to which higher layer protocols are bound
instead of an IP address. By using public keys (and their
representations) as host identifiers, dynamic changes to IP
address sets can be directly authenticated between hosts, and
if desired, strong authentication between hosts at the TCP/IP
stack level can be obtained.
</t>
<t>
This memo specifies the base HIP protocol ("base exchange")
used between hosts to establish an IP-layer communications
context, called a HIP association, prior to communications. It
also defines a packet format and procedures for updating and
terminating an
active HIP association. Other elements of the HIP architecture
are specified in other documents, such as:
<list style='symbols'>
<t>
"Using the Encapsulating Security Payload (ESP) transport
format with the Host Identity Protocol (HIP)" <xref
target="I-D.ietf-hip-rfc5202-bis" />: how to use the Encapsulating Security
Payload (ESP) for integrity protection and optional
encryption
</t>
<t>
"Host Mobility with the Host Identity
Protocol" <xref target="I-D.ietf-hip-rfc5206-bis" />: how to support
host mobility in HIP
</t>
<t>
"Host Identity Protocol (HIP) Domain Name System (DNS)
Extensions" <xref target="I-D.ietf-hip-rfc5205-bis" />: how to extend DNS to
contain Host Identity information
</t>
<t>
"Host Identity Protocol (HIP) Rendezvous Extension" <xref
target="I-D.ietf-hip-rfc5204-bis" />: using a rendezvous mechanism to
contact mobile HIP hosts
</t>
</list>
</t>
<t>
Since the HIP base exchange was first developed, there have
been a few advances in cryptography and attacks against
cryptographic systems. As a result, all cryptographic
protocols need to be agile. That is, it should be a part of
the protocol to be able to switch from one cryptographic
primitive to another. It is important to support a reasonable
set of mainstream algorithms to cater for different use cases
and allow moving away from algorithms that are later
discovered to be vulnerable. This update to the base exchange
includes this needed cryptographic agility while addressing
the downgrade attacks that such flexibility introduces. In
particular, Elliptic Curve support by Elliptic Curve DSA
(ECDSA) and Elliptic Curve Diffie-Hellman (ECDH) and
alternative hash functions have been added.
</t>
<section title="A New Namespace and Identifiers">
<t>
The Host Identity Protocol introduces a new namespace, the
Host Identity namespace. Some ramifications of this new
namespace are explained in the HIP architecture description
<xref target="I-D.ietf-hip-rfc4423-bis" />.
</t>
<t>
There are two main representations of the Host Identity, the
full Host Identity (HI) and the Host Identity Tag (HIT).
The HI is a public key and directly represents the Identity
of a host. Since there are different public key algorithms
that can be used with different key lengths, the HI, as
such, is unsuitable for use as a packet identifier, or as an
index into the various state-related implementation
structures needed to support HIP. Consequently, a hash of
the HI, the Host Identity Tag (HIT), is used as the operational
representation. The HIT is 128 bits long and is used in the
HIP headers and to index the corresponding state in the end
hosts. The HIT has an important security property in that
it is self-certifying (see <xref target="HI" />).
</t>
</section>
<section title="The HIP Base Exchange (BEX)">
<t>
The HIP base exchange is a two-party cryptographic protocol
used to establish communications context between hosts. The
base exchange is a SIGMA-compliant <xref target="KRA03" />
four-packet exchange. The first party is called the
Initiator and the second party the Responder. The protocol
exchanges Diffie-Hellman <xref target="DIF76" /> keys in the
2nd and 3rd packets, and authenticates the parties in the
3rd and 4th packets. The four-packet design helps to make
HIP DoS resilient. It allows the Responder to stay
stateless until the IP address and the cryptographic
puzzle is verified. The Responder starts the puzzle exchange
in the 2nd packet, with the Initiator completing it in the
3rd packet before the Responder stores any state from the
exchange.
</t>
<t>
The exchange can use the Diffie-Hellman output to encrypt the
Host Identity of the Initiator in the 3rd packet (although
Aura, et al., <xref target="AUR03" /> notes that such
operation may interfere with packet-inspecting middleboxes),
or the Host Identity may instead be sent unencrypted. The
Responder's Host Identity is not protected. It should be
noted, however, that both the Initiator's and the Responder's
HITs are transported as such (in cleartext) in the packets,
allowing an eavesdropper with a priori knowledge about the
parties to identify them by their HITs. Hence, encrypting
the HI of any party does not provide privacy against such
attacker.
</t>
<t>
Data packets start to flow after the 4th packet. The 3rd and
4th HIP packets may carry a data payload in the future.
However, the details of this may be defined later.
</t>
<t>
An existing HIP association can be updated using the update
mechanism defined in this document, and when the association
is no longer needed, it can be closed using the defined
closing mechanism.
</t>
<t>
Finally, HIP is designed as an end-to-end authentication and
key establishment protocol, to be used with Encapsulated
Security Payload (ESP) <xref target="I-D.ietf-hip-rfc5202-bis" /> and other
end-to-end security protocols. The base protocol does not
cover all the fine-grained policy control found in Internet
Key Exchange (IKE) <xref target="RFC5996" /> that allows IKE
to support complex gateway policies. Thus, HIP is not a
complete replacement for IKE.
</t>
</section>
<section title="Memo Structure">
<t>
The rest of this memo is structured as follows. <xref
target="terms" /> defines the central keywords, notation, and
terms used throughout the rest of the document. <xref
target="HI" /> defines the structure of the Host Identity and
its various representations. <xref target="proto_overview"
/> gives an overview of the HIP base exchange protocol.
Sections <xref target="sec-param-tlv" format="counter" /> and
<xref target="packet_processing" format="counter" /> define
the detailed packet formats and rules for packet processing.
Finally, Sections <xref target="sec-policy" format="counter"/>,
<xref target="sec-considerations" format="counter" />,
and <xref target="iana" format="counter" /> discuss policy,
security, and IANA considerations, respectively.
</t>
</section>
</section>
<section anchor="terms" title="Terms and Definitions">
<section title="Requirements Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section anchor="notation" title="Notation">
<t>
<list style="hanging">
<t hangText="[x] ">
indicates that x is optional.
</t>
<t hangText="{x} ">
indicates that x is encrypted.
</t>
<t hangText="X(y) ">
indicates that y is a parameter of X.
</t>
<t hangText="<x>i ">
indicates that x exists i times.
</t>
<t hangText="--> ">
signifies "Initiator to Responder" communication
(requests).
</t>
<t hangText="<-- ">
signifies "Responder to Initiator" communication
(replies).
</t>
<t hangText="| ">
signifies concatenation of information (e.g., X | Y is the
concatenation of X with Y).
</t>
<t hangText="Ltrunc (H(x), K) ">
denotes the lowest order #K bits of the result
of the hash function H on the input x.
</t>
</list>
</t>
</section>
<section title="Definitions">
<t>
<list style="hanging">
<t hangText="HIP base exchange (BEX):">
the handshake for establishing a new HIP association.
</t>
<t hangText="Host Identity (HI):">
The public key of the signature algorithm that
represents the identity of the host. In HIP, a host
proves its identity by creating a signature with the
private key belonging to its HI (c.f. <xref target="HI"
/>).
</t>
<t hangText="Host Identity Tag (HIT):">
A shorthand for the HI in IPv6 format. It is generated
by hashing the HI (c.f. <xref
target="HIT" />).
</t>
<t hangText="HIT Suite:">
A HIT Suite groups all cryptographic algorithms that are
required to generate and use an HI and its HIT. In
particular, these algorithms are: 1) the public key
signature algorithm and 2) the hash function, 3) the
truncation (c.f. <xref target="hit-suites" />).
</t>
<t hangText="HIP association: ">
The shared state between two peers after completion of
the BEX.
</t>
<t hangText="HIP packet: ">
A control packet carrying a HIP packet header relating to
the establishment, maintenance, or termination of the HIP
association.
</t>
<t hangText="Initiator: ">
The host that initiates the BEX. This role is typically
forgotten once the BEX is completed.
</t>
<t hangText="Responder: ">
The host that responds to the Initiator in the BEX. This
role is typically forgotten once the BEX is completed.
</t>
<t hangText="Responder's HIT Hash Algorithm (RHASH): ">
The Hash algorithm used for various hash calculations in
this document. The algorithm is the same as is used to
generate the Responder's HIT. The RHASH is the hash
function defined by the HIT Suite of the Responder's HIT
(c.f. <xref target="hit_suite_list" />).
</t>
<t hangText="Length of the Responder's HIT Hash Algorithm (RHASH_len): ">
The natural output length of RHASH in bits.
</t>
<t hangText="Signed data: ">
Data that is signed is protected by a digital signature
that was created by the sender of the data by using the
private key of its HI.
</t>
<t hangText="KDF: ">
The Key Derivation Function (KDF) is used for deriving
the symmetric keys from the Diffie-Hellman key exchange.
</t>
<t hangText="KEYMAT: ">
The keying material derived from the Diffie-Hellman key
exchange by using the KDF. Symmetric keys for
encryption and integrity protection of HIP packets and
encrypted user data packets are drawn from this keying material.
</t>
</list>
</t>
</section>
</section>
<section anchor="HI" title="Host Identity (HI) and its Structure">
<t>
In this section, the properties of the Host Identity and Host
Identity Tag are discussed, and the exact format for them is
defined. In HIP, the public key of an asymmetric key pair is
used as the Host Identity (HI). Correspondingly, the host
itself is defined as the entity that holds the private key
of the key pair. See the HIP architecture specification
<xref target="I-D.ietf-hip-rfc4423-bis" /> for more details on
the difference between an identity and the corresponding
identifier.
</t>
<t>
HIP implementations MUST support the Rivest Shamir Adelman
<xref target="RSA" /> public key algorithm and the
Elliptic Curve Digital
Signature Algorithm (ECDSA) for generating the HI as defined
in <xref target="host-id"/>. Additional algorithms MAY be
supported.
</t>
<t>
A hashed encoding of the HI, the Host Identity Tag (HIT),
is used in protocols to represent the Host Identity. The
HIT is 128 bits long and has the following three key properties:
i) it is the same length as an IPv6 address and can be used
in fixed address-sized fields in APIs and protocols, ii) it is
self-certifying (i.e., given a HIT, it is computationally
hard to find a Host Identity key that matches the HIT), and
iii) the probability of a HIT collision between two hosts is
very low, hence, it is infeasible for an attacker to find a
collision with a HIT that is in use. For details on the
security properties of the HIT see <xref target="I-D.ietf-hip-rfc4423-bis"
/>.
<!--TH: Make sure that the HIT security is discussed
appropriately in RFC4423-bis. -->
</t>
<t>
The structure of the HIT is defined in <xref
target="RFC7343" />. The HIT is an Overlay
Routable Cryptographic Hash Identifier (ORCHID) and consists
of three parts: first, an IANA assigned prefix to distinguish
it from other IPv6 addresses. Second, a four-bit encoding of
the algorithms that were used for generating the HI and the
hashed representation of HI. Third, a 96-bit hashed
representation of the Host Identity. The encoding of the
ORCHID generation algorithm and the exact algorithm for
generating the hashed representation is specified in <xref
target="hit-suites" /> and <xref target="RFC7343" />.
</t>
<t>
Carrying HIs and HITs in the header of user data packets would
increase the overhead of packets. Thus, it is not expected
that they are carried in every packet, but other methods are
used to map the data packets to the corresponding HIs. In some
cases, this makes it possible to use HIP without any additional
headers in the user data packets. For example, if ESP is used
to protect data traffic, the Security Parameter Index (SPI)
carried in the ESP header can be used to map the encrypted data
packet to the correct HIP association.
</t>
<section anchor="HIT" title="Host Identity Tag (HIT)">
<t>
The Host Identity Tag is a 128-bit value -- a hashed
encoding of the Host Identifier. There are two advantages
of using a hashed encoding over the actual variable-sized
Host Identity public key in protocols. First, the fixed
length of the HIT keeps packet sizes manageable and eases
protocol coding. Second, it presents a consistent format for
the protocol, independent of the underlying identity
technology in use.
</t>
<t>
<xref target="RFC7343">RFC 7343</xref> specifies
128-bit hash-based identifiers, called Overlay Routable
Cryptographic Hash Identifiers, ORCHIDs. Their prefix,
allocated from the IPv6 address block, is defined in <xref
target="RFC7343" />. The Host Identity Tag is one type of
an ORCHID.
</t>
<t>
This document extends the original, experimental HIP
specification <xref target="RFC5201" /> with measures to
support crypto agility. One of these measures is to allow
different hash functions for creating a HIT. HIT Suites
group the sets of algorithms that are required to generate
and use a particular HIT. The Suites are encoded in HIT
Suite IDs. These HIT Suite IDs are transmitted in the ORCHID
Generation Algorithm (OGA) field in the ORCHID. With the HIT
Suite ID in the OGA field, a host can tell from another
host's HIT, whether it supports the necessary hash and
signature algorithms to establish a HIP association with
that host.
</t>
</section>
<section title="Generating a HIT from an HI" anchor="gener_hit">
<t>
The HIT MUST be generated according to the ORCHID generation
method described in <xref target="RFC7343" /> using a
context ID value of 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA
(this tag value has been generated randomly by the editor of
this specification), and an input that encodes the Host
Identity field (see <xref target="host-id" />) present in a
HIP payload packet. The set of hash function, signature
algorithm, and the algorithm used for generating the HIT from
the HI depends on the HIT Suite (see <xref
target="hit_suite_list" />) and is indicated by the four bits of
the ORCHID Generation Algorithm (OGA) field in the ORCHID.
Currently, truncated SHA-1, truncated SHA-384, and truncated SHA-256 <xref
target="FIPS.180-2.2002"/> are defined as hashes
for generating a HIT.
</t>
<t>
For identities that are either RSA, Digital Signature
Algorithm (DSA) <xref target="FIPS186-3" />, or
Elliptic Curve DSA (ECDSA) public keys,
the ORCHID input consists of the public key encoding as
specified for the Host Identity field of the HOST_ID
parameter (see <xref target="host-id"/>). This
document defines four algorithm profiles: RSA, DSA, ECDSA,
and ECDSA_LOW. The ECDSA_LOW profile is meant for devices
with low computational capabilities. Hence, one of the
following applies:
<list style="empty">
<t>
The RSA public key is encoded as defined in <xref
target="RFC3110" /> Section 2, taking the exponent length
(e_len), exponent (e), and modulus (n) fields
concatenated. The length (n_len) of the modulus (n) can
be determined from the total HI Length and the preceding
HI fields including the exponent (e). Thus, the data
that serves as input for the HIT generation has the same
length as the HI. The fields MUST be encoded in network
byte order, as defined in <xref target="RFC3110" />.
</t>
<t>
The DSA public key is encoded as defined in <xref
target="RFC2536" /> Section 2, taking the fields T, Q, P,
G, and Y, concatenated as input. Thus, the data to be hashed is 1
+ 20 + 3 * 64 + 3 * 8 * T octets long, where T is the
size parameter as defined in <xref target="RFC2536" />.
The size parameter T, affecting the field lengths, MUST
be selected as the minimum value that is long enough to
accommodate P, G, and Y. The fields MUST be encoded
in network byte order, as defined in <xref
target="RFC2536" />.
</t>
<t>
The ECDSA public keys are encoded as defined in <xref
target="RFC6090" /> Section 4.2 and 6.
<!--TH: check ECC text for completeness. -->
</t>
</list>
</t>
<t>
In <xref target="app_generhit" />, the public key encoding
process is illustrated using pseudo-code.
</t>
</section>
</section>
<section anchor="proto_overview" title="Protocol Overview">
<t>
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 <xref
target="sec-param-tlv" format="counter" /> and <xref
target="packet_processing" format="counter" /> describe in more
detail the packet formats and packet processing steps,
respectively, and are normative in case of any conflicts with
this section.
</t>
<t>
The protocol number 139 has been assigned by IANA to the Host
Identity Protocol.
</t>
<t>
The <xref target="ssec-payload">HIP payload</xref> 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 <xref target="I-D.ietf-hip-rfc5202-bis" />.
</t>
<section anchor="hip-base-exch" title="Creating a HIP Association">
<t>
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.
</t>
<t>
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 <xref target="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.
</t>
<t>
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
by 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.
</t>
<t>
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 level of trust with the
Initiator, 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.
</t>
<t>
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.
</t>
<t>
The R2 packet acknowledges the receipt of the I2 packet and
completes the base exchange. The packet is signed by the
Responder.
</t>
<t>
The base exchange is illustrated below in <xref
target="fig:bex-simple" />. 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.
</t>
<figure anchor="fig:bex-simple">
<artwork>
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
</artwork>
</figure>
<section anchor="hip-cookie" title="HIP Puzzle Mechanism">
<t>
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.
</t>
<t>
The puzzle allows a Responder implementation to completely
delay association-specific state creation until a valid I2
packet is received. An I2 packet without valid puzzle
solution can be rejected immediately once the Responder
has checked the solution by computing only one hash
function before state is created and 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.
</t>
<t>
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 <xref target="resp-cookie" /> for
one possible implementation. Responder implementations
SHOULD include sufficient randomness in the puzzle values
so that algorithmic complexity attacks become impossible
<xref target="CRO03" />.
</t>
<t>
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.
</t>
</section>
<section title="Puzzle Exchange" anchor="puzzle_exchange">
<t>
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.
</t>
<t>
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 <xref target="sec-puzzle" />). 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.
</t>
<t>
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 <xref
target="resp-cookie" /> for an example on how to implement
this.
</t>
<t>
Using the Opaque data field in the PUZZLE (see <xref
target="sec-puzzle" />), in an ECHO_REQUEST_SIGNED (see <xref
target="sec-echo-request-signed" />) or in an
ECHO_REQUEST_UNSIGNED parameter (see <xref
target="sec-echo-request-unsigned" />), 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.
</t>
<t>
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 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.
</t>
<t>
The puzzle value #I and the solution #J are inputs for
deriving the keying material from the Diffie-Hellman key
exchange (see <xref target="keymat" />). Therefore, a Responder
SHOULD NOT use the same puzzle #I with the same DH keys for
the same Initiator twice to ensure that the derived keying
material differs. 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 <xref
target="sec-puzzle" />), in an ECHO_REQUEST_SIGNED (see <xref
target="sec-echo-request-signed" />) or in an
ECHO_REQUEST_UNSIGNED parameter (see <xref
target="sec-echo-request-unsigned" />) without the need to
establish state.
</t>
<t>
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.
</t>
<t>
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 not to
use memory-bound functions.
<!--Removed this after there were no good arguments for
keeping it on the mailing list:
At the time of the decision,
the idea of memory-bound functions was relatively new and
their IPR status were unknown. Once there is more
experience about memory-bound functions and once their IPR
status is better known, it may be reasonable to reconsider
this decision.-->
<!--DONE TH: maybe the time for reconsideration has come -->
<!--DONE RGM Bring it up on the list, and we can file an issue. -->
<!--TH: There were no concrete proposals nor any strong
arguments for other puzzles on the list. I will keep
this comment open for future considerations (e.g., in
the document crafting session in Maastricht,)-->
</t>
</section>
<section anchor="auth_dh"
title="Authenticated Diffie-Hellman Protocol with DH Group
Negotiation">
<t>
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 from replay attacks.
</t>
<t>
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).
<!--TH: I removed the following optimization for now:
Note that the R1 packet may be precomputed. Hence,
only the hashes of the DH values supported by the Responder
are covered by the PK signature in the R1 packet while the
actual DH public value is not covered by the PK signature.
-->
<!--TH: Now we have to ask ourselves if we really want to
have full flexibility in the DH key exchange so that
the Responder can support a large number of DH group
IDs. In this case we need something like signed hashes
to have more flexibility in the R1. Otherwise we could
leave things as they are and accept that the Responder
may have to precalculate several R1 packets with
different public DH values. -->
</t>
<t>
If none of the DH Group IDs in the I1 packet is 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.
</t>
<t>
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 of 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.
</t>
<t>
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 <xref target="keymat"
/>), 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 <xref target="hippars" />) in
the packet without exceptions as in the R1.
</t>
<t>
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.
</t>
<t>
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 an HMAC as well as uses the private key of its
Host Identity to sign the packet contents.
</t>
</section>
<section anchor="hip-replay" title="HIP Replay Protection">
<t>
The HIP protocol 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 <xref
target="hip-cookie" /> 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.
</t>
<t>
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.
</t>
<t>
A host may receive more than one R1, either due to sending
multiple I1 packets (see <xref target="multi-i1" />) 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.
</t>
<t>
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.
</t>
</section>
<section title="Refusing a HIP base exchange">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Aborting a HIP base exchange">
<t>
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.
</t>
<t>
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.
</t>
<t>
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 Suite 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 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.
</t>
</section>
<section title="HIP Downgrade Protection" anchor="downgrade">
<t>
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 to 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 un-detected by the victims and the victims
falsely assume a secure communication channel.
</t>
<t>
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.
</t>
<t>
In contrast to the first version of HIP <xref
target="RFC5201"/>,the version 2 of HIP 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 for 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 to 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.
</t>
</section>
<section anchor="op_mode" title="HIP Opportunistic Mode">
<t>
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.
</t>
<t>
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 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.
</t>
<t> 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.
</t>
<t>
There are both security and API issues involved with the
opportunistic mode. These issues are described in the
reminder of this section.
</t>
<t>
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:
</t>
<t>
<list style="symbols">
<t>
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.
</t>
<t>
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. <vspace blankLines='1' /> 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.
</t>
</list>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
An attacker outside the path will be unable to do so, given
that it cannot respond to the messages in the base
exchange.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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, and 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.
</t>
</section>
</section>
<section title="Updating a HIP Association">
<t>
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.
</t>
<t>
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:
<list>
<t>
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.
</t>
<t>
UPDATE is protected by both HIP_MAC and HIP_SIGNATURE
parameters, since processing UPDATE signatures alone is a
potential DoS attack against intermediate systems.
</t>
<t>
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).
</t>
</list>
</t>
<t>
The UPDATE packet is defined in <xref target="UPDATE" />.
</t>
</section>
<section anchor="error_proc" title="Error Processing">
<t>
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 <xref target="ICMP" /> for more
details.
</t>
<t>
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.
<list>
<t>No prior state between the two systems.
<list>
<t>
The system with data to send is the Initiator. The
process follows the standard four-packet base
exchange, establishing the HIP association.
</t>
</list>
</t>
<t>
The system with data to send has no state with the
receiver, but the receiver has a residual HIP
association.
<list>
<t>
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.
</t>
</list>
</t>
<t>
The system with data to send has a HIP association, but
the receiver does not.
<list>
<t>
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.
</t>
<t>
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 <xref target="ICMP" />).
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="state-machine" title="HIP State Machine">
<t>
The HIP protocol 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.
</t>
<t>
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.
</t>
<t>
This document extends the state machine as defined in <xref
target="RFC5201" /> and introduces a restart option to allow
for the negotiation of cryptographic algorithms. The
extension to the previous state machine in <xref target="RFC5201" />
is a transition from state I1-SENT to I1-SENT - 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.
</t>
<t>
Implementors must understand that the state machine, as
described here, is informational. Specific implementations
are free to implement the actual processing logic differently.
<xref target="packet_processing" /> 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).
</t>
<section title="State Machine Terminology">
<t>
<list style="hanging">
<t hangText="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.
</t>
<t hangText="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 <xref target="RFC0793" /> because it is a
prevailing assumption for packet lifetimes.
</t>
<t hangText="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.
</t>
<t hangText="Receive ANYOTHER: ">
Any received packet for which no state transitions or
processing rules are defined for a given state.
</t>
</list>
</t>
</section>
<section anchor="states" title="HIP States">
<?rfc compact="no"?>
<texttable align="left" title="HIP States" anchor="table_states">
<ttcol width="30%" align="left">State</ttcol>
<ttcol align="left">Explanation</ttcol>
<c>UNASSOCIATED</c><c>State machine start</c>
<c>I1-SENT</c><c> Initiating base exchange </c>
<c>I2-SENT</c><c> Waiting to complete base exchange </c>
<c>R2-SENT</c><c> Waiting to complete base exchange </c>
<c>ESTABLISHED</c><c> HIP association established </c>
<c>CLOSING</c><c> HIP association closing, no data can be sent</c>
<c>CLOSED</c><c> HIP association closed, no data can be sent</c>
<c>E-FAILED</c><c> HIP base exchange failed </c>
</texttable>
<?rfc compact="yes"?>
</section>
<section title="HIP State Processes">
<?rfc compact="no"?>
<texttable align="left" title="UNASSOCIATED - Start state" anchor="table_unassociated">
<preamble>System behavior in state UNASSOCIATED, <xref
target="table_unassociated" />.</preamble>
<ttcol width="30%" align="left">Trigger</ttcol>
<ttcol align="left">Action</ttcol>
<c>User data to send, requiring a new HIP association</c>
<c>Send I1 and go to I1-SENT</c>
<c>Receive I1</c>
<c>Send R1 and stay at UNASSOCIATED</c>
<c>Receive I2, process</c>
<c>If successful, send R2 and go to R2-SENT</c>
<c></c>
<c>If fail, stay at UNASSOCIATED</c>
<c>Receive user data for an unknown HIP association</c>
<c>Optionally send ICMP as defined in <xref target="ICMP" />
and stay at UNASSOCIATED</c>
<c>Receive CLOSE</c>
<c>Optionally send ICMP Parameter Problem and stay at
UNASSOCIATED</c>
<c>Receive ANYOTHER</c>
<c>Drop and stay at UNASSOCIATED</c>
</texttable>
<texttable align="left" title="I1-SENT - Initiating the HIP base exchange" anchor="table_i1sent">
<preamble>System behavior in state I1-SENT, <xref
target="table_i1sent" />.</preamble>
<ttcol width="30%" align="left">Trigger</ttcol>
<ttcol align="left">Action</ttcol>
<c>Receive I1 from Responder</c>
<c>If the local HIT is smaller than the peer HIT, drop I1 and
stay at I1-SENT (see <xref target="keymat" /> for HIT
comparison)</c>
<c></c>
<c>If the local HIT is greater than the peer HIT, send R1
and stay at I1-SENT</c>
<c>Receive I2, process</c>
<c>If successful, send R2 and go to R2-SENT</c>
<c></c>
<c>If fail, stay at I1-SENT</c>
<c>Receive R1, process</c>
<c>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</c>
<c></c>
<c>If successful, send I2 and go to I2-SENT</c>
<c></c>
<c>If fail, stay at I1-SENT</c>
<c>Receive ANYOTHER</c>
<c>Drop and stay at I1-SENT</c>
<c>Timeout</c>
<c>Increment trial counter</c>
<c></c>
<c>If counter is less than I1_RETRIES_MAX, send I1 and stay at I1-SENT</c>
<c></c>
<c>If counter is greater than I1_RETRIES_MAX, go to E-FAILED</c>
</texttable>
<texttable align="left" title="I2-SENT - Waiting to finish the HIP base exchange" anchor="table_i2sent">
<preamble>System behavior in state I2-SENT, <xref
target="table_i2sent" />.</preamble>
<ttcol width="30%" align="left">Trigger</ttcol>
<ttcol align="left">Action</ttcol>
<c>Receive I1</c>
<c>Send R1 and stay at I2-SENT</c>
<c>Receive R1, process</c>
<c>If successful, send I2 and stay at I2-SENT</c>
<c></c>
<c>If fail, stay at I2-SENT</c>
<c>Receive I2, process</c>
<c>If successful and local HIT is smaller than the peer HIT,
drop I2 and stay at I2-SENT</c>
<c></c>
<c>If successful and local HIT is greater than the peer HIT,
send R2 and go to R2-SENT</c>
<c></c>
<c>If fail, stay at I2-SENT</c>
<c>Receive R2, process</c>
<c>If successful, go to ESTABLISHED</c>
<c></c>
<c>If fail, stay at I2-SENT</c>
<c>Receive CLOSE, process</c>
<c>If successful, send CLOSE_ACK and go to CLOSED</c>
<c></c>
<c>If fail, stay at I2-SENT</c>
<c>Receive ANYOTHER</c>
<c>Drop and stay at I2-SENT</c>
<c>Timeout</c>
<c>Increment trial counter</c>
<c></c>
<c>If counter is less than I2_RETRIES_MAX, send I2 and
stay at I2-SENT</c>
<c></c>
<c>If counter is greater than I2_RETRIES_MAX, go to E-FAILED</c>
</texttable>
<texttable align="left" title="R2-SENT - Waiting to finish HIP" anchor="table_r2sent">
<preamble>System behavior in state R2-SENT, <xref
target="table_r2sent" />.</preamble>
<ttcol width="30%" align="left">Trigger</ttcol>
<ttcol align="left">Action</ttcol>
<c>Receive I1</c>
<c>Send R1 and stay at R2-SENT</c>
<c>Receive I2, process</c>
<c>If successful, send R2 and stay at R2-SENT</c>
<c></c>
<c>If fail, stay at R2-SENT</c>
<c>Receive R1</c>
<c>Drop and stay at R2-SENT</c>
<c>Receive R2</c>
<c>Drop and stay at R2-SENT</c>
<c>Receive data or UPDATE</c>
<c>Move to ESTABLISHED</c>
<c>Exchange Complete Timeout</c>
<c>Move to ESTABLISHED</c>
<c>Receive CLOSE, process</c>
<c>If successful, send CLOSE_ACK and go to CLOSED</c>
<c></c>
<c>If fail, stay at ESTABLISHED</c>
<c>Receive CLOSE_ACK</c>
<c>Drop and stay at R2-SENT</c>
<c>Receive NOTIFY</c>
<c>Process and stay at R2-SENT</c>
</texttable>
<texttable align="left"
title="ESTABLISHED - HIP association established"
anchor="table_established">
<preamble>System behavior in state ESTABLISHED, <xref
target="table_established" />.</preamble>
<ttcol width="30%" align="left">Trigger</ttcol>
<ttcol align="left">Action</ttcol>
<c>Receive I1</c>
<c>Send R1 and stay at ESTABLISHED</c>
<c>Receive I2</c>
<c>Process with puzzle and possible Opaque
data verification</c>
<c></c>
<c>If successful, send R2, drop old HIP association,
establish a new HIP association and go to R2-SENT</c>
<c></c>
<c>If fail, stay at ESTABLISHED</c>
<c>Receive R1</c>
<c>Drop and stay at ESTABLISHED</c>
<c>Receive R2</c>
<c>Drop and stay at ESTABLISHED</c>
<c>Receive user data for HIP association</c>
<c>Process and stay at ESTABLISHED</c>
<c>No packet sent/received during UAL minutes</c>
<c>Send CLOSE and go to CLOSING</c>
<c>Receive UPDATE</c>
<c>Process and stay at ESTABLISHED</c>
<c>Receive CLOSE, process</c>
<c>If successful, send CLOSE_ACK and go to CLOSED</c>
<c></c>
<c>If fail, stay at ESTABLISHED</c>
<c>Receive CLOSE_ACK</c>
<c>Drop and stay at ESTABLISHED</c>
<c>Receive NOTIFY</c>
<c>Process and stay at ESTABLISHED</c>
</texttable>
<texttable align="left" title="CLOSING - HIP association has not been used for UAL minutes" anchor="table_closing">
<preamble>System behavior in state CLOSING, <xref
target="table_closing" />.</preamble>
<ttcol width="30%" align="left">Trigger</ttcol>
<ttcol align="left">Action</ttcol>
<c>User data to send, requires the creation of another incarnation
of the HIP association</c>
<c>Send I1 and go to I1-SENT</c>
<c>Receive I1</c>
<c>Send R1 and stay at CLOSING</c>
<c>Receive I2, process</c>
<c>If successful, send R2 and go to R2-SENT</c>
<c></c>
<c>If fail, stay at CLOSING</c>
<c>Receive R1, process</c>
<c>If successful, send I2 and go to I2-SENT</c>
<c></c>
<c>If fail, stay at CLOSING</c>
<c>Receive CLOSE, process</c>
<c>If successful, send CLOSE_ACK, discard state and
go to CLOSED</c>
<c></c>
<c>If fail, stay at CLOSING</c>
<c>Receive CLOSE_ACK, process</c>
<c>If successful, discard state and go to UNASSOCIATED</c>
<c></c>
<c>If fail, stay at CLOSING</c>
<c>Receive ANYOTHER</c>
<c>Drop and stay at CLOSING</c>
<c>Timeout</c>
<c>
Increment timeout sum and reset timer. If timeout sum is
less than UAL+MSL minutes, retransmit CLOSE and stay at
CLOSING
</c>
<c></c>
<c>If timeout sum is greater than UAL+MSL minutes, go
to UNASSOCIATED</c>
</texttable>
<texttable align="left" title="CLOSED - CLOSE_ACK sent, resending CLOSE_ACK if necessary"
anchor="table_closed">
<preamble>System behavior in state CLOSED, <xref
target="table_closed" />.</preamble>
<ttcol width="30%" align="left">Trigger</ttcol>
<ttcol align="left">Action</ttcol>
<c>Datagram to send, requires the creation of another incarnation
of the HIP association</c>
<c>Send I1, and stay at CLOSED</c>
<c>Receive I1</c>
<c>Send R1 and stay at CLOSED</c>
<c>Receive I2, process</c>
<c>If successful, send R2 and go to R2-SENT</c>
<c></c>
<c>If fail, stay at CLOSED</c>
<c>Receive R1, process</c>
<c>If successful, send I2 and go to I2-SENT</c>
<c></c>
<c>If fail, stay at CLOSED</c>
<c>Receive CLOSE, process</c>
<c>If successful, send CLOSE_ACK, stay at CLOSED</c>
<c></c>
<c>If fail, stay at CLOSED</c>
<c>Receive CLOSE_ACK, process</c>
<c>If successful, discard state and go to UNASSOCIATED</c>
<c></c>
<c>If fail, stay at CLOSED</c>
<c>Receive ANYOTHER</c>
<c>Drop and stay at CLOSED</c>
<c>Timeout (UAL+2MSL)</c>
<c>Discard state, and go to UNASSOCIATED</c>
</texttable>
<?rfc needLines="10"?>
<texttable align="left" title="E-FAILED - HIP failed to establish association with peer"
anchor="table_efailed">
<preamble>System behavior in state E-FAILED, <xref
target="table_efailed" />.</preamble>
<ttcol width="30%" align="left">Trigger</ttcol>
<ttcol align="left">Action</ttcol>
<c>Wait for implementation-specific time</c>
<c>Go to UNASSOCIATED. Re-negotiation is possible after moving to
UNASSOCIATED state.</c>
</texttable>
<?rfc compact="yes"?>
</section>
<section anchor="hipstates" title="Simplified HIP State Diagram">
<t>
The following diagram (<xref target="fig:states" />) shows the major state transitions.
Transitions based on received packets implicitly assume that
the packets are successfully authenticated or processed.
</t>
<figure anchor="fig:states">
<artwork>
+--+ +----------------------------+
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) |
+-+ +------------------------------------+
</artwork>
</figure>
</section>
</section>
<section title="User Data Considerations">
<section anchor="tcp-udp-pseudo-header" title="TCP and UDP Pseudo-Header Computation for User Data">
<t>
When computing TCP and UDP checksums on user data packets
that flow through sockets bound to HITs, the IPv6
pseudo-header format <xref target="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 <xref
target="ssec-crc" />.
</t>
</section>
<section title="Sending Data on HIP Packets">
<t>
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.
</t>
</section>
<section title="Transport Formats">
<t>
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
<xref target="I-D.ietf-hip-rfc5202-bis" />.
The transport format to be chosen is negotiated in the
base exchange. The Responder expresses its preference of
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.
</t>
</section>
<section anchor="reboot" title="Reboot, Timeout, and Restart of HIP">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Certificate Distribution">
<t>
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 for HIP
Version 1 <xref target="RFC6253" />. A parameter
type value, meant to be used for carrying certificates, is
reserved, though: CERT, Type 768; see <xref target="hippars"
/>.
</t>
</section>
</section>
<section anchor="sec-param-tlv" title="Packet Formats">
<section anchor="ssec-payload" title="Payload Format">
<t>
All HIP packets start with a fixed header.
</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Length |0| Packet Type |Version| RES.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Controls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ HIP Parameters /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The HIP header is logically an IPv6 extension header.
However, this document does not describe processing for Next
Header values other than decimal 59, IPPROTO_NONE, the IPv6
'no next header' value. Future documents MAY define
behavior for also other values. However, current
implementations MUST ignore trailing data if an
unimplemented Next Header value is received.
</t>
<t>
The Header Length field contains the combined length of the
HIP Header and HIP parameters in 8-byte units, excluding the
first 8 bytes. Since all HIP headers MUST contain the
sender's and receiver's HIT fields, the minimum value for
this field is 4, and conversely, the maximum length of the
HIP Parameters field is (255*8)-32 = 2008 bytes (see
<xref target="hipfrag" /> regarding HIP fragmentation).
Note: this
sets an additional limit for sizes of parameters included in
the Parameters field, independent of the individual
parameter maximum lengths.
</t>
<t>
The Packet Type indicates the HIP packet type. The
individual packet types are defined in the relevant sections.
If a HIP host receives a HIP packet that contains an
unrecognized packet type, it MUST drop the packet.
</t>
<t>
The HIP Version field is four bits. The version defined in
this document is 2. The version number is expected to be
incremented only if there are incompatible changes to the
protocol. Most extensions can be handled by defining new
packet types, new parameter types, or new Controls (see
<xref target="hip_controls" />) .
</t>
<t>
The following three bits are reserved for future use. They
MUST be zero when sent, and they MUST be ignored when
handling a received packet.
</t>
<t>
The two fixed bits in the header are reserved for SHIM6
compatibility <xref target="RFC5533" />, Section 5.3. For
implementations adhering (only) to this specification, they
MUST be set as shown when sending and MUST be ignored when
receiving. This is to ensure optimal forward compatibility.
Note that for implementations that implement other
compatible specifications in addition to this specification,
the corresponding rules may well be different. For example,
an implementation that implements both this specification
and the SHIM6 protocol may need to check these bits in order
to determine how to handle the packet.
</t>
<t>The HIT fields are always 128 bits (16 bytes) long.</t>
<section anchor="ssec-crc" title="Checksum">
<t>
Since the checksum covers the source and destination
addresses in the IP header, it MUST be recomputed on
HIP-aware NAT devices.
</t>
<t>
If IPv6 is used to carry the HIP packet, the pseudo-header
<xref target="RFC2460" /> contains the source and
destination IPv6 addresses, HIP packet length in the
pseudo-header length field, a zero field, and the HIP
protocol number (see <xref target="ssec-payload" />) in
the Next Header field. The length field is in bytes and
can be calculated from the HIP header length field:
</t>
<t>
(HIP Header Length + 1) * 8.
</t>
<t>
In case of using IPv4, the IPv4 UDP pseudo-header format
<xref target="RFC0768" /> is used. In the pseudo-header,
the source and destination addresses are those used in the
IP header, the zero field is obviously zero, the protocol
is the HIP protocol number (see <xref
target="proto_overview" />), and the length is calculated
as in the IPv6 case.
</t>
</section>
<section title="HIP Controls" anchor="hip_controls">
<t>
The HIP Controls field conveys information about the
structure of the packet and capabilities of the host.
</t>
<t>
The following fields have been defined:
<figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="A - Anonymous: ">
If this is set, the sender's HI in this packet is
anonymous, i.e., one not listed in a directory.
Anonymous HIs SHOULD NOT be stored. This control is
set in packets using anonymous sender HIs. The peer
receiving an anonymous HI in an R1 or I2 may choose
to refuse it.
</t>
</list>
The rest of the fields are reserved for future use and MUST
be set to zero in sent packets and MUST be ignored in received
packets.
</t>
</section>
<section anchor="hipfrag" title="HIP Fragmentation Support">
<t>
A HIP implementation MUST support IP
fragmentation/reassembly. Fragment reassembly MUST be
implemented in both IPv4 and IPv6, but fragment generation
is REQUIRED to be implemented in IPv4 (IPv4 stacks and
networks will usually do this by default) and RECOMMENDED
to be implemented in IPv6. In IPv6 networks, the minimum
MTU is larger, 1280 bytes, than in IPv4 networks. The
larger MTU size is usually sufficient for most HIP packets,
and therefore fragment generation may not be needed. If it
is expected that a host will send HIP packets that are
larger than the minimum IPv6 MTU, the implementation MUST
implement fragment generation even for IPv6.
</t>
<t>
In IPv4 networks, HIP packets may encounter low MTUs along
their routed path. Since basic HIP, as defined in this
document, does not provide a mechanism to use multiple IP
datagrams for a single HIP packet, support for path MTU
discovery does not bring any value to HIP in IPv4
networks. HIP-aware NAT devices SHOULD perform IPv4
reassembly/fragmentation for HIP packets.
</t>
<t>
All HIP implementations have to be careful while employing
a reassembly algorithm so that the algorithm is
sufficiently resistant to DoS attacks.
</t>
<t>
Certificate chains can cause the packet to be fragmented
and fragmentation can open implementations to
denial-of-service attacks <xref target="KAU03" />. "Hash
and URL" schemes as defined in <xref
target="RFC6253" /> for HIP version 1 may be
used to avoid fragmentation and mitigate resulting DoS
attacks.
</t>
</section>
</section>
<section anchor="hippars" title="HIP Parameters">
<t>
The HIP parameters carry information that is necessary
for establishing and maintaining a HIP association. For
example, the peer's public keys as well as the signaling for
negotiating ciphers and payload handling are encapsulated in
HIP parameters. Additional information, meaningful for
end-hosts or middleboxes, may also be included in HIP
parameters. The specification of the HIP parameters and
their mapping to HIP packets and packet types is flexible to
allow HIP extensions to define new parameters and new
protocol behavior.
</t>
<t>
In HIP packets, HIP parameters are ordered according to
their numeric type number and encoded in TLV format.
</t>
<t>
The following parameter types are currently defined.
</t>
<?rfc compact="no"?>
<texttable>
<ttcol width="27%" align="left">TLV</ttcol>
<ttcol width="5%" align="left">Type</ttcol>
<ttcol width="14%" align="left">Length</ttcol>
<ttcol align="left">Data</ttcol>
<c>R1_COUNTER</c><c>129</c><c>12</c><c>Puzzle generation
counter</c>
<c>PUZZLE</c><c>257</c><c>12</c><c>K and Random #I</c>
<c>SOLUTION</c><c>321</c><c>20</c><c>K, Random #I and puzzle
solution J</c>
<c>SEQ</c><c>385</c><c>4</c><c>UPDATE packet ID number</c>
<c>ACK</c><c>449</c><c>variable</c><c>UPDATE packet ID number</c>
<c>DH_GROUP_LIST</c><c>511</c><c>variable</c><c>Ordered list of DH
Group IDs supported by a host</c>
<c>DIFFIE_HELLMAN</c><c>513</c><c>variable</c><c>public key</c>
<c>HIP_CIPHER</c><c>579</c><c>variable</c><c>List of HIP encryption
algorithms</c>
<c>ENCRYPTED</c><c>641</c><c>variable</c><c>Encrypted part of
a HIP packet</c>
<c>HOST_ID</c><c>705</c><c>variable</c><c>Host Identity with
Fully-Qualified Domain FQDN (Name) or Network Access Identifier (NAI)</c>
<c>HIT_SUITE_LIST</c><c>715</c><c>variable</c><c>Ordered list of the HIT
suites supported by the Responder</c>
<c>CERT</c><c>768</c><c>variable</c><c>HI Certificate; used
to transfer certificates. Specified in a separate docment.</c>
<c>NOTIFICATION</c><c>832</c><c>variable</c><c>Informational
data</c>
<c>ECHO_REQUEST_SIGNED</c><c>897</c><c>variable</c><c>Opaque
data to be echoed back; signed</c>
<c>ECHO_RESPONSE_SIGNED</c><c>961</c><c>variable</c><c>Opaque data
echoed back by request; signed</c>
<c>TRANSPORT_FORMAT_LIST</c><c>2049</c><c>Ordered list of preferred
HIP transport type numbers</c><c>variable</c>
<c>HIP_MAC</c><c>61505</c><c>variable</c><c>HMAC-based message
authentication code, with key material from KEYMAT</c>
<c>HIP_MAC_2</c><c>61569</c><c>variable</c><c>HMAC based message
authentication code, with key material from KEYMAT.
Unlike HIP_MAC, the HOST_ID parameter is included in HIP_MAC_2
calculation.</c>
<c>HIP_SIGNATURE_2</c><c>61633</c><c>variable</c><c>Signature
used in R1 packet</c>
<c>HIP_SIGNATURE</c><c>61697</c><c>variable</c><c>Signature
of the packet</c>
<c>ECHO_REQUEST_UNSIGNED</c><c>63661</c><c>variable</c><c>Opaque
data to be echoed back; after signature</c>
<c>ECHO_RESPONSE_UNSIGNED</c><c>63425</c><c>variable</c><c>Opaque
data echoed back by request; after signature</c>
</texttable>
<?rfc compact="yes"?>
<t>
As the ordering (from lowest to highest) of HIP
parameters is strictly enforced (see <xref target="tlvformat"
/>), the parameter type values for existing parameters have
been spaced to allow for future protocol extensions.
</t>
<t>
The following parameter type number ranges are defined.
</t>
<?rfc compact="no"?>
<texttable>
<ttcol align="left" width="20%">Type Range</ttcol>
<ttcol align="left">Purpose</ttcol>
<c> 0 - 1023</c>
<c>Handshake</c>
<c> 1024 - 2047</c>
<c>Reserved</c>
<c> 2048 - 4095</c>
<c>Parameters related to HIP transport formats</c>
<c> 4096 - 8191</c>
<c>Signed parameters allocated through specification documents</c>
<c> 8192 - 32767</c>
<c>Reserved</c>
<c>32768 - 49151</c>
<c>Free for experimentation. Signed parameters.</c>
<c>49152 - 61439</c>
<c>Reserved</c>
<c>61440 - 62463</c>
<c>Signatures and (signed) MACs</c>
<c>62464 - 63487</c>
<c>Parameters that are neither signed nor MACed</c>
<c>63488 - 64511</c>
<c>Rendezvous and relaying</c>
<c>64512 - 65023</c>
<c>Parameters that are neither signed nor MACed</c>
<c>65024 - 65535</c>
<c>Reserved</c>
</texttable>
<?rfc compact="yes"?>
<t>
The process for defining new parameters is described in <xref
target="newparameter"/> of this document.
</t>
<t>
The range between 32768 (2^15) and 49151 (2^15 + 2^14) are
free for experimentation. Types from this range SHOULD be
selected in a random fashion to reduce the probability of
collisions.
</t>
<section anchor="tlvformat" title="TLV Format">
<t>
The TLV-encoded parameters are described in the following
subsections. The type-field value also describes the order
of these fields in the packet.
The parameters MUST be included in the packet so that
their types form an increasing order. If multiple
parameters with the same type number are in one packet,
the parameters with the same type MUST be consecutive in
the packet. If the order does not follow this rule, the
packet is considered to be malformed and it MUST be
discarded.
</t>
<t>
Parameters using type values from 2048 up to 4095 are
related to transport formats. Currently, one transport format
is defined: the ESP transport format <xref
target="I-D.ietf-hip-rfc5202-bis"
/>.
</t>
<t>
All of the encoded TLV parameters have a length (that
includes the Type and Length fields), which is a multiple
of 8 bytes. When needed, padding MUST be added to the end
of the parameter so that the total length is a multiple of
8 bytes. This rule ensures proper alignment of data. Any
added padding bytes MUST be zeroed by the sender, and
their values SHOULD NOT be checked by the receiver.
</t>
<t>
The Length field indicates the length of the Contents
field (in bytes). Consequently, the total length of the
TLV parameter (including Type, Length, Contents, and
Padding) is related to the Length field according to the
following formula:
</t>
<t>
Total Length = 11 + Length - (Length + 3) % 8;
</t>
<t>
where % is the modulo operator
</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Contents /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type code for the parameter. 16 bits long, C-bit
being part of the Type code.
C Critical. One if this parameter is critical, and
MUST be recognized by the recipient, zero otherwise.
The C bit is considered to be a part of the Type
field. Consequently, critical parameters are always
odd and non-critical ones have an even value.
Length Length of the Contents, in bytes excluding Type,
Length, and Padding.
Contents Parameter specific, defined by Type
Padding Padding, 0-7 bytes, added if needed
</artwork>
</figure>
<t>
Critical parameters (indicated by the odd type number)
MUST be recognized by the recipient. If a recipient
encounters a critical parameter that it does not
recognize, it MUST NOT process the packet any further. It
MAY send an ICMP or NOTIFY, as defined in <xref
target="error_proc" />.
</t>
<t>
Non-critical parameters MAY be safely ignored. If a
recipient encounters a non-critical parameter that it does
not recognize, it SHOULD proceed as if the parameter was
not present in the received packet.
</t>
</section>
<section anchor="newparameter" title="Defining New Parameters">
<t>
Future specifications may define new parameters as needed.
When defining new parameters, care must be taken to ensure
that the parameter type values are appropriate and leave
suitable space for other future extensions. One must
remember that the parameters MUST always be arranged in
numerically increasing order by Type code, thereby
limiting the order of parameters (see <xref
target="tlvformat" />).
</t>
<t>
The following rules MUST be followed when defining new
parameters.
<list style="numbers">
<t>
The low-order bit C of the Type code is used to
distinguish between critical and non-critical
parameters. Hence, even parameter type numbers indicate
non-critical parameters while odd parameter type
numbers indicate critical parameters.
</t>
<t>
A new parameter MAY be critical only if an old
implementation that ignored it would cause security problems.
In general, new parameters SHOULD be defined as
non-critical, and expect a reply from the recipient.
</t>
<t>
If a system implements a new critical parameter, it
MUST provide the ability to set the associated feature
off, such that the critical parameter is not sent at
all. The configuration option MUST be well documented.
Implementations operating in a mode adhering to this
specification MUST disable the sending of new critical
parameters by default. In other words, the management interface
MUST allow vanilla standards-only mode as a default
configuration setting, and MAY allow new critical
payloads to be configured on (and off).
</t>
<t>
See <xref target="iana" /> for allocation rules
regarding Type codes.
</t>
</list>
</t>
</section>
<section anchor="r1_counter" title="R1_COUNTER">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, 4 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R1 generation counter, 8 bytes |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 129
Length 12
R1 generation
counter The current generation of valid puzzles
</artwork>
</figure>
<t>
The R1_COUNTER parameter contains a 64-bit unsigned integer
in network-byte order, indicating the current generation of
valid puzzles. The sender SHOULD increment this
counter periodically. It is RECOMMENDED that the counter
value is incremented at least as often as old PUZZLE values
are deprecated so that SOLUTIONs to them are no longer
accepted.
</t>
<t>
Support for the R1_COUNTER parameter is mandatory although
its inclusion in the R1 packet is optional. It SHOULD be
included in the R1 (in which case, it is covered by the
signature), and if present in the R1, it MUST be echoed
(including the Reserved field verbatim) by the Initiator in
the I2 packet.
</t>
</section>
<section anchor="sec-puzzle" title="PUZZLE">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #K, 1 byte | Lifetime | Opaque, 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random #I, RHASH_len/8 bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 257
Length 4 + RHASH_len / 8
#K #K is the number of verified bits
Lifetime puzzle lifetime 2^(value-32) seconds
Opaque data set by the Responder, indexing the puzzle
Random #I random number of size RHASH_len bits
</artwork>
</figure>
<t>
Random #I is represented as a n-bit integer (where n is RHASH_len),
#K and Lifetime as 8-bit integers, all in network byte order.
</t>
<t>
The PUZZLE parameter contains the puzzle difficulty #K and a
n-bit random integer #I. The Puzzle Lifetime
indicates the time during which the puzzle solution is
valid, and sets a time limit that should not be exceeded by
the Initiator while it attempts to solve the puzzle. The
lifetime is indicated as a power of 2 using the formula
2^(Lifetime-32) seconds. A puzzle MAY be augmented with an
ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter
included in the R1; the contents of the echo request are
then echoed back in the ECHO_RESPONSE_SIGNED or in the
ECHO_RESPONSE_UNSIGNED parameter, allowing the Responder to use the
included information as a part of its puzzle processing.
</t>
<t>
The Opaque and Random #I field are not covered by the
HIP_SIGNATURE_2 parameter.
</t>
</section>
<section title="SOLUTION">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #K, 1 byte | Reserved | Opaque, 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random #I, n bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Puzzle solution #J, RHASH_len/8 bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 321
Length 4 + RHASH_len /4
#K #K is the number of verified bits
Reserved zero when sent, ignored when received
Opaque copied unmodified from the received PUZZLE
parameter
Random #I random number of size RHASH_len bits
Puzzle solution #J random number of size RHASH_len bits
</artwork>
</figure>
<t>
Random #I and Random #J are represented as n-bit unsigned
integers (where n is RHASH_len), #K as an 8-bit unsigned
integer, all in network byte order.
</t>
<t>
The SOLUTION parameter contains a solution to a puzzle. It
also echoes back the random difficulty #K, the Opaque field,
and the puzzle integer #I.
</t>
</section>
<section anchor="dh_group_list" title="DH_GROUP_LIST">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #n| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 511
Length number of DH Group IDs
DH GROUP ID identifies a DH GROUP ID supported by the host.
The list of IDs is ordered by preference of the
host. The possible DH Group IDs are defined
in the DIFFIE_HELLMAN parameter. Each DH Group ID
is one octet long.
</artwork>
</figure>
<t>
The DH_GROUP_LIST parameter contains the list of supported
DH Group IDs of a host. The Initiator sends the
DH_GROUP_LIST in the I1 packet, the Responder sends its
own list in the signed part of the R1 packet. The DH Group
IDs in the DH_GROUP_LIST are listed in the order of their
preference of the host sending the list. DH Group IDs that
are listed first are preferred over the DH Group IDs
listed later. The information in the DH_GROUP_LIST allows
the Responder to select the DH group preferred by itself
and supported by the Initiator. Based on the DH_GROUP_LIST
in the R1 packet, the Initiator can determine if the
Responder has selected the best possible choice based on
the Initiator's and Responder's preferences. If the
Responder's choice differs from the best choice, the
Initiator can conclude that there was an attempted
downgrade attack (see <xref target="downgrade" />).
</t>
<t>
When selecting the DH group for the DIFFIE_HELLMAN
parameter in the R1 packet, the Responder MUST select the
first DH Group ID in its DH_GROUP_LIST in the R1 packet
that is compatible with one of the Suite IDs in the
Initiator's DH_GROUP_LIST in the I1 packet. The Responder
MUST NOT select any other DH Group ID that is contained in
both lists because a downgrade attack cannot be detected
then.
</t>
<t>In general, hosts SHOULD prefer stronger groups over
weaker ones if the computation overhead is not prohibitively
high for the intended application.
</t>
</section>
<section anchor="diffie_hellman" title="DIFFIE_HELLMAN">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | Public Value Length | Public Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 513
Length length in octets, excluding Type, Length, and
Padding
Group ID identifies values for p and g as well as the KDF
Public Value length of the following Public Value in octets
Length
Public Value the sender's public Diffie-Hellman key
</artwork>
</figure>
<t>A single DIFFIE_HELLMAN parameter may be included in selected
HIP packets based on the DH Group ID selected
(<xref target="dh_group_list" />).
The following Group IDs have been defined:
</t>
<figure>
<artwork>
Group KDF Value
Reserved 0
DEPRECATED 1
DEPRECATED 2
1536-bit MODP group [RFC3526] HKDF [RFC5869] 3
3072-bit MODP group [RFC3526] HKDF [RFC5869] 4
DEPRECATED 5
DEPRECATED 6
NIST P-256 [RFC5903] HKDF [RFC5869] 7
NIST P-384 [RFC5903] HKDF [RFC5869] 8
NIST P-521 [RFC5903] HKDF [RFC5869] 9
SECP160R1 [SECG] HKDF [RFC5869] 10
2048-bit MODP group [RFC3526] HKDF [RFC5869] 11
</artwork>
</figure>
<t>
The MODP Diffie-Hellman groups are defined in <xref
target="RFC3526" />. The ECDH groups 7 - 9 are defined
in <xref target="RFC5903" /> and <xref
target="RFC6090" />. ECDH group 10 is covered in
<xref target="ecdh-160-group" />. Any ECDH used with HIP
MUST have a co-factor of 1.
</t>
<t>
The Group ID also defines the key derivation function that
is to be used for deriving the symmetric keys for the HMAC
and symmetric encryption from the keying material from the
Diffie Hellman key exchange (see <xref target="keymat" />).
</t>
<t>
A HIP implementation MUST implement Group ID 3. The 160-bit
SECP160R1 group can be used when lower security is enough (e.g.,
web surfing) and when the equipment is not powerful enough
(e.g., some PDAs). Implementations SHOULD implement Group
IDs 4 and 8.
</t>
<!--RM will we need an appendix for ECDH 160? and is this the 'right'
lite size? -->
<!--TH: I would rather prefer to stick to ECC groups that are
defined elsewhere. 160 bit seems okay from a size
perspective. The keys will be 20 bytes long - that seems
afordable to me - even in ressource constrained
environments. The secp160r1 curve from secg seems to be
widely implemented and could be used here.-->
<t>
To avoid unnecessary failures during the base exchange, the
rest of the groups SHOULD be implemented in hosts where
resources are adequate.
</t>
</section>
<section anchor="hip_cipher" title="HIP_CIPHER">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher ID #1 | Cipher ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 579
Length length in octets, excluding Type, Length, and
Padding
Cipher ID identifies the cipher algorithm to be used for
encrypting the contents of the ENCRYPTED parameter
</artwork>
</figure>
<t>
The following Cipher IDs are defined:</t>
<figure>
<artwork>
Suite ID Value
RESERVED 0
NULL-ENCRYPT 1 ([RFC2410])
AES-128-CBC 2 ([RFC3602])
RESERVED 3 (unused value)
AES-256-CBC 4 ([RFC3602])
</artwork>
</figure>
<t>
The sender of a HIP_CIPHER parameter MUST make sure
that there are no more than six (6) Cipher IDs in one
HIP_CIPHER parameter. Conversely, a recipient MUST be
prepared to handle received transport parameters that
contain more than six Cipher IDs by accepting the first
six Cipher IDs and dropping the rest. The limited
number of Cipher IDs sets the maximum size of the
HIP_CIPHER parameter. As the default configuration,
the HIP_CIPHER parameter MUST contain at least one of
the mandatory Cipher IDs. There MAY be a configuration
option that allows the administrator to override this
default.
</t>
<t>
The Responder lists supported and desired Cipher IDs in
order of preference in the R1, up to the maximum of six
Cipher IDs. The Initiator MUST choose only one of the
corresponding Cipher IDs. This Cipher ID will be used
for generating the ENCRYPTED parameter.
</t>
<t>
Mandatory implementation: AES-128-CBC. Implementors
SHOULD support NULL-ENCRYPT for testing/debugging purposes,
but MUST NOT offer or accept this value unless explicitly
configured for testing/debugging of the HIP protocol.
</t>
</section>
<section anchor="host-id" title="HOST_ID">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HI Length |DI-type| DI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Host Identity /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Domain Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 705
Length length in octets, excluding Type, Length, and
Padding
HI Length length of the Host Identity in octets
DI-type type of the following Domain Identifier field
DI Length length of the Domain Identifier field in octets
Algorithm index to the employed algorithm
Host Identity actual Host Identity
Domain Identifier the identifier of the sender
</artwork>
</figure>
<t>The following DI-types have been defined:</t>
<figure>
<artwork>
Type Value
none included 0
FQDN 1
NAI 2
FQDN Fully Qualified Domain Name, in binary format.
NAI Network Access Identifier
</artwork>
</figure>
<t>
The format for the FQDN is defined in <xref
target="RFC1035"> RFC 1035</xref> Section 3.1. The format
for the NAI is defined in <xref target="RFC4282" />
</t>
<t>
A host MAY optionally associate the Host Identity with a single
Domain Identifier in the HOST_ID parameter.
If there is no Domain Identifier, i.e., the DI-type field
is zero, the DI Length field is set to zero as well.
</t>
<t>The following HI Algorithms have been defined:</t>
<figure>
<artwork>
Algorithm
profiles Values
RESERVED 0
DSA 3 [FIPS186-3] (RECOMMENDED)
RSA 5 [RFC3447] (REQUIRED)
ECDSA 7 [RFC4754] (REQUIRED)
ECDSA_LOW 9 [SECG] (RECOMMENDED)
</artwork>
</figure>
<t> For DSA, RSA, and ECDSA key types, profiles containing at least
112 bits of security strength (as defined by
<xref target="NIST.800-131A.2011" />) should be used. For RSA
signature padding, the PSS method of padding
<xref target="RFC3447" /> MUST be used.
</t>
<t>
The Host Identity is derived from the DNSKEY format for RSA and DSA.
For these, the Public Key field of the RDATA part from <xref target="RFC4034">
RFC 4034</xref> is used. For ECC we distinguish two different profiles:
ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and
defined in <xref target="RFC4754">RFC 4754</xref>. ECDSA_LOW is defined
for devices with low computational capabilities and uses
shorter curves from <xref target="SECG">SECG</xref>.
Any ECDSA used with HIP MUST have a co-factor of 1.
</t>
<t>
For ECDSA and ECDSA_LOW Host Identities are represented by
the following fields:
</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECC Curve | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Public Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ECC Curve Curve label
Public Key Represented in Octet-string format
[RFC6090]
</artwork>
</figure>
<t>
For hosts that implement ECDSA as algorithm the following
ECC curves are required:
</t>
<figure>
<artwork>
Algorithm Curve Values
ECDSA RESERVED 0
ECDSA NIST P-256 1 [RFC4754]
ECDSA NIST P-384 2 [RFC4754]
</artwork>
</figure>
<t>
For hosts that implement the ECDSA_LOW algorithm profile,
the following curve is required:
</t>
<figure>
<artwork>
Algorithm Curve Values
ECDSA_LOW RESERVED 0
ECDSA_LOW SECP160R1 1 [SECG]
</artwork>
</figure>
</section>
<section anchor="hit_suite_list" title="HIT_SUITE_LIST">
<t>
The HIT_SUITE_LIST parameter contains a list of the supported HIT
Suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST
in the signed part of the R1 packet. Based on the HIT_SUITE_LIST,
the Initiator can determine which source HIT Suite IDs are
supported by the Responder.
</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID #1 | ID #2 | ID #3 | ID #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 715
Length number of HIT Suite IDs
ID identifies a HIT Suite ID supported by the host.
The list of IDs is ordered by preference of the
host. Each HIT Suite ID is one octet long. The four
higher-order bits of the ID field correspond to the
HIT Suite ID in the ORCHID OGA field. The four
lower-order bits are reserved and set to 0 by
the sender. The reception of an ID with the
four lower-order bits not set to 0 SHOULD be
considered as an error that MAY result in a
NOTIFICATION of type UNSUPPORTED_HIT_SUITE.
</artwork>
</figure>
<t>
The HIT Suite ID indexes a HIT Suite. HIT Suites are
composed of signature algorithms as defined in <xref
target="host-id"/> and hash functions.
</t>
<t>
The ID field in the HIT_SUITE_LIST is defined as eight-bit
field as opposed to the four-bit HIT Suite ID and OGA
field in the ORCHID. This difference is a measure to
accommodate larger HIT Suite IDs if the 16 available
values prove insufficient. In that case, one of the 16
values, zero, will be used to indicate that four
additional bits of the ORCHID will be used to encode the
HIT Suite ID. Hence, the current four-bit HIT Suite-IDs
only use the four higher order bits in the ID field.
Future documents may define the use of the four
lower-order bits in the ID field.
</t>
<t>
The following HIT Suites ID are defined, and the
relationship between the four-bit ID value used in
the OGA ID field, and the eight-bit encoding within the
HIT_SUITE_LIST ID field, is clarified:</t>
<figure>
<artwork>
HIT Suite Four-bit ID Eight-bit encoding
RESERVED 0 0x00
RSA,DSA/SHA-256 1 0x10 (REQUIRED)
ECDSA/SHA-384 2 0x20 (RECOMMENDED)
ECDSA_LOW/SHA-1 3 0x30 (RECOMMENDED)
</artwork>
<!--TH Do we really need 1, 256 AND 384. We are using up suite IDs
much too quick. -->
<!--TH: I left the HIT Suite 0-reserved there because I think
it might be smartest to have 0 as optional growth class
instead of 15.-->
<!--RGM I do not like how many I needed so far for ECDSA...-->
</figure>
<t>
The following table provides more detail on the
above HIT Suite combinations. The
input for each generation algorithm is the encoding of the HI
as defined in <xref target="gener_hit" />. The output is 96
bits long and is directly used in the ORCHID.
</t>
<texttable title="HIT Suites" anchor="table_hit_suites">
<ttcol align="right">Index</ttcol>
<ttcol align="left">Hash function</ttcol>
<ttcol align="left">HMAC</ttcol>
<ttcol align="left">Signature algorithm family</ttcol>
<ttcol align="left">Description</ttcol>
<c>0</c> <c></c> <c></c><c></c> <c>Reserved</c>
<c>1</c> <c>SHA-256</c> <c>HMAC-SHA-256</c><c>RSA, DSA</c> <c>RSA or DSA HI hashed with SHA-256, truncated to 96 bits</c>
<c>2</c> <c>SHA-384</c> <c>HMAC-SHA-384</c><c>ECDSA</c> <c>ECDSA HI hashed with SHA-384, truncated to 96 bits</c>
<c>3</c> <c>SHA-1</c> <c>HMAC-SHA-1</c><c>ECDSA_LOW</c> <c>ECDSA_LOW HI hashed with SHA-1, truncated to 96 bits</c>
</texttable>
<t>
The hash of the responder as defined in the HIT Suite
determines the HMAC to be used for the RHASH function.
The HMACs currently defined here are HMAC-SHA-256 <xref target="RFC4868" />,
HMAC-SHA-384 <xref target="RFC4868" />, and HMAC-SHA-1 <xref target="RFC2404" />.
</t>
</section>
<section anchor="transport_format_list" title="TRANSPORT_FORMAT_LIST">
<t>
The TRANSPORT_FORMAT_LIST parameter contains a list of the supported HIP
transport formats (TFs) of the Responder. The Responder sends the
TRANSPORT_FORMAT_LIST in the signed part of the R1 packet.
Based on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable
transport format and includes the respective HIP transport format parameter
in its response packet.
</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TF type #1 | TF type #2 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TF type #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2049
Length 2x number of TF types
TF Type identifies a transport format (TF) type supported by
the host. The TF type numbers correspond to the HIP
parameter type numbers of the respective transport
format
parameters. The list of TF types is ordered by
preference of the sender
</artwork>
</figure>
<t>
The TF type numbers index the respective HIP parameters
for the transport formats in the type number range between
2050 to 4095. The parameters and their use are defined in
separate documents. Currently, the only transport format
defined is IPsec ESP <xref target="I-D.ietf-hip-rfc5202-bis" />.
</t>
<t>
For each listed TF type, the sender of the
TRANSPORT_FORMAT_LIST parameter MUST
include the respective transport format parameter in the HIP
packet. The receiver MUST ignore the TF type in the
TRANSPORT_FORMAT_LIST if no matching transport format
parameter is present in the packet.
</t>
</section>
<section anchor="HIP_MAC" title="HIP_MAC">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC |
/ /
/ +-------------------------------+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 61505
Length length in octets, excluding Type, Length, and
Padding
HMAC HMAC computed over the HIP packet, excluding the
HIP_MAC parameter and any following parameters, such
as HIP_SIGNATURE, HIP_SIGNATURE_2,
ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED.
The checksum field MUST be set to zero and the HIP
header length in the HIP common header MUST be
calculated not to cover any excluded parameters
when the HMAC is calculated. The size of the
HMAC is the natural size of the hash computation
output depending on the used hash function.
</artwork>
</figure>
<t>
The HMAC uses RHASH as hash algorithm. The calculation and
verification process is presented in <xref
target="hmac-processing" />.
</t>
</section>
<section anchor="HIP_MAC_2" title="HIP_MAC_2">
<t>
The HIP_MAC_2 is a MAC of the packet and the HI of the
sender in the form of a HOST_ID parameter when that parameter
is not actually included in the packet.
The parameter structure is
the same as in <xref target="HIP_MAC" />. The fields are:
</t>
<figure>
<artwork>
Type 61569
Length length in octets, excluding Type, Length, and
Padding
HMAC HMAC computed over the HIP packet, excluding the
HIP_MAC_2 parameter and any following parameters
such as HIP_SIGNATURE, HIP_SIGNATURE_2,
ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED,
and including an additional sender's HOST_ID
parameter during the HMAC calculation. The checksum
field MUST be set to zero and the HIP header length
in the HIP common header MUST be calculated not to
cover any excluded parameters when the HMAC is
calculated. The size of the HMAC is the natural
size of the hash computation output depending on the
used hash function.
</artwork>
</figure>
<t>
The HMAC uses RHASH as hash algorithm. The calculation and
verification process is presented in <xref
target="hmac-processing" />.
</t>
</section>
<section anchor="hip-signature" title="HIP_SIGNATURE">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIG alg | Signature /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 61697
Length length in octets, excluding Type, Length, and
Padding
SIG alg signature algorithm
Signature the signature is calculated over the HIP packet,
excluding the HIP_SIGNATURE parameter and any
parameters that follow the HIP_SIGNATURE parameter.
When the signature is calculated the checksum field
MUST be set to zero, and the HIP header length in
the HIP common header MUST be calculated only up to
the beginning of the HIP_SIGNATURE parameter.
</artwork>
</figure>
<t>
The signature algorithms are defined in <xref
target="host-id" />. The signature in the Signature field
is encoded using the method depending on the
signature algorithm (e.g., according to <xref
target="RFC3110"/> in case of RSA/SHA-1, according to <xref
target="RFC5702" /> in case of RSA/SHA-256, according to
<xref target="RFC2536" /> in case of DSA, or according to
<xref target="RFC6090" /> in case of ECDSA).
</t>
<t>
The HIP_SIGNATURE calculation and verification process are
presented in <xref target="sig-processing" />.
</t>
</section>
<section anchor="HIP_SIGNATURE_2" title="HIP_SIGNATURE_2">
<t>
The HIP_SIGNATURE_2 excludes the variable parameters in
the R1 packet to allow R1 pre-creation. The parameter structure
is the same as in <xref target="hip-signature" />.
The fields are:
</t>
<figure>
<artwork>
Type 61633
Length length in octets, excluding Type, Length, and
Padding
SIG alg signature algorithm
Signature Within the R1 packet that contains the
HIP_SIGNATURE_2 parameter, the Initiator's HIT, the
checksum field, and the Opaque and Random #I fields
in the PUZZLE parameter MUST be set to zero while
computing the HIP_SIGNATURE_2 signature. Further,
the HIP packet length in the HIP header MUST be
adjusted as if the HIP_SIGNATURE_2 was not in the
packet during the signature calculation, i.e., the
HIP packet length points to the beginning of
the HIP_SIGNATURE_2 parameter during signing and
verification.
</artwork>
</figure>
<t>
Zeroing the Initiator's HIT makes it possible to create R1
packets beforehand, to minimize the effects of possible DoS
attacks. Zeroing the Random #I and Opaque fields within the
PUZZLE parameter allows these fields to be populated
dynamically on precomputed R1s.
</t>
<t>
Signature calculation and verification follows the process
defined in <xref target="sig-processing" />.
</t>
</section>
<section title="SEQ">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 385
Length 8
Update ID 32-bit sequence number
</artwork>
</figure>
<t>
The Update ID is an unsigned number in network byte order,
initialized by a host to zero upon moving to ESTABLISHED
state. The Update ID has scope within a single HIP
association, and not across multiple associations or
multiple hosts. The Update ID is incremented by one
before each new UPDATE that is sent by the host; the first
UPDATE packet originated by a host has an Update ID of 0.
</t>
</section>
<section title="ACK">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| peer Update ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ peer Update ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 449
Length length in octets, excluding Type and Length
peer Update ID 32-bit sequence number corresponding to the
Update ID being ACKed.
</artwork>
</figure>
<t>
The ACK parameter includes one or more Update IDs that have
been received from the peer. The number of peer Update
IDs can be inferred from the length by dividing it by 4.
</t>
</section>
<section title="ENCRYPTED">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV /
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ Encrypted data /
/ /
/ +-------------------------------+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 641
Length length in octets, excluding Type, Length, and
Padding
Reserved zero when sent, ignored when received
IV Initialization vector, if needed, otherwise
nonexistent. The length of the IV is inferred from
the HIP_CIPHER.
Encrypted The data is encrypted using the encryption algorithm
data defined in the HIP_CIPHER parameter.
</artwork>
</figure>
<t>
The ENCRYPTED parameter encapsulates other parameters, the
encrypted data, which holds one or more HIP parameters in
block encrypted form.
</t>
<t>
Consequently, the first fields in the encapsulated
parameter(s) are Type and Length of the first such
parameter, allowing the contents to be easily parsed after
decryption.
</t>
<t>
The field labeled "Encrypted data" consists of the output
of one or more HIP parameters concatenated together that
have been passed through an encryption algorithm. Each of
these inner parameters is padded according to the rules of
<xref target="tlvformat"/> for padding individual
parameters. As a result, the concatenated parameters will
be a block of data that is 8-byte aligned.
</t>
<t>
Some encryption algorithms require that the data to be
encrypted must be a multiple of the cipher algorithm block
size. In this case, the above block of data MUST include
additional padding, as specified by the encryption
algorithm. The size of the extra padding is selected so
that the length of the unencrypted data block is a multiple
of the cipher block size. The encryption algorithm may
specify padding bytes other than zero; for example, <xref
target="FIPS.197.2001">AES</xref> uses the PKCS5 padding
scheme (see section 6.1.1 of <xref target="RFC2898"/>) where
the remaining n bytes to fill the block each have the value
of n. This yields an "unencrypted data" block that is
transformed to an "encrypted data" block by the cipher
suite. This extra padding added to the set of parameters to
satisfy the cipher block alignment rules is not counted in
HIP TLV length fields, and this extra padding should be
removed by the cipher suite upon decryption.
</t>
<t>
Note that the length of the cipher suite output may be
smaller or larger than the length of the set of parameters
to be encrypted, since the encryption process may compress
the data or add additional padding to the data.
</t>
<t>
Once this encryption process is completed, the Encrypted
data field is ready for inclusion in the parameter. If
necessary, additional Padding for 8-byte alignment is then
added according to the rules of <xref target="tlvformat"/>.
</t>
</section>
<section anchor="notify" title="NOTIFICATION">
<t>
The NOTIFICATION parameter is used to transmit
informational data, such as error conditions and state
transitions, to a HIP peer. A NOTIFICATION parameter may
appear in NOTIFY packets. The use of the NOTIFICATION
parameter in other packet types is for further study.
</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ Notification Data /
/ +---------------+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 832
Length length in octets, excluding Type, Length, and
Padding
Reserved zero when sent, ignored when received
Notify Message specifies the type of notification
Type
Notification informational or error data transmitted in addition
Data to the Notify Message Type. Values for this field
are type specific (see below).
multiple of 8 bytes.
</artwork>
</figure>
<t>
Notification information can be error messages specifying
why an HIP Security Association could not be established.
It can also be status data that a HIP implementation
wishes to communicate with a peer process. The table
below lists the notification messages and their
Notification Message Types. HIP packets MAY contain
multiple NOTIFICATION parameters if several problems exist or
several independent pieces of information must be
transmitted.
</t>
<t>
To avoid certain types of attacks, a Responder SHOULD avoid
sending a NOTIFICATION to any host with which it has not
successfully verified a puzzle solution.
</t>
<t>
Notify Message Types in the range 0-16383 are intended for
reporting errors and in the range 16384-65535 for other
status information. An implementation that receives a
NOTIFY packet with a Notify Message Type that indicates an
error in response to a request packet (e.g., I1, I2,
UPDATE) SHOULD assume that the corresponding request has
failed entirely. Unrecognized error types MUST be ignored
except that they SHOULD be logged.
</t>
<t>
As currently defined, Notify Message Type values 1-10 are
used for informing about errors in packet structures,
values 11-20 for informing about problems in parameters.
</t>
<t>
Notification Data in NOTIFICATION parameters where the Notify
Message Type is in the status range
MUST be ignored if not recognized.
</t>
<figure>
<artwork>
Notify Message Types - Errors Value
----------------------------- -----
UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1
Sent if the parameter type has the "critical" bit set and the
parameter type is not recognized. Notification Data contains the
two-octet parameter type.
INVALID_SYNTAX 7
Indicates that the HIP message received was invalid because some
type, length, or value was out of range or because the request
was otherwise malformed. To avoid a denial-of-service
attack using forged messages, this status may only be returned
for packets whose HIP_MAC (if present) and SIGNATURE have been
verified. This status MUST be sent in response to any error not
covered by one of the other status types, and SHOULD NOT contain
details to avoid leaking information to someone probing a node.
To aid debugging, more detailed error information SHOULD be
written to a console or log.
NO_DH_PROPOSAL_CHOSEN 14
None of the proposed group IDs was acceptable.
INVALID_DH_CHOSEN 15
The DH Group ID field does not correspond to one offered
by the Responder.
NO_HIP_PROPOSAL_CHOSEN 16
None of the proposed HIT Suites or HIP Encryption Algorithms was
acceptable.
INVALID_HIP_CIPHER_CHOSEN 17
The HIP_CIPHER Crypto ID does not correspond to one offered by
the Responder.
UNSUPPORTED_HIT_SUITE 20
Sent in response to an I1 or R1 packet for which the HIT suite
is not supported.
AUTHENTICATION_FAILED 24
Sent in response to a HIP signature failure, except when
the signature verification fails in a NOTIFY message.
CHECKSUM_FAILED 26
Sent in response to a HIP checksum failure.
HIP_MAC_FAILED 28
Sent in response to a HIP HMAC failure.
ENCRYPTION_FAILED 32
The Responder could not successfully decrypt the
ENCRYPTED parameter.
INVALID_HIT 40
Sent in response to a failure to validate the peer's
HIT from the corresponding HI.
BLOCKED_BY_POLICY 42
The Responder is unwilling to set up an association
for some policy reason (e.g., received HIT is NULL
and policy does not allow opportunistic mode).
RESPONDER_BUSY_PLEASE_RETRY 44
The Responder is unwilling to set up an association as it is
suffering under some kind of overload and has chosen to shed load
by rejecting the Initiator's request. The Initiator may retry;
however, the Initiator MUST find another (different) puzzle
solution for any such retries. Note that the Initiator may need
to obtain a new puzzle with a new I1/R1 exchange.
Notify Message Types - Status Value
----------------------------- -----
I2_ACKNOWLEDGEMENT 16384
The Responder has an I2 packet from the Initiator but had to
queue the I2 packet for processing. The puzzle was correctly
solved and the Responder is willing to set up an association but
currently has a number of I2 packets in the processing queue.
The R2 packet is sent after the I2 packet was processed.
</artwork>
</figure>
</section>
<section anchor="sec-echo-request-signed" title="ECHO_REQUEST_SIGNED">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 897
Length length of the opaque data in octets
Opaque data opaque data, supposed to be meaningful only to the
node that sends ECHO_REQUEST_SIGNED and receives a
corresponding ECHO_RESPONSE_SIGNED or
ECHO_RESPONSE_UNSIGNED.
</artwork>
</figure>
<t>
The ECHO_REQUEST_SIGNED parameter contains an opaque blob
of data that the sender wants to get echoed back in the
corresponding reply packet.
</t>
<t>
The ECHO_REQUEST_SIGNED and corresponding echo response
parameters MAY be used for any purpose where a node wants
to carry some state in a request packet and get it back in
a response packet. The ECHO_REQUEST_SIGNED is covered by
the HIP_MAC and SIGNATURE. A HIP packet can contain only
one ECHO_REQUEST_SIGNED parameter and MAY contain multiple
ECHO_REQUEST_UNSIGNED parameters. The ECHO_REQUEST_SIGNED
parameter MUST be responded to with an
ECHO_RESPONSE_SIGNED.
</t>
</section>
<section anchor="sec-echo-request-unsigned"
title="ECHO_REQUEST_UNSIGNED">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 63661
Length length of the opaque data in octets
Opaque data opaque data, supposed to be meaningful only to the
node that sends ECHO_REQUEST_UNSIGNED and receives a
corresponding ECHO_RESPONSE_UNSIGNED.
</artwork>
</figure>
<t>
The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob
of data that the sender wants to get echoed back in the
corresponding reply packet.
</t>
<t>
The ECHO_REQUEST_UNSIGNED and corresponding echo response
parameters MAY be used for any purpose where a node wants
to carry some state in a request packet and get it back in
a response packet. The ECHO_REQUEST_UNSIGNED is not
covered by the HIP_MAC and SIGNATURE. A HIP packet can
contain one or more ECHO_REQUEST_UNSIGNED parameters. It
is possible that middleboxes add ECHO_REQUEST_UNSIGNED
parameters in HIP packets passing by. The creator of the
ECHO_REQUEST_UNSIGNED (end-host or middlebox) has to
create the Opaque field so that it can later identify and
remove the corresponding ECHO_RESPONSE_UNSIGNED parameter.
</t>
<t>
The ECHO_REQUEST_UNSIGNED parameter MUST be responded to
with an ECHO_RESPONSE_UNSIGNED parameter.
</t>
</section>
<section anchor="echo_response_signed"
title="ECHO_RESPONSE_SIGNED">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 961
Length length of the opaque data in octets
Opaque data opaque data, copied unmodified from the
ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED
parameter that triggered this response.
</artwork>
</figure>
<t>
The ECHO_RESPONSE_SIGNED parameter contains an opaque blob
of data that the sender of the ECHO_REQUEST_SIGNED wants to
get echoed back. The opaque data is copied unmodified from
the ECHO_REQUEST_SIGNED parameter.
</t>
<t>
The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters
MAY be used for any purpose where a node wants to carry
some state in a request packet and get it back in a
response packet. The ECHO_RESPONSE_SIGNED is covered by
the HIP_MAC and SIGNATURE.
</t>
</section>
<section anchor="echo_response_unsigned"
title="ECHO_RESPONSE_UNSIGNED">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 63425
Length length of the opaque data in octets
Opaque data opaque data, copied unmodified from the
ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED
parameter that triggered this response.
</artwork>
</figure>
<t>
The ECHO_RESPONSE_UNSIGNED parameter contains an opaque
blob of data that the sender of the ECHO_REQUEST_SIGNED or
ECHO_REQUEST_UNSIGNED wants to get echoed back. The opaque
data is copied unmodified from the corresponding echo
request parameter.
</t>
<t>
The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY
be used for any purpose where a node wants to carry some
state in a request packet and get it back in a response
packet. The ECHO_RESPONSE_UNSIGNED is not covered by the
HIP_MAC and SIGNATURE.
</t>
</section>
</section>
<section title="HIP Packets">
<t>
There are eight basic HIP packets (see <xref
target="table_hip_packets" />). Four are for the HIP base
exchange, one is for updating, one is for sending
notifications, and two are for closing a HIP association.
Support for NOTIFY packet type is optional, but support
for all other HIP packet types listed below is mandatory.
</t>
<?rfc compact="no"?>
<texttable title="HIP packets and packet type values"
anchor="table_hip_packets">
<ttcol width="25%" align="center">Packet type</ttcol>
<ttcol align="left">Packet name</ttcol>
<c>1</c><c>I1 - the HIP Initiator Packet</c>
<c>2</c><c>R1 - the HIP Responder Packet</c>
<c>3</c><c>I2 - the Second HIP Initiator Packet</c>
<c>4</c><c>R2 - the Second HIP Responder Packet</c>
<c>16</c><c>UPDATE - the HIP Update Packet</c>
<c>17</c><c>NOTIFY - the HIP Notify Packet</c>
<c>18</c><c>CLOSE - the HIP Association Closing Packet</c>
<c>19</c><c>CLOSE_ACK - the HIP Closing Acknowledgment Packet</c>
</texttable>
<?rfc compact="yes"?>
<t>Packets consist of the fixed header as described in <xref
target="ssec-payload" />, followed by the parameters. The
parameter part, in turn, consists of zero or more TLV-coded
parameters.</t>
<t>
In addition to the base packets, other packet types may be
defined later in separate specifications. For example,
support for mobility and multi-homing is not included in this
specification.
</t>
<t>
See <xref target="notation">Notation</xref> for the notation
used in the operations.
</t>
<t>
In the future, an optional upper-layer payload MAY follow the
HIP header. The Next Header field in the header indicates if
there is additional data following the HIP header. The HIP
packet, however, MUST NOT be fragmented into multiple extension
headers by setting the Next Header field in a HIP header to the
HIP protocol number. This limits the
size of the possible additional data in the packet.
</t>
<section anchor="I1" title="I1 - the HIP Initiator Packet">
<t>The HIP header values for the I1 packet:</t>
<figure>
<artwork>
Header:
Packet Type = 1
SRC HIT = Initiator's HIT
DST HIT = Responder's HIT, or NULL
IP ( HIP ( DH_GROUP_LIST ) )
</artwork>
</figure>
<t>The I1 packet contains the fixed HIP header and the
Initiator's DH_GROUP_LIST.</t>
<t>Valid control bits: none</t>
<t>
The Initiator receives the Responder's HIT either from a
DNS lookup of the Responder's FQDN (see 5205-bis), from
some other repository, or from a local table. If the
Initiator does not know the Responder's HIT, it may
attempt to use opportunistic mode by using NULL (all
zeros) as the Responder's HIT. See also <xref
target="op_mode">"HIP Opportunistic Mode"</xref>.
</t>
<t>
Since the I1 packet is so easy to spoof even if it were
signed, no attempt is made to add to its generation or
processing cost.
</t>
<t>
The Initiator includes a DH_GROUP_LIST parameter in the I1
packet to inform the Responder of its preferred DH Group
IDs. Note that the DH_GROUP_LIST in the I1 packet is not
protected by a signature.
</t>
<t>
Implementations MUST be able to handle a storm of received
I1 packets, discarding those with common content that
arrive within a small time delta.
</t>
</section>
<section anchor="R1" title="R1 - the HIP Responder Packet">
<t>The HIP header values for the R1 packet:</t>
<figure>
<artwork>
Header:
Packet Type = 2
SRC HIT = Responder's HIT
DST HIT = Initiator's HIT
IP ( HIP ( [ R1_COUNTER, ]
PUZZLE,
DIFFIE_HELLMAN,
HIP_CIPHER,
HOST_ID,
HIT_SUITE_LIST,
DH_GROUP_LIST,
[ ECHO_REQUEST_SIGNED, ]
TRANSPORT_FORMAT_LIST,
HIP_SIGNATURE_2 )
<, ECHO_REQUEST_UNSIGNED >i)
</artwork>
</figure>
<t>
Valid control bits: A
</t>
<t>
If the Responder's HI is an anonymous one, the A control
MUST be set.
</t>
<t>
The Initiator's HIT MUST match the one received in the I1
packet if the R1 is a response to an I1. If the Responder
has multiple HIs, the Responder's HIT used MUST match
Initiator's request. If the Initiator used opportunistic
mode, the Responder may select freely among its HIs. See
also <xref target="op_mode">"HIP Opportunistic
Mode"</xref>.
</t>
<t>
The R1 packet generation counter is used to determine the
currently valid generation of puzzles. The value is
increased periodically, and it is RECOMMENDED that it is
increased at least as often as solutions to old puzzles
are no longer accepted.
</t>
<t>
The Puzzle contains a Random #I and the difficulty #K.
The difficulty #K indicates the number of lower-order
bits, in the puzzle hash result, that must be zeros; see
<xref target="puzzle_exchange"/>. The Random #I is not
covered by the signature and must be zeroed during the
signature calculation, allowing the sender to select and
set the #I into a precomputed R1 packet just prior sending
it to the peer.
</t>
<t>
The Responder selects the Diffie-Hellman public value
based on the Initiator's preference expressed in the
DH_GROUP_LIST parameter in the I1 packet. The Responder
sends back its own preference based on which it chose the
DH public value as DH_GROUP_LIST. This allows the
Initiator to determine whether its own DH_GROUP_LIST in
the sent I1 packet was manipulated by an attacker.
</t>
<t>
The Diffie-Hellman public value is ephemeral, and values
SHOULD NOT be reused across different HIP associations. Once the
Responder has received a valid response to an R1 packet,
that Diffie-Hellman value SHOULD be deprecated. It
is possible that the Responder has sent the same
Diffie-Hellman value to different hosts simultaneously in
corresponding R1 packets and those responses should also be
accepted. However, as a defense against I1 packet storms,
an implementation MAY propose, and re-use unless
avoidable, the same Diffie-Hellman value for a period of
time, for example, 15 minutes. By using a small number of
different puzzles for a given Diffie-Hellman value, the R1
packets can be precomputed and delivered as quickly as I1
packets arrive. A scavenger process should clean up
unused Diffie-Hellman values and puzzles.
</t>
<t>
Re-using Diffie-Hellman public values opens up the potential
security risk of more than one Initiator ending up with the
same keying material (due to faulty random number
generators). Also, more than one Initiator using the same
Responder public key half may lead to potentially easier
cryptographic attacks and to imperfect forward security.
</t>
<t>
However, these risks involved in re-using the same public
value are
statistical; that is, the authors are not aware of any
mechanism that would allow manipulation of the protocol so
that the risk of the re-use of any given Responder
Diffie-Hellman public key would differ from the base
probability. Consequently, it is RECOMMENDED that
Responders avoid re-using the same DH key with
multiple Initiators, but because the risk is considered
statistical and not known to be manipulable, the
implementations MAY re-use a key in order to ease
resource-constrained implementations and to increase the
probability of successful communication with legitimate
clients even under an I1 packet storm. In particular,
when it is too expensive to generate enough precomputed R1
packets to supply each potential Initiator with a
different DH key, the Responder MAY send the same DH key
to several Initiators, thereby creating the possibility of
multiple legitimate Initiators ending up using the same
Responder-side public key. However, as soon as the
Responder knows that it will use a particular DH key, it
SHOULD stop offering it. This design is aimed to allow
resource-constrained Responders to offer services under I1
packet storms and to simultaneously make the probability
of DH key re-use both statistical and as low as possible.
</t>
<t>
If the Responder uses the same DH keypair for multiple
handshakes, it must take care to avoid small subgroup
attacks <xref target="RFC2785" />. To avoid these
attacks, when receiving the I2 message, the Responder
SHOULD validate the Initiators DH public key as described
in <xref target="RFC2785" /> Section 3.1. In case the
validation fails, the Responder MUST NOT generate a DH
shared key and MUST silently abort the HIP BEX.
</t>
<t>
The HIP_CIPHER contains the encryption algorithms
supported by the Responder to encrypt the contents of the
ENCRYPTED parameter, in the order of preference. All
implementations MUST support AES <xref target="RFC3602"
/>.
</t>
<t>
The HIT_SUITE_LIST parameter is an ordered list of the
Responder's preferred and supported HIT Suites. The list
allows the Initiator to determine whether its own source
HIT matches any suite supported by the Responder.
</t>
<t>
The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED
parameters contain data that the sender wants to receive
unmodified in the corresponding response packet in the
ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED parameter.
The R1 packet may contain zero or more
ECHO_REQUEST_UNSIGNED parameters as described in Section
<xref target="sec-echo-request-unsigned" />.
</t>
<t>
The TRANSPORT_FORMAT_LIST parameter is an ordered list of
the Responder's preferred and supported transport format
types. The list allows the Initiator and the Responder
to agree on a common type for payload protection.
This parameter is described in
<xref target="transport_format_list"/>.
</t>
<t>
The signature is calculated over the whole HIP packet
as described in <xref
target="HIP_SIGNATURE_2" />. This allows the Responder to
use precomputed R1s. The Initiator SHOULD validate this
signature. It MUST check that the Responder's HI
matches with the one expected, if any.
</t>
</section>
<section anchor="I2" title="I2 - the Second HIP Initiator Packet">
<t>The HIP header values for the I2 packet:</t>
<figure>
<artwork>
Header:
Type = 3
SRC HIT = Initiator's HIT
DST HIT = Responder's HIT
IP ( HIP ( [R1_COUNTER,]
SOLUTION,
DIFFIE_HELLMAN,
HIP_CIPHER,
ENCRYPTED { HOST_ID } or HOST_ID,
[ ECHO_RESPONSE_SIGNED ,]
TRANSPORT_FORMAT_LIST,
HIP_MAC,
HIP_SIGNATURE
<, ECHO_RESPONSE_UNSIGNED>i ) )
</artwork>
</figure>
<t>
Valid control bits: A
</t>
<t>
The HITs used MUST match the ones used in the R1.
</t>
<t>
If the Initiator's HI is an anonymous one, the A control
bit MUST be set.
</t>
<t>
If present in the I1 packet, the Initiator MUST include an
unmodified copy of the R1_COUNTER parameter received in
the corresponding R1 packet into the I2 packet.
</t>
<t>
The Solution contains the Random #I from R1 and the
computed #J. The low-order #K bits of the RHASH(I | ... |
J) MUST be zero.
</t>
<t>
The Diffie-Hellman value is ephemeral. If precomputed, a
scavenger process should clean up unused Diffie-Hellman
values. The Responder MAY re-use Diffie-Hellman values
under some conditions as specified in <xref target="R1" />.
</t>
<t>
The HIP_CIPHER contains the single encryption
suite selected by the Initiator, that it uses to
encrypt the ENCRYPTED parameters. The chosen cipher MUST
correspond to one of the ciphers offered by the Responder
in the R1. All implementations MUST support AES
<xref target="RFC3602" />.
</t>
<t>
The Initiator's HI MAY be encrypted using the
HIP_CIPHER encryption algorithm. The keying material
is derived from the Diffie-Hellman exchanged as defined in
<xref target="keymat" />.
</t>
<t>
The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain
the unmodified Opaque data copied from the corresponding
echo request parameter(s).
</t>
<t>
The TRANSPORT_FORMAT_LIST contains the single transport
format type selected by the Initiator. The chosen type MUST
correspond to one of the types offered by the Responder
in the R1. Currently, the only transport format defined
is the ESP transport format
(<xref target="I-D.ietf-hip-rfc5202-bis" />).
</t>
<t>
The HMAC value in the HIP_MAC parameter is calculated over
the whole HIP packet, excluding any parameters after the
HIP_MAC, as described in <xref target="hmac-processing"
/>. The Responder MUST validate the HIP_MAC.
</t>
<t>
The signature is calculated over the whole HIP packet,
excluding any parameters after the HIP_SIGNATURE, as
described in <xref target="hip-signature" />. The
Responder MUST validate this signature. The Responder uses
the HI in the packet or a HI acquired by some other
means for verifying the signature.
</t>
</section>
<section anchor="R2" title="R2 - the Second HIP Responder Packet">
<t>The HIP header values for the R2 packet:</t>
<figure>
<artwork>
Header:
Packet Type = 4
SRC HIT = Responder's HIT
DST HIT = Initiator's HIT
IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) )
</artwork>
</figure>
<t>Valid control bits: none</t>
<t>
The HIP_MAC_2 is calculated over the whole HIP packet,
with Responder's HOST_ID parameter concatenated with the
HIP packet. The HOST_ID parameter is removed after the
HMAC calculation. The procedure is described in <xref
target="hmac-processing" />.
</t>
<t>
The signature is calculated over the whole HIP packet.
</t>
<t>
The Initiator MUST validate both the HIP_MAC and the signature.
</t>
</section>
<section anchor="UPDATE" title="UPDATE - the HIP Update Packet">
<t>The HIP header values for the UPDATE packet:</t>
<figure>
<artwork>
Header:
Packet Type = 16
SRC HIT = Sender's HIT
DST HIT = Recipient's HIT
IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) )
</artwork>
</figure>
<t>Valid control bits: None</t>
<t>
The UPDATE packet contains mandatory HIP_MAC and
HIP_SIGNATURE parameters, and other optional parameters.
</t>
<t>
The UPDATE packet contains zero or one SEQ parameter. The
presence of a SEQ parameter indicates that the receiver
MUST acknowledge the the UPDATE. An UPDATE that does not
contain a SEQ but only an ACK parameter is simply an acknowledgment of a
previous UPDATE and itself MUST NOT be acknowledged by a
separate ACK parameter.
Such UPDATE packets containing only an ACK parameter
do not require processing in relative order to other UPDATE packets.
An UPDATE packet without either a SEQ or an ACK parameter
is invalid; such unacknowledged updates MUST instead
use a NOTIFY packet.
</t>
<t>
An UPDATE packet contains zero or one ACK parameters. The
ACK parameter echoes the SEQ sequence number of the UPDATE
packet being ACKed. A host MAY choose to acknowledge more than one
UPDATE packet at a time; e.g., the ACK parameter may contain the last
two SEQ values received, for resilience against packet loss. ACK
values are not cumulative; each received unique SEQ value
requires at least one corresponding ACK value in reply.
Received ACK parameters that are redundant are ignored. Hosts MUST
implement the processing of ACK parameters with multiple SEQ numbers
even if they do not implement sending ACK parameters with multiple
SEQ numbers.
</t>
<t>
The UPDATE packet may contain both a SEQ and an ACK
parameter. In this case, the ACK parameter
is being piggybacked on
an outgoing UPDATE. In general, UPDATEs carrying SEQ
SHOULD be ACKed upon completion of the processing of the
UPDATE. A host MAY choose to hold the UPDATE carrying an ACK
parameter for a short period of time to allow for the possibility of
piggybacking the ACK parameter, in a manner similar to TCP
delayed acknowledgments.
</t>
<t>
A sender MAY choose to forego reliable transmission of a
particular UPDATE (e.g., it becomes overcome by events).
The semantics are such that the receiver MUST acknowledge
the UPDATE, but the sender MAY choose to not care about
receiving the ACK parameter.
</t>
<t>
UPDATEs MAY be retransmitted without incrementing SEQ. If
the same subset of parameters is included in multiple
UPDATEs with different SEQs, the host MUST ensure that the
receiver's processing of the parameters multiple times will
not result in a protocol error.
</t>
</section>
<section title="NOTIFY - the HIP Notify Packet">
<t>
The NOTIFY packet MAY be
used to provide information to a peer. Typically, NOTIFY
is used to indicate some type of protocol error or
negotiation failure. NOTIFY packets are unacknowledged.
The receiver can handle the packet only as informational,
and SHOULD NOT change its HIP state (see <xref target="states"
/>) based purely on a received NOTIFY packet.
</t>
<t>The HIP header values for the NOTIFY packet:</t>
<figure>
<artwork>
Header:
Packet Type = 17
SRC HIT = Sender's HIT
DST HIT = Recipient's HIT, or zero if unknown
IP ( HIP (<NOTIFICATION>i, [HOST_ID, ] HIP_SIGNATURE) )
</artwork>
</figure>
<t>Valid control bits: None</t>
<t>
The NOTIFY packet is used to carry one or more NOTIFICATION
parameters.
</t>
</section>
<section anchor="CLOSE"
title="CLOSE - the HIP Association Closing Packet">
<t>The HIP header values for the CLOSE packet:</t>
<figure>
<artwork>
Header:
Packet Type = 18
SRC HIT = Sender's HIT
DST HIT = Recipient's HIT
IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) )
</artwork>
</figure>
<t>Valid control bits: none</t>
<t>
The sender MUST include an ECHO_REQUEST_SIGNED used to
validate CLOSE_ACK received in response, and both a
HIP_MAC and a signature (calculated over the whole HIP
packet).
</t>
<t>
The receiver peer MUST reply with a
CLOSE_ACK containing an ECHO_RESPONSE_SIGNED
corresponding to the received ECHO_REQUEST_SIGNED.
</t>
</section>
<section anchor="CLOSE_ACK"
title="CLOSE_ACK - the HIP Closing Acknowledgment Packet">
<t>
The HIP header values for the CLOSE_ACK packet:
</t>
<figure>
<artwork>
Header:
Packet Type = 19
SRC HIT = Sender's HIT
DST HIT = Recipient's HIT
IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) )
</artwork>
</figure>
<t>Valid control bits: none</t>
<t>
The sender MUST include both an HMAC and signature
(calculated over the whole HIP packet).
</t>
<t>
The receiver peer MUST validate the ECHO_RESPONSE_SIGNED
and validate both the HIP_MAC and the signature if the
receiver has state for a HIP association.
</t>
</section>
</section>
<section anchor="ICMP" title="ICMP Messages">
<t>
When a HIP implementation detects a problem with an incoming
packet, and it either cannot determine the identity of the
sender of the packet or does not have any existing HIP
association with the sender of the packet, it MAY respond
with an ICMP packet. Any such replies MUST be rate-limited
as described in <xref target="RFC4443" />. In most cases,
the ICMP packet has the Parameter Problem type (12 for
ICMPv4, 4 for ICMPv6), with the Pointer field pointing to the
field that caused the ICMP message to be generated.
</t>
<section title="Invalid Version">
<t>
If a HIP implementation receives a HIP packet that has an
unrecognized HIP version number, it SHOULD respond,
rate-limited, with an ICMP packet with type Parameter
Problem, with the Pointer pointing to the Version/RES. byte in the
HIP header.
</t>
</section>
<section
title="Other Problems with the HIP Header and Packet Structure">
<t>
If a HIP implementation receives a HIP packet that has
other unrecoverable problems in the header or packet
format, it MAY respond, rate-limited, with an ICMP packet
with type Parameter Problem, the Pointer pointing to the
field that failed to pass the format checks. However, an
implementation MUST NOT send an ICMP message if the
checksum fails; instead, it MUST silently drop the packet.
</t>
</section>
<section title="Invalid Puzzle Solution">
<t>
If a HIP implementation receives an I2 packet that has an
invalid puzzle solution, the behavior depends on the
underlying version of IP. If IPv6 is used, the
implementation SHOULD respond with an ICMP packet with type
Parameter Problem, the Pointer pointing to the beginning of
the Puzzle solution #J field in the SOLUTION payload in the
HIP message.
</t>
<t>
If IPv4 is used, the implementation MAY respond with an
ICMP packet with the type Parameter Problem, copying enough
of bytes from the I2 message so that the SOLUTION parameter
fits into the ICMP message, the Pointer pointing to the
beginning of the Puzzle solution #J field, as in the IPv6
case. Note, however, that the resulting ICMPv4 message
exceeds the typical ICMPv4 message size as defined in <xref
target="RFC0792" />.
</t>
</section>
<section anchor="non-existing-hip" title="Non-Existing HIP Association">
<t>
If a HIP implementation receives a CLOSE or UPDATE packet,
or any other packet whose handling requires an existing
association, that has either a Receiver or Sender HIT that
does not match with any existing HIP association, the
implementation MAY respond, rate-limited, with an ICMP
packet with the type Parameter Problem. The Pointer of the
ICMP Parameter Problem packet is set pointing to the
beginning of the first HIT that does not match.
</t>
<t>
A host MUST NOT reply with such an ICMP if it receives any
of the following messages: I1, R2, I2, R2, and NOTIFY
packet. When introducing new packet types, a
specification SHOULD define the appropriate rules for
sending or not sending this kind of ICMP reply.
</t>
</section>
</section>
</section>
<section anchor="packet_processing" title="Packet Processing">
<t>
Each host is assumed to have a single HIP protocol
implementation that manages the host's HIP associations and
handles requests for new ones. Each HIP association is
governed by a conceptual state machine, with states defined
above in <xref target="state-machine" />. The HIP
implementation can simultaneously maintain HIP associations
with more than one host. Furthermore, the HIP implementation
may have more than one active HIP association with another
host; in this case, HIP associations are distinguished by their
respective HITs. It is not possible to have more than one HIP
association between any given pair of HITs. Consequently, the
only way for two hosts to have more than one parallel
association is to use different HITs, at least at one end.
</t>
<t>
The processing of packets depends on the state of the HIP
association(s) with respect to the authenticated or apparent
originator of the packet. A HIP implementation determines
whether it has an active association with the originator of the
packet based on the HITs. In the case of user data carried in
a specific transport format, the transport format document
specifies how the incoming packets are matched with the active
associations.
</t>
<section title="Processing Outgoing Application Data">
<t>
In a HIP host, an application can send application-level data
using an identifier specified via the underlying API. The
API can be a backwards-compatible API (see <xref
target="RFC5338" />), using identifiers that look similar to
IP addresses, or a completely new API, providing enhanced
services related to Host Identities. Depending on the HIP
implementation, the identifier provided to the application
may be different; for example, it can be a HIT or an IP
address.
</t>
<t>
The exact format and method for transferring the user data from the
source HIP host to the destination HIP host is defined in the
corresponding transport format document. The actual data is
transferred in the network using the appropriate source and
destination IP addresses.
</t>
<t>
In this document, conceptual processing rules are defined
only for the base case where both hosts have only single
usable IP addresses; the multi-address multi-homing case is
specified separately.
</t>
<t>
The following conceptual algorithm describes the steps that
are required for handling outgoing datagrams destined to a
HIT.
<list style="numbers">
<t>
If the datagram has a specified source address, it MUST
be a HIT. If it is not, the implementation MAY replace
the source address with a HIT. Otherwise, it MUST drop
the packet.
</t>
<t>
If the datagram has an unspecified source address, the
implementation MUST choose a suitable source HIT for the
datagram. Selecting the source HIT is subject to local
policy.
</t>
<t>
If there is no active HIP association with the given
<source, destination> HIT pair, one MUST be created
by running the base exchange. While waiting for the base
exchange to complete, the implementation SHOULD queue at
least one user data packet per HIP association to be formed,
and it MAY queue more than one.
</t>
<t>
Once there is an active HIP association for the given
<source, destination> HIT pair, the outgoing
datagram is passed to transport handling. The possible
transport formats are defined in separate documents, of
which the ESP transport format for HIP is mandatory for
all HIP implementations.
</t>
<t>
Before sending the packet, the HITs in the datagram are
replaced with suitable IP addresses. For IPv6, the rules
defined in <xref target="RFC6724" /> SHOULD be followed.
Note that this HIT-to-IP-address conversion step MAY also
be performed at some other point in the stack, e.g.,
before wrapping the packet into the output format.
</t>
</list>
</t>
</section>
<section title="Processing Incoming Application Data">
<t>
The following conceptual algorithm describes the incoming
datagram handling when HITs are used at the receiving host as
application-level identifiers. More detailed steps for
processing packets are defined in corresponding transport
format documents.
</t>
<t>
<list style="numbers">
<t>
The incoming datagram is mapped to an existing HIP
association, typically using some information from the
packet. For example, such mapping may be based on the ESP
Security Parameter Index (SPI).
</t>
<t>
The specific transport format is unwrapped, in a way
depending on the transport format, yielding a packet that
looks like a standard (unencrypted) IP packet. If
possible, this step SHOULD also verify that the packet
was indeed (once) sent by the remote HIP host, as
identified by the HIP association.
<vspace blankLines='1' />
Depending on the used transport mode, the verification
method can vary. While the HI (as well as HIT) is used as
the higher-layer identifier, the verification method has
to verify that the data packet was sent by the correct
node identity and that the actual identity maps to this
particular HIT. When using ESP transport format <xref
target="I-D.ietf-hip-rfc5202-bis" />, the verification
is done using the SPI value in the data packet to find
the corresponding SA with associated HIT and key, and
decrypting the packet with that associated key.
</t>
<t>
The IP addresses in the datagram are replaced with the
HITs associated with the HIP association. Note that this
IP-address-to-HIT conversion step MAY also be performed
at some other point in the stack.
</t>
<t>
The datagram is delivered to the upper layer (e.g., UDP
or TCP). When demultiplexing the datagram, the right
upper-layer socket is selected based on the HITs.
</t>
</list>
</t>
</section>
<section title="Solving the Puzzle">
<t>
This subsection describes the details for solving the puzzle.
</t>
<t>
In the R1 packet, the values #I and #K are sent in network
byte order. Similarly, in the I2 packet, the values #I and #J
are sent in network byte order. The hash is created by
concatenating, in network byte order, the following data, in
the following order and using the RHASH algorithm:
<list>
<t>
n-bit random value #I (where n is RHASH_len), in network
byte order, as appearing in the R1 and I2 packets.
</t>
<t>
128-bit Initiator's HIT, in network byte order, as
appearing in the HIP Payload in the R1 and I2 packets.
</t>
<t>
128-bit Responder's HIT, in network byte order, as
appearing in the HIP Payload in the R1 and I2 packets.
</t>
<t>
n-bit random value #J (where n is RHASH_len), in
network byte order, as appearing in the I2 packet.
</t>
</list>
In a valid response puzzle, the #K low-order bits
of the resulting RHASH digest MUST be zero.
</t>
<t>
Notes:
<list>
<t>
i) The length of the data to be hashed is variable
depending on the output length of the Responder's hash
function RHASH.
</t>
<t>
ii) All the data in the hash input MUST be in network
byte order.
</t>
<t>
iii) The order of the Initiator's and Responder's HITs
are different in the R1 and I2 packets; see <xref
target="ssec-payload" />. Care must be taken to copy the
values in the right order to the hash input.
</t>
<t>
iv) For a puzzle #I, there may exist multiple valid
puzzle solutions #J.
</t>
</list>
</t>
<t>
The following procedure describes the processing steps
involved, assuming that the Responder chooses to
precompute the R1 packets:
</t>
<t>
<list style="hanging">
<t hangText="Precomputation by the Responder:">
<vspace blankLines="0" />
Sets up the puzzle difficulty #K.
<vspace blankLines="0" />
Creates a signed R1 and caches it.
<vspace blankLines="0" />
</t>
<t hangText="Responder:">
<vspace blankLines="0" />
Selects a suitable cached R1.
<vspace blankLines="0" />
Generates a random number #I.
<vspace blankLines="0" />
Sends #I and #K in an R1.
<vspace blankLines="0" />
Saves #I and #K for a Delta time.
<vspace blankLines="0" />
</t>
<t hangText="Initiator:">
<vspace blankLines="0" />
Generates repeated attempts to solve the puzzle
until a matching #J is found:
<vspace blankLines="0" />
Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0
<vspace blankLines="0" />
Sends #I and #J in an I2.
<vspace blankLines="1" />
</t>
<t hangText="Responder:">
<vspace blankLines="0" />
Verifies that the received #I is a saved one.
<vspace blankLines="0" />
Finds the right #K based on #I.
<vspace blankLines="0" />
Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K )
<vspace blankLines="0" />
Rejects if V != 0
<vspace blankLines="0" />
Accept if V == 0
<vspace blankLines="0" />
</t>
</list>
</t>
</section>
<section title="HIP_MAC and SIGNATURE Calculation and Verification">
<t>
The following subsections define the actions for processing
HIP_MAC, HIP_MAC_2, HIP_SIGNATURE and HIP_SIGNATURE_2
parameters.
The HIP_MAC_2 parameter is contained in the R2 packet. The
HIP_SIGNATURE_2 parameter is contained in the R1 packet. The
HIP_SIGNATURE and HIP_MAC parameter are contained in other
HIP packets.
</t>
<section anchor="hmac-processing" title="HMAC Calculation">
<t>
The HMAC uses RHASH as underlying hash function. The type
of RHASH depends on the HIT Suite of the Responder. Hence,
HMAC-SHA-256 <xref target="RFC4868" /> is used for HIT Suite
RSA/DSA/SHA-256, HMAC-SHA-1 <xref target="RFC2404" /> is used
for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384
<xref target="RFC4868" /> for HIT Suite ECDSA/SHA-384.
</t>
<t>
The following process applies both to the HIP_MAC and
HIP_MAC_2 parameters. When processing HIP_MAC_2, the
difference is that the HIP_MAC calculation includes a
pseudo HOST_ID field containing the Responder's information
as sent in the R1 packet earlier.
</t>
<t>
Both the Initiator and the Responder should take some care
when verifying or calculating the HIP_MAC_2. Specifically,
the Initiator has to preserve the HOST_ID exactly as it
was received in the R1 packet until it receives the
HIP_MAC_2 in the R2 packet.
</t>
<t>
The scope of the calculation for HIP_MAC is:
</t>
<figure>
<artwork>
HMAC: { HIP header | [ Parameters ] }
</artwork>
</figure>
<t>
where Parameters include all HIP parameters of the
packet that is being calculated with Type values ranging from 1
to (HIP_MAC's Type value - 1) and exclude parameters with
Type values greater or equal to HIP_MAC's Type value.
</t>
<t>
During HIP_MAC calculation, the following applies:
<list style="symbols">
<t>
In the HIP header, the Checksum field is set to zero.
</t>
<t>
In the HIP header, the Header Length field value is
calculated to the beginning of the HIP_MAC parameter.
</t>
</list>
</t>
<t>
Parameter order is described in <xref target="tlvformat"
/>.
</t>
<t>
The scope of the calculation for HIP_MAC_2 is:
</t>
<figure>
<artwork>
HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID }
</artwork>
</figure>
<t>
where Parameters include all HIP parameters for the packet
that is being calculated with Type values from 1 to
(HIP_MAC_2's Type value - 1) and exclude parameters with
Type values greater or equal to HIP_MAC_2's Type value.
</t>
<t>
During HIP_MAC_2 calculation, the following applies:
<list style="symbols">
<t>
In the HIP header, the Checksum field is set to zero.
</t>
<t>
In the HIP header, the Header Length field value is
calculated to the beginning of the HIP_MAC_2 parameter
and increased by the length of the concatenated HOST_ID
parameter length (including type and length fields).
</t>
<t>
HOST_ID parameter is exactly in the form it was received
in the R1 packet from the Responder.
</t>
</list>
</t>
<t>
Parameter order is described in <xref target="tlvformat"
/>, except that the HOST_ID parameter in this calculation is
added to the end.
</t>
<t>
The HIP_MAC parameter is defined in <xref target="HIP_MAC"
/> and the HIP_MAC_2 parameter in <xref target="HIP_MAC_2"
/>. The HMAC calculation and verification process (the
process applies both to HIP_MAC and HIP_MAC_2 except where
HIP_MAC_2 is mentioned separately) is as follows:
</t>
<t>Packet sender:
<list style="numbers">
<t>
Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE,
HIP_SIGNATURE_2, or any other parameter with greater Type
value than the HIP_MAC parameter has.
</t>
<t>In case of HIP_MAC_2 calculation, add a HOST_ID (Responder)
parameter to the end of the packet.
</t>
<t>
Calculate the Header Length field in the HIP header
including the added HOST_ID parameter in case of HIP_MAC_2.
</t>
<t>
Compute the HMAC using either HIP-gl or HIP-lg integrity
key retrieved from KEYMAT as defined in <xref
target="keymat" />.
</t>
<t>
In case of HIP_MAC_2, remove the HOST_ID parameter from the
packet.
</t>
<t>
Add the HIP_MAC parameter to the packet and any
parameter with greater Type value than the HIP_MAC's
(HIP_MAC_2's) that may follow, including possible
HIP_SIGNATURE or HIP_SIGNATURE_2 parameters
</t>
<t>
Recalculate the Length field in the HIP header.
</t>
</list>
</t>
<t>Packet receiver:
<list style="numbers">
<t>Verify the HIP header Length field.</t>
<t>
Remove the HIP_MAC or HIP_MAC_2 parameter, as well as
all other parameters that follow it with greater Type
value including possible HIP_SIGNATURE or
HIP_SIGNATURE_2 fields, saving the contents if they
are needed later.
</t>
<t>
In case of HIP_MAC_2, build and add a HOST_ID parameter
(with Responder information) to the packet. The HOST_ID
parameter should be identical to the one previously
received from the Responder.
</t>
<t>
Recalculate the HIP packet length in the HIP header and
clear the Checksum field (set it to all zeros). In
case of HIP_MAC_2, the length is calculated with the
added HOST_ID parameter.
</t>
<t>
Compute the HMAC using either HIP-gl or HIP-lg
integrity key as defined in <xref target="keymat" />
and verify it against the received HMAC.
</t>
<t>
Set Checksum and Header Length field in the HIP header
to original values. Note that the checksum and length
fields contain incorrect values after this step.
</t>
<t>
In case of HIP_MAC_2, remove the HOST_ID parameter from
the packet before further processing.
</t>
</list>
</t>
</section>
<section anchor="sig-processing" title="Signature Calculation">
<t>
The following process applies both to the HIP_SIGNATURE
and HIP_SIGNATURE_2 parameters. When processing the
HIP_SIGNATURE_2, the only difference is that instead of
the HIP_SIGNATURE parameter, the HIP_SIGNATURE_2 parameter
is used, and the Initiator's HIT and PUZZLE Opaque and
Random #I fields are cleared (set to all zeros) before
computing the signature. The HIP_SIGNATURE parameter is
defined in <xref target="hip-signature" /> and the
HIP_SIGNATURE_2 parameter in <xref
target="HIP_SIGNATURE_2" />.
</t>
<t>
The scope of the calculation for HIP_SIGNATURE and
HIP_SIGNATURE_2 is:
</t>
<figure>
<artwork>
HIP_SIGNATURE: { HIP header | [ Parameters ] }
</artwork>
</figure>
<t>
where Parameters include all HIP parameters for the packet
that is being calculated with Type values from 1 to
(HIP_SIGNATURE's Type value - 1).
</t>
<t>
During signature calculation, the following applies:
<list style="symbols">
<t>
In the HIP header, the Checksum field is set to zero.
</t>
<t>
In the HIP header, the Header Length field value is
calculated to the beginning of the HIP_SIGNATURE
parameter.
</t>
</list>
</t>
<t>
The parameter order is described in <xref target="tlvformat" />.
</t>
<figure>
<artwork>
HIP_SIGNATURE_2: { HIP header | [ Parameters ] }
</artwork>
</figure>
<t>
where Parameters include all HIP parameters for the packet
that is being calculated with Type values ranging from 1
to (HIP_SIGNATURE_2's Type value - 1).
</t>
<t>
During signature calculation, the following apply:
<list style="symbols">
<t>
In the HIP header, the Initiator's HIT field and
Checksum fields are set to zero.
</t>
<t>
In the HIP header, the Header Length field value is
calculated to the beginning of the HIP_SIGNATURE_2
parameter.
</t>
<t>
PUZZLE parameter's Opaque and Random #I fields are set
to zero.
</t>
</list>
</t>
<t>
Parameter order is described in <xref target="tlvformat" />.
</t>
<t>
The signature calculation and verification process (the
process applies both to HIP_SIGNATURE and HIP_SIGNATURE_2
except in the case where HIP_SIGNATURE_2 is separately
mentioned) is as follows:
</t>
<t>Packet sender:
<list style="numbers">
<t>
Create the HIP packet without the HIP_SIGNATURE
parameter or any other parameters that follow the
HIP_SIGNATURE parameter.
</t>
<t>
Calculate the Length field and zero the Checksum field
in the HIP header. In case of HIP_SIGNATURE_2, set
Initiator's HIT field in the HIP header as well as
PUZZLE parameter's Opaque and Random #I fields to
zero.
</t>
<t>
Compute the signature using the private key
corresponding to the Host Identifier (public key).
</t>
<t>
Add the HIP_SIGNATURE parameter to the packet.
</t>
<t>
Add any parameters that follow the HIP_SIGNATURE
parameter.
</t>
<t>
Recalculate the Length field in the HIP header, and
calculate the Checksum field.
</t>
</list>
</t>
<t>Packet receiver:
<list style="numbers">
<t>Verify the HIP header Length field and checksum.</t>
<t>
Save the contents of the HIP_SIGNATURE parameter and
any other parameters following the HIP_SIGNATURE parameter
and remove them from the packet.
</t>
<t>
Recalculate the HIP packet Length in the HIP header and
clear the Checksum field (set it to all zeros). In
case of HIP_SIGNATURE_2, set Initiator's HIT field in
the HIP header as well as PUZZLE parameter's Opaque and
Random #I fields to zero.
</t>
<t>
Compute the signature and verify it against the
received signature using the packet sender's Host
Identity (public key).
</t>
<t>
Restore the original packet by adding removed
parameters (in step 2) and resetting the values that
were set to zero (in step 3).
</t>
</list>
</t>
<t>
The verification can use either the HI received from a HIP
packet, the HI from a DNS query, if the FQDN has been
received in the HOST_ID packet or one received by some
other means.
</t>
</section>
</section>
<section anchor="keymat" title="HIP KEYMAT Generation">
<t>
HIP keying material is derived from the Diffie-Hellman
session key, Kij, produced during the HIP base exchange
(see <xref target="auth_dh" />). The Initiator has Kij during
the creation of the I2 packet, and the Responder has Kij once
it receives the I2 packet. This is why I2 can already
contain encrypted information.
</t>
<t>
The KEYMAT is derived by feeding Kij into the key derivation
function defined by the DH Group ID. Currently
the only key derivation function defined in this document is
the Hash-based Key Derivation Function (HKDF) <xref
target="RFC5869"/> using the RHASH hash function. Other
documents may define new DH Group IDs and
corresponding key distribution functions.
</t>
<t>
In the following we provide the details for deriving the
keying material using HKDF.
</t>
<figure>
<artwork>
where
info = sort(HIT-I | HIT-R)
salt = #I | #J
</artwork>
</figure>
<t>
Sort(HIT-I | HIT-R) is defined as the network byte order
concatenation of the two HITs, with the smaller HIT preceding
the larger HIT, resulting from the numeric comparison of the
two HITs interpreted as positive (unsigned) 128-bit integers
in network byte order. The #I and #J values are from the
puzzle and its solution that were exchanged in R1 and I2
messages when this HIP association was set up. Both hosts
have to store #I and #J values for the HIP
association for future use.
</t>
<t>
The initial keys are drawn sequentially in the order that is
determined by the numeric comparison of the two HITs, with
comparison method described in the previous paragraph.
HOST_g denotes the host with the greater HIT value, and
HOST_l the host with the lower HIT value.
</t>
<t>The drawing order for the four initial keys is as follows:
<list>
<t>HIP-gl encryption key for HOST_g's ENCRYPTED parameter</t>
<t>HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP
packets</t>
<t>HIP-lg encryption key for HOST_l's ENCRYPTED
parameter</t>
<t>HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP
packets</t>
</list>
</t>
<t>The number of bits drawn for a given algorithm is the
"natural" size of the keys. For the mandatory algorithms, the
following sizes apply:
<list style="hanging">
<t hangText="AES">128 or 256 bits</t>
<t hangText="SHA-1">160 bits</t>
<t hangText="SHA-256">256 bits</t>
<t hangText="SHA-384">384 bits</t>
<t hangText="NULL">0 bits</t>
</list>
</t>
<t>
If other key sizes are used, they MUST be treated as different
encryption algorithms and defined separately.
</t>
</section>
<section title="Initiation of a HIP Base Exchange">
<t>
An implementation may originate a HIP base exchange to another
host based on a local policy decision, usually triggered by
an application datagram, in much the same way that an IPsec
IKE key exchange can dynamically create a Security
Association. Alternatively, a system may initiate a HIP
exchange if it has rebooted or timed out, or otherwise lost
its HIP state, as described in <xref target="reboot" />.
</t>
<t>
The implementation prepares an I1 packet and sends it to the
IP address that corresponds to the peer host. The IP
address of the peer host may be obtained via conventional
mechanisms, such as DNS lookup. The I1 packet contents are
specified in <xref target="I1" />. The selection of which
source or destination Host Identity to use, if a Initiator
or Responder has more than one to choose from, is typically
a policy decision.
</t>
<t>
The following steps define the conceptual processing rules for
initiating a HIP base exchange:
<list style="numbers">
<t>
The Initiator receives one or more of the Responder's
HITs and one or more addresses either from a DNS lookup
of the Responder's FQDN, from some other repository, or
from a local database. If the Initiator does not know
the Responder's HIT, it may attempt opportunistic mode
by using NULL (all zeros) as the Responder's HIT (see
also <xref target="op_mode"> "HIP Opportunistic Mode"
</xref>). If the Initiator can choose from multiple
Responder HITs, it selects a HIT for which the Initiator
supports the HIT Suite.
</t>
<t>
The Initiator sends an I1 packet to one of the
Responder's addresses. The selection of which address
to use is a local policy decision.
</t>
<t>
The Initiator includes the DH_GROUP_LIST in the I1
packet. The selection and order of DH Group IDs in the
DH_GROUP_LIST MUST be stored by the Initiator because
this list is needed for later R1 processing. In most
cases, the preferences regarding the DH Groups will be
static, so no per-association storage is necessary.
</t>
<t>
Upon sending an I1 packet, the sender transitions to
state I1-SENT, starts a timer for which the timeout
value SHOULD be larger than the worst-case anticipated
RTT. The sender SHOULD also increment the trial counter
associated with the I1.
</t>
<t>
Upon timeout, the sender SHOULD retransmit the I1 packet
and restart the timer, up to a maximum of I1_RETRIES_MAX
tries.
</t>
</list>
</t>
<section anchor="multi-i1" title="Sending Multiple I1 Packets in Parallel">
<t>
For the sake of minimizing the association establishment
latency, an implementation MAY send the same I1 packet to
more than one of the Responder's addresses. However, it
MUST NOT send to more than three (3) Responder addresses in
parallel. Furthermore, upon timeout, the implementation
MUST refrain from sending the same I1 packet to multiple
addresses. That is, if it retries to initialize the
connection after a timeout, it MUST NOT send the I1 packet
to more than one destination address. These limitations
are placed in order to avoid congestion of the network,
and potential DoS attacks that might occur, e.g., because
someone's claim to have hundreds or thousands of addresses
could generate a huge number of I1 packets from the
Initiator.
</t>
<t>
As the Responder is not guaranteed to distinguish the
duplicate I1 packets it receives at several of its addresses
(because it avoids storing states when it answers back an
R1 packet), the Initiator may receive several duplicate R1 packets.
</t>
<t>
The Initiator SHOULD then select the initial preferred
destination address using the source address of the
selected received R1, and use the preferred address as a
source address for the I2 packet. Processing rules for
received R1s are discussed in <xref target="inr1" />.
</t>
</section>
<section title="Processing Incoming ICMP Protocol Unreachable
Messages">
<t>
A host may receive an ICMP 'Destination Protocol
Unreachable' message as a response to sending a HIP I1
packet. Such a packet may be an indication that the peer
does not support HIP, or it may be an attempt to launch an
attack by making the Initiator believe that the Responder
does not support HIP.
</t>
<t>
When a system receives an ICMP 'Destination Protocol
Unreachable' message while it is waiting for an R1 packet,
it MUST NOT terminate waiting. It MAY continue as if it
had not received the ICMP message, and send a few more I1
packets. Alternatively, it MAY take the ICMP message as a
hint that the peer most probably does not support HIP, and
return to state UNASSOCIATED earlier than otherwise.
However, at minimum, it MUST continue waiting for an R1
packet for a reasonable time before returning to
UNASSOCIATED.
</t>
</section>
</section>
<section anchor="i1process" title="Processing Incoming I1 Packets">
<t>
An implementation SHOULD reply to an I1 with an R1 packet,
unless the implementation is unable or unwilling to set up a
HIP association. If the implementation is unable to set up
a HIP association, the host SHOULD send an ICMP Destination
Protocol Unreachable, Administratively Prohibited, message
to the I1 packet source IP address. If the implementation
is unwilling to set up a HIP association, the host MAY
ignore the I1 packet. This latter case may occur during a
DoS attack such as an I1 packet flood.
</t>
<t>
The implementation SHOULD be able to handle a storm of received
I1 packets, discarding those with common content that arrive
within a small time delta.
</t>
<t>
A spoofed I1 packet can result in an R1 attack on a system.
An R1 packet sender MUST have a mechanism to rate-limit R1
packets sent to an address.
</t>
<t>
It is RECOMMENDED that the HIP state machine does not transition
upon sending an R1 packet.
</t>
<t>
The following steps define the conceptual processing rules
for responding to an I1 packet:
<list style="numbers">
<t>
The Responder MUST check that the Responder's HIT in the
received I1 packet is either one of its own HITs or NULL.
Otherwise it must drop the packet.
</t>
<t>
If the Responder is in ESTABLISHED state, the Responder
MAY respond to this with an R1 packet, prepare to drop
an existing HIP security association with the peer, and
stay at ESTABLISHED state.
</t>
<t>
If the Responder is in I1-SENT state, it MUST make a
comparison between the sender's HIT and its own (i.e.,
the receiver's) HIT. If the sender's HIT is greater than
its own HIT, it should drop the I1 packet and stay at I1-SENT.
If the sender's HIT is smaller than its own HIT, it
SHOULD send the R1 packet and stay at I1-SENT. The HIT comparison
is performed as defined in <xref target="keymat" />.
</t>
<t>
If the implementation chooses to respond to the I1
packet with an R1 packet, it creates a new R1 or selects
a precomputed R1 according to the format described in
<xref target="R1" />. It creates or chooses an R1 that
contains its most preferred DH public value that is also
contained in the DH_GROUP_LIST in the I1 packet. If no
suitable DH Group ID was contained in the DH_GROUP_LIST
in the I1 packet, it sends an R1 with any suitable DH
public key.
</t>
<t>
If the received Responder's HIT in the I1 is NULL, the
Responder selects a HIT with a the same HIT Suite as the
Initiator's HIT. If this HIT Suite is not supported by
the Responder, it SHOULD select a REQUIRED HIT Suite
from <xref target="hit_suite_list"/>, which is currently
RSA/DSA/SHA-256. Other than that, selecting the HIT is a
local policy matter.
</t>
<t>
The responder expresses its supported HIP transport
formats in the TRANSPORT_FORMAT_LIST as described in
<xref target="transport_format_list"/>. The Responder
MUST at least provide one payload transport format type.
</t>
<t>
The Responder sends the R1 packet to the source IP
address of the I1 packet.
</t>
</list>
</t>
<section title="R1 Management">
<t>
All compliant implementations MUST be able to produce R1
packets; even if a device is configured by policy to only
initiate associations, it must be able to process I1s in
case of recovery from loss of state or key exhaustion.
An R1 packet MAY be precomputed. An R1 packet
MAY be reused for time Delta T, which is implementation
dependent, and SHOULD be deprecated and not used once a
valid response I2 packet has been received from an
Initiator. During an I1 message storm, an R1 packet MAY
be re-used beyond this limit. R1 information MUST NOT be
discarded until Delta S after T. Time S is the delay
needed for the last I2 packet to arrive back to the
Responder.
</t>
<t>
Implementations that support multiple DH groups MAY
pre-compute R1 packets for each supported group so that
incoming I1 packets with different DH Group IDs in the
DH_GROUP_LIST can be served quickly.
</t>
<t>
An implementation MAY keep state about received I1 packets
and match the received I2 packets against the state, as
discussed in <xref target="hip-cookie" />.
</t>
</section>
<section title="Handling Malformed Messages">
<t>
If an implementation receives a malformed I1 packet, it
SHOULD NOT respond with a NOTIFY message, as such practice
could open up a potential denial-of-service threat.
Instead, it MAY respond with an ICMP packet, as defined in
<xref target="ICMP" />.
</t>
</section>
</section>
<section anchor="inr1" title="Processing Incoming R1 Packets">
<t>
A system receiving an R1 packet MUST first check to see if
it has sent an I1 packet to the originator of the R1 packet
(i.e., it is in state I1-SENT). If so, it SHOULD process
the R1 as described below, send an I2 packet, and transition to
state I2-SENT, setting a timer to protect the I2 packet. If
the system is in state I2-SENT, it MAY respond to the R1
packet if the R1 packet has a larger R1 generation counter;
if so, it should drop its state due to processing the
previous R1 packet and start over from state I1-SENT. If
the system is in any other state with respect to that host,
the system SHOULD silently drop the R1 packet.
</t>
<t>
When sending multiple I1 packets, an Initiator SHOULD wait for a
small amount of time after the first R1 reception to allow
possibly multiple R1 packets to arrive, and it SHOULD respond to an
R1 packet among the set with the largest R1 generation counter.
</t>
<t>
The following steps define the conceptual processing rules
for responding to an R1 packet:
<list style="numbers">
<t>
A system receiving an R1 MUST first check to see if it
has sent an I1 packet to the originator of the R1 packet
(i.e., it has a HIP association that is in state I1-SENT
and that is associated with the HITs in the R1). Unless
the I1 packet was sent in opportunistic mode (see <xref
target="op_mode" />), the IP addresses in the received
R1 packet SHOULD be ignored by the R1 processing and,
when looking up the
right HIP association, the received R1 packet SHOULD be
matched against the associations using only the HITs.
If a match exists, the system should process the R1
packet as described below.
</t>
<t>
Otherwise, if the system is in any other state than
I1-SENT or I2-SENT with respect to the HITs included in
the R1 packet, it SHOULD silently drop the R1 packet and
remain in the current state.
</t>
<t>
If the HIP association state is I1-SENT or I2-SENT, the
received Initiator's HIT MUST correspond to the HIT used
in the original I1. Also, the Responder's
HIT MUST correspond to the one used in the I1, unless the I1
packet contained a NULL HIT.
</t>
<t>
The system SHOULD validate the R1 signature before
applying further packet processing, according to <xref
target="HIP_SIGNATURE_2" />.
</t>
<t>
If the HIP association state is I1-SENT, and multiple
valid R1 packets are present, the system MUST select
from among the R1 packets with the largest R1 generation
counter.
</t>
<!--TH: Changed the SHOULD in the previous section to MUST
because otherwise, an attacker could replay old R1s
with an outdated HIT_SUITE_LIST and force the
Initiator to abort the connection. -->
<!--TH: Added restart option for the Initiator here. Do we
need to define what an acceptable time span is?-->
<t>
The system MUST check that the Initiator HIT Suite is
contained in the HIT_SUITE_LIST parameter in the R1
packet (i.e., the Initiator's HIT Suite is supported by the
Responder). If the HIT Suite is supported by the
Responder, the system proceeds normally. Otherwise, the
system MAY stay in state I1-sent and restart the BEX by
sending a new I1 packet with an Initiator HIT that is
supported by the Responder and hence is contained in the
HIT_SUITE_LIST in the R1 packet. The system MAY abort
the BEX if no suitable source HIT is available. The
system SHOULD wait for an acceptable time span to allow
further R1 packets with higher R1 generation counters or
different HIT and HIT Suites to arrive before restarting
or aborting the BEX.
</t>
<t>
The system MUST check that the DH Group ID in the
DIFFIE_HELLMAN parameter in the R1 matches the first DH
Suite ID in the Responder's DH_GROUP_LIST in the R1
packet that was also contained in the Initiator's
DH_GROUP_LIST in the I1 packet. If the DH Group ID of
the DIFFIE_HELLMAN parameter does not express the
Responder's best choice, the Initiator can conclude that
the DH_GROUP_LIST in the I1 packet was adversely
modified. In such case, the Initiator MAY send a new I1
packet, however, it SHOULD NOT change its preference in
the DH_GROUP_LIST in the new I1 packet. Alternatively,
the Initiator MAY abort the HIP base exchange.
</t>
<t>
If the HIP association state is I2-SENT, the system MAY
re-enter state I1-SENT and process the received R1 packet
if it has a larger R1 generation counter than the R1
packet responded to previously.
</t>
<t>
The R1 packet may have the A bit set -- in this case,
the system MAY choose to refuse it by dropping the R1
packet and returning to state UNASSOCIATED. The system
SHOULD consider dropping the R1 packet only if it used a
NULL HIT in I1 packet. If the A bit is set, the
Responder's HIT is anonymous and SHOULD NOT be stored
permanently.
</t>
<t>
The system SHOULD attempt to validate the HIT against the
received Host Identity by using the received Host
Identity to construct a HIT and verify that it matches
the Sender's HIT.
</t>
<t>
The system MUST store the received R1 generation counter
for future reference.
</t>
<t>
The system attempts to solve the puzzle in the R1
packet. The system MUST terminate the search after
exceeding the remaining lifetime of the puzzle. If the
puzzle is not successfully solved, the implementation
MAY either resend the I1 packet within the retry bounds or
abandon the HIP base exchange.
</t>
<t>
The system computes standard Diffie-Hellman keying
material according to the public value and Group ID
provided in the DIFFIE_HELLMAN parameter. The
Diffie-Hellman keying material Kij is used for key
extraction as specified in <xref target="keymat" />.
</t>
<t>
The system selects the HIP_CIPHER ID from the choices
presented in the R1 packet and uses the selected values
subsequently when generating and using encryption keys,
and when sending the I2 packet. If the proposed
alternatives are not acceptable to the system, it may
either resend an I1 within the retry bounds or abandon
the HIP base exchange.
</t>
<t>
The system chooses one suitable transport format from
the TRANSPORT_FORMAT_LIST and includes the respective
transport format parameter in the subsequent I2 packet.
</t>
<t>
The system initializes the remaining variables in the
associated state, including Update ID counters.
</t>
<t>
The system prepares and sends an I2 packet, as described in
<xref target="I2" />.
</t>
<t>
The system SHOULD start a timer whose timeout value
SHOULD be larger than the worst-case anticipated RTT,
and MUST increment a trial counter associated with the
I2 packet. The sender SHOULD retransmit the I2 packet
upon a timeout and restart the timer, up to a maximum of
I2_RETRIES_MAX tries.
</t>
<t>
If the system is in state I1-SENT, it SHALL transition
to state I2-SENT. If the system is in any other state,
it remains in the current state.
</t>
</list>
</t>
<section title="Handling of Malformed Messages">
<t>
If an implementation receives a malformed R1 message, it
MUST silently drop the packet. Sending a NOTIFY or ICMP
would not help, as the sender of the R1 packet typically
doesn't have any state. An implementation SHOULD wait for
some more time for a possibly well-formed R1, after which it MAY
try again by sending a new I1 packet.
</t>
</section>
</section>
<section anchor="ini2" title="Processing Incoming I2 Packets">
<t>
Upon receipt of an I2 packet, the system MAY perform initial
checks to determine whether the I2 packet corresponds to a
recent R1 packet that has been sent out, if the Responder
keeps such state. For example, the sender could check
whether the I2 packet is from an address or HIT for which
the Responder has recently received an I1. The R1 packet may
have had Opaque data included that was echoed back in the I2
packet. If the I2 packet is considered to be suspect, it
MAY be silently discarded by the system.
</t>
<t>
Otherwise, the HIP implementation SHOULD process the I2
packet. This includes validation of the puzzle solution,
generating the Diffie-Hellman key, possibly decrypting the
Initiator's Host Identity, verifying the signature, creating
state, and finally sending an R2 packet.
</t>
<t>
The following steps define the conceptual processing rules
for responding to an I2 packet:
<list style="numbers">
<t>
The system MAY perform checks to verify that the I2
packet corresponds to a recently sent R1 packet. Such
checks are implementation dependent. See <xref
target="resp-cookie" /> for a description of an example
implementation.
</t>
<t>
The system MUST check that the Responder's HIT
corresponds to one of its own HITs and MUST drop the
packet otherwise.
</t>
<t>
The system MUST further check that the Initiator's HIT
Suite is supported. The Responder SHOULD silently drop I2 packets
with unsupported Initiator HITs.
</t>
<t>
If the system's state machine is in the R2-SENT state,
the system MAY check if the newly received I2 packet is
similar to the one that triggered moving to R2-SENT. If
so, it MAY retransmit a previously sent R2 packet, reset
the R2-SENT timer, and the state machine stays in
R2-SENT.
</t>
<t>
If the system's state machine is in the I2-SENT state,
the system MUST make a comparison between its local and
sender's HITs (similarly as in <xref target="keymat"
/>). If the local HIT is smaller than the sender's HIT,
it should drop the I2 packet, use the peer
Diffie-Hellman key and nonce #I from the R1 packet
received earlier, and get the local Diffie-Hellman key
and nonce #J from the I2 packet sent to the peer earlier.
Otherwise, the system should process the received I2
packet and drop any previously derived Diffie-Hellman
keying material Kij it might have formed upon sending
the I2 packet previously. The peer Diffie-Hellman key
and the nonce #J are taken from the just arrived I2
packet. The local Diffie-Hellman key and the nonce I
are the ones that were sent earlier in the R1 packet.
</t>
<t>
If the system's state machine is in the I1-SENT state,
and the HITs in the I2 packet match those used in the
previously sent I1 packet, the system uses this received
I2 packet as the basis for the HIP association it was
trying to form, and stops retransmitting I1 packets
(provided that the I2 packet passes the additional
checks below).
</t>
<t>
If the system's state machine is in any other state than
R2-SENT, the system SHOULD check that the echoed R1
generation counter in the I2 packet is within the
acceptable range if the counter is included.
Implementations MUST accept puzzles from the current
generation and MAY accept puzzles from earlier
generations. If the generation counter in the newly
received I2 packet is outside the accepted range, the I2
packet is stale (and perhaps replayed) and SHOULD be
dropped.
</t>
<t>
The system MUST validate the solution to the puzzle by
computing the hash described in <xref target="I2" /> using
the same RHASH algorithm.
</t>
<t>
The I2 packet MUST have a single value in the HIP_CIPHER
parameter, which MUST match one of the values offered
to the Initiator in the R1 packet.
</t>
<t>
The system must derive Diffie-Hellman keying material Kij
based on the public value and Group ID in the
DIFFIE_HELLMAN parameter. This key is used to derive the
HIP association keys, as described in <xref
target="keymat" />. If the Diffie-Hellman Group ID is
unsupported, the I2 packet is silently dropped.
</t>
<t>
The encrypted HOST_ID is decrypted by the Initiator's
encryption key defined in <xref target="keymat" />. If
the decrypted data is not a HOST_ID parameter, the I2
packet is silently dropped.
</t>
<t>
The implementation SHOULD also verify that the
Initiator's HIT in the I2 packet corresponds to the
Host Identity sent in the I2 packet. (Note: some
middleboxes may not able to make this verification.)
</t>
<t>
The system MUST process the TRANSPORT_FORMAT_LIST
parameter. Other documents specifying transport formats
(e.g. <xref target="I-D.ietf-hip-rfc5202-bis" />)
contain specifications for handling any specific
transport selected.
</t>
<t>
The system MUST verify the HIP_MAC according to the
procedures in <xref target="HIP_MAC" />.
</t>
<t>
The system MUST verify the HIP_SIGNATURE according to
<xref target="hip-signature" /> and <xref target="I2"
/>.
</t>
<t>
If the checks above are valid, then the system proceeds
with further I2 processing; otherwise, it discards the I2
and its state machine remains in the same state.
</t>
<t>
The I2 packet may have the A bit set -- in this case, the
system MAY choose to refuse it by dropping the I2 and the
state machine returns to state UNASSOCIATED. If the A
bit is set, the Initiator's HIT is anonymous and should
not be stored permanently.
</t>
<t>
The system initializes the remaining variables in the
associated state, including Update ID counters.
</t>
<t>
Upon successful processing of an I2 message when the
system's state machine is in state UNASSOCIATED,
I1-SENT, I2-SENT, or R2-SENT, an R2 packet is sent and
the system's state machine transitions to state R2-SENT.
</t>
<t>
Upon successful processing of an I2 packet when the system's
state machine is in state ESTABLISHED, the old HIP
association is dropped and a new one is installed, an R2
packet is sent, and the system's state machine
transitions to R2-SENT.
</t>
<t>
Upon the system's state machine transitioning to
R2-SENT, the system starts a timer. The state machine
transitions to ESTABLISHED if some data has been
received on the incoming HIP association, or an UPDATE
packet has been received (or some other packet that
indicates that the peer system's state machine has moved
to ESTABLISHED). If the timer expires (allowing for
maximal amount of retransmissions of I2 packets), the state
machine transitions to ESTABLISHED.
</t>
</list>
</t>
<section title="Handling of Malformed Messages">
<t>
If an implementation receives a malformed I2 message, the
behavior SHOULD depend on how many checks the message has
already passed. If the puzzle solution in the message has
already been checked, the implementation SHOULD report the
error by responding with a NOTIFY packet. Otherwise, the
implementation MAY respond with an ICMP message as defined
in <xref target="ICMP" />.
</t>
</section>
</section>
<section anchor="inc_r2" title="Processing of Incoming R2 Packets">
<t>
An R2 packet received in states UNASSOCIATED, I1-SENT, or
ESTABLISHED results in the R2 packet being dropped and the state
machine staying in the same state. If an R2 packet is received in
state I2-SENT, it MUST be processed.
</t>
<t>
The following steps define the conceptual processing rules
for an incoming R2 packet:
<list style="numbers">
<t>
If the system is in any other state than I2-SENT, the
R2 packet is silently dropped.
</t>
<t>
The system MUST verify that the HITs in use correspond
to the HITs that were received in the R1 packet that
caused the transition to the I1-SENT state.
</t>
<t>
The system MUST verify the HIP_MAC_2 according to the
procedures in <xref target="HIP_MAC_2" />.
</t>
<t>
The system MUST verify the HIP signature according to the
procedures in <xref target="hip-signature" />.
</t>
<t>
If any of the checks above fail, there is a high
probability of an ongoing man-in-the-middle or other
security attack. The system SHOULD act accordingly, based
on its local policy.
</t>
<t>
Upon successful processing of the R2 packet, the state machine
transitions to state ESTABLISHED.
</t>
</list>
</t>
</section>
<section anchor="send_upd" title="Sending UPDATE Packets">
<t>
A host sends an UPDATE packet when it intends to update some
information related to a HIP association. There are a number
of possible scenarios when this can occur, e.g., mobility management and rekeying
of an existing ESP Security Association. The following
paragraphs define the conceptual rules for sending an UPDATE
packet to the peer. Additional steps can be defined in other
documents where the UPDATE packet is used.
</t>
<t>
The sequence of UPDATE messages is indicated by their SEQ parameter.
Before sending an UPDATE message, the system first
determines whether there are any outstanding UPDATE messages
that may conflict with the new UPDATE message under
consideration. When multiple UPDATEs are outstanding (not
yet acknowledged), the sender must assume that such UPDATEs
may be processed in an arbitrary order by the receiver.
Therefore, any new UPDATEs that depend on a previous
outstanding UPDATE being successfully received and
acknowledged MUST be postponed until reception of the
necessary ACK(s) occurs. One way to prevent any conflicts
is to only allow one outstanding UPDATE at a time. However,
allowing multiple UPDATEs may improve the performance of
mobility and multihoming protocols.
</t>
<t>
The following steps define the conceptual processing rules
for sending UPDATE packets.
</t>
<t>
<list style="numbers">
<t>
The first UPDATE packet is sent with Update ID of zero.
Otherwise, the system increments its own Update ID value
by one before continuing the steps below.
</t>
<t>
The system creates an UPDATE packet that contains a SEQ
parameter with the current value of Update ID.
The UPDATE packet MAY also include zero or more ACKs of
the peer's Update ID(s) from previously received UPDATE
SEQ parameter(s)
</t>
<t>
The system sends the created UPDATE packet and starts an
UPDATE timer. The default value for the timer is 2 *
RTT estimate. If multiple UPDATEs are outstanding,
multiple timers are in effect.
</t>
<t>
If the UPDATE timer expires, the UPDATE is resent. The
UPDATE can be resent UPDATE_RETRY_MAX times. The UPDATE
timer SHOULD be exponentially backed off for subsequent
retransmissions. If no acknowledgment is received from
the peer after UPDATE_RETRY_MAX times, the HIP
association is considered to be broken and the state
machine SHOULD move from state ESTABLISHED to state
CLOSING as depicted in <xref target="hipstates" />. The
UPDATE timer is cancelled upon receiving an ACK from the
peer that acknowledges receipt of the UPDATE.
</t>
</list>
</t>
</section>
<section title="Receiving UPDATE Packets">
<t>
When a system receives an UPDATE packet, its processing
depends on the state of the HIP association and the presence
and values of the SEQ and ACK parameters. Typically, an
UPDATE message also carries optional parameters whose
handling is defined in separate documents.
</t>
<t>
For each association, a host stores the peer's next expected
in-sequence Update ID ("peer Update ID"). Initially, this
value is zero. Update ID comparisons of "less than" and
"greater than" are performed with respect to a circular
sequence number space. Hence, a wrap around after 2^32
updates has to be expected and MUST be handled accordingly.
</t>
<t>
The sender MAY send multiple outstanding UPDATE messages.
These messages are processed in the order in which they are
received at the receiver (i.e., no re-sequencing is
performed). When processing UPDATEs out-of-order, the
receiver MUST keep track of which UPDATEs were previously
processed, so that duplicates or retransmissions are ACKed
and not reprocessed. A receiver MAY choose to define a
receive window of Update IDs that it is willing to process at
any given time, and discard received UPDATEs falling outside
of that window.
</t>
<t>
The following steps define the conceptual processing rules
for receiving UPDATE packets.
</t>
<t>
<list style="numbers">
<t>
If there is no corresponding HIP association, the
implementation MAY reply with an ICMP Parameter Problem,
as specified in <xref target="non-existing-hip" />.
</t>
<t>
If the association is in the ESTABLISHED state and the
SEQ (but not ACK) parameter is present, the UPDATE is
processed and replied to as described in <xref
target="upd_seq" />.
</t>
<t>
If the association is in the ESTABLISHED state and the
ACK (but not SEQ) parameter is present, the UPDATE is
processed as described in <xref target="upd_ack" />.
</t>
<t>
If the association is in the ESTABLISHED state and there
is both an ACK and SEQ in the UPDATE, the ACK is first
processed as described in <xref target="upd_ack" />, and
then the rest of the UPDATE is processed as described in
<xref target="upd_seq" />.
</t>
</list>
</t>
<section anchor="upd_seq"
title="Handling a SEQ Parameter in a Received UPDATE Message">
<t>
The following steps define the conceptual processing rules
for handling a SEQ parameter in a received UPDATE packet.
</t>
<t>
<list style="numbers">
<t>
If the Update ID in the received SEQ is not the next
in the sequence of Update IDs and is greater than the
receiver's window for new UPDATEs, the packet MUST be
dropped.
</t>
<t>
If the Update ID in the received SEQ corresponds to an
UPDATE that has recently been processed, the packet is
treated as a retransmission. The HIP_MAC verification
(next step) MUST NOT be skipped. (A byte-by-byte
comparison of the received and a stored packet would be
acceptable, though.) It is recommended that a host caches
UPDATE packets sent with ACKs to avoid the cost of
generating a new ACK packet to respond to a replayed
UPDATE. The system MUST acknowledge, again, such
(apparent) UPDATE message retransmissions but SHOULD
also consider rate-limiting such retransmission
responses to guard against replay attacks.
</t>
<t>
The system MUST verify the HIP_MAC in the UPDATE
packet. If the verification fails, the packet MUST be
dropped.
</t>
<t>
The system MAY verify the SIGNATURE in the UPDATE
packet. If the verification fails, the packet SHOULD
be dropped and an error message logged.
</t>
<t>
If a new SEQ parameter is being processed, the
parameters in the UPDATE are then processed. The
system MUST record the Update ID in the received SEQ
parameter, for replay protection.
</t>
<t>
An UPDATE acknowledgment packet with ACK parameter is
prepared and sent to the peer. This ACK parameter MAY
be included in a separate UPDATE or piggybacked in an
UPDATE with SEQ parameter, as described in <xref
target="UPDATE" />. The ACK parameter MAY acknowledge
more than one of the peer's Update IDs.
</t>
</list>
</t>
</section>
<section anchor="upd_ack"
title="Handling an ACK Parameter in a Received UPDATE Packet">
<t>
The following steps define the conceptual processing rules
for handling an ACK parameter in a received UPDATE packet.
</t>
<t>
<list style="numbers">
<t>
The sequence number reported in the ACK must match
with an UPDATE packet sent earlier that has not
already been acknowledged. If no match is found or if
the ACK does not acknowledge a new UPDATE, the packet
MUST either be dropped if no SEQ parameter is present,
or the processing steps in <xref target="upd_seq" />
are followed.
</t>
<t>
The system MUST verify the HIP_MAC in the UPDATE
packet. If the verification fails, the packet MUST be
dropped.
</t>
<t>
The system MAY verify the SIGNATURE in the UPDATE
packet. If the verification fails, the packet SHOULD
be dropped and an error message logged.
</t>
<t>
The corresponding UPDATE timer is stopped (see <xref
target="send_upd" />) so that the now acknowledged
UPDATE is no longer retransmitted. If multiple UPDATEs
are acknowledged, multiple timers are stopped.
</t>
</list>
</t>
</section>
</section>
<section title="Processing of NOTIFY Packets">
<t>
Processing of NOTIFY packets is OPTIONAL. If processed, any
errors in a received NOTIFICATION parameter SHOULD be logged.
Received errors MUST be considered only as informational, and
the receiver SHOULD NOT change its HIP state (see <xref
target="states" />) purely based on the received NOTIFY
message.
</t>
</section>
<section title="Processing CLOSE Packets">
<t>
When the host receives a CLOSE message, it responds with a
CLOSE_ACK message and moves to CLOSED state. (The
authenticity of the CLOSE message is verified using both
HIP_MAC and SIGNATURE). This processing applies whether or
not the HIP association state is CLOSING in order to handle
simultaneous CLOSE messages from both ends that cross in
flight.
</t>
<t>
The HIP association is not discarded before the host moves
to the UNASSOCIATED state.
</t>
<t>
Once the closing process has started, any new need to send data
packets triggers creating and establishing of a new HIP
association, starting with sending of an I1 packet.
</t>
<t>
If there is no corresponding HIP association, the CLOSE packet
is dropped.
</t>
</section>
<section title="Processing CLOSE_ACK Packets">
<t>
When a host receives a CLOSE_ACK message, it verifies that
it is in CLOSING or CLOSED state and that the CLOSE_ACK was
in response to the CLOSE. A host can map CLOSE_ACK messages to
CLOSE messages by comparing the value of ECHO_REQUEST_SIGNED
(in the CLOSE packet) to the value of ECHO_RESPONSE_SIGNED
(in the CLOSE_ACK packet).
</t>
<t>
The CLOSE_ACK contains the HIP_MAC and the SIGNATURE
parameters for verification. The state is discarded when
the state changes to UNASSOCIATED and, after that, the host
MAY respond with an ICMP Parameter Problem to an incoming
CLOSE message (see <xref target="non-existing-hip" />).
</t>
</section>
<section title="Handling State Loss">
<t>
In the case of a system crash and unanticipated state loss, the
system SHOULD delete the corresponding HIP state, including
the keying material. That is, the state SHOULD NOT be stored
in long-term storage. If the implementation does drop the state
(as RECOMMENDED), it MUST also drop the peer's R1 generation
counter value, unless a local policy explicitly defines that
the value of that particular host is stored. An
implementation MUST NOT store a peer's R1 generation counters by
default, but storing R1 generation counter values, if done,
MUST be configured by explicit HITs.
</t>
</section>
</section>
<section anchor="sec-policy" title="HIP Policies">
<t>
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.
</t>
<t>
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 is decided by local policy and depends on the privacy
requirements of the Initiator.
</t>
<t>
The value of #K used in the HIP R1 must be chosen with care.
Too high numbers of #K will exclude clients with weak CPUs
because these devices cannot solve the puzzle within reasonable
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.
</t>
<t>
Responders that only respond to selected Initiators require an 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.
</t>
</section>
<section anchor="sec-considerations" title="Security Considerations">
<t>
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 usual.
</t>
<t>
Denial-of-service attacks often take advantage of asymmetries
in the cost of an 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
protocol 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 packets.
</t>
<t>
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 <xref target="inr1" /> step 1).
</t>
<t>
The R1 packet is considerably larger than the I1 packet. This
asymmetry can be exploited in an 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.
</t>
<t>
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 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 to 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.
</t>
<t>
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.
</t>
<t>
A fourth form of DoS attack is emulating 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 (for e.g.,
firewalling, SPI-based NATing, etc.). However, the optional
behavior of replying to CLOSE with an ICMP Parameter Problem
packet (as described in <xref target="non-existing-hip" />)
might allow an attacker spoofing the source IP address to send
CLOSE messages to launch reflection attacks.
</t>
<t>
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 <xref target="hip-replay"
/>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <xref
target="op_mode" />.
</t>
<t>
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.
</t>
<t>
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 from 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 a 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.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
IANA has reserved protocol number 139 for the Host Identity Protocol
and included it in the "IPv6 Extension Header Types" registry
<xref target="RFC7045"/> and the "Assigned Internet Protocol
Numbers" registry. The reference in both of these registries
should be updated from <xref target="RFC5201" /> to this specification.
</t>
<t>
The reference to the 128-bit value under the CGA Message
Type namespace <xref target="RFC3972"/> of "0xF0EF F02F BFF4 3D0F
E793 0C3C 6E61 74EA" should be changed from <xref target="RFC5201" />
to this specification.
</t>
<t>
The following changes to the "Host Identity Protocol (HIP) Parameters"
registries are requested. In many cases, the changes required
involve updating the reference from <xref target="RFC5201" /> to this
specification, but there are some differences as outlined below.
Allocation terminology is defined in <xref target="RFC5226" />;
any existing references to "IETF Consensus" can be replaced with
"IETF Review" as per <xref target="RFC5226" />.
</t>
<t>
<list style='hanging'>
<t hangText='HIP Version'><vspace blankLines='1'/>
This document adds the value "2" to the existing registry.
The value of "1" should be left with a reference to
<xref target="RFC5201"/>.
</t>
<t hangText='Packet Type'><vspace blankLines='1'/>
The 7-bit Packet Type field in a HIP protocol packet
describes the type of a HIP protocol message. It is defined
in <xref target='ssec-payload'/>. All existing values
referring to <xref target="RFC5201" /> should be updated
to refer to this specification. Other values should be
left unchanged.
</t>
<t hangText='HIT Suite ID'><vspace blankLines='1'/>
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
(<xref target="RFC5201" />). The registry should be closed
to new registrations.
<vspace blankLines='1'/>
The four-bit HIT Suite ID uses the OGA field in the ORCHID
to express the type of the HIT. This document defines three
HIT Suites (see <xref target="hit_suite_list" />).
<vspace blankLines='1'/>
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.
<vspace blankLines='1'/>
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, <xref target="RFC7343">RFC 7343</xref>
does not presently support such an extension, and the rollover
approach described in Appendix E is suggested to be tried
first. Possible extensions of the HIT Suite ID space to
accommodate eight bits and new HIT Suite IDs are defined
through IETF Review.
<vspace blankLines='1'/>
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.
</t>
<t hangText='Parameter Type'><vspace blankLines='1'/>
The 16-bit Type field in a HIP parameter describes the type
of the parameter. It is defined in <xref
target='tlvformat'/>. The current values are defined in
Sections <xref target='r1_counter' format="counter"/>
through <xref target='echo_response_unsigned'
format="counter"/>.
The existing registry for "Parameter Type" should be
updated as follows.
<vspace blankLines='1'/>
A new value (129) for R1_COUNTER should
be introduced, with a reference to this specification, and
the existing value (128) for R1_COUNTER left in place
with a reference to <xref target="RFC5201" />. This
documents the change in value that has occurred in version
2 of this protocol. For clarity, we recommend that the
name for the value 128 be changed from "R1_COUNTER" to
"R1_Counter (v1 only)".
<vspace blankLines='1'/>
A new value (579) for a new Parameter Type HIP_CIPHER should
be added, with reference to this specification. This Parameter
Type functionally replaces the HIP_TRANSFORM Parameter Type
(value 577) which can be left in the table with existing
reference to <xref target="RFC5201" />. For clarity, we
recommend that the name for the value 577 be changed from
"HIP_TRANSFORM" to "HIP_TRANSFORM (v1 only)".
<vspace blankLines='1'/>
A new value (715) for a new Parameter Type HIT_SUITE_LIST should
be added, with reference to this specification.
<vspace blankLines='1'/>
A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST
should be added, with reference to this specification.
<vspace blankLines='1'/>
The name of the HMAC Parameter Type (value 61505) should be
changed to HIP_MAC. The name of the HMAC_2 Parameter Type
(value 61569) should be changed to HIP_MAC_2. The reference
should be changed to this specification.
<vspace blankLines='1'/>
All other Parameter Types that reference <xref target="RFC5201" />
should be updated to refer to this specification, and
Parameter Types that reference other RFCs should be unchanged.
<vspace blankLines='1'/>
Regarding the range assignments, the Type codes 32768 through
49151 (not 49141) should be Reserved for Private Use.
Where the existing ranges state "First Come First Served
with Specification Required", this should be changed to
"Specification Required".
<vspace blankLines='1'/>
The Type codes 32768 through 49151 are reserved for
experimentation. 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.
</t>
<t hangText='Group ID'><vspace blankLines='1'/>
The eight-bit Group ID values appear in the DIFFIE_HELLMAN
parameter and the DH_GROUP_LIST parameter and are defined in
<xref target='diffie_hellman'/>. This registry should be
updated based on the new values specified in
<xref target='diffie_hellman'/>; values noted as being
DEPRECATED can be left in the table with reference to
<xref target="RFC5201" />. New values are assigned
through IETF Review.
</t>
<t hangText='HIP Cipher ID'><vspace blankLines='1'/>
The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined in
<xref target='hip_cipher'/>. This is a new registry.
New values either from the reserved or unassigned space are
assigned through IETF Review.
</t>
<t hangText='DI-Type'><vspace blankLines='1'/>
The four-bit DI-Type values in a HOST_ID parameter are
defined in <xref target='host-id'/>. New values are
assigned through IETF Review. All existing values
referring to <xref target="RFC5201" /> should be updated
to refer to this specification.
</t>
<t hangText='HI Algorithm'><vspace blankLines='1'/>
The 16-bit Algorithm values in a HOST_ID parameter are defined in
<xref target='host-id'/>. This is a new registry.
New values either from the reserved or unassigned space are
assigned through IETF Review.
</t>
<t hangText='ECC Curve Label'><vspace blankLines='1'/>
When the HI Algorithm values in a HOST_ID parameter is 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 <xref target='host-id' />.
This might be handled by specifying two algorithm-specific
sub-registries named "ECDSA Curve Label" and
"ECDSA_LOW Curve Label".
New values are to be assigned through IETF Review.
</t>
<t hangText='Notify Message Type'><vspace blankLines='1'/>
The 16-bit Notify Message Type values in a NOTIFICATION
parameter are defined in <xref target='notify'/>.
</t>
<t>
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, 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.
<vspace blankLines='1'/>
The existing registration procedures should be updated as follows.
The range from 1-50 can remain as "IETF Review". The
range from 51-8191 should be marked as "Specification Required".
Values 8192-16383 can remain as "Reserved for Private Use".
Values 16385-40959 should be marked as "Specification Required".
Values 40960-65535 can remain as "Reserved for Private Use".
<vspace blankLines='1'/>
The following updates to the values should be made to the
existing registry. All existing values
referring to <xref target="RFC5201" /> should be updated
to refer to this specification.
<vspace blankLines='1'/>
INVALID_HIP_TRANSFORM_CHOSEN should be renamed to
INVALID_HIP_CIPHER_CHOSEN with the same value (17).
<vspace blankLines='1'/>
A new value of 20 for the type UNSUPPORTED_HIT_SUITE should be
added.
<vspace blankLines='1'/>
HMAC_FAILED should be renamed to HIP_MAC_FAILED with the same
value (28).
<vspace blankLines='1'/>
SERVER_BUSY_PLEASE_RETRY should be renamed to
RESPONDER_BUSY_PLEASE_RETRY with the same value (44).
</t>
</list>
</t>
</section>
<section title="Acknowledgments">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
In the usual IETF fashion, a large number of people have
contributed to the actual text or ideas. The list of these
people include Jeff Ahrenholz, Francis Dupont, Derek Fawcus,
George Gross, Andrew McGregor, Julien Laganier, Miika Komu,
Mika Kousa, Jan Melen, Henrik Petander, Michael Richardson,
Rene Hummen, Tim Shepard, Jorma Wall, Xin Gu, and Jukka
Ylitalo. Our apologies to anyone whose name is missing.
</t>
<t>
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., <xref target="AUR03" /> were added at a later stage.
</t>
</section>
<section title="Changes from RFC 5201">
<t>
This section summarizes the changes made from <xref
target="RFC5201" />.
</t>
<section title="Changes from draft-ietf-hip-rfc5201-bis-19">
<t>
<list style='symbols'>
<t> Clarified encoding of HIT Suite ID in HIT_SUITE_LIST parameter. Moved Table 11 from Appendix E forward to the HIT_SUITE_LIST parameter section. </t>
<t> Clarified the possible strategies for reusing HIT Suite ID values or expanding the field, noting that RFC 7343 does not support HIT Suite ID field expansion and that any such future changes are to be defined through IETF Review. </t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-18">
<t>
<list style='symbols'>
<t> Correct documentation prefix in Appendix C from 2001:D88/32 to 2001:DB8/32, and update IPv6 checksum </t>
<t> Correct documentation prefix reference from RFC 5747 to 5737</t>
<t> Clarified HIT generation in Appendix E</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-17">
<t>
<list style='symbols'>
<t> Update ORCHID reference to newly published RFC 7343 </t>
<t> Update example checksum section to RFC 7343 HIT prefix of 2001:20::/28, and fix incorrect Header Length fields</t>
<t> Update IANA considerations comment on legacy HIP_TRANSFORM parameter naming </t>
<t> Add 2048-bit MODP DHE group as Group ID value 11.</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-16">
<t>
<list style='symbols'>
<t> Clarify that receipt of user data in state CLOSING (Table 7) results in transition to I1-SENT
</t>
<t> Add academic reference for the first mention of the RSA algorithm
</t>
<t> As part of comment resolution on use of NULL encryption, note that use of a NULL HIP CIPHER is only to be used when debugging and testing the HIP protocol. This only pertains to the ENCRYPTED parameter, which is optional; in practice, if encryption is not desired, better to just not encrypt the Host ID.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-15">
<t>
<list style='symbols'>
<t> Additional edits to IANA Considerations section based on
initial IANA review.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-14">
<t>
<list style='symbols'>
<t> Update source XML to comply with xmlrfcv2 version of the
xml2rfc tool, resulting in a few table formatting changes.
</t>
<t> Editorial and minor technical revisions based on IESG
review.
</t>
<t> Significant revisions to IANA Considerations section based
on initial IANA review.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-13">
<t>
<list style='symbols'>
<t> Update a few references and fix some editorial nits.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-12">
<t>
<list style='symbols'>
<t> Fix I-D nits.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-11">
<t>
<list style='symbols'>
<t> Specify that TRANSPORT_FORMAT_LIST is mandatory in R1 and I2; fix incorrect section reference.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-10">
<t>
<list style='symbols'>
<t> Issue 39: Text clarifying R1 counter rollover and Initiator response to unexpected reset of the counter.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-09">
<t>
<list style='symbols'>
<t> Editorial changes based on working group last call.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-08">
<t>
<list style='symbols'>
<t>
Issue 29: Use different RSA mode OEAP/PSS, elevate ECDSA
to REQUIRED status
</t>
<t>
Issue 35: limiting ECC cofactor to 1
</t>
<t>
Changed text regarding issue 33 reusing DH values
</t>
<t>
Fix tracker issue 32 on Domain Identifier normative text
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-07">
<t>
<list style='symbols'>
<t>
Removed lingering references to SHA-1 as the mandatory
hash algorithm (which was changed to SHA-256 in the
-02 draft version).
</t>
<t>
For parameter type number changes, changed "IETF
Review" to "IETF Review or IESG Approval".
</t>
<t>
Updated Appendix C checksum examples to conform to
HIPv2 packets.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-06">
<t>
<list style='symbols'>
<t>
Made echoing the R1_COUNTER in the I2 mandatory if
the R1 contains an R1_COUNTER. This required to make
the R1 counter a critical parameter. Hence, the
parameter type number of the R1_COUNTER changed from
128 to 129.
</t>
<t>
Made KDF dependent on DH Group to enable negotiation
of the KDF.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-05">
<t>
<list style='symbols'>
<t>
Changed type number of DH_GROUP_LIST from 2151 to 511
because it was in the number space that is reserved for the
HIP transport mode negotiations.
</t>
<t>
Added transport form type list parameter. Transport
forms are now negotiated with this list instead of by
their order in the HIP packet. This allows to remove
the exception of the transport format parameters that
were ordered by their preference instead of by their
type number. This should remove complexity from
implementations.
</t>
<t>
Clarify that in HIP signature processing, the restored
checksum and length fields have been rendered invalid
by the previous steps.
</t>
<t>
Clarify behavior for when UPDATE does not contain SEQ
or ACQ (disallow this).
</t>
<t>
For namespace changes, changed "IETF Review" to "IETF
Review or IESG Approval".
</t>
<t>
Addressed IESG comment about ignoring packet IP
addresses.
</t>
<t>
Permit using Anonymous HI control in packets other
than R1/I2.
</t>
<t>
Fixed minor reference error (RFC2418, RFC2410).
</t>
<t>
Deleted comment that NULL-ENCRYPTION SHOULD NOT be
configurable via the UI.
</t>
<t>
Editorial changes.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-04">
<t>
<list style='symbols'>
<t>
Clarifications of the Security Considerations
section. One DoS defense mechanism was changed to be
more effective and less prone to misuse.
</t>
<t>
Minor clarifications of the state machine.
</t>
<t>
Clarified text on HIP puzzle.
</t>
<t>
Added names and references for figures.
</t>
<t>
Extended the definitions section.
</t>
<t>
Added a reference to the HIP Version 1 certificate
document.
</t>
<t>
Added Initiator, Responder, HIP association, and
signed data to the definitions section.
</t>
<t>
Changed parameter figure for PUZZLE and SOLUTION to
use RHASH_len/8 instead of n-byte.
</t>
<t>
Replaced occurrences of lowercase 'not' in SHOULD NOT.
</t>
<t>
Changed text to reflect the fact that several
ECHO_REQUEST_UNSIGNED parameters may be present in an
R1 and several ECHO_RESPONSE parameters may be present
in an I2.
</t>
<t>
Added text on verifying the ECHO_RESPONSE_SIGNED
parameter in CLOSE_ACK.
</t>
<t>
Changed wording from HMAC to HIP_MAC in Section
5.3.8.
</t>
<t>
Reflected fact that the UPDATE packet MAY include
zero or more ACKs.
</t>
<t>
Added BEX to Definitions section.
</t>
<t>
Changed HIP_SIGNATURE algorithm field from 8 bit to
16 bit to achieve alignment with the HOST_ID
parameters.
</t>
<t>
Fixed the wrong figures of the SEQ and ACK
parameters. SEQ always contains ONE update ID. ACK
may acknowledge SEVERAL update IDs.
</t>
<t>
Added wording that several NOTIFY parameters may be
present in a HIP packet.
</t>
<t>
Changed wording for the ECHO_RESPONSE_SIGNED
parameter. Also lifted the restriction that only one
ECHO_RESPONSE_UNSIGNED parameter MUST be present in
each HIP packet. This did contradict the
definition of the ECHO_RESPONSE_UNSIGNED parameter.
</t>
<t>
Changed IETF Consensus to IETF Review or IESG Approval in IANA
section.
</t>
<t>
Aligned use of I, J, and K. Now I is #I, J is #J and
K is #K throughout the document.
</t>
<t>
Updated references.
</t>
<t>
Editorial changes.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-03">
<t>
<list style='symbols'>
<t>
Editorial changes to improve clarity and readability.
</t>
<t>
Removed obsoleted (not applicable) attack from
security consideration section.
</t>
<t>
Added a requirement that hosts MUST support
processing of ACK parameters with several SEQ
numbers even when they do not support sending such
parameters.
</t>
<t>
Removed note on memory bound puzzles. The use of
memory bound puzzles was reconsidered but no
convincing arguments for inclusion in this document
have been made on the list.
</t>
<t>
Changed references to reference the new bis
documents.
</t>
<t>
Specified the ECC curves and the hashes used for
these.
</t>
<t>
Specified representation of ECC curves in the HI.
</t>
<t>
Added text on the dependency between RHASH and HMAC.
</t>
<t>
Rephrased part of the security considerations to make
them clearer.
</t>
<t>
Clarified the use of HITs in opportunistic mode.
</t>
<t>
Clarified the difference between HIP_MAC and
HIP_MAC_2 as well as between SIGNATURE and
SIGNATURE_2.
</t>
<t>
Changed NOTIFY name for value 44 from
SERVER_BUSY_PLEASE_RETRY to
RESPONDER_BUSY_PLEASE_RETRY.
</t>
<t>
Mentioned that there are multiple valid puzzle
solutions.
</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-02">
<t>
<list style='symbols'>
<t>Added recommendation to not use puzzle #I twice for
the same host to avoid identical key material.</t>
<t>Revised state machine and added missing event
handling.</t>
<t>Added UNSUPPORTED_HIT_SUITE to NOTIFY to indicate
unsupported HIT suites.</t>
<t>Revised parameter type numbers (corresponding to IANA
allocations) and added missing "free for
experimentation" range to the description.</t>
<t>Clarifying note on the use of the C bit in the
parameter type numbers.</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-01">
<t>
<list style='symbols'>
<t>Changed RHASH-len to RHASH_len to avoid confusion in
calculations (- could be minus)</t>
<t>Added RHASH_len to list of abbreviations</t>
<t>Fixed length of puzzle #I and #J to be 1*RHASH_len</t>
<t>Changed RHASH-len to RHASH_len to avoid confusion in
calculations (- could be minus)</t>
<t>Added RHASH_len to list of abbreviations</t>
<t>Fixed length of puzzle #I and #J to be 1*RHASH_len</t>
<t>Included HIT_SUITEs.</t>
<t>Added DH negotiation to I1 and R1.</t>
<t>Added DH_LIST parameter.</t>
<t>Added text for DH Group negotiation.</t>
<t>Removed second DH public value from DH parameter.</t>
<t>Added ECC to HI generation.</t>
<t>Added Responder HIT selection to opportunistic mode.</t>
<t>Added ECDSA HI text and references (not complete
yet).</t>
<t>Added separate section on aborting BEX.</t>
<t>Added separate section on downgrade attack
prevention.</t>
<t>Added text about DH Group selection for use cases
without I1.</t>
<t>Removed type range allocation for parameters related
to HIP transform types.</t>
<t>New type range allocation for parameters that are
only covered by a signature if a signature is present
(Applies to DH_GROUP_LIST).</t>
<t>Renamed HIP_TRANSFORM to HIP_CIPHER and removed
hashes from it - hashes are determined by RHASH.</t>
<t>The length of #I and #J for the puzzle now depends on
RHASH.</t>
<t>New keymat generation.</t>
<t>Puzzle seed and solution now use RHASH and have
variable length.</t>
<t>Moved timing definitions closer to state machine.</t>
<t>Simplified text regarding puzzle lifetime.</t>
<t>Clarified the description of the use of #I in the
puzzle</t>
<t>Removed "Opportunistic mode" description from general
definitions.</t>
<t>More consistency across the old RFC5201 text. Aligned
capitalization and abbreviations.</t>
<t>Extended protocol overview to include restart
option.</t>
<t>Extended state machine to include restart option
because of unsupported Algorithms.</t>
<t>Replaced SHA-1 with SHA-256 for required
implementation.</t>
<t>Added OGA list parameter (715) for detecting the
Responder's set of OGAs.</t>
<t>Added Appendix on ORCHID use in HITs.</t>
<t>Added truncated SHA-256 option for HITs.</t>
<t>Added truncated SHA-1 option for HITs.</t>
<t>Added text about new ORCHID structure to HIT
overview.</t>
<t>Moved Editor role to Robert Moskowitz.</t>
<t>Added SHA-256 to puzzle parameter.</t>
<t>Generalized LTRUNC to be hash-function agnostic.</t>
<t>Added text about RHASH depending on OGA.</t>
</list>
</t>
</section>
<section title="Changes from draft-ietf-hip-rfc5201-bis-00">
<t>
<list style='symbols'>
<t>Added reasoning why BIS document is needed.</t>
</list>
</t>
</section>
<section title="Contents of draft-ietf-hip-rfc5201-bis-00">
<t>
<list style='symbols'>
<t>RFC5201 was submitted as draft-RFC.</t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&RFC0768;
&RFC0793;
&RFC1035;
&RFC2404;
&RFC2119;
&RFC2410;
&RFC2460;
&RFC4443;
&RFC2536;
&RFC3110;
&RFC3526;
&RFC3602;
&RFC3972;
&RFC4034;
&RFC4282;
&RFC4754;
&RFC4868;
&RFC5202-bis;
&RFC5702;
&RFC6724;
&RFC7343;
&FIPS180-2;
&NIST.800-131A.2011;
</references>
<references title="Informative References">
&RFC0792;
&RFC2785;
&RFC2898;
&RFC3447;
&RFC5996;
&RFC5226;
&RFC5201;
&rfc4423-bis; <!-- was RFC4423 -->
&RFC5533;
&RFC5338;
&RFC5206-bis;
&RFC5205-bis;
&RFC5204-bis;
&RFC6253;
&RFC5869;
&RFC5903;
&RFC6090;
&RFC3849;
&RFC5737;
&RFC7045;
<reference anchor="SECG" target="http://www.secg.org/">
<front>
<title>Recommended Elliptic Curve Domain Parameters</title>
<author><organization>SECG</organization></author>
<date year="2000"/>
</front>
<seriesInfo name="SEC 2" value=""/>
</reference>
<reference anchor="AUR03">
<front>
<title>Analysis of the HIP Base Exchange Protocol </title>
<author initials="T" surname="Aura"
fullname="Tuomas Aura">
<organization>Microsoft Research</organization>
</author>
<author initials="A" surname="Nagarajan"
fullname="Aarthi Nagarajan">
<organization>Technische Universitaet Hamburg</organization>
</author>
<author initials="A" surname="Gurtov"
fullname="Andrei Gurtov">
<organization>Helsinki Institute for Information Technology
</organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="in Proceedings of"
value="10th Australasian Conference on Information Security and
Privacy" />
</reference>
<reference anchor="KRA03">
<front>
<title>SIGMA: The 'SIGn-and-MAc' Approach to Authenticated
Diffie-Hellman and Its Use in the IKE-Protocols</title>
<author initials="H" surname="Krawczyk"
fullname="Hugo Krawczyk">
<organization></organization>
</author>
<date month="August" year="2003" />
</front>
<seriesInfo name="in Proceedings of"
value="CRYPTO 2003, pages 400-425" />
</reference>
<reference anchor="CRO03">
<front>
<title>Denial of Service via Algorithmic Complexity
Attacks</title>
<author initials="SA" surname="Crosby"
fullname="Scott A. Crosby">
<organization>Rice University</organization>
</author>
<author initials="DS" surname="Wallach"
fullname="Dan S. Wallach">
<organization>Rice University</organization>
</author>
<date month="August" day="4-8" year="2003" />
</front>
<seriesInfo name="in Proceedings of"
value="Usenix Security Symposium 2003" />
<seriesInfo name="" value="Washington, DC." />
</reference>
&FIPS197;
&FIPS186-3;
<reference anchor="DIF76">
<front>
<title>New Directions in Cryptography</title>
<author initials="W" surname="Diffie"
fullname="Whitfield Diffie">
<organization />
</author>
<author initials="M.E." surname="Hellman"
fullname="Martin E. Hellman">
<organization />
</author>
<date month="Nov" year="1976" />
</front>
<seriesInfo name="IEEE Transactions on Information Theory"
value="vol. IT-22, number 6, pages 644-654" />
</reference>
<reference anchor="RSA">
<front>
<title>A Method for Obtaining Digital Signatures and Public-Key Cryptosystems</title>
<author initials="R" surname="Rivest" fullname="R. Rivest">
<organization />
</author>
<author initials="A" surname="Shamir" fullname="A. Shamir">
<organization />
</author>
<author initials="L" surname="Adleman" fullname="L. Adleman">
<organization />
</author>
<date month="February" year="1978" />
</front>
<seriesInfo name="Communications of the ACM" value="21 (2), pp. 120-126" />
</reference>
<reference anchor="KAU03">
<front>
<title>DoS protection for UDP-based protocols</title>
<author initials="C" surname="Kaufman"
fullname="C. Kaufman">
<organization />
</author>
<author initials="R" surname="Perlman"
fullname="R. Perlman">
<organization />
</author>
<author initials="B" surname="Sommerfeld"
fullname="B. Sommerfeld">
<organization />
</author>
<date month="Oct" year="2003" />
</front>
<seriesInfo name="ACM Conference on Computer and Communications Security"
value="" />
</reference>
</references>
<section anchor="resp-cookie" title="Using Responder Puzzles">
<t>
As mentioned in <xref target="hip-cookie" />, 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 on 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.
</t>
<t>
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.
</t>
<t>
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 regeneration.
</t>
<t>
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.
</t>
<figure>
<artwork>
#I value calculation:
#I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n)
where n = RHASH_len
</artwork>
</figure>
<t>
The RHASH algorithm is the same that is used to generate
the Responder's HIT value.
</t>
<t>
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.
</t>
<figure>
<artwork>
puzzle_check:
V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K )
if V != 0, drop the packet
</artwork>
</figure>
<t>
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 is generated.
</t>
<t>
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 <xref target="hip-cookie"
/>).
</t>
</section>
<section anchor="app_generhit" title="Generating a Public Key Encoding
from an HI">
<t>
The following pseudo-code illustrates the process to generate a
public key encoding from an HI for both RSA and DSA.
</t>
<t>
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.
</t>
<figure>
<artwork>
switch ( HI.algorithm )
{
case RSA:
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 )
break;
case DSA:
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 )
break;
}
</artwork>
</figure>
</section>
<section title="Example Checksums for HIP Packets">
<t>
The HIP checksum for HIP packets is specified in <xref
target="ssec-crc" />. Checksums for TCP and UDP packets
running over HIP-enabled security associations are specified in
<xref target="tcp-udp-pseudo-header" />.
The examples below use <xref target="RFC3849" />
and <xref target="RFC5737" /> addresses, and HITs with the prefix of
2001:20 followed by zeros, followed by a decimal 1 or 2,
respectively.
</t>
<t>
The following example is defined only for testing the checksum
calculation.
</t>
<section title="IPv6 HIP Example (I1 packet)">
<figure>
<artwork>
Source Address: 2001:DB8::1
Destination Address: 2001:DB8::2
Upper-Layer Packet Length: 48 0x30
Next Header: 139 0x8b
Payload Protocol: 59 0x3b
Header Length: 5 0x5
Packet Type: 1 0x1
Version: 2 0x2
Reserved: 1 0x1
Control: 0 0x0
Checksum: 6750 0x1a5e
Sender's HIT : 2001:20::1
Receiver's HIT: 2001:20::2
DH_GROUP_LIST type: 511 0x1ff
DH_GROUP_LIST length: 3 0x3
DH_GROUP_LIST group IDs: 3,4,8
</artwork>
</figure>
</section>
<section title="IPv4 HIP Packet (I1 packet)">
<t>
The IPv4 checksum value for the example I1 packet is shown below.
</t>
<figure>
<artwork>
Source Address: 192.0.2.1
Destination Address: 192.0.2.2
Upper-Layer Packet Length: 48 0x30
Next Header: 139 0x8b
Payload Protocol: 59 0x3b
Header Length: 5 0x5
Packet Type: 1 0x1
Version: 2 0x2
Reserved: 1 0x1
Control: 0 0x0
Checksum: 61902 0xf1ce
Sender's HIT : 2001:20::1
Receiver's HIT: 2001:20::2
DH_GROUP_LIST type: 511 0x1ff
DH_GROUP_LIST length: 3 0x3
DH_GROUP_LIST group IDs: 3,4,8
</artwork>
</figure>
</section>
<section title="TCP Segment">
<t>
Regardless of whether IPv6 or IPv4 is used, the TCP and UDP
sockets use the IPv6 pseudo-header format <xref
target="RFC2460"/>, with the HITs used in place of the IPv6
addresses.
</t>
<figure>
<artwork>
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
</artwork>
</figure>
</section>
</section>
<section anchor="ecdh-160-group" title="ECDH and ECDSA 160 Bit Groups">
<t>
The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80
bits symmetric strength. Once this was 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 required).
</t>
<!--RM: We need the parameter values here for ECDH-160 with reference source. -->
</section>
<section anchor="hit-suites" title="HIT Suites and HIT Generation">
<t>
The HIT as an ORCHID <xref target="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 is
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 field of the ORCHID.
</t>
<t>
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 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.
</t>
<t>
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.
</t>
<t>
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
<xref target="table_hit_suites" />.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:55:52 |