Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5201

Host Identity Protocol

Pages: 104
Obsoleted by:  7401
Updated by:  6253
Part 2 of 3 – Pages 31 to 66
First   Prev   Next

ToP   noToC   RFC5201 - Page 31   prevText

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 / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP   noToC   RFC5201 - Page 32
   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.
ToP   noToC   RFC5201 - Page 33

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
ToP   noToC   RFC5201 - Page 34
   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.
ToP   noToC   RFC5201 - Page 35
   +------------------------+-------+----------+-----------------------+
   | 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 |
   |                        |       |          |                       |
ToP   noToC   RFC5201 - Page 36
   | 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.
ToP   noToC   RFC5201 - Page 37

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
ToP   noToC   RFC5201 - Page 38
       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.
ToP   noToC   RFC5201 - Page 39
   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.
ToP   noToC   RFC5201 - Page 40

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.
ToP   noToC   RFC5201 - Page 41

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.
ToP   noToC   RFC5201 - Page 42

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
ToP   noToC   RFC5201 - Page 43
   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.
ToP   noToC   RFC5201 - Page 44
   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
ToP   noToC   RFC5201 - Page 45
          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.
ToP   noToC   RFC5201 - Page 46

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.
ToP   noToC   RFC5201 - Page 47
   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.
ToP   noToC   RFC5201 - Page 48

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.
ToP   noToC   RFC5201 - Page 49

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
ToP   noToC   RFC5201 - Page 50
   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.
ToP   noToC   RFC5201 - Page 51
       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.
ToP   noToC   RFC5201 - Page 52
   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.
ToP   noToC   RFC5201 - Page 53
   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.
ToP   noToC   RFC5201 - Page 54

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.
ToP   noToC   RFC5201 - Page 55
   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.
ToP   noToC   RFC5201 - Page 56

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.
ToP   noToC   RFC5201 - Page 57
   +------------------+------------------------------------------------+
   |    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.
ToP   noToC   RFC5201 - Page 58

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
ToP   noToC   RFC5201 - Page 59
   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
ToP   noToC   RFC5201 - Page 60
   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.
ToP   noToC   RFC5201 - Page 61

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.
ToP   noToC   RFC5201 - Page 62
   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 ) )
ToP   noToC   RFC5201 - Page 63
   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.
ToP   noToC   RFC5201 - Page 64
   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
ToP   noToC   RFC5201 - Page 65
   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
ToP   noToC   RFC5201 - Page 66
   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)

Next Section