INTERNET-DRAFT P.Jokela Expires May 2003 J.Wall draft-jokela-hip-packets-01.txt J.Ylitalo P.Nikander NomadicLab, Ericsson Research November 2002 Optimized Packet Structure for HIP Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Table of Contents 1. Abstract......................................................... 2 2. Conventions used in this document................................ 2 3. Optimized Packet Structure....................................... 3 3.1 HIP header...................................................... 3 3.2 HIP controls.................................................... 4 3.3 HIP Parameter................................................... 5 3.4 TLV format...................................................... 6 3.4.1 SPI_LSI....................................................... 7 3.4.2 BIRTHDAY_COOKIE............................................... 7 3.4.3 DIFFIE_HELLMAN................................................ 8 3.4.4 HIP_TRANSFORM................................................. 8 3.4.5 ESP_TRANSFORM................................................. 9 3.4.6 HOST_ID...................................................... 10 draft-jokela-hip-packets-01.txt [Page 1]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 3.4.7 HOST_ID_FQDN................................................. 11 3.4.8 CERT......................................................... 11 3.4.9 HIP_SIGNATURE................................................ 12 3.4.10 HIP_SIGNATURE_2............................................. 13 3.4.11 REA_INFO.................................................... 13 3.4.12 NEW_SPI..................................................... 15 3.4.13 ENCRYPTED................................................... 15 4. HIP Packets..................................................... 16 4.1 I1............................................................. 16 4.2 R1............................................................. 16 4.3 I2............................................................. 17 4.4 R2............................................................. 18 4.5 NES............................................................ 18 4.6 REA............................................................ 19 4.7 BOS............................................................ 19 4.8 CER............................................................ 20 4.9 PAYLOAD........................................................ 20 5. Security considerations......................................... 21 6. References...................................................... 21 7. Change History.................................................. 22 8. Acknowledgments................................................. 23 9. Author's Address................................................ 22 10. Copyright Statement............................................ 24 1. Abstract This memo describes alternative, optimized packet structures for the Host Identity Payload and Host Layer Protocol (HIP). The packet structures presented in this memo are intended replace original packets in HIP. In addition, this memo describes a new packet, CER, to transmit certificates. The main objective in redefining HIP packet structures is to make the packet structures simpler and more distinct, which makes the implementation work easier, hopefully leading to more secure protocol implementation. The new structures reduce the average packet size and take advantage of other existing IPv6 protocols formats, including alignments concerns, like the newly suggested Mobility header format for Mobile IPv6. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. draft-jokela-hip-packets-01.txt [Page 2]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 3. Optimized Packet Format This proposed packet format is based on a fixed header followed by strictly ordered TLV encoded parameters. The chosen format maintains the extensibility of the original HIP proposal, while giving a more compact packet structure that is easy and efficient to generate and parse. The proposed format allows new OPTIONAL extensions to be developed and deployed. All HIP packets have the common header part. The header is partly similar to the MIPv6 [MIPv6] Mobility Header. The MIPv6 header structure allows hosts to OPTIONALLY send piggy packed payloads, following the HIP header. This capability is indicated in the control field in the HIP header. The HIP header is 8 bytes aligned, as IPv6 extension headers. Additionally, the parameters are designed so that all fields within the options are properly 8 byte aligned. Any extensions to this format SHOULD preserve this property. 3.1. HIP header The HIP header contains fixed fields, including both sender's and receiver's HITs. In the first packet, I1, the receiver's HIT may also be zero, if it is unknown (opportunistic HIP). Both sender's and receiver's HITs are included in the HIP header to make the HIP based NAT implementations easier. The same applies also to the SPI that will follow the header part; we place the SPI always as the first field in the HIP Key Parameter so that the NAT boxes and firewalls find it easily. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Length | Packet Type | VER. | RES. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Host Identity Tag (HIT) | | | | | draft-jokela-hip-packets-01.txt [Page 3]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / HIP Parameters / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unless the receiving host has indicated its willingness to receive piggy backed packets, the Payload Proto [PRN] MUST be set to 59 there MUST NOT be any payload following the HIP header. The Header Length is the length, in 8 bytes units, of the HIP header, 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. The Packet Type indicates the HIP packet type, see Section 4. The HIP Version is four bits. The current version is 1. The following four bits are reserved for future use. They MUST be zero when send, and they SHOULD be ignored when handling a received packet. The Control field is described in the Section 3.2. The checksum field is the checksum over a pseudo-header and the HIP packet. The checksum field is located at the same location within the header as the checksum field in UDP packets, enabling hardware assisted checksum generation and verification. Note that since the checksum covers the source and destination addresses in the IP header, it must be recomputed on HIP based NAT boxes. The pseudo-header [RFC2460] contains the source and destination IPv6 addresses, HIP packet length in the pseudo-header length field, zero field and HIP protocol number in the Next Header field. The length field is in bytes and can be calculated from the HIP header length field: (header length + 1) * 8. The HIT fields are always 128 bits (16 bytes) long. 3.2 HIP controls The HIP control section transfers information about the structure of the packet and capabilities of the host. draft-jokela-hip-packets-01.txt [Page 4]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 The following fields have been defined: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |P|C| | | | | | | | | | | |E|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P - Piggy backing -- The sending host is capable of sending and receiving additional data (e.g. ESP) in HIP packets. C - One or more certificate packets (CER) follows this HIP packet (see 4.8). E - ESP sequence bit, the ESP transform requires 64-bit sequence number. A - Anonymous bit: if this is set, the senders HI in this packet is anonymous, i.e. one not listed in a directory. The rest of the fields are reserved for future use and MUST be set to zero on sent packets and ignored on received packets. 3.3 HIP Parameters The HIP Parameters are used to carry the public key associated with the sender's HIT, together with other related security information. The HIP Parameters consists of ordered parameters, encoded in TLV format. The following parameter types are currently defined. TLV Type Length Data SPI_LSI 16 Remote's SPI, Remote's LSI. BIRTHDAY_COOKIE 40 System Boot Counter plus 3 64 bit fields: Random #I, K or random # J, Hash target DIFFIE_HELLMAN variable public key HIP_TRANSFORM variable HIP Encryption Transform ESP_TRANSFORM variable ESP Encryption and Authentication Transform HOST_ID variable Host Identity HOST_ID_FQDN variable Host Identity with Fully Qualified Domain Name draft-jokela-hip-packets-01.txt [Page 5]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 CERT variable HI certificate NEW_SPI 16 ESP sequence number, Old SPI, New SPI REA_INFO variable ESP sequence number, Current SPI, followed by 1-N triplets of Interface ID, Address lifetime, Address (16 bytes) ENCRYPTED variable Encrypted part of I2 or CER packets HIP_SIGNATURE variable Signature of the packet HIP_SIGNATURE_2 variable Signature of the packet R1 3.4 TLV format The TLV encoded parameters are described in the following subsections. The type-field value also describes the order of these fields in the packet. The parameters MUST be included into the packet so that the types form an increasing order. If the order does not follow this rule, the packet is considered to be malformed and it MUST be discarded. All the TLV parameters have a length 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. If padding is added, the Length field MUST NOT include the padding. Consequently, Length indicates the length of the Contents, in bytes, and the total length of the parameter is calculated according to the following formula: Total Length = 11 + Length - (Length + 3) % 8; 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Contents / / +-+-+-+-+-+-+-+-+ draft-jokela-hip-packets-01.txt [Page 6]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.4.1 SPI_LSI 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 12 Reserved Zero when sent, ignored when received SPI Security Parameter Index LSI Local Scope Identifier 3.4.2 BIRTHDAY_COOKIE 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Birthday, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # I, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random # J or K, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash Target, 8 bytes | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 (in R1) or 3 (in I2) draft-jokela-hip-packets-01.txt [Page 7]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 Length 36 Reserved Zero when sent, ignored when received Birthday System boot counter Random # I random number K or K is the number of verified bits (in R1 packet) Random # J random number (in I2 packet) Hash Target calculated hash value 3.4.3 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 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 6 Length length in octets, excluding T and L fields and padding Group ID defines values for p and g public value The following Group IDs have been defined: Group Value Reserved 0 - 4 1536-bit MODP group 5 2048-bit MODP group 6 3072-bit MODP group 7 4096-bit MODP group 8 6144-bit MODP group 9 8192-bit MODP group 10 MODP Diffie-Hellman groups are defined in [MODP]. 3.4.4 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transform-ID #1 | Transform-ID #2 | draft-jokela-hip-packets-01.txt [Page 8]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transform-ID #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 16 Length length in octets, excluding T and L fields and padding Transform-ID Defines the HIP Transform to be used The following encryption algorithms are defined. Transform-ID Values RESERVED 0 ENCR_NULL 1 ENCR_3DES 2 ENCR_AES_128 3 There MUST NOT be more than three (3) HIP Transform-IDs in one HIP transform TLV. The limited number of transforms sets the maximum size of HIP_TRANSFORM TLV. The HIP_TRANSFORM TLV MUST contain at least one of the mandatory Transform-IDs. Mandatory implementations: ENCR_3DES and ENCR_NULL 3.4.5 ESP_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 18 Length length in octets, excluding T and L fields and padding Suite-ID Defines the ESP Suite to be used The following Suite-IDs are defined ([IKEv2],[JFK]): Suite-ID Value RESERVED 0 ESP-AES-CBC with HMAC-SHA1 1 ESP-3DES-CBC with HMAC-SHA1 2 draft-jokela-hip-packets-01.txt [Page 9]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 ESP-3DES-CBC with HMAC-MD5 3 ESP-BLOWFISH-CBC with HMAC-SHA1 4 ESP-NULL with HMAC-SHA1 5 ESP-NULL with HMAC-MD5 6 There MUST NOT be more than six (6) ESP Suite-IDs in one ESP_TRANSFORM TLV. The limited number of Suite-IDs sets the maximum size of ESP_TRANSFORM TLV. The ESP_TRANSFORM MUST contain at least one of the mandatory Suite-IDs. Mandatory implementations: ESP-3DES-CBC with HMAC-SHA1 and ESP-NULL with HMAC-SHA1 3.4.6 HOST_ID When the host sends a Host Identity to a peer, it MAY send the identity without any verification information or use certificates to proof the HI. If certificates are sent, they are sent in a separate HIP packet (CER). 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | Host Identity / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 32 Length length in octets, excluding T and L fields and padding Algorithm Host Identity algorithm Host Identity The following algorithms are defined: Algorithm value RESERVED 0 DSA 1 The encoding format for DSA keys is defined in FIPS 186 and ANSI X9.30 standard. 3.4.7 HOST_ID_FQDN draft-jokela-hip-packets-01.txt [Page 10]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | HI Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Host Identity / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | FQDN Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / FQDN | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 33 Length length in octets, excluding T and L fields and padding Algorithm Host Identity algorithm, defined in HOST_ID TLV Host Identity length length of the HI Host Identity FQDN length length of the FQDN FQDN Fully Qualified Domain Name If there is no FQDN, the HOST_ID TLV is sent instead. The algorithms are the same as defined in 3.4.6. 3.4.8 CERT 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert count | Cert ID | Cert type | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Certificate / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 64 Length length in octets, excluding T and L fields and padding Cert count total count of certificates that are sent, possibly in different CER packets Cert ID the order number for this certificate Cert Type describes the type of the certificate draft-jokela-hip-packets-01.txt [Page 11]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 The receiver must know the total number (Cert count) of certificates that it will receive from the sender, related to the R1 or I2. The Cert ID identifies the particular certificate and its order in the certificate chain. The numbering in Cert ID MUST go from 1 to Cert count. The following certificate types have been identified: Cert format Type number X.509 v3 1 The encoding format for X.509v3 certificate is defined in [RFC2459]. 3.4.9 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 65534 (2^16-2) Length length in octets, excluding T and L fields and padding SIG alg Signature algorithm Signature the signature is calculated over the HIP packet, excluding the HIP_SIGNATURE TLV field. The checksum field MUST be set to zero and the HIP header length in the HIP common header MUST be calculated to the beginning of the HIP_SIGNATURE TLV when the signature is calculated. Signature calculation and verification process: Packet sender: 1. Create the HIP packet without the HIP_SIGNATURE TLV 2. Calculate the length field in the HIP header 3. Compute the signature 4. Add the HIP_SIGNATURE TLV to the packet 5. Recalculate the length field in the HIP header Packet receiver: draft-jokela-hip-packets-01.txt [Page 12]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 1. Verify the HIP header length field 2. Save the HIP_SIGNATURE TLV and remove it from the packet 3. Recalculate the HIP packet length in the HIP header and zero checksum field. 4. Compute the signature and verify it against the received signature The signature algorithms are defined in 3.4.6. The verification can use either the HI received from a HIP packet or the HI from a DNS query, if the FQDN has been received either in the HOST_ID_FQDN or in the CER packet. 3.4.10 HIP_SIGNATURE_2 The TLV structure is the same as in 3.4.9. The fields are: Type 65533 (2^16-3) Length length in octets, excluding T and L fields and padding SIG alg Signature algorithm Signature the signature is calculated over the R1 packet, excluding the HIP_SIGNATURE_2 TLV field. Initiator's HIT and Checksum field MUST be set to zero and the HIP packet length in the HIP header MUST be calculated to the beginning of the HIP_SIGNATURE_2 TLV when the signature is calculated. Zeroing the Initiator's HIT makes it possible to create R1 packets beforehand to minimize the effects of possible DoS attacks. Signature calculation and verification process: see the process in 3.4.9 HIP_SIGNATURE. Just replace the HIP_SIGNATURE with HIP_SIGNATURE_2 and zero Initiator's HIT at the receiver's end-point. The signature algorithms are defined in 3.4.6. The verification can use either the HI received from a HIP packet or the HI from a DNS query, if the FQDN has been received either in the HOST_ID_FQDN or in the CER packet. 3.4.11 REA_INFO 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-jokela-hip-packets-01.txt [Page 13]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | current SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 128 Length length in octets, excluding T and L fields ESP sequence the ESP sequence number from the last sent ESP packet number Current SPI the SPI used for ESP Reserved zero when sent, ignored when received ID Interface ID, local to the host Lifetime Address lifetime Address IPv6 or IPv4-in-IPv6 format [RFC2373] The <ID, Lifetime, Address> triplet may be repeated several times. The maximum header size gives the limit how many triplets may be included in a single packet. 3.4.12 NEW_SPI draft-jokela-hip-packets-01.txt [Page 14]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 Length length in octets, excluding T and L fields ESP sequence number Old SPI New SPI 3.4.13 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 / / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 20 Length length in octets, excluding T and L fields Reserved zero when sent, ignored when received IV Initialization vector, if needed, zero otherwise Encrypted the data is encrypted using an encryption algorithm as data defined in HIP transform The encrypted data is in TLV format itself. Consequently, the first fields in the contents are Type and Length. 4. HIP Packets draft-jokela-hip-packets-01.txt [Page 15]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 The HIP protocol consists of nine packets. Each packet is described in following subsections. Packets contain the fixed HIP header, followed by the parameters. The parameters part consists of zero or more TLV coded parameters. Packet representation uses the following operations: () parameter x{y} operation x on content y <x>i x exists i times [] optional parameter x|y x or y An OPTIONAL upper layer payload MAY follow the HIP header. The payload proto field in the header indicates if there is additional data following the HIP header. The P-bit in the control field of the HIP packet header indicates whether the sender is capable of sending and receiving this additional data. The HIP packet, however, MUST NOT be fragmented. This limits the size of the possible additional data in the packet. 4.1. I1 - the HIP Initiator packet +----------------------+ | Fixed Header | +----------------------+ Header: Packet Type = 1 IP ( HIP () ) The I1 packet contains only the fixed HIP header. Valid control bits: P 4.2. R1 - the HIP Responder packet +----------------------+ | Fixed Header | +----------------------+ | BIRTHDAY_COOKIE | +----------------------+ | DIFFIE_HELLMAN | +----------------------+ draft-jokela-hip-packets-01.txt [Page 16]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 | HIP_TRANSFORM | +----------------------+ | ESP_TRANSFORM | +----------------------+ | HOST_ID | | | HOST_ID_FQDN | +----------------------+ | HIP_SIGNATURE_2 | +----------------------+ Header: Packet Type = 2 IP ( HIP ( BIRTHDAY_COOKIE, DIFFIE_HELLMAN, HIP_TRANSFORM, ESP_TRANSFORM, ( HOST_ID | HOST_ID_FQDN ), HIP_SIGNATURE_2 ) ) The R1 packet may be followed by one or more CER packets. In this case, the C-bit in the header control field MUST be set. Valid control bits: P, C, A 4.3. I2 - the HIP Second Initiator packet +----------------------+ | Fixed Header | +----------------------+ | SPI_LSI | +----------------------+ | BIRTHDAY_COOKIE | +----------------------+ | DIFFIE_HELLMAN | +----------------------+ | HIP_TRANSFORM | +----------------------+ | ESP_TRANSFORM | +----------------------+ | ENCRYPTED | +----------------------+ | HIP_SIGNATURE | +----------------------+ Header: Packet Type = 3 draft-jokela-hip-packets-01.txt [Page 17]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 IP ( HIP ( SPI_LSI, BIRTHDAY_COOKIE, DIFFIE_HELLMAN, HIP_TRANSFORM, ESP_TRANSFORM, ENCRYPTED { HOST_ID | HOST_ID_FQDN }, HIP_SIGNATURE ) ) The HOST_ID or the HOST_ID_FQDN field is encrypted and it is as a payload in the ENCRYPTED field. The I2 packet may be followed by one or more CER packets. In this case, the C-bit in the header control field MUST be set. Valid control bits: P, C, E, A 4.4. R2 - the HIP Second Responder packet +----------------------+ | Fixed Header | +----------------------+ | SPI_LSI | +----------------------+ | HIP_SIGNATURE | +----------------------+ Header: Packet Type = 4 IP ( HIP ( SPI_LSI, HIP_SIGNATURE ) ) Valid control bits: P, E 4.5. NES - the HIP New SPI Packet +----------------------+ | Fixed Header | +----------------------+ | NEW_SPI | +----------------------+ | DIFFIE_HELLMAN (opt) | +----------------------+ | HIP_SIGNATURE | +----------------------+ draft-jokela-hip-packets-01.txt [Page 18]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 Header: Packet Type = 5 IP ( HIP ( NEW_SPI [ ,DIFFIE_HELLMAN ], HIP_SIGNATURE ) ) Valid control bits: P 4.6. REA - the HIP Readdress Packet +----------------------+ | Fixed Header | +----------------------+ | REA_INFO | +----------------------+ | HIP_SIGNATURE | +----------------------+ Header: Packet Type = 6 IP ( HIP ( REA_INFO, HIP_SIGNATURE ) ) Valid control bits: P 4.7. BOS - the HIP Bootstrap Packet +----------------------+ | Fixed Header | +----------------------+ | HOST_ID | | | HOST_ID_FQDN | +----------------------+ | HIP_SIGNATURE | +----------------------+ Header: Packet Type = 7 IP ( HIP ( ( HOST_ID | HOST_ID_FQDN ), HIP_SIGNATURE ) ) draft-jokela-hip-packets-01.txt [Page 19]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 The BOS packet may be followed by a CER packet if the HI is signed. In this case, the C-bit in the header control field MUST be set. Valid control bits: P, C, A 4.8. CER - the HIP Certificate Packet +----------------------+ | Fixed Header | +----------------------+ | ENCRYPTED | +----------------------+ | HIP_SIGNATURE | +----------------------+ Header: Packet Type = 8 IP ( HIP ( ENCRYPTED { <CERT>i }, HIP_SIGNATURE ) ) Certificates in the CER packet MAY be encrypted. The encryption algorithm is provided in the HIP transform of the previous (R1 or I2) packet. Valid control bits: P 4.9. PAYLOAD - the HIP Payload Packet +----------------------+ | Fixed Header | +----------------------+ | payload | +----------------------+ Header: Packet Type = 64 IP ( HIP ( payload ) ) Payload Proto field in the Header MUST be set to correspond the correct protocol number of the payload. The PAYLOAD packet is used to carry a non-ESP protected data. By usign HIP header we ensure interoperability with NAT and other draft-jokela-hip-packets-01.txt [Page 20]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 middle boxes. Processing rules of the PAYLOAD packet are the following: Receiving: if there is an existing HIP security association with the given HITs, and the IP addresses match the IP addresses associated with the HITs, pass the packet to the upper layer, associated with metadata indicating that the packet was NOT integrity or confidentiality protected. Sending: if the IPsec SPD defines BYPASS for a given destination HIT, send it with the PAYLOAD packet. Otherwise use the ESP as specified in the SPD. Valid control bits: P 5. Security considerations This draft does not change the security framework presented in [HIP] but defines an alternative packet structure. The new structure brings some enhancements to the security. The checksum calculation provides means to detect transmission errors in packets without calculating the signature, thus making error detection more efficient. The strict order of TLVs and the semantic differentiation between them makes the interpretation of these fields definite. A separate signature, HIP_SIGNATURE_2 TLV, allows the generation of the R1 packet beforehand. This provides a better protection against DoS attacks which has been main principle in HIP design. The new CER packet provides support for different kinds of PKI solutions. 6. References [HIP], Moskowitz, R., "Host Identity Payload and Protocol", draft-ietf-moskowitz-hip-05.txt, November 2001, "Expired". [HIPARCH], Moskowitz, R., "Host Identity Payload Architecture", draft-ietf-moskowitz-hip-arch-03.txt, January 2001, "Expired". draft-jokela-hip-packets-01.txt [Page 21]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 [HIPIMPL], Moskowitz, R., "Host Identity Payload Implementation", draft-ietf-moskowitz-hip-impl-02.txt, January 2001, "Expired". [IKEv2], Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-03.txt, October 2002, "work in progress". [JFK], Aiello, W., Bellovin, S.M., Blaze, M., Canetti, R., Ioannidis, J., Keromytis, A.D., Reingold, O., "Just Fast Keying (JFK)", draft-ietf-ipsec-jfk-04.txt, September 2002, "work in progress". [MIPv6], Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18.txt, June 2002, "work in progress". [MODP], Kivinen, T., Kojo, M., "More MODP Diffie-Hellman groups for IKE", http://hip4inter.net/documentation/draft-ietf-ipsec-ike-modp- groups-04.txt, December 2001, "Expired". [PRN], "Protocol Numbers", IANA, http://www.iana.org/assignments/protocol-numbers, September 2002 [RFC2373], R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC2407], Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC2407, November 1998 [RFC2459], Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC2459, January 1999 [RFC2460], Deering ,S., Hinden, R., "Internet Protocol, version 6 Specification", RFC2460, December 1998 7. Change History Changes from hip-packets-00 to hip-packets-01. 1) Fixed typos. 2) DIFFIE_HELLMAN_FULL TLV has been removed. 3) Groups IDs for DIFFIE_HELLMAN TLV has benn changed. Old OAKLEY draft-jokela-hip-packets-01.txt [Page 22]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 groups has been replaced with MODP groups defined in [MODP]. 4) The structure of HIP_TRANSFORM TLV has been changed. 5) ESP_ENC_TRANSFORM and ESP_AUTH_TRANSFORM TLVs are combined together. The new TLV is named as ESP_TRANSFORM. We have predefined Suites for ESP encryption and authentication on account of [IKEv2] [JFK]. 6) TLVs total length calculation formula has been corrected in chapter 3.4. 7) HIP packet structures in chapter 4 have been changed to follow the new ESP_TRANSFORM TLV. 8) A new packet, PAYLOAD, has been added. 8. Acknowledgments Thanks to R. Moskowitz, A. McGregor, The Boeing HIP implementation team and to the HIPL team C. Candolin, J. Lundberg, M. Kousa, M. Komu. A special thanks to Kimmo Nieminen for his valuable feedback. 9. Author's Addresses Petri Jokela Oy L M Ericsson Ab FIN-02420 JORVAS Finland Phone: +358 9 299 2413 Fax: +358 9 299 3535 E-mail: petri.jokela@ericsson.fi Jorma Wall Oy L M Ericsson Ab FIN-02420 JORVAS Finland Phone: +358 9 299 3343 Fax: +358 9 299 3535 E-mail: jorma.wall@ericsson.fi draft-jokela-hip-packets-01.txt [Page 23]
INTERNET-DRAFT Optimized Packet Structure for HIP November 1, 2002 Jukka Ylitalo Oy L M Ericsson Ab FIN-02420 JORVAS Finland Phone: +358 9 299 2622 Fax: +358 9 299 3535 E-mail: jukka.ylitalo@ericsson.fi Pekka Nikander Oy L M Ericsson Ab FIN-02420 JORVAS Finland Phone: +358 9 299 3143 Fax: +358 9 299 3535 E-mail: pekka.nikander@ericsson.fi 10. Copyright Statement Copyright (c) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. draft-jokela-hip-packets-01.txt [Page 24]