RFC 5201
Host Identity Protocol
5. Packet Formats
5.1. Payload Format
All HIP packets start with a fixed header. 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 | VER. | RES.|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Controls | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / HIP Parameters / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 do so. However, current implementations MUST ignore trailing data if an unimplemented Next Header value is received. The Header Length field contains the 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. Note: this sets an additional limit for sizes of parameters included in the Parameters field, independent of the individual parameter maximum lengths. 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 unknown packet type, it MUST drop the packet. The HIP Version is four bits. The current version is 1. 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. The following three bits are reserved for future use. They MUST be zero when sent, and they SHOULD be ignored when handling a received packet. The two fixed bits in the header are reserved for potential SHIM6 compatibility [SHIM6-PROTO]. 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, in the case that the forthcoming SHIM6 protocol happens to be compatible with this specification, 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. The HIT fields are always 128 bits (16 bytes) long.
5.1.1. Checksum
Since the checksum covers the source and destination addresses in the IP header, it must be recomputed on HIP-aware NAT devices. If IPv6 is used to carry the HIP packet, the pseudo-header [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 Section 4) in the Next Header field. The length field is in bytes and can be calculated from the HIP header length field: (HIP Header Length + 1) * 8. In case of using IPv4, the IPv4 UDP pseudo-header format [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 Section 4), and the length is calculated as in the IPv6 case.5.1.2. HIP Controls
The HIP Controls section conveys information about the structure of the packet and capabilities of the host. The following fields have been defined: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 R1 and/or I2. The peer receiving an anonymous HI may choose to refuse it. The rest of the fields are reserved for future use and MUST be set to zero on sent packets and ignored on received packets.5.1.3. HIP Fragmentation Support
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 a host expects to send HIP packets that are larger than the minimum IPv6 MTU, it MUST implement fragment generation even for IPv6. In IPv4 networks, HIP packets may encounter low MTUs along their routed path. Since HIP 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 MUST perform any IPv4 reassembly/fragmentation. All HIP implementations have to be careful while employing a reassembly algorithm so that the algorithm is sufficiently resistant to DoS attacks. Because certificate chains can cause the packet to be fragmented and fragmentation can open implementation to denial-of-service attacks [KAU03], it is strongly recommended that the separate document specifying the certificate usage in the HIP Base Exchange defines the usage of "Hash and URL" formats rather than including certificates in exchanges. With this, most problems related to DoS attacks with fragmentation can be avoided.5.2. HIP Parameters
The HIP Parameters are used to carry the public key associated with the sender's HIT, together with related security and other information. They consist of ordered parameters, encoded in TLV format. The following parameter types are currently defined.
+------------------------+-------+----------+-----------------------+ | TLV | Type | Length | Data | +------------------------+-------+----------+-----------------------+ | R1_COUNTER | 128 | 12 | System Boot Counter | | | | | | | PUZZLE | 257 | 12 | K and Random #I | | | | | | | SOLUTION | 321 | 20 | K, Random #I and | | | | | puzzle solution J | | | | | | | SEQ | 385 | 4 | Update packet ID | | | | | number | | | | | | | ACK | 449 | variable | Update packet ID | | | | | number | | | | | | | DIFFIE_HELLMAN | 513 | variable | public key | | | | | | | HIP_TRANSFORM | 577 | variable | HIP Encryption and | | | | | Integrity Transform | | | | | | | ENCRYPTED | 641 | variable | Encrypted part of I2 | | | | | packet | | | | | | | HOST_ID | 705 | variable | Host Identity with | | | | | Fully-Qualified | | | | | Domain FQDN (Name) or | | | | | Network Access | | | | | Identifier (NAI) | | | | | | | CERT | 768 | variable | HI Certificate; used | | | | | to transfer | | | | | certificates. Usage | | | | | is not currently | | | | | defined, but it will | | | | | be specified in a | | | | | separate document | | | | | once needed. | | | | | | | NOTIFICATION | 832 | variable | Informational data | | | | | | | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | | | | | echoed back; under | | | | | signature | | | | | | | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | | | | | back; under signature | | | | | |
| HMAC | 61505 | variable | HMAC-based message | | | | | authentication code, | | | | | with key material | | | | | from HIP_TRANSFORM | | | | | | | HMAC_2 | 61569 | variable | HMAC based message | | | | | authentication code, | | | | | with key material | | | | | from HIP_TRANSFORM. | | | | | Compared to HMAC, the | | | | | HOST_ID parameter is | | | | | included in HMAC_2 | | | | | calculation. | | | | | | | HIP_SIGNATURE_2 | 61633 | variable | Signature of the R1 | | | | | packet | | | | | | | HIP_SIGNATURE | 61697 | variable | Signature of the | | | | | packet | | | | | | | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | | | | | echoed back; after | | | | | signature | | | | | | | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | | | | | back; after signature | +------------------------+-------+----------+-----------------------+ Because the ordering (from lowest to highest) of HIP parameters is strictly enforced (see Section 5.2.1), the parameter type values for existing parameters have been spaced to allow for future protocol extensions. Parameters numbered between 0-1023 are used in HIP handshake and update procedures and are covered by signatures. Parameters numbered between 1024-2047 are reserved. Parameters numbered between 2048-4095 are used for parameters related to HIP transform types. Parameters numbered between 4096 and (2^16 - 2^12) 61439 are reserved. Parameters numbered between 61440-62463 are used for signatures and signed MACs. Parameters numbered between 62464- 63487 are used for parameters that fall outside of the signed area of the packet. Parameters numbered between 63488-64511 are used for rendezvous and other relaying services. Parameters numbered between 64512-65535 are reserved.
5.2.1. TLV Format
The TLV-encoded parameters are described in the following subsections. The type-field value also describes the order of these fields in the packet, except for type values from 2048 to 4095 which are reserved for new transport forms. The parameters MUST be included in the packet such that their types form an increasing order. If the parameter can exist multiple times in the packet, the type value may be the same in consecutive parameters. If the order does not follow this rule, the packet is considered to be malformed and it MUST be discarded. Parameters using type values from 2048 up to 4095 are transport formats. Currently, one transport format is defined: the ESP transport format [RFC5202]. The order of these parameters does not follow the order of their type value, but they are put in the packet in order of preference. The first of the transport formats it the most preferred, and so on. All of the TLV parameters have a length (including 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 becomes 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. Consequently, the Length field indicates the length of the Contents field (in bytes). The total length of the TLV parameter (including Type, Length, Contents, and Padding) is related to the Length field according to the following formula: Total Length = 11 + Length - (Length + 3) % 8; where % is the modulo operator
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.
Contents Parameter specific, defined by Type
Padding Padding, 0-7 bytes, added if needed
Critical parameters 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 Section 4.3.
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.
5.2.2. Defining New Parameters
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 increasing order by Type code, thereby limiting
the order of parameters (see Section 5.2.1).
The following rules must be followed when defining new parameters.
1. The low-order bit C of the Type code is used to distinguish
between critical and non-critical parameters.
2. A new parameter may be critical only if an old recipient ignoring
it would cause security problems. In general, new parameters
SHOULD be defined as non-critical, and expect a reply from the
recipient.
3. 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. 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).
4. See Section 9 for allocation rules regarding Type codes.
5.2.3. R1_COUNTER
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 128
Length 12
R1 generation
counter The current generation of valid puzzles
The R1_COUNTER parameter contains a 64-bit unsigned integer in
network-byte order, indicating the current generation of valid
puzzles. The sender is supposed to 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.
The R1_COUNTER parameter 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 MAY be echoed (including the Reserved field verbatim) by
the Initiator in the I2.
5.2.4. PUZZLE
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, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 257 Length 12 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 Random #I is represented as a 64-bit integer, K and Lifetime as 8-bit integers, all in network byte order. The PUZZLE parameter contains the puzzle difficulty K and a 64-bit puzzle 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, allowing the Responder to use the included information as a part of its puzzle processing. The Opaque and Random #I field are not covered by the HIP_SIGNATURE_2 parameter.
5.2.5. SOLUTION
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, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Puzzle solution #J, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 321 Length 20 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 Puzzle solution #J random number Random #I and Random #J are represented as 64-bit integers, K as an 8-bit integer, all in network byte order. 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.
5.2.6. DIFFIE_HELLMAN
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 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | Public Value Length | Public Value / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 513 Length length in octets, excluding Type, Length, and padding Group ID defines values for p and g Public Value length of the following Public Value in octets Length Public Value the sender's public Diffie-Hellman key The following Group IDs have been defined: Group Value Reserved 0 384-bit group 1 OAKLEY well-known group 1 2 1536-bit MODP group 3 3072-bit MODP group 4 6144-bit MODP group 5 8192-bit MODP group 6 The MODP Diffie-Hellman groups are defined in [RFC3526]. The OAKLEY well-known group 1 is defined in Appendix E. The sender can include at most two different Diffie-Hellman public values in the DIFFIE_HELLMAN parameter. This gives the possibility, e.g., for a server to provide a weaker encryption possibility for a PDA host that is not powerful enough. It is RECOMMENDED that the Initiator, receiving more than one public value, selects the stronger one, if it supports it. A HIP implementation MUST implement Group IDs 1 and 3. The 384-bit 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). It
is REQUIRED that the default configuration allows Group ID 1 usage, but it is RECOMMENDED that applications that need stronger security turn Group ID 1 support off. Equipment powerful enough SHOULD implement also Group ID 5. The 384-bit group is defined in Appendix D. To avoid unnecessary failures during the base exchange, the rest of the groups SHOULD be implemented in hosts where resources are adequate.5.2.7. HIP_TRANSFORM
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suite ID #1 | Suite ID #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suite ID #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 577 Length length in octets, excluding Type, Length, and padding Suite ID defines the HIP Suite to be used The following Suite IDs are defined ([RFC4307],[RFC2451]): Suite ID Value RESERVED 0 AES-CBC with HMAC-SHA1 1 3DES-CBC with HMAC-SHA1 2 3DES-CBC with HMAC-MD5 3 BLOWFISH-CBC with HMAC-SHA1 4 NULL-ENCRYPT with HMAC-SHA1 5 NULL-ENCRYPT with HMAC-MD5 6 The sender of a HIP_TRANSFORM parameter MUST make sure that there are no more than six (6) HIP Suite IDs in one HIP_TRANSFORM parameter. Conversely, a recipient MUST be prepared to handle received transport parameters that contain more than six Suite IDs by accepting the first six Suite IDs and dropping the rest. The limited number of transforms sets the maximum size of HIP_TRANSFORM parameter. As the default configuration, the HIP_TRANSFORM parameter MUST contain at least one of the mandatory Suite IDs. There MAY be a configuration option that allows the administrator to override this default.
The Responder lists supported and desired Suite IDs in order of preference in the R1, up to the maximum of six Suite IDs. The Initiator MUST choose only one of the corresponding Suite IDs. That Suite ID will be used for generating the I2. Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL-ENCRYPTION with HMAC-SHA1.5.2.8. HOST_ID
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 FQDN or NAI in octets Host Identity actual Host Identity Domain Identifier the identifier of the sender The Host Identity is represented in RFC 4034 [RFC4034] format. The algorithms used in RDATA format are the following: Algorithms Values RESERVED 0 DSA 3 [RFC2536] (RECOMMENDED) RSA/SHA1 5 [RFC3110] (REQUIRED) The following DI-types have been defined: Type Value none included 0 FQDN 1 NAI 2
FQDN Fully Qualified Domain Name, in binary format.
NAI Network Access Identifier
The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1.
The format for NAI is defined in [RFC4282]
If there is no Domain Identifier, i.e., the DI-type field is zero,
the DI Length field is set to zero as well.
5.2.9. HMAC
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
HMAC 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.
The HMAC calculation and verification process is presented in
Section 6.4.1.
5.2.10. HMAC_2
The parameter structure is the same as in Section 5.2.9. The fields are: Type 61569 Length length in octets, excluding Type, Length, and Padding HMAC HMAC computed over the HIP packet, excluding the HMAC 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. The HMAC calculation and verification process is presented in Section 6.4.1.5.2.11. HIP_SIGNATURE
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. The checksum field MUST be set to zero, and the HIP header length in the HIP common header MUST be calculated only to the beginning of the HIP_SIGNATURE parameter when the signature is calculated.
The signature algorithms are defined in Section 5.2.8. The signature in the Signature field is encoded using the proper method depending on the signature algorithm (e.g., according to [RFC3110] in case of RSA/SHA1, or according to [RFC2536] in case of DSA). The HIP_SIGNATURE calculation and verification process is presented in Section 6.4.2.5.2.12. HIP_SIGNATURE_2
The parameter structure is the same as in Section 5.2.11. The fields are: 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. 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. Signature calculation and verification follows the process in Section 6.4.2.
5.2.13. SEQ
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 4 Update ID 32-bit sequence number The Update ID is an unsigned quantity, 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.5.2.14. ACK
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 449 Length variable (multiple of 4) peer Update ID 32-bit sequence number corresponding to the Update ID being ACKed. The ACK parameter includes one or more Update IDs that have been received from the peer. The Length field identifies the number of peer Update IDs that are present in the parameter.
5.2.15. ENCRYPTED
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 transform. Encrypted The data is encrypted using an encryption algorithm data as defined in HIP transform. The ENCRYPTED parameter encapsulates another parameter, the encrypted data, which holds one or more HIP parameters in block encrypted form. 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. The field labelled "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 Section 5.2.1 for padding individual parameters. As a result, the concatenated parameters will be a block of data that is 8-byte aligned. 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, AES [FIPS01] uses the PKCS5 padding scheme (see section 6.1.1 of [RFC2898]) where the remaining n bytes to fill the block each have the value 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. 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. 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 Section 5.2.1.5.2.16. NOTIFICATION
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 the NOTIFY packet type. The use of the NOTIFICATION parameter in other packet types is for further study.
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).
Padding any Padding, if necessary, to make the parameter a
multiple of 8 bytes.
Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process.
The table below lists the Notification messages and their
corresponding values.
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.
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 NOTIFICATION
error parameter 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.
Notify payloads with status types MUST be ignored if not recognized.
NOTIFICATION PARAMETER - ERROR TYPES 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 rejected for policy reasons. To avoid a denial-
of-service attack using forged messages, this status may only be
returned for packets whose HMAC (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 D-H Group ID field does not correspond to one offered
by the Responder.
NO_HIP_PROPOSAL_CHOSEN 16
None of the proposed HIP Transform crypto suites was
acceptable.
INVALID_HIP_TRANSFORM_CHOSEN 17
The HIP Transform crypto suite does not correspond to
one offered by the Responder.
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.
HMAC_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).
SERVER_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 MESSAGES - STATUS TYPES Value
------------------------------ -----
I2_ACKNOWLEDGEMENT 16384
The Responder has an I2 from the Initiator but had to queue the I2
for processing. The puzzle was correctly solved and the Responder
is willing to set up an association but currently has a number of
I2s in the processing queue. R2 will be sent after the I2 has
been processed.
5.2.17. ECHO_REQUEST_SIGNED
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 variable 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. The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data that the sender wants to get echoed back in the corresponding reply packet. 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 HMAC and SIGNATURE. A HIP packet can contain only one ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED parameter. The ECHO_REQUEST_SIGNED parameter MUST be responded to with a corresponding echo response. ECHO_RESPONSE_SIGNED SHOULD be used, but if it is not possible, e.g., due to a middlebox-provided response, it MAY be responded to with an ECHO_RESPONSE_UNSIGNED.5.2.18. ECHO_REQUEST_UNSIGNED
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 variable Opaque data opaque data, supposed to be meaningful only to the node that sends ECHO_REQUEST_UNSIGNED and receives a corresponding ECHO_RESPONSE_UNSIGNED.
The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data that the sender wants to get echoed back in the corresponding reply packet. 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 HMAC 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 sender has to create the Opaque field so that it can later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED parameter. The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an ECHO_RESPONSE_UNSIGNED parameter.5.2.19. ECHO_RESPONSE_SIGNED
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 variable Opaque data opaque data, copied unmodified from the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED parameter that triggered this response. 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. 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 HMAC and SIGNATURE.
5.2.20. ECHO_RESPONSE_UNSIGNED
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 variable Opaque data opaque data, copied unmodified from the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED parameter that triggered this response. 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. 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 HMAC and SIGNATURE.5.3. HIP Packets
There are eight basic HIP packets (see Table 10). Four are for the HIP base exchange, one is for updating, one is for sending notifications, and two are for closing a HIP association.
+------------------+------------------------------------------------+ | Packet type | Packet name | +------------------+------------------------------------------------+ | 1 | I1 - the HIP Initiator Packet | | | | | 2 | R1 - the HIP Responder Packet | | | | | 3 | I2 - the Second HIP Initiator Packet | | | | | 4 | R2 - the Second HIP Responder Packet | | | | | 16 | UPDATE - the HIP Update Packet | | | | | 17 | NOTIFY - the HIP Notify Packet | | | | | 18 | CLOSE - the HIP Association Closing Packet | | | | | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | | | Packet | +------------------+------------------------------------------------+ Table 10: HIP packets and packet type numbers Packets consist of the fixed header as described in Section 5.1, followed by the parameters. The parameter part, in turn, consists of zero or more TLV-coded parameters. In addition to the base packets, other packet types will be defined later in separate specifications. For example, support for mobility and multi-homing is not included in this specification. See Notation (Section 2.2) for used operations. 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. This limits the size of the possible additional data in the packet.
5.3.1. I1 - the HIP Initiator Packet
The HIP header values for the I1 packet: Header: Packet Type = 1 SRC HIT = Initiator's HIT DST HIT = Responder's HIT, or NULL IP ( HIP () ) The I1 packet contains only the fixed HIP header. Valid control bits: none The Initiator gets the Responder's HIT either from a DNS lookup of the Responder's FQDN, 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 "HIP Opportunistic Mode" (Section 4.1.6). Since this packet is so easy to spoof even if it were signed, no attempt is made to add to its generation or processing cost. Implementations MUST be able to handle a storm of received I1 packets, discarding those with common content that arrive within a small time delta.5.3.2. R1 - the HIP Responder Packet
The HIP header values for the R1 packet: Header: Packet Type = 2 SRC HIT = Responder's HIT DST HIT = Initiator's HIT IP ( HIP ( [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_TRANSFORM, HOST_ID, [ ECHO_REQUEST_SIGNED, ] HIP_SIGNATURE_2 ) <, ECHO_REQUEST_UNSIGNED >i) Valid control bits: A
If the Responder's HI is an anonymous one, the A control MUST be set. The Initiator's HIT MUST match the one received in 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 "HIP Opportunistic Mode" (Section 4.1.6). The R1 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. 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 Section 4.1.2. 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 just prior sending it to the peer. The Diffie-Hellman value is ephemeral, and one value SHOULD be used only for one connection. Once the Responder has received a valid response to an R1 packet, that Diffie-Hellman value SHOULD be deprecated. Because it is possible that the Responder has sent the same Diffie-Hellman value to different hosts simultaneously in corresponding R1 packets, those responses should also be accepted. However, as a defense against I1 storms, an implementation MAY propose, and re-use if not 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. Re-using Diffie-Hellman public keys 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. However, these risks involved in re-using the same key 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 implementations avoid re-using the same D-H 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 storm. In particular, when it is too expensive to generate enough precomputed R1 packets to supply each potential Initiator with a different D-H key, the Responder MAY send the same D-H 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 D-H key, it SHOULD stop offering it. This design is aimed to allow resource-constrained Responders to offer services under I1 storms and to simultaneously make the probability of D-H key re-use both statistical and as low as possible. If a future version of this protocol is considered, we strongly recommend that these issues be studied again. Especially, the current design allows hosts to become potentially more vulnerable to a statistical, low-probability problem during I1 storm attacks than what they are if no attack is taking place; whether this is acceptable or not should be reconsidered in the light of any new experience gained. The HIP_TRANSFORM contains the encryption and integrity algorithms supported by the Responder to protect the HI exchange, in the order of preference. All implementations MUST support the AES [RFC3602] with HMAC-SHA-1-96 [RFC2404]. The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED contains data that the sender wants to receive unmodified in the corresponding response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED parameter. The signature is calculated over the whole HIP envelope, after setting the Initiator's HIT, header checksum, as well as the Opaque field and the Random #I in the PUZZLE parameter temporarily to zero, and excluding any parameters that follow the signature, as described in Section 5.2.12. This allows the Responder to use precomputed R1s. The Initiator SHOULD validate this signature. It SHOULD check that the Responder's HI received matches with the one expected, if any.
5.3.3. I2 - the Second HIP Initiator Packet
The HIP header values for the I2 packet: Header: Type = 3 SRC HIT = Initiator's HIT DST HIT = Responder's HIT IP ( HIP ( [R1_COUNTER,] SOLUTION, DIFFIE_HELLMAN, HIP_TRANSFORM, ENCRYPTED { HOST_ID } or HOST_ID, [ ECHO_RESPONSE_SIGNED ,] HMAC, HIP_SIGNATURE <, ECHO_RESPONSE_UNSIGNED>i ) ) Valid control bits: A The HITs used MUST match the ones used previously. If the Initiator's HI is an anonymous one, the A control MUST be set. The Initiator MAY include an unmodified copy of the R1_COUNTER parameter received in the corresponding R1 packet into the I2 packet. 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. 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 Section 5.3.2. The HIP_TRANSFORM contains the single encryption and integrity transform selected by the Initiator, that will be used to protect the HI exchange. The chosen transform MUST correspond to one offered by the Responder in the R1. All implementations MUST support the AES transform [RFC3602]. The Initiator's HI MAY be encrypted using the HIP_TRANSFORM encryption algorithm. The keying material is derived from the Diffie-Hellman exchanged as defined in Section 6.5.
The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the unmodified Opaque data copied from the corresponding echo request parameter. The HMAC is calculated over the whole HIP envelope, excluding any parameters after the HMAC, as described in Section 6.4.1. The Responder MUST validate the HMAC. The signature is calculated over the whole HIP envelope, excluding any parameters after the HIP_SIGNATURE, as described in Section 5.2.11. The Responder MUST validate this signature. It MAY use either the HI in the packet or the HI acquired by some other means.5.3.4. R2 - the Second HIP Responder Packet
The HIP header values for the R2 packet: Header: Packet Type = 4 SRC HIT = Responder's HIT DST HIT = Initiator's HIT IP ( HIP ( HMAC_2, HIP_SIGNATURE ) ) Valid control bits: none The HMAC_2 is calculated over the whole HIP envelope, with Responder's HOST_ID parameter concatenated with the HIP envelope. The HOST_ID parameter is removed after the HMAC calculation. The procedure is described in Section 6.4.1. The signature is calculated over the whole HIP envelope. The Initiator MUST validate both the HMAC and the signature.5.3.5. UPDATE - the HIP Update Packet
Support for the UPDATE packet is MANDATORY. The HIP header values for the UPDATE packet: Header: Packet Type = 16 SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( [SEQ, ACK, ] HMAC, HIP_SIGNATURE ) )
Valid control bits: None The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE parameters, and other optional parameters. The UPDATE packet contains zero or one SEQ parameter. The presence of a SEQ parameter indicates that the receiver MUST ACK the UPDATE. An UPDATE that does not contain a SEQ parameter is simply an ACK of a previous UPDATE and itself MUST NOT be ACKed. 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 ACK more than one UPDATE packet at a time; e.g., the ACK may contain the last two SEQ values received, for robustness to ACK loss. ACK values are not cumulative; each received unique SEQ value requires at least one corresponding ACK value in reply. Received ACKs that are redundant are ignored. The UPDATE packet may contain both a SEQ and an ACK parameter. In this case, the ACK 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 ACK for a short period of time to allow for the possibility of piggybacking the ACK parameter, in a manner similar to TCP delayed acknowledgments. A sender MAY choose to forgo 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. 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.5.3.6. NOTIFY - the HIP Notify Packet
The NOTIFY packet is OPTIONAL. 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 (Section 4.4.1) based purely on a received NOTIFY packet.
The HIP header values for the NOTIFY packet:
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) )
Valid control bits: None
The NOTIFY packet is used to carry one or more NOTIFICATION
parameters.
5.3.7. CLOSE - the HIP Association Closing Packet
The HIP header values for the CLOSE packet:
Header:
Packet Type = 18
SRC HIT = Sender's HIT
DST HIT = Recipient's HIT
IP ( HIP ( ECHO_REQUEST_SIGNED, HMAC, HIP_SIGNATURE ) )
Valid control bits: none
The sender MUST include an ECHO_REQUEST_SIGNED used to validate
CLOSE_ACK received in response, and both an HMAC and a signature
(calculated over the whole HIP envelope).
The receiver peer MUST validate both the HMAC and the signature if it
has a HIP association state, and MUST reply with a CLOSE_ACK
containing an ECHO_RESPONSE_SIGNED corresponding to the received
ECHO_REQUEST_SIGNED.
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet
The HIP header values for the CLOSE_ACK packet:
Header:
Packet Type = 19
SRC HIT = Sender's HIT
DST HIT = Recipient's HIT
IP ( HIP ( ECHO_RESPONSE_SIGNED, HMAC, HIP_SIGNATURE ) )
Valid control bits: none
The sender MUST include both an HMAC and signature (calculated over the whole HIP envelope). The receiver peer MUST validate both the HMAC and the signature.5.4. ICMP Messages
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 [RFC2463]. In most cases, the ICMP packet will have 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.5.4.1. Invalid Version
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, the Pointer pointing to the VER./RES. byte in the HIP header.5.4.2. Other Problems with the HIP Header and Packet Structure
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.5.4.3. Invalid Puzzle Solution
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. 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 [RFC0792].5.4.4. Non-Existing HIP Association
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, and with the Pointer pointing to the beginning of the first HIT that does not match. A host MUST NOT reply with such an ICMP if it receives any of the following messages: I1, R2, I2, R2, and NOTIFY. When introducing new packet types, a specification SHOULD define the appropriate rules for sending or not sending this kind of ICMP reply.
(page 66 continued on part 3)
