One document matched: draft-jokela-hip-packets-01.txt
Differences from draft-jokela-hip-packets-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-20 20:34:44 |