tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5201

 
 
 

Host Identity Protocol

Part 2 of 3, p. 31 to 66
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 31 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part