RFC 7401
Host Identity Protocol Version 2 (HIPv2)
Pages: 128
Proposed Standard
→ Errata
Obsoletes: 5201
Updated by: 8002 9374
Proposed Standard
→ Errata
Obsoletes: 5201
Updated by: 8002 9374
Part 3 of 5 – Pages 38 to 70
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 |Version| 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 define behavior for other values. However, current implementations MUST ignore trailing data if an unimplemented Next Header value is received. 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 Section 5.1.3 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. 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. 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 Section 5.1.2). 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. The two fixed bits in the header are reserved for SHIM6 compatibility [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. 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 5.1) 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 field 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 using anonymous sender HIs. The peer receiving an anonymous HI in an R1 or I2 may choose to refuse it. 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.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 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. 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. All HIP implementations have to be careful while employing a reassembly algorithm so that the algorithm is sufficiently resistant to DoS attacks. Certificate chains can cause the packet to be fragmented, and fragmentation can open implementations to denial-of-service attacks [KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP version 1 may be used to avoid fragmentation and mitigate resulting DoS attacks.5.2. HIP Parameters
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. In HIP packets, HIP parameters are ordered according to their numeric type number and encoded in TLV format.
The following parameter types are currently defined. +------------------------+-------+-----------+----------------------+ | TLV | Type | Length | Data | +------------------------+-------+-----------+----------------------+ | R1_COUNTER | 129 | 12 | Puzzle generation | | | | | 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 | | | | | | | DH_GROUP_LIST | 511 | variable | Ordered list of DH | | | | | Group IDs supported | | | | | by a host | | | | | | | DIFFIE_HELLMAN | 513 | variable | public key | | | | | | | HIP_CIPHER | 579 | variable | List of HIP | | | | | encryption | | | | | algorithms | | | | | | | ENCRYPTED | 641 | variable | Encrypted part of a | | | | | HIP packet | | | | | | | HOST_ID | 705 | variable | Host Identity with | | | | | Fully Qualified | | | | | Domain Name (FQDN) | | | | | or Network Access | | | | | Identifier (NAI) | | | | | | | HIT_SUITE_LIST | 715 | variable | Ordered list of the | | | | | HIT Suites supported | | | | | by the Responder | | | | | | | CERT | 768 | variable | HI Certificate; used | | | | | to transfer | | | | | certificates. | | | | | Specified in a | | | | | separate document. | | | | | |
| NOTIFICATION | 832 | variable | Informational data | | | | | | | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | | | | | echoed back; signed | | | | | | | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | | | | | back by request; | | | | | signed | | | | | | | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable | | | | list of | | | | | preferred | | | | | HIP | | | | | transport | | | | | type | | | | | numbers | | | | | | | | HIP_MAC | 61505 | variable | HMAC-based message | | | | | authentication code, | | | | | with key material | | | | | from KEYMAT | | | | | | | HIP_MAC_2 | 61569 | variable | HMAC-based message | | | | | authentication code, | | | | | with key material | | | | | from KEYMAT. Unlike | | | | | HIP_MAC, the HOST_ID | | | | | parameter is | | | | | included in | | | | | HIP_MAC_2 | | | | | calculation. | | | | | | | HIP_SIGNATURE_2 | 61633 | variable | Signature used in 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 by request; | | | | | after signature | +------------------------+-------+-----------+----------------------+
As 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. The following parameter type number ranges are defined. +---------------+---------------------------------------------------+ | Type Range | Purpose | +---------------+---------------------------------------------------+ | 0 - 1023 | Handshake | | | | | 1024 - 2047 | Reserved | | | | | 2048 - 4095 | Parameters related to HIP transport formats | | | | | 4096 - 8191 | Signed parameters allocated through specification | | | documents | | | | | 8192 - 32767 | Reserved | | | | | 32768 - 49151 | Reserved for Private Use. Signed parameters. | | | | | 49152 - 61439 | Reserved | | | | | 61440 - 62463 | Signatures and (signed) MACs | | | | | 62464 - 63487 | Parameters that are neither signed nor MACed | | | | | 63488 - 64511 | Rendezvous and relaying | | | | | 64512 - 65023 | Parameters that are neither signed nor MACed | | | | | 65024 - 65535 | Reserved | +---------------+---------------------------------------------------+ The process for defining new parameters is described in Section 5.2.2 of this document. The range between 32768 (2^15) and 49151 (2^15 + 2^14) is Reserved for Private Use. Types from this range SHOULD be selected in a random fashion to reduce the probability of collisions.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. 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. Parameters using type values from 2048 up to 4095 are related to transport formats. Currently, one transport format is defined: the ESP transport format [RFC7402]. 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. 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: 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, excluding Type, Length, and Padding Contents Parameter specific, defined by Type Padding Padding, 0-7 bytes, added if needed
Critical parameters (indicated by the odd type number value) 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 numerically 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. Hence, even parameter type numbers indicate non-critical parameters while odd parameter type numbers indicate critical parameters. 2. 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. 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 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). 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 129 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 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. 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.
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, 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 Random #I is represented as an n-bit integer (where n is RHASH_len), and #K and Lifetime as 8-bit integers, all in network byte order. The PUZZLE parameter contains the puzzle difficulty #K and an 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. The Opaque and Random #I fields 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, 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 Random #I and Random #J are represented as n-bit unsigned integers (where n is RHASH_len), and #K as an 8-bit unsigned 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. DH_GROUP_LIST
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. 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, and 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 Section 4.1.7). 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 then a downgrade attack cannot be detected. In general, hosts SHOULD prefer stronger groups over weaker ones if the computation overhead is not prohibitively high for the intended application.
5.2.7. 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 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | 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 A single DIFFIE_HELLMAN parameter may be included in selected HIP packets based on the DH Group ID selected (Section 5.2.6). The following Group IDs have been defined; values are assigned by this document: 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 The MODP Diffie-Hellman groups are defined in [RFC3526]. ECDH groups 7-9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 is covered in Appendix D. Any ECDH used with HIP MUST have a co-factor of 1.
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 Section 6.5). 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. To avoid unnecessary failures during the base exchange, the rest of the groups SHOULD be implemented in hosts where resources are adequate.5.2.8. HIP_CIPHER
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
The following Cipher IDs are defined:
Suite ID Value
RESERVED 0
NULL-ENCRYPT 1 ([RFC2410])
AES-128-CBC 2 ([RFC3602])
RESERVED 3 (unused value)
AES-256-CBC 4 ([RFC3602])
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.
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.
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 HIP.
5.2.9. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 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 the NAI is defined in [RFC4282]. 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.
The following HI Algorithms have been defined:
Algorithm profiles Values
RESERVED 0
DSA 3 [FIPS.186-4.2013] (RECOMMENDED)
RSA 5 [RFC3447] (REQUIRED)
ECDSA 7 [RFC4754] (REQUIRED)
ECDSA_LOW 9 [SECG] (RECOMMENDED)
For DSA, RSA, and ECDSA key types, profiles containing at least
112 bits of security strength (as defined by [NIST.800-131A.2011])
should be used. For RSA signature padding, the Probabilistic
Signature Scheme (PSS) method of padding [RFC3447] MUST be used.
The Host Identity is derived from the DNSKEY format for RSA and DSA.
For these, the Public Key field of the RDATA part from RFC 4034
[RFC4034] is used. For Elliptic Curve Cryptography (ECC), we
distinguish two different profiles: ECDSA and ECDSA_LOW. ECC
contains curves approved by NIST and defined in RFC 4754 [RFC4754].
ECDSA_LOW is defined for devices with low computational capabilities
and uses shorter curves from the Standards for Efficient Cryptography
Group [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1.
For ECDSA and ECDSA_LOW, Host Identities are represented by the
following fields:
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]
For hosts that implement ECDSA as the algorithm, the following ECC
curves are required:
Algorithm Curve Values
ECDSA RESERVED 0
ECDSA NIST P-256 1 [RFC4754]
ECDSA NIST P-384 2 [RFC4754]
For hosts that implement the ECDSA_LOW algorithm profile, the
following curve is required:
Algorithm Curve Values
ECDSA_LOW RESERVED 0
ECDSA_LOW SECP160R1 1 [SECG]
5.2.10. HIT_SUITE_LIST
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.
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 ID 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.
The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of
signature algorithms as defined in Section 5.2.9, and hash functions.
The ID field in the HIT_SUITE_LIST is defined as an eight-bit field,
as opposed to the four-bit HIT Suite ID and OGA ID 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.
The following HIT Suite IDs 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:
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)
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 Section 3.2. The output is 96 bits
long and is directly used in the ORCHID.
+-------+----------+--------------+------------+--------------------+
| Index | Hash | HMAC | Signature | Description |
| | function | | algorithm | |
| | | | family | |
+-------+----------+--------------+------------+--------------------+
| 0 | | | | Reserved |
| | | | | |
| 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI |
| | | | | hashed with |
| | | | | SHA-256, truncated |
| | | | | to 96 bits |
| | | | | |
| 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed |
| | | | | with SHA-384, |
| | | | | truncated to 96 |
| | | | | bits |
| | | | | |
| 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI |
| | | | | hashed with SHA-1, |
| | | | | truncated to 96 |
| | | | | bits |
+-------+----------+--------------+------------+--------------------+
Table 10: HIT Suites
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 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC-SHA-1 [RFC2404].5.2.11. TRANSPORT_FORMAT_LIST
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. 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. The TF type numbers index the respective HIP parameters for the transport formats in the type number range between 2050 and 4095. The parameters and their use are defined in separate documents. Currently, the only transport format defined is IPsec ESP [RFC7402]. 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.
5.2.12. HIP_MAC
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. The HMAC uses RHASH as the hash algorithm. The calculation and verification process is presented in Section 6.4.1.5.2.13. HIP_MAC_2
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 the structure shown in Section 5.2.12. The fields are as follows: 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.
The HMAC uses RHASH as the hash algorithm. The calculation and
verification process is presented in Section 6.4.1.
5.2.14. 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. 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.
The signature algorithms are defined in Section 5.2.9. The signature
in the Signature field is encoded using the method depending on the
signature algorithm (e.g., according to [RFC3110] in the case of RSA/
SHA-1, [RFC5702] in the case of RSA/SHA-256, [RFC2536] in the case of
DSA, or [RFC6090] in the case of ECDSA).
HIP_SIGNATURE calculation and verification follow the process defined
in Section 6.4.2.
5.2.15. HIP_SIGNATURE_2
HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet to allow R1 pre-creation. The parameter structure is the same as the structure shown in Section 5.2.14. The fields are as follows: 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 follow the process defined in Section 6.4.2.5.2.16. 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 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.5.2.17. 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 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 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.5.2.18. 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_CIPHER.
Encrypted The data is encrypted using the encryption algorithm
data defined in the HIP_CIPHER parameter.
The ENCRYPTED parameter encapsulates other parameters, 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 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 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 [FIPS.197.2001] 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 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.
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.19. 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 NOTIFY packets. 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 Data addition to the Notify Message Type. Values for this field are type specific (see below). Notification information can be error messages specifying why a 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 Notify Message Types. HIP packets MAY contain multiple NOTIFICATION parameters if several problems exist or several independent pieces of information must be transmitted. 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. Notify Message Types in the range 0-16383 are intended for reporting errors, and those in the range 16384-65535 are 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.
As currently defined, Notify Message Type values 1-10 are used for
informing about errors in packet structures, and values 11-20 for
informing about problems in parameters.
Notification Data in NOTIFICATION parameters where the Notify Message
Type is in the status range MUST be ignored if not recognized.
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 were 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 were
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., the received HIT is NULL
and the 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.
5.2.20. 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 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
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 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.
5.2.21. 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 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 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 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. The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an ECHO_RESPONSE_UNSIGNED parameter.
5.2.22. 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 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 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 HIP_MAC and SIGNATURE.5.2.23. 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 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 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 HIP_MAC and SIGNATURE.
(page 70 continued on part 4)