< draft-moskowitz-hip-08.txt   draft-moskowitz-hip-09.txt >
Network Working Group R. Moskowitz Network Working Group R. Moskowitz
Internet-Draft ICSAlabs, a Division of TruSecure Internet-Draft ICSAlabs, a Division of TruSecure
Expires: April 22, 2004 Corporation Expires: August 10, 2004 Corporation
P. Nikander (editor) P. Nikander
P. Jokela P. Jokela (editor)
Ericsson Research Nomadiclab Ericsson Research Nomadiclab
T. Henderson T. Henderson
The Boeing Company The Boeing Company
October 23, 2003 February 10, 2004
Host Identity Protocol Host Identity Protocol
draft-moskowitz-hip-08 draft-moskowitz-hip-09
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2004. This Internet-Draft will expire on August 10, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo specifies the details of the Host Identity Protocol (HIP). This memo specifies the details of the Host Identity Protocol (HIP).
The overall description of protocol and the underlying architectural The overall description of protocol and the underlying architectural
thinking is available in the separate HIP architecture specification. thinking is available in the separate HIP architecture specification.
The Host Identity Protocol is used to establish a rapid The Host Identity Protocol is used to establish a rapid
authentication between two hosts and to provide continuity of authentication between two hosts and to provide continuity of
communications between those hosts independent of the networking communications between those hosts independent of the networking
layer. layer.
The various forms of the Host Identity, Host Identity Tag (HIT) and The various forms of the Host Identity, Host Identity Tag (HIT) and
Local Scope Identifier (LSI), are covered in detail. It is described Local Scope Identifier (LSI), are covered in detail. It is described
how they are used to support authentication and the establishment of how they are used to support authentication and the establishment of
keying material, which is then used by IPsec Encapsulated Security keying material, which is then used by IPsec Encapsulated Security
payload (ESP) to establish a two-way secured communication channel payload (ESP) to establish a two-way secured communication channel
between the hosts. The basic state machine for HIP provides a HIP between the hosts. The basic state machine for HIP provides a HIP
compliant host with the resiliency to avoid many denial-of-service compliant host with the resiliency to avoid many denial-of-service
(DoS) attacks. The basic HIP exchange for two public hosts shows the (DoS)attacks. The basic HIP exchange for two public hosts shows the
actual packet flow. Other HIP exchanges, including those that work actual packet flow. Other HIP exchanges, including those that work
across NATs are covered elsewhere. across NATs are covered elsewhere.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 A new name space and identifiers . . . . . . . . . . . . . 5 1.1 A new name space and identifiers . . . . . . . . . . . . . 5
1.2 The HIP protocol . . . . . . . . . . . . . . . . . . . . . 5 1.2 The HIP protocol . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions used in this document . . . . . . . . . . . . 7 2. Conventions used in this document . . . . . . . . . . . . 7
3. Host Identifier (HI) and its representations . . . . . . . 8 3. Host Identifier (HI) and its representations . . . . . . . 8
3.1 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8 3.1 Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 8
3.1.1 Generating a HIT from a HI . . . . . . . . . . . . . . . . 8 3.1.1 Generating a HIT from a HI . . . . . . . . . . . . . . . . 9
3.2 Local Scope Identifier (LSI) . . . . . . . . . . . . . . . 9 3.2 Local Scope Identifier (LSI) . . . . . . . . . . . . . . . 9
3.3 Security Parameter Index (SPI) . . . . . . . . . . . . . . 10 3.3 Security Parameter Index (SPI) . . . . . . . . . . . . . . 10
3.4 Difference between an LSI and the SPI . . . . . . . . . . 11 3.4 Difference between an LSI and the SPI . . . . . . . . . . 11
3.5 TCP and UDP pseudo-header computation . . . . . . . . . . 11 3.5 TCP and UDP pseudo-header computation . . . . . . . . . . 11
4. Host Identity Protocol . . . . . . . . . . . . . . . . . . 12 4. Host Identity Protocol . . . . . . . . . . . . . . . . . . 13
4.1 HIP base exchange . . . . . . . . . . . . . . . . . . . . 12 4.1 HIP base exchange . . . . . . . . . . . . . . . . . . . . 13
4.1.1 HIP Cookie Mechanism . . . . . . . . . . . . . . . . . . . 13 4.1.1 HIP Cookie Mechanism . . . . . . . . . . . . . . . . . . . 14
4.1.2 Authenticated Diffie-Hellman protocol . . . . . . . . . . 15 4.1.2 Authenticated Diffie-Hellman protocol . . . . . . . . . . 16
4.1.3 HIP Birthday . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3 HIP Birthday . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Sending data on HIP packets . . . . . . . . . . . . . . . 16 4.2 Sending data on HIP packets . . . . . . . . . . . . . . . 17
4.3 Rekey . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3 Rekey . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Bootstrap support . . . . . . . . . . . . . . . . . . . . 16 4.4 Bootstrap support . . . . . . . . . . . . . . . . . . . . 18
4.5 Certificate distribution . . . . . . . . . . . . . . . . . 17 4.5 Certificate distribution . . . . . . . . . . . . . . . . . 18
5. HIP packet flow and state machine . . . . . . . . . . . . 18 5. HIP packet flow and state machine . . . . . . . . . . . . 19
5.1 HIP Scenarios . . . . . . . . . . . . . . . . . . . . . . 18 5.1 HIP Scenarios . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Refusing a HIP exchange . . . . . . . . . . . . . . . . . 19 5.2 Refusing a HIP exchange . . . . . . . . . . . . . . . . . 20
5.3 Reboot and SA timeout restart of HIP . . . . . . . . . . . 19 5.3 Reboot and SA timeout restart of HIP . . . . . . . . . . . 20
5.4 HIP State Machine . . . . . . . . . . . . . . . . . . . . 20 5.4 HIP State Machine . . . . . . . . . . . . . . . . . . . . 20
5.4.1 HIP States . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4.1 HIP States . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4.2 HIP State Processes . . . . . . . . . . . . . . . . . . . 20 5.4.2 HIP State Processes . . . . . . . . . . . . . . . . . . . 21
5.4.3 Simplified HIP State Diagram . . . . . . . . . . . . . . . 22 5.4.3 Simplified HIP State Diagram . . . . . . . . . . . . . . . 24
6. Packet formats . . . . . . . . . . . . . . . . . . . . . . 24 6. Packet formats . . . . . . . . . . . . . . . . . . . . . . 26
6.1 Payload format . . . . . . . . . . . . . . . . . . . . . . 24 6.1 Payload format . . . . . . . . . . . . . . . . . . . . . . 26
6.1.1 HIP Controls . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.1 HIP Controls . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 HIP parameters . . . . . . . . . . . . . . . . . . . . . . 26 6.2 HIP parameters . . . . . . . . . . . . . . . . . . . . . . 28
6.2.1 TLV format . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2.1 TLV format . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.2 Defining new parameters . . . . . . . . . . . . . . . . . 28 6.2.2 Defining new parameters . . . . . . . . . . . . . . . . . 30
6.2.3 SPI_LSI . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2.3 SPI_LSI . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.4 BIRTHDAY_COOKIE . . . . . . . . . . . . . . . . . . . . . 29 6.2.4 BIRTHDAY_COOKIE . . . . . . . . . . . . . . . . . . . . . 33
6.2.5 DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . . . . 30 6.2.5 DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . . . . 33
6.2.6 HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 31 6.2.6 HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 34
6.2.7 ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 31 6.2.7 ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 35
6.2.8 HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.2.8 HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2.9 HOST_ID_FQDN . . . . . . . . . . . . . . . . . . . . . . . 33 6.2.9 CERT . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.10 CERT . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.2.10 HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.11 HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.2.11 HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . . . 39
6.2.12 HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . . . 35 6.2.12 HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . . . 39
6.2.13 HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . . . 36 6.2.13 NES . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.14 NES_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.2.14 ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2.15 ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . . . 38 7. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 43
7. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 40 7.1 I1 - the HIP initiator packet . . . . . . . . . . . . . . 43
7.1 I1 - the HIP initiator packet . . . . . . . . . . . . . . 40 7.2 R1 - the HIP responder packet . . . . . . . . . . . . . . 44
7.2 R1 - the HIP responder packet . . . . . . . . . . . . . . 41 7.3 I2 - the second HIP initiator packet . . . . . . . . . . . 45
7.3 I2 - the second HIP initiator packet . . . . . . . . . . . 42 7.4 R2 - the second HIP responder packet . . . . . . . . . . . 46
7.4 R2 - the second HIP responder packet . . . . . . . . . . . 43 7.5 UPDATE - the HIP New SPI Packet . . . . . . . . . . . . . 46
7.5 NES - the HIP New SPI Packet . . . . . . . . . . . . . . . 43 7.6 BOS - the HIP Bootstrap Packet . . . . . . . . . . . . . . 47
7.6 BOS - the HIP Bootstrap Packet . . . . . . . . . . . . . . 44 7.7 CER - the HIP Certificate Packet . . . . . . . . . . . . . 48
7.7 CER - the HIP Certificate Packet . . . . . . . . . . . . . 45 7.8 PAYLOAD - the HIP Payload Packet . . . . . . . . . . . . . 48
7.8 PAYLOAD - the HIP Payload Packet . . . . . . . . . . . . . 45 8. Packet processing . . . . . . . . . . . . . . . . . . . . 50
8. Packet processing . . . . . . . . . . . . . . . . . . . . 47 8.1 Processing outgoing application data . . . . . . . . . . . 50
8.1 Processing outgoing application data . . . . . . . . . . . 47 8.2 Processing incoming application data . . . . . . . . . . . 51
8.2 Processing incoming application data . . . . . . . . . . . 48 8.3 HMAC and SIGNATURE calculation and verification . . . . . 52
8.3 Initiation of a HIP exchange . . . . . . . . . . . . . . . 49 8.3.1 HMAC calculation . . . . . . . . . . . . . . . . . . . . . 52
8.3.1 Sending multiple I1s in parallel . . . . . . . . . . . . . 50 8.3.2 Signature calculation . . . . . . . . . . . . . . . . . . 53
8.3.2 Processing incoming ICMP Protocol Unreachable messages . . 50 8.4 Initiation of a HIP exchange . . . . . . . . . . . . . . . 53
8.4 Processing incoming I1 packets . . . . . . . . . . . . . . 50 8.4.1 Sending multiple I1s in parallel . . . . . . . . . . . . . 54
8.4.1 R1 Management . . . . . . . . . . . . . . . . . . . . . . 51 8.4.2 Processing incoming ICMP Protocol Unreachable messages . . 55
8.5 Processing incoming R1 packets . . . . . . . . . . . . . . 51 8.5 Processing incoming I1 packets . . . . . . . . . . . . . . 55
8.6 Processing incoming I2 packets . . . . . . . . . . . . . . 54 8.5.1 R1 Management . . . . . . . . . . . . . . . . . . . . . . 56
8.7 Processing incoming R2 packets . . . . . . . . . . . . . . 56 8.6 Processing incoming R1 packets . . . . . . . . . . . . . . 56
8.8 Initiating rekeying . . . . . . . . . . . . . . . . . . . 57 8.7 Processing incoming I2 packets . . . . . . . . . . . . . . 58
8.9 Processing NES packets . . . . . . . . . . . . . . . . . . 58 8.8 Processing incoming R2 packets . . . . . . . . . . . . . . 60
8.9.1 Processing an initial NES packet . . . . . . . . . . . . . 59 8.9 Initiating rekeying . . . . . . . . . . . . . . . . . . . 61
8.9.2 Processing a reply NES packet . . . . . . . . . . . . . . 60 8.10 Processing UPDATE packets . . . . . . . . . . . . . . . . 62
8.10 Processing BOS packets . . . . . . . . . . . . . . . . . . 60 8.10.1 Processing an initial UPDATE packet . . . . . . . . . . . 63
8.11 Processing CER packets . . . . . . . . . . . . . . . . . . 60 8.10.2 Processing a reply UPDATE packet . . . . . . . . . . . . . 64
8.12 Processing PAYLOAD packets . . . . . . . . . . . . . . . . 61 8.11 Processing BOS packets . . . . . . . . . . . . . . . . . . 65
9. HIP KEYMAT . . . . . . . . . . . . . . . . . . . . . . . . 62 8.12 Processing CER packets . . . . . . . . . . . . . . . . . . 65
10. HIP Fragmentation Support . . . . . . . . . . . . . . . . 64 8.13 Processing PAYLOAD packets . . . . . . . . . . . . . . . . 65
11. ESP with HIP . . . . . . . . . . . . . . . . . . . . . . . 65 9. HIP KEYMAT . . . . . . . . . . . . . . . . . . . . . . . . 66
11.1 Security Association Management . . . . . . . . . . . . . 65 10. HIP Fragmentation Support . . . . . . . . . . . . . . . . 68
11.2 Security Parameter Index (SPI) . . . . . . . . . . . . . . 65 11. ESP with HIP . . . . . . . . . . . . . . . . . . . . . . . 69
11.3 Supported Transforms . . . . . . . . . . . . . . . . . . . 65 11.1 ESP Security Associations . . . . . . . . . . . . . . . . 69
11.4 Sequence Number . . . . . . . . . . . . . . . . . . . . . 65 11.2 Updating ESP SAs during rekeying . . . . . . . . . . . . . 69
12. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . 67 11.3 Security Association Management . . . . . . . . . . . . . 70
13. Security Considerations . . . . . . . . . . . . . . . . . 68 11.4 Security Parameter Index (SPI) . . . . . . . . . . . . . . 70
14. IANA Considerations . . . . . . . . . . . . . . . . . . . 70 11.5 Supported Transforms . . . . . . . . . . . . . . . . . . . 70
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 71 11.6 Sequence Number . . . . . . . . . . . . . . . . . . . . . 70
Normative references . . . . . . . . . . . . . . . . . . . 72 12. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . 72
Informative references . . . . . . . . . . . . . . . . . . 74 13. Security Considerations . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 74 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 75
A. Backwards compatibility API issues . . . . . . . . . . . . 76 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 76
B. Probabilities of HIT collisions . . . . . . . . . . . . . 79 Normative references . . . . . . . . . . . . . . . . . . . 77
C. Probabilities in the cookie calculation . . . . . . . . . 80 Informative references . . . . . . . . . . . . . . . . . . 79
D. Using responder cookies . . . . . . . . . . . . . . . . . 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 79
E. Running HIP over IPv4 UDP . . . . . . . . . . . . . . . . 84 A. Backwards compatibility API issues . . . . . . . . . . . . 81
Intellectual Property and Copyright Statements . . . . . . 85 B. Probabilities of HIT collisions . . . . . . . . . . . . . 84
C. Probabilities in the cookie calculation . . . . . . . . . 85
D. Using responder cookies . . . . . . . . . . . . . . . . . 86
E. Running HIP over IPv4 UDP . . . . . . . . . . . . . . . . 89
F. Example checksums for HIP packets . . . . . . . . . . . . 90
F.1 IPv6 HIP example (I1) . . . . . . . . . . . . . . . . . . 90
F.2 IPv4 HIP packet (I1) . . . . . . . . . . . . . . . . . . . 90
F.3 TCP segment . . . . . . . . . . . . . . . . . . . . . . . 90
Intellectual Property and Copyright Statements . . . . . . 92
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) provides a rapid exchange of Host The Host Identity Protocol (HIP) provides a rapid exchange of Host
Identities between two hosts. The exchange also establishes a pair Identities between two hosts. The exchange also establishes a pair
IPsec Security Associations (SA), to be used with IPsec Encapsulated IPsec Security Associations (SA), to be used with IPsec Encapsulated
Security Payload (ESP) [15]. The HIP protocol is designed to be Security Payload (ESP) [15]. The HIP protocol is designed to be
resistant to Denial-of-Service (DoS) and Man-in-the-middle (MitM) resistant to Denial-of-Service (DoS) and Man-in-the-middle (MitM)
attacks, and when used to enable ESP, provides DoS and MitM attacks, and when used to enable ESP, provides DoS and MitM
protection for upper layer protocols, such as TCP and UDP. protection for upper layer protocols, such as TCP and UDP.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
design helps to make HIP DoS resilient. The protocol exchanges design helps to make HIP DoS resilient. The protocol exchanges
Diffie-Hellman keys in the 2nd and 3rd packets, and authenticates the Diffie-Hellman keys in the 2nd and 3rd packets, and authenticates the
parties in the 3rd and 4th packets. Additionally, it starts the parties in the 3rd and 4th packets. Additionally, it starts the
cookie exchange in the 2nd packet, completing it in the 3rd packet. cookie exchange in the 2nd packet, completing it in the 3rd packet.
The exchange uses the Diffie-Hellman exchange to hide the Host The exchange uses the Diffie-Hellman exchange to hide the Host
Identity of the Initiator in packet 3. The Responder's Host Identity Identity of the Initiator in packet 3. The Responder's Host Identity
is not protected. It should be noted, however, that both the is not protected. It should be noted, however, that both the
Initiator's and the Responder's HITs are transported as such (in Initiator's and the Responder's HITs are transported as such (in
cleartext) in the packets, allowing an eavesdropper with a priori cleartext) in the packets, allowing an eavesdropper with a priori
knowledge about the parties to verify their identies. knowledge about the parties to verify their identities.
Data packets start after the 4th packet. The 3rd and 4th HIP packets Data packets start after the 4th packet. The 3rd and 4th HIP packets
may carry a data payload in the future. However, the details of this may carry a data payload in the future. However, the details of this
are to be defined later as more implementation experience is gained. are to be defined later as more implementation experience is gained.
Finally, HIP is designed as an end-to-end authentication and key Finally, HIP is designed as an end-to-end authentication and key
establishment protocol. It lacks much of the fine-grain policy establishment protocol. It lacks much of the fine-grain policy
control found in IKE that allows IKE to support complex gateway control found in IKE that allows IKE to support complex gateway
policies. Thus, HIP is not a complete replacement for IKE. policies. Thus, HIP is not a complete replacement for IKE.
skipping to change at page 9, line 4 skipping to change at page 9, line 6
This document fully specifies only type 1 HITs. HITs that consists This document fully specifies only type 1 HITs. HITs that consists
of the HAA field and the hash are specified in [20]. of the HAA field and the hash are specified in [20].
Any conforming implementation MUST be able to deal with both types of Any conforming implementation MUST be able to deal with both types of
HITs. When handling other than type 1 HITs, the implementation is HITs. When handling other than type 1 HITs, the implementation is
RECOMMENDED to explicitly learn and record the binding between the RECOMMENDED to explicitly learn and record the binding between the
Host Identifier and the HIT, as it may not be able generate such HITs Host Identifier and the HIT, as it may not be able generate such HITs
from Host Identifiers. from Host Identifiers.
3.1.1 Generating a HIT from a HI 3.1.1 Generating a HIT from a HI
The 126 or 64 hash bits in a HIT MUST be generated by taking the The 126 or 64 hash bits in a HIT MUST be generated by taking the
least significant 126 or 64 bits of the SHA-1 [18] hash of the Host least significant 126 or 64 bits of the SHA-1 [18] hash of the Host
Identifier as it is represented in the Host Identity field in a HIP Identifier as it is represented in the Host Identity field in a HIP
payload packet. payload packet.
For Identities that are DSA public keys, the HIT is formed as For Identities that are DSA public keys, the HIT is formed as
follows: follows:
1. The DSA public key is encoded as defined in RFC2536 [10] Section 1. The DSA public key is encoded as defined in RFC2536 [10] Section
2, taking the fields T, Q, P, G, and Y, concatenated. Thus, the 2, taking the fields T, Q, P, G, and Y, concatenated. Thus, the
data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long,
where T is the size parameter as defined in RFC2536 [10]. The where T is the size parameter as defined in RFC2536 [10]. The
size parameter T, affecting the field lengths, MUST be selected size parameter T, affecting the field lengths, MUST be selected
as the minimum value that is long enough to accomodate P, G, and as the minimum value that is long enough to accommodate P, G, and
Y. The fields MUST be encoded in network byte order, as defined Y. The fields MUST be encoded in network byte order, as defined
in RFC2536 [10]. in RFC2536 [10].
2. A SHA-1 hash [18] is calculated over the encoded key. 2. A SHA-1 hash [18] is calculated over the encoded key.
3. The least significant 126 or 64 bits of the hash result are used 3. The least significant 126 or 64 bits of the hash result are used
to create the HIT, as defined above. to create the HIT, as defined above.
The following pseudo-code illustrates the process. The symbol := The following pseudo-code illustrates the process. The symbol :=
denotes assignment; the symbol += denotes appending. The denotes assignment; the symbol += denotes appending. The
skipping to change at page 11, line 25 skipping to change at page 11, line 27
host; this is to avoid a replay attack. Additionally, when a host host; this is to avoid a replay attack. Additionally, when a host
rekeys, the SPI MUST be changed. Furthermore, if a host changes over rekeys, the SPI MUST be changed. Furthermore, if a host changes over
to use a different IP address, it MAY change the SPI. to use a different IP address, it MAY change the SPI.
One method for SPI creation that meets these criteria would be to One method for SPI creation that meets these criteria would be to
concatenate the HIT with a 32 bit random or sequential number, hash concatenate the HIT with a 32 bit random or sequential number, hash
this (using SHA1), and then use the high order 32 bits as the SPI. this (using SHA1), and then use the high order 32 bits as the SPI.
The selected SPI is communicated to the peer in the third (I2) and The selected SPI is communicated to the peer in the third (I2) and
fourth (R2) packets of the base HIP exchange. Changes in SPI are fourth (R2) packets of the base HIP exchange. Changes in SPI are
signalled with NES packets. signaled with NES packets.
3.4 Difference between an LSI and the SPI 3.4 Difference between an LSI and the SPI
There is a subtle difference between an LSI and a SPI. There is a subtle difference between an LSI and a SPI.
The LSI is designed to be relatively long-lived. A system selects The LSI is designed to be relatively long-lived. A system selects
the LSI it locally uses to represent its peer, and it SHOULD reuse a the LSI it locally uses to represent its peer, and it SHOULD reuse a
previous LSI for a HIT during a subsequent HIP exchange. This could previous LSI for a HIT during a subsequent HIP exchange. This could
be important in a timeout recovery situation. The LSI only appears be important in a timeout recovery situation. The LSI only appears
in the 3rd and 4th HIP packets. The LSI is used anywhere in system in the 3rd and 4th HIP packets. The LSI is used anywhere in system
skipping to change at page 14, line 33 skipping to change at page 15, line 33
R1 once every few minutes. Furthermore, it is RECOMMENDED that the R1 once every few minutes. Furthermore, it is RECOMMENDED that the
Responder remembers an old cookie at least 60 seconds after it has Responder remembers an old cookie at least 60 seconds after it has
been deprecated. These time values allow a slower Initiator to solve been deprecated. These time values allow a slower Initiator to solve
the cookie puzzle while limiting the usability that an old, solved the cookie puzzle while limiting the usability that an old, solved
cookie has to an attacker. cookie has to an attacker.
NOTE: The protocol developers explicitly considered whether R1 should NOTE: The protocol developers explicitly considered whether R1 should
include a timestamp in order to protect the Initiator from replay include a timestamp in order to protect the Initiator from replay
attacks. The decision was NOT to include a timestamp. attacks. The decision was NOT to include a timestamp.
In R1, the values I and K are sent in network byte order. Similarily, In R1, the values I and K are sent in network byte order. Similarly,
in I2 the values I and J are sent in network byte order. The SHA-1 in I2 the values I and J are sent in network byte order. The SHA-1
hash is created by concatenating, in network byte order, the hash is created by concatenating, in network byte order, the
following data, in the following order: following data, in the following order:
64-bit random value I, in network byte order, as appearing in R1 64-bit random value I, in network byte order, as appearing in R1
and I2. and I2.
128-bit initiator HIT, in network byte order, as appearing in the 128-bit initiator HIT, in network byte order, as appearing in the
HIP Payload in R1 and I2. HIP Payload in R1 and I2.
skipping to change at page 15, line 38 skipping to change at page 16, line 38
Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) == 0 Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) == 0
Sends I and J in HIP Cookie in a I2. Sends I and J in HIP Cookie in a I2.
Responder Verifies that the received I is a saved one. Responder Verifies that the received I is a saved one.
Finds the right K based on I. Finds the right K based on I.
Computes V := Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K ) Computes V := Ltrunc( SHA-1( I | HIT-I | HIT-R | J ), K )
Rejects if V != 0 Rejects if V != 0
Accept if V == 0 Accept if V == 0
The Ltrunc (SHA-1(), K) denotes the lowest order K bits of the SHA-1
result.
4.1.2 Authenticated Diffie-Hellman protocol 4.1.2 Authenticated Diffie-Hellman protocol
The packets R1, I2, and R2 implement a standard authenticated The packets R1, I2, and R2 implement a standard authenticated
Diffie-Hellman exchange. The Responder sents its public Diffie-Hellman exchange. The Responder sends its public
Diffie-Hellman key and its public authentication key, i.e., its host Diffie-Hellman key and its public authentication key, i.e., its host
identity, in R1. The signature in R1 allows the Initiator to verify identity, in R1. The signature in R1 allows the Initiator to verify
that the R1 has been once generated by the Responder. However, since that the R1 has been once generated by the Responder. However, since
it is precomputed and therefore does not cover all of the packet, it it is precomputed and therefore does not cover all of the packet, it
does not protect from replay attacks. does not protect from replay attacks.
When the Initiator receives an R1, it computes the Diffie-Hellman When the Initiator receives an R1, it computes the Diffie-Hellman
session key. It creates a HIP security association using keying session key. It creates a HIP security association using keying
material from the session key (see Section 9), and uses the security material from the session key (see Section 9), and uses the security
association to encrypt its public authentication key, i.e., host association to encrypt its public authentication key, i.e., host
skipping to change at page 17, line 12 skipping to change at page 18, line 17
This memo defines an OPTIONAL HIP based bootstrap mechanism, intended This memo defines an OPTIONAL HIP based bootstrap mechanism, intended
for ad hoc like environments; see Section 7.6. There is little for ad hoc like environments; see Section 7.6. There is little
operational experience of the usability of this mechanism, and it may operational experience of the usability of this mechanism, and it may
be dropped or completely revised in some future protocol version. be dropped or completely revised in some future protocol version.
4.5 Certificate distribution 4.5 Certificate distribution
HIP does not define how to use certificates. However, it does define HIP does not define how to use certificates. However, it does define
a simple certificate transport mechanisms that MAY be used to a simple certificate transport mechanisms that MAY be used to
implement certificate based security policies. The certificate implement certificate based security policies. The certificate
payload is defined in Section 6.2.10, and the certificate packet in payload is defined in Section 6.2.9, and the certificate packet in
Section 7.7. Section 7.7.
5. HIP packet flow and state machine 5. HIP packet flow and state machine
A typical HIP packet flow is shown below. A typical HIP packet flow is shown below.
I --> Directory: lookup of R I --> Directory: lookup of R
I <-- Directory: return R's addresses, and HI and/or HIT I <-- Directory: return R's addresses, and HI and/or HIT
I1 I --> R (Hi. Here is my I1, let's talk HIP) I1 I --> R (Hi. Here is my I1, let's talk HIP)
R1 I <-- R (OK. Here is my R1, handle this HIP cookie) R1 I <-- R (OK. Here is my R1, handle this HIP cookie)
skipping to change at page 18, line 41 skipping to change at page 19, line 41
Initiator acts as in no prior state, sending I1 and getting R1. Initiator acts as in no prior state, sending I1 and getting R1.
When the Receiver gets an I2, the old SAs are 'discovered' and When the Receiver gets an I2, the old SAs are 'discovered' and
deleted; the new SAs are established. deleted; the new SAs are established.
The system with data to send has an SA, but the receiver does not. The system with data to send has an SA, but the receiver does not.
The receiver 'detects' the situation when it receives an ESP The receiver 'detects' the situation when it receives an ESP
packet that contains an unknown SPI. The receiver sends an R1 packet that contains an unknown SPI. The receiver sends an R1
with a NULL initiator HIT. The sender gets the R1 with a later with a NULL initiator HIT. The sender gets the R1 with a later
birthdate, discards old SA, and continues the base exchange to birthday, discards old SA, and continues the base exchange to
establish new SAs for sending data. establish new SAs for sending data.
A peer determines that it needs to reset Sequence number or rekey. A peer determines that it needs to reset Sequence number or rekey.
It sends NES. Receiver sends NES response, establishes new SAs It sends UPDATE. Receiver sends UPDATE response, establishes
for peers. new SAs for peers.
5.2 Refusing a HIP exchange 5.2 Refusing a HIP exchange
A HIP aware host may choose not to accept a HIP exchange. If the A HIP aware host may choose not to accept a HIP exchange. If the
host's policy is to only be an initiator, it should begin its own HIP host's policy is to only be an initiator, it should begin its own HIP
exchange. A host MAY choose to have such a policy since only the exchange. A host MAY choose to have such a policy since only the
initiator HI is protected in the exchange. There is a risk of a race initiator HI is protected in the exchange. There is a risk of a race
condition if each host's policy is to only be an Initiator, at which condition if each host's policy is to only be an Initiator, at which
point the HIP exchange will fail. point the HIP exchange will fail.
skipping to change at page 19, line 35 skipping to change at page 20, line 35
If a host reboots or times out, it has lost its HIP state. If the If a host reboots or times out, it has lost its HIP state. If the
system that lost state has a datagram to deliver to its peer, it system that lost state has a datagram to deliver to its peer, it
simply restarts the HIP exchange. The peer sends an R1 HIP packet, simply restarts the HIP exchange. The peer sends an R1 HIP packet,
but does not reset its state until it receives the I2 HIP packet. but does not reset its state until it receives the I2 HIP packet.
The I2 packet MUST have a Birthday greater than the current SA's The I2 packet MUST have a Birthday greater than the current SA's
Birthday. This is to handle DoS attacks that simulate a reboot of a Birthday. This is to handle DoS attacks that simulate a reboot of a
peer. Note that either the original Initiator or the Responder could peer. Note that either the original Initiator or the Responder could
end up restarting the exchange, becoming the new Initiator. end up restarting the exchange, becoming the new Initiator.
If a system receives an ESP packet for an unknown SPI, the assumption If a system receives an ESP packet for an unknown SPI, it is possible
is that it has lost the state and its peer did not. In this case, the that it has lost the state and its peer has not. In this case, the
system treats the ESP packet like an I1 packet and sends an R1 system MAY initiate a new HIP exchange for re-establishing the SA.
packet. The initiator HIT is typically NULL in the R1, since the The RESYNC bit in the I1 packet is set to indicate the peer about the
system usually does not know the peer's HIT any more. possible state loss.
The system receiving the R1 packet first checks to see if it has an The initiating host cannot know, if the SA indicated by the received
established and recently used SA with the party sending the R1. If ESP packet is either a HIP SA or and IKE SA. If the old SA was not a
such an SA exists, the system checks the Birthday, and if the HIP SA, the peer may not respond to the I1 packet.
Birthday is greater than the current SA's Birthday, it processes the
R1 packet, optionally queuing the payload packet(s) to be resent
later. The peer system processes the I2 in the normal manner, and
replies with an R2. This will re-establish state between the two
peers. Note that the process will result in new ESP SAs being used,
and therefore simply resending ESP packets is not sufficient.
Note that there is a potential DoS attack. If an attacker can After sending the I1, the HIP negotiation proceeds as normally and,
simulate a situation where a large number of peers apparently loose when successful, the SA is created at the initiating end. The peer
their state at the same time, and all send R1 packet at once to a end removes the OLD SA and replaces it with the new one.
server, the server will choke on trying to solve all the puzzles at
the same time. However, such an attack would require that the
attacker has specific knowledge about the SAs being used, and an
ability to trigger R1s as the SAs are used.
5.4 HIP State Machine 5.4 HIP State Machine
The HIP protocol itself has very little state. In the HIP base The HIP protocol itself has very little state. In the HIP base
exchange, there is an Initiator and a Responder. Once the SAs are exchange, there is an Initiator and a Responder. Once the SAs are
established, this distinction is lost. If the HIP state needs to be established, this distinction is lost. If the HIP state needs to be
re-established, the controlling parameters are which peer still has re-established, the controlling parameters are which peer still has
state and which has a datagram to send to its peer. The following state and which has a datagram to send to its peer. The following
state machine attempts to capture these processes. state machine attempts to capture these processes.
skipping to change at page 20, line 30 skipping to change at page 21, line 20
either an Initiator or a Responder. There is not a complete overlap either an Initiator or a Responder. There is not a complete overlap
of processing logic here and in the packet definitions. Both are of processing logic here and in the packet definitions. Both are
needed to completely implement HIP. needed to completely implement HIP.
Implementors must understand that the state machine, as described Implementors must understand that the state machine, as described
here, is informational. Specific implementations are free to here, is informational. Specific implementations are free to
implement the actual functions differently. implement the actual functions differently.
5.4.1 HIP States 5.4.1 HIP States
E0 State machine start UNASSOCIATED State machine start
E1 Initiating HIP I1-SENT Initiating HIP
E2 Waiting to finish HIP I2-SENT Waiting to finish HIP
E3 HIP SA established ESTABLISHED HIP SA established
E4 HIP SA established, rekeying REKEYING HIP SA established, rekeying
RESYNC Peer lost state, resyncing
E-FAILED HIP SA establishment failed E-FAILED HIP SA establishment failed
5.4.2 HIP State Processes 5.4.2 HIP State Processes
+---------+ +------------+
| E0 | Start state |UNASSOCIATED| Start state
+---------+ +------------+
Datagram to send, send I1 and go to E1 Datagram to send, send I1 and go to I1-SENT
Receive I1, send R1 and stay at E0 Receive I1, send R1 and stay at UNASSOCIATED
Receive I2, process Receive I2, process
if successful, send R2 and go to E3 if successful, send R2 and go to ESTABLISHED
if fail, stay at E0 if fail, stay at UNASSOCIATED
Receive ESP for unknown SA, send R1 and stay at E0
Receive ANYOTHER, drop and stay at E0 Receive ESP for unknown SA, send I1 and go to I1-SENT
Receive ANYOTHER, drop and stay at UNASSOCIATED
+---------+ +---------+
| E1 | Initiating HIP | I1-SENT | Initiating HIP
+---------+ +---------+
Receive I1, send R1 and stay at E1 Receive I1, send R1 and stay at I1-SENT
Receive I2, process Receive I2, process
if successful, send R2 and go to E3 if successful, send R2 and go to ESTABLISHED
if fail, stay at E1 if fail, stay at I1-SENT
Receive R1, process Receive R1, process
if successful, send I2 and go to E2 if successful, send I2 and go to I2-SENT
if fail, go to E-FAILED if fail, go to E-FAILED
Receive ANYOTHER, drop and stay at E1
Receive ANYOTHER, drop and stay at I1-SENT
Timeout, increment timeout counter Timeout, increment timeout counter
If counter is less than I1_RETRIES_MAX, send I1 and stay at E1 If counter is less than I1_RETRIES_MAX, send I1 and stay at I1-SENT
If counter is greater than I1_RETRIES_MAX, go to E-FAILED If counter is greater than I1_RETRIES_MAX, go to E-FAILED
+---------+ +---------+
| E2 | Waiting to finish HIP | I2-SENT | Waiting to finish HIP
+---------+ +---------+
Receive I1, send R1 and stay at E2 Receive I1, send R1 and stay at I2-SENT
Receive I2, process Receive I2, process
if successful, send R2 and go to E3 if successful, send R2 and go to ESTABLISHED
if fail, stay at E2 if fail, stay at I2-SENT
Receive R2, process Receive R2, process
if successful, go to E3 if successful, go to ESTABLISHED
if fail, go to E-FAILED if fail, go to E-FAILED
Receive ANYOTHER, drop and stay at E2
Receive ANYOTHER, drop and stay at I2-SENT
Timeout, increment timeout counter Timeout, increment timeout counter
If counter is less than I2_RETRIES_MAX, send I2 and stay at E2 If counter is less than I2_RETRIES_MAX, send I2 and stay at I2-SENT
If counter is greater than I2_RETRIES_MAX, go to E-FAILED If counter is greater than I2_RETRIES_MAX, go to E-FAILED
+---------+ +------------+
| E3 | HIP SA established |ESTABLISHED | HIP SA established
+---------+ +------------+
Receive I1, send R1 and stay at E3 Receive I1, send R1 and go to RESYNC
Receive I2, process with Birthday check Receive I2, process with Birthday check
if successful, send R2, drop old SA and cycle at E3 if successful, send R2, drop old SAs, establish new SA, reenter
if fail, stay at E3 ESTABLISHED
Receive R1, process with SA and Birthday check if fail, stay at ESTABLISHED
if successful, send I2, prepare to drop old SA and cycle at E3 Receive R1, drop and stay at ESTABLISHED
if fail, stay at E3 Receive R2, drop and stay at ESTABLISHED
Receive R2, drop and stay at E3 Receive ESP for SA, process and stay at ESTABLISHED
Receive UPDATE, process
if successful, send UPDATE and stay at ESTABLISHED
if failed, stay at ESTABLISHED
Receive ESP for SA, process and stay at E3
Receive NES, process
if successful, send NES and stay at E3
if failed, stay at E3
Need rekey, Need rekey,
send NES and go to E4 send UPDATE and go to REKEYING
+---------+ +----------+
| E4 | HIP SA established, rekey pending | REKEYING | HIP SA established, rekey pending
+---------+ +----------+
Receive I1, send R1 and stay at E4 Receive I1, send R1 and stay at REKEYING
Receive I2, process with Birthday check Receive I2, process with Birthday check
if successful, send R2, drop old SA and go to E3 if successful, send R2, drop old SA and go to ESTABLISHED
if fail, stay at E4 if fail, stay at REKEYING
Receive R1, process with SA and Birthday check Receive R1, drop and stay at REKEYING
if successful, send I2, prepare to drop old SA and go to E3 Receive R2, drop and stay at REKEYING
if fail, stay at E4
Receive R2, drop and stay at E4
Receive ESP for SA, process and stay at E4 Receive ESP for SA, process and stay at REKEYING
Receive NES, process Receive UPDATE, process
if successful, replace SAs and go to E3 if successful, replace SAs and go to ESTABLISHED
if failed, stay at E4 if failed, stay at REKEYING
Timeout, increment timeout counter Timeout, increment timeout counter
If counter is less than NES_RETRIES_MAX, send NES and stay at E4 If counter is less than UPDATE_RETRIES_MAX, send UPDATE and stay at REKEYING
If counter is greater than NES_RETRIES_MAX, go to E-FAILED If counter is greater than UPDATE_RETRIES_MAX, go to E-FAILED
+--------+
| RESYNC | HIP SA established, resync pending
+--------+
Receive I1, send R1 and cycle at RESYNC
Receive I2, process with Birthday check
if successful, send R2, drop old SA and go to ESTABLISHED
if fail, stay at RESYNC
Receive R1, drop and stay at RESYNC
Receive R2, drop and stay at RESYNC
Receive ESP for SA, process and go to ESTABLISHED
Receive UPDATE, process
if successful, send UPDATE and go to ESTABLISHED
if failed, stay at RESYNC
Timeout, increment timeout counter
if counter is less than UPDATE_RETRIES_MAX, send I2 and stay at RESYNC
if counter is greater than UPDATE_RETRIES_MAX, go to ESTABLISHED
+----------+
| E-FAILED | HIP failed to establish association with peer
+----------+
Move to UNASSOCIATED after an implementation specific time. Re-negotiation
is possible after moving to UNASSOCIATED state.
5.4.3 Simplified HIP State Diagram 5.4.3 Simplified HIP State Diagram
Receive packets cause a move to a new state. Receive packets cause a move to a new state.
+---------+ +------------+
| E0 |>---+ |UNASSOCIATED|>---+
+---------+ | +------------+ |
| ^ | | | ^ | |
| | | Dgm to | | | | Dgm to |
+-+ | send | +-+ | send, |
I1 | | (note: ESP- means ESP with unknown SPI) I1 | ESP- | (note: ESP- means ESP with unknown SPI)
ESP- | | | |
v | v |
+---------+ | +---------+ |
| E1 |>---|----------+ | I1-SENT |>---|----------+
+---------+ | | +---------+ | |
| | | | | |
| R1 | | | R1 | |
| |I2 |I2 | |I2 |I2
v | | v | |
+---------+ | | +---------+ | |
| E2 |>---|----------|-----+ | I2-SENT |>---|----------|-----+
| | | | | | | | | |
+---------+ | | | +---------+ | | |
| | | | | | | |
| R2 | | |I2 | R2 | | |I2
| | | | | | | |
v | | | v | | |
+---------+<---+ | | +-----------+<-+ | |
| | | | | | | |
| E3 |<--------------+ | |ESTABLISHED|<------------+ |
| |<--------------------+ | |<------------------+
| |<-------+ | |<------------------+
| |----+ | | |>-------------+ |
+---------+ | | | |<-------+ | |
| ^ ^ | | | |---+ | | |
| | | | | +-----------+ | | | |
+--+ | | | | ^ ^ | | | |
ESP, | rekey| |R1,I2 | | | | | | |
NES, | | | +--+ | | | | |
I1, |NES | | ESP, | rekey| |I2 | |
I2, | | | UPDATE,| | | | |
R1 | | | I2 |UPDATE | | | |
| | | | | | | |
+---------+ | | | | | | |
| |<---+ | | | | | |
| E4 |>-------+ +---------+ | | | |
+---------+ | |<-----+ | | |
| ^ |REKEYING |>---------+ | |
| | +---------+ | |
+--+ | ^ | | I2, ESP
ESP, | | I1 | | UPDATE, Timeout
I1, +--+ | |
ESP, | |
I1 | |
v ^
+--------+
| RESYNC |
+--------+
| ^
| |
+--+
I1
6. Packet formats 6. Packet formats
6.1 Payload format 6.1 Payload format
All HIP packets start with a fixed header. All HIP packets start with a fixed header.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 48 skipping to change at page 26, line 48
data if a Next Header value is received that is not implemented. data if a Next Header value is received that is not implemented.
The Header Length field contains the length of the HIP Header and the The Header Length field contains the length of the HIP Header and the
length of HIP parameters in 8 bytes units, excluding the first 8 length of HIP parameters in 8 bytes units, excluding the first 8
bytes. Since all HIP headers MUST contain the sender's and bytes. Since all HIP headers MUST contain the sender's and
receiver's HIT fields, the minimum value for this field is 4, and receiver's HIT fields, the minimum value for this field is 4, and
conversely, the maximum length of the HIP Parameters field is conversely, the maximum length of the HIP Parameters field is
(255*8)-32 = 2008 bytes. (255*8)-32 = 2008 bytes.
The Packet Type indicates the HIP packet type. The individual packet The Packet Type indicates the HIP packet type. The individual packet
types are defined in the relevant sections. If a HIP host receives a 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 HIP packet that contains an unknown packet type, it MUST drop the
packet. packet.
The HIP Version is four bits. The current version is 1. The version The HIP Version is four bits. The current version is 1. The version
number is expected to be incremented only if there are incompatible number is expected to be incremented only if there are incompatible
changes to the protocol. Most extensions can be handled by defining changes to the protocol. Most extensions can be handled by defining
new packet types, new parameter types, or new controls. new packet types, new parameter types, or new controls.
The following four bits are reserved for future use. They MUST be The following four bits are reserved for future use. They MUST be
zero when sent, and they SHOULD be ignored when handling a received zero when sent, and they SHOULD be ignored when handling a received
packet. packet.
The HIT fields are always 128 bits (16 bytes) long. The HIT fields are always 128 bits (16 bytes) long.
6.1.1 HIP Controls 6.1.1 HIP Controls
The HIP control section transfers information about the structure of The HIP control section transfers information about the structure of
the packet and capabilities of the host. the packet and capabilities of the host.
The following fields have been defined: The following fields have been defined:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | |C|E|A| | | | | | | | | | | | | | |C|R|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C - Certificate One or more certificate packets (CER) follows this C - Certificate One or more certificate packets (CER) follows this
HIP packet (see Section 7.7). HIP packet (see Section 7.7).
E - ESP sequence numbers The ESP transform requires 64-bit sequence R - Resync Indicating that the sender has lost state and is trying to
numbers. See Section 11.4 for processing this control. resynchronize. See Section 5.3.
A - Anonymous If this is set, the sender's HI in this packet is 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 anonymous, i.e., one not listed in a directory. Anonymous HIs
SHOULD NOT be stored. This control is set in packets R1 and/or 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 by I2. The peer receiving an anonymous HI may choose to refuse it by
silently dropping the exchange. silently dropping the exchange.
The rest of the fields are reserved for future use and MUST be set to The rest of the fields are reserved for future use and MUST be set to
zero on sent packets and ignored on received packets. zero on sent packets and ignored on received packets.
skipping to change at page 26, line 25 skipping to change at page 29, line 7
The HIP Parameters are used to carry the public key associated with The HIP Parameters are used to carry the public key associated with
the sender's HIT, together with other related security information. the sender's HIT, together with other related security information.
The HIP Parameters consists of ordered parameters, encoded in TLV The HIP Parameters consists of ordered parameters, encoded in TLV
format. format.
The following parameter types are currently defined. The following parameter types are currently defined.
TLV Type Length Data TLV Type Length Data
SPI_LSI 0 16 Remote's SPI, Remote's LSI. SPI_LSI 1 16 Remote's SPI, Remote's LSI.
BIRTHDAY_COOKIE 2/4 32 System Boot Counter plus BIRTHDAY_COOKIE 3/5 32 System Boot Counter plus
two 64-bit fields: two 64-bit fields:
- Random #I - Random #I
- K or random #J - K or random #J
DIFFIE_HELLMAN 6 variable public key NES 9 Old SPI, New SPI and other
info needed for UPDATE
NES_INFO 10 Old SPI, New SPI and other DIFFIE_HELLMAN 13 variable public key
info needed for NES
HIP_TRANSFORM 16 variable HIP Encryption and Integrity HIP_TRANSFORM 17 variable HIP Encryption and Integrity
Transform Transform
ESP_TRANSFORM 18 variable ESP Encryption and ESP_TRANSFORM 19 variable ESP Encryption and
Authentication Transform Authentication Transform
ENCRYPTED 20 variable Encrypted part of I2 or CER ENCRYPTED 21 variable Encrypted part of I2 or CER
packets packets
HOST_ID 32 variable Host Identity
HOST_ID_FQDN 34 variable Host Identity with Fully HOST_ID 35 variable Host Identity with Fully
Qualified Domain Name Qualified Domain Name
CERT 64 variable HI certificate CERT 64 variable HI certificate
HMAC 65500 24 HMAC based message
HMAC 65245 24 HMAC based message
authentication code, with authentication code, with
key material from HIP_TRANSFORM key material from HIP_TRANSFORM
HIP_SIGNATURE2 65532 variable Signature of the R1 packet HIP_SIGNATURE2 65277 variable Signature of the R1 packet
HIP_SIGNATURE 65534 variable Signature of the packet HIP_SIGNATURE 65279 variable Signature of the packet
6.2.1 TLV format 6.2.1 TLV format
The TLV encoded parameters are described in the following The TLV encoded parameters are described in the following
subsections. The type-field value also describes the order of these subsections. The type-field value also describes the order of these
fields in the packet. The parameters MUST be included into the fields in the packet. The parameters MUST be included into the
packet so that the types form an increasing order. If the order does 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 not follow this rule, the packet is considered to be malformed and it
MUST be discarded. MUST be discarded.
skipping to change at page 27, line 48 skipping to change at page 30, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |C| Length | | Type |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Contents / / Contents /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type code for the parameter Type Type code for the parameter
C Critical. Zero if this parameter is critical, and C Critical. One if this parameter is critical, and
MUST be recognized by the recipient, one otherwise. MUST be recognized by the recipient, zero otherwise.
The C bit is considered to be a part of the Type field. The C bit is considered to be a part of the Type field.
Consequently, critical parameters are always even Consequently, critical parameters are always odd
and non-critical ones have an odd value. and non-critical ones have an even value.
Length Length of the parameter, in bytes. Length Length of the parameter, in bytes.
Contents Parameter specific, defined by Type Contents Parameter specific, defined by Type
Padding Padding, 0-7 bytes, added if needed Padding Padding, 0-7 bytes, added if needed
Critical parameters MUST be recognized by the recipient. If a Critical parameters MUST be recognized by the recipient. If a
recipient encounters a critical parameter that it does not recognize, recipient encounters a critical parameter that it does not recognize,
it MUST NOT process the packet any further. it MUST NOT process the packet any further.
Non-critical parameters MAY be safely ignored. If a recipient Non-critical parameters MAY be safely ignored. If a recipient
encounters a non-critical parameter that it does not recognize, it encounters a non-critical parameter that it does not recognize, it
skipping to change at page 29, line 17 skipping to change at page 31, line 44
65024 - 65535 65024 - 65535
5. The following type codes are reserved for experimentation and 5. The following type codes are reserved for experimentation and
private use. Types SHOULD be selected in a random fashion from private use. Types SHOULD be selected in a random fashion from
this range, thereby reducing the probability of collisions. A this range, thereby reducing the probability of collisions. A
method employing genuine randomness (such as flipping a coin) method employing genuine randomness (such as flipping a coin)
SHOULD be used. SHOULD be used.
32768 - 49141 32768 - 49141
6. All other parameter type codes MUST be registed by the IANA. See 6. All other parameter type codes MUST be registered by the IANA.
Section 14. See Section 14.
6.2.3 SPI_LSI 6.2.3 SPI_LSI
The SPI_LSI parameter contains the SPI that the receiving host must The SPI_LSI parameter contains the SPI that the receiving host must
use when sending data to the sending host, and the LSI that the use when sending data to the sending host, and the LSI that the
receiving host must to represent itself when talkin to the sending receiving host must use to represent itself when talking to the
host. sending host.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSI | | LSI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 0 Type 1
Length 12 Length 12
Reserved Zero when sent, ignored when received Reserved Zero when sent, ignored when received
SPI Security Parameter Index SPI Security Parameter Index
LSI Local Scope Identifier LSI Local Scope Identifier
6.2.4 BIRTHDAY_COOKIE 6.2.4 BIRTHDAY_COOKIE
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 30, line 17 skipping to change at page 33, line 24
| Birthday, 8 bytes | | Birthday, 8 bytes |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random # I, 8 bytes | | Random # I, 8 bytes |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K or Random # J, 8 bytes | | K or Random # J, 8 bytes |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2 (in R1) or 4 (in I2) Type 3 (in R1) or 5 (in I2)
Length 28 Length 28
Reserved Zero when sent, ignored when received Reserved Zero when sent, ignored when received
Birthday System boot counter Birthday System boot counter
Random # I random number Random # I random number
K K is the number of verified bits (in R1 packet) K K is the number of verified bits (in R1 packet)
Random # J random number (in I2 packet) Random # J random number (in I2 packet)
Birthday, Random #I, K, and Random #J are represented as 64-bit Birthday, Random #I, K, and Random #J are represented as 64-bit
integers, in network byte order. integers, in network byte order.
skipping to change at page 30, line 40 skipping to change at page 33, line 47
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | Public Value / | Group ID | Public Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | padding | / | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 6 Type 13
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and padding
Group ID defines values for p and g Group ID defines values for p and g
Public Value the sender's public Diffie-Hellman key Public Value the sender's public Diffie-Hellman key
The following Group IDs have been defined: The following Group IDs have been defined:
Group Value Group Value
Reserved 0 Reserved 0
OAKLEY well known group 1 1 384-bit group 1
OAKLEY well known group 2 2 OAKLEY well known group 1 2
1536-bit MODP group 3 1536-bit MODP group 3
2048-bit MODP group 4 3072-bit MODP group 4
3072-bit MODP group 5 6144-bit MODP group 5
4096-bit MODP group 6 8192-bit MODP group 6
6144-bit MODP group 7
8192-bit MODP group 8
The MODP Diffie-Hellman groups are defined in [14]. The OAKLEY The MODP Diffie-Hellman groups are defined in [14]. The OAKLEY group
groups are defined in [6]. The OAKLEY well known group 5 is the same is defined in [6]. The OAKLEY well known group 5 is the same as the
as the 1536-bit MODP group. 1536-bit MODP group.
A HIP implementation MUST support Group IDs 1 and 3. The 384-bit
group can be used when lower security is enough (e.g. web surfing)
or when the equipment is not powerful enough (e.g. some PDAs).
Equipment powerful enough SHOULD implement also group ID 5.
To avoid unnecessary failures during the 4-way handshake, the rest of
the groups SHOULD be implemented in hosts where resources are
adequate.
6.2.6 HIP_TRANSFORM 6.2.6 HIP_TRANSFORM
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform-ID #1 | Transform-ID #2 | | Transform-ID #1 | Transform-ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform-ID #n | Padding | | Transform-ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 16 Type 17
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and padding
Transform-ID Defines the HIP Suite to be used Transform-ID Defines the HIP Suite to be used
The Suite-IDs are identical to those defined in Section 6.2.7. The Suite-IDs are identical to those defined in Section 6.2.7.
There MUST NOT be more than six (6) HIP Suite-IDs in one HIP There MUST NOT be more than six (6) HIP Suite-IDs in one HIP
transform TLV. The limited number of transforms sets the maximum size 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 HIP_TRANSFORM TLV. The HIP_TRANSFORM TLV MUST contain at least one
of the mandatory Suide-IDs. of the mandatory Suite-IDs.
Mandatory implementations: ENCR-3DES-CBC with HMAC-SHA1 and ENCR-NULL Mandatory implementations: ENCR-3DES-CBC with HMAC-SHA1 and ENCR-NULL
with HMAC-SHA1. with HMAC-SHA1.
6.2.7 ESP_TRANSFORM 6.2.7 ESP_TRANSFORM
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite-ID #1 | Suite-ID #2 | | Reserved |E| Suite-ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite-ID #2 | Suite-ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite-ID #n | Padding | | Suite-ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 18
Type 19
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and padding
Suite-ID Defines the ESP Suite to be used E One if the ESP transform requires 64-bit sequence
numbers
(see
Section 11.6
)
Reserved zero when sent, ignored when received
Suite-ID defines the ESP Suite to be used
The following Suite-IDs are defined ([16],[19]): The following Suite-IDs are defined ([16],[19]):
Suite-ID Value Suite-ID Value
RESERVED 0 RESERVED 0
ESP-AES-CBC with HMAC-SHA1 1 ESP-AES-CBC with HMAC-SHA1 1
ESP-3DES-CBC with HMAC-SHA1 2 ESP-3DES-CBC with HMAC-SHA1 2
ESP-3DES-CBC with HMAC-MD5 3 ESP-3DES-CBC with HMAC-MD5 3
ESP-BLOWFISH-CBC with HMAC-SHA1 4 ESP-BLOWFISH-CBC with HMAC-SHA1 4
skipping to change at page 32, line 30 skipping to change at page 36, line 7
There MUST NOT be more than six (6) ESP Suite-IDs in one 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 ESP_TRANSFORM TLV. The limited number of Suite-IDs sets the maximum
size of ESP_TRANSFORM TLV. The ESP_TRANSFORM MUST contain at least size of ESP_TRANSFORM TLV. The ESP_TRANSFORM MUST contain at least
one of the mandatory Suite-IDs. one of the mandatory Suite-IDs.
Mandatory implementations: ESP-3DES-CBC with HMAC-SHA1 and ESP-NULL Mandatory implementations: ESP-3DES-CBC with HMAC-SHA1 and ESP-NULL
with HMAC-SHA1. with HMAC-SHA1.
6.2.8 HOST_ID 6.2.8 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
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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Identity / | HI Length | FQDN Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | padding | | Host Identity /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | FQDN /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 32 Type 35
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and Padding
HI Length length of the Host Identity in octets
FQDN Length length of the FQDN in octets
Host Identity actual host identity Host Identity actual host identity
FQDN Fully Qualified Domain Name, in the binary format.
The Host Identity is represented in RFC2535 [9] format. The The Host Identity is represented in RFC2535 [9] format. The
algorithms used in RDATA format are the following: algorithms used in RDATA format are the following:
Algorithms Values Algorithms Values
RESERVED 0 RESERVED 0
DSA 3 [RFC2536] (REQUIRED) DSA 3 [RFC2536] (REQUIRED)
RSA 5 [RFC3110] (OPTIONAL) RSA 5 [RFC3110] (OPTIONAL)
6.2.9 HOST_ID_FQDN The format for the FQDN is defined in RFC1035 [2] Section 3.1. If
there is no FQDN, the FQDN Length field is set to zero.
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 | FQDN Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Identity /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | FDQN /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 34
Length length in octets, excluding Type, Length, and padding
HI length length of the Host Identity
FQDN length length of the FQDN
Host Identity actual host identity
FQDN Fully Qualified Domain Name, in the binary format.
The Host Identity is represented in RFC2535 [9] format; see above.
The format for the FQDN is defined in RFC1035 [2] Section 3.1.
If there is no FQDN, the HOST_ID TLV is sent instead.
6.2.10 CERT 6.2.9 CERT
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert count | Cert ID | Cert type | / | Cert count | Cert ID | Cert type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Certificate / / Certificate /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 64 Type 64
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and padding
Cert count total count of certificates that are sent, possibly Cert count total count of certificates that are sent, possibly
in several consequtive CER packets in several consecutive CER packets
Cert ID the order number for this certificate Cert ID the order number for this certificate
Cert Type describes the type of the certificate Cert Type describes the type of the certificate
The receiver must know the total number (Cert count) of certificates 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 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 Cert ID identifies the particular certificate and its order in the
certificate chain. The numbering in Cert ID MUST go from 1 to Cert certificate chain. The numbering in Cert ID MUST go from 1 to Cert
count. count.
The following certificate types are defined: The following certificate types are defined:
Cert format Type number Cert format Type number
X.509 v3 1 X.509 v3 1
The encoding format for X.509v3 certificate is defined in [11]. The encoding format for X.509v3 certificate is defined in [11].
6.2.11 HMAC 6.2.10 HMAC
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC | | HMAC |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65500 Type 65245
Length 20 Length 20
HMAC HMAC 160 low order bits of the HMAC computed over the HIP
160 low order bits of the HMAC computed over the HIP
packet, excluding the HMAC parameter and any packet, excluding the HMAC parameter and any
following HIP_SIGNATURE or HIP_SIGNATURE2 following HIP_SIGNATURE or HIP_SIGNATURE2
parameters. The checksum field MUST be set to zero parameters. The checksum field MUST be set to zero
and the HIP header length in the HIP common header and the HIP header length in the HIP common header
MUST be calculated not to cover any excluded MUST be calculated not to cover any excluded
parameters when the HMAC is calculated. parameters when the HMAC is calculated.
HMAC calculation and verification process: The HMAC calculation and verification process is presented in Section
8.3.1
Packet sender:
1. Create the HIP packet, without the HMAC and possibly following
the HIP_SIGNATURE or HIP_SIGNATURE2 TLVs.
2. Calculate the length field in the HIP header.
3. Compute the HMAC.
4. Add the HMAC TLV to the packet.
5. Recalculate the length field in the HIP header.
Packet receiver:
1. Verify the HIP header length field.
2. Remove the HIP TLV, and if the packet contains any HIP_SIGNATURE
or HIP_SIGNATURE2 fields, remove them too, saving the contents if
they will be needed later.
3. Recalculate the HIP packet length in the HIP header and clear the
checksum field (set it to all zeros).
4. Compute the HMAC and verify it against the received HMAC.
6.2.12 HIP_SIGNATURE 6.2.11 HIP_SIGNATURE
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIG alg | Signature / | SIG alg | Signature /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65534 (2^16-2) Type 65279 (2^16-2^8-1)
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and Padding
SIG alg Signature algorithm SIG alg Signature algorithm
Signature the signature is calculated over the HIP packet, Signature the signature is calculated over the HIP packet,
excluding the HIP_SIGNATURE TLV field, but including excluding the HIP_SIGNATURE TLV field, but including
the HMAC field, if present. The checksum field MUST the HMAC field, if present. The checksum field MUST
be set to zero and the HIP header length in the HIP be set to zero and the HIP header length in the HIP
common header MUST be calculated to the beginning of common header MUST be calculated to the beginning of
the HIP_SIGNATURE TLV when the signature is the HIP_SIGNATURE TLV when the signature is
calculated. 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:
1. Verify the HIP header length field.
2. Save the contents of the HIP_SIGNATURE TLV and remove it from the
packet.
3. Recalculate the HIP packet length in the HIP header and clear the
checksum field (set it to all zeros).
4. Compute the signature and verify it against the received
signature.
The signature algorithms are defined in Section 6.2.8. The signature The signature algorithms are defined in Section 6.2.8. The signature
in the Signature field is encoded using the proper method depending in the Signature field is encoded using the proper method depending
on the signature algorithm (e.g. in case of DSA, according to [10]). on the signature algorithm (e.g. in case of DSA, according to [10]).
The verification can use either the HI received from a HIP packet, The HIP_SIGNATURE calculation and verification process is presented
the HI from a DNS query, if the FQDN has been received either in the in Section 8.3.2
HOST_ID_FQDN or in the CER packet, or one received by some other
means.
6.2.13 HIP_SIGNATURE_2 6.2.12 HIP_SIGNATURE_2
The TLV structure is the same as in Section 6.2.12. The fields are: The TLV structure is the same as in Section 6.2.11. The fields are:
Type 65532 (2^16-4) Type 65277 (2^16-2^8-3)
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and Padding
SIG alg Signature algorithm SIG alg Signature algorithm
Signature the signature is calculated over the R1 packet, Signature the signature is calculated over the R1 packet,
excluding the HIP_SIGNATURE_2 TLV field, but excluding the HIP_SIGNATURE_2 TLV field, but
including the HMAC field, if present. Initiator's including the HMAC field, if present. Initiator's
HIT and Checksum field MUST be set to zero and the HIT and Checksum field MUST be set to zero and the
HIP packet length in the HIP header MUST be HIP packet length in the HIP header MUST be
calculated to the beginning of the HIP_SIGNATURE_2 calculated to the beginning of the HIP_SIGNATURE_2
TLV when the signature is calculated. TLV when the signature is calculated.
Zeroing the Initiator's HIT makes it possible to create R1 packets Zeroing the Initiator's HIT makes it possible to create R1 packets
beforehand to minimize the effects of possible DoS attacks. beforehand to minimize the effects of possible DoS attacks.
Signature calculation and verification process follows the process in Signature calculation and verification follows the process in Section
Section 6.2.12. The only difference is that instead of the the 8.3.2.
HIP_SIGNATURE TLV the HIP_SIGNATURE_2 TLV is used, and the
Initiator's HIT is cleared (set to all zeros) before computing the
signature.
6.2.14 NES_INFO 6.2.13 NES
The NES payload is used to reset Security Associations. It introduces The UPDATE payload is used to reset Security Associations. It
a new SPI to be used when sending data to the sender of the NES introduces a new SPI to be used when sending data to the sender of
packet. The keys for the new Security Association will be drawn from the UPDATE packet. The keys for the new Security Association will be
KEYMAT. If the packet contains a Diffie-Hellman parameter, the drawn from KEYMAT. If the packet contains a Diffie-Hellman
KEYMAT is first recomputed before drawing the new keys. parameter, the KEYMAT is first recomputed before drawing the new
keys.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Keymat Index | NES ID | |R| Keymat Index | UPDATE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old SPI | | Old SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New SPI | | New SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 10 Type 9
Length 12 Length 12
R One if the NES is a reply to another NES, R One if the NES is a reply to another UPDATE,
otherwise zero. otherwise zero.
Keymat Index Index, in bytes, where to continue to draw ESP keys Keymat Index Index, in bytes, where to continue to draw ESP keys
from KEYMAT. If the packet includes a new from KEYMAT. If the packet includes a new
Diffie-Hellman key, the field MUST be zero. Note Diffie-Hellman key, the field MUST be zero. Note
that the length of this field limits the amount of that the length of this field limits the amount of
keying material that can be drawn from KEYMAT. If keying material that can be drawn from KEYMAT. If
that amount is exceeded, the NES packet MUST contain that amount is exceeded, the NES packet MUST contain
a new Diffie-Hellman key. a new Diffie-Hellman key.
NES ID Packet identifier. Used to tie NES packets UPDATE ID Packet identifier. Used to tie UPDATE packets
into pairs. Initialized to zero and incremented into pairs. Initialized to zero and incremented
for each NES. for each UPDATE.
Old SPI Old SPI for data sent to the source address of Old SPI Old SPI for data sent to the source address of
this packet this packet
New SPI New SPI for data sent to the source address of New SPI New SPI for data sent to the source address of
this packet this packet
Note that the NES_INFO used to include the SPI used in reverse Note that the NES used to include the SPI used in reverse direction,
direction, too. However, since NES packets are now always sent in too. However, since UPDATE packets are now always sent in pairs,
pairs, that is not needed any more. Any middleboxes between the that is not needed any more. Any middleboxes between the
communicating hosts will learn the reverse mappings from the NES communicating hosts will learn the reverse mappings from the UPDATE
reply. reply.
6.2.15 ENCRYPTED 6.2.14 ENCRYPTED
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV / | IV /
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ Encrypted data / / Encrypted data /
/ / / /
/ +-------------------------------+ / +-------------------------------+
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 20 Type 21
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and padding
Reserved zero when sent, ignored when received Reserved zero when sent, ignored when received
IV Initialization vector, if needed, otherwise nonexisting. IV Initialization vector, if needed, otherwise nonexistent.
The length of the IV is inferred from the HIP transform. The length of the IV is inferred from the HIP transform.
Encrypted The data is encrypted using an encryption algorithm as Encrypted The data is encrypted using an encryption algorithm as
data defined in HIP transform. data defined in HIP transform.
Padding Any Padding, if necessary, to make the TLV a multiple Padding Any Padding, if necessary, to make the TLV a multiple
of 8 bytes. of 8 bytes.
The encrypted data is in TLV format itself. Consequently, the first The encrypted data is in TLV format itself. Consequently, the first
fields in the contents are Type and Length, allowing the contents to fields in the contents are Type and Length, allowing the contents to
be easily parsed after decryption. be easily parsed after decryption. Each of the TLVs to be encrypted,
must be padded according to rules in Section 6.2.1 before encryption.
If the encryption algorithm requires the length of the data to be If the encryption algorithm requires the length of the data to be
encrypted to be a multiple of the cipher algorithm block size, encrypted to be a multiple of the cipher algorithm block size,
thereby necessitating padding, and if the encryption algorithm does thereby necessitating padding, and if the encryption algorithm does
not specify the padding contents, then an implementation MUST append not specify the padding contents, then an implementation MUST append
the TLV parameter that is to be encrypted with an additional padding, the TLV parameter that is to be encrypted with an additional padding,
so that the length of the resulting cleartext is a multiple of the so that the length of the resulting cleartext is a multiple of the
cipher block size length. Such a padding MUST be constructed as cipher block size length. Such a padding MUST be constructed as
specified in [15] Section 2.4. On the other hand, if the data to be specified in [15] Section 2.4. On the other hand, if the data to be
encrypted is already a multiple of the block size, or if the encrypted is already a multiple of the block size, or if the
skipping to change at page 39, line 29 skipping to change at page 42, line 17
length of the data after encryption (including the Reserved field, length of the data after encryption (including the Reserved field,
the IV field, and the output from the encryption process specified the IV field, and the output from the encryption process specified
for that suite, but not any additional external padding). Note that for that suite, but not any additional external padding). Note that
the length of the cipher suite output may be smaller or larger than the length of the cipher suite output may be smaller or larger than
the length of the data to be encrypted, since the encryption process the length of the data to be encrypted, since the encryption process
may compress the data or add additional padding to the data. may compress the data or add additional padding to the data.
The ENCRYPTED payload may contain additional external padding, if the The ENCRYPTED payload may contain additional external padding, if the
result of encryption, the TLV header and the IV is not a multiple of result of encryption, the TLV header and the IV is not a multiple of
8 bytes. The contents of this external padding MUST follow the rules 8 bytes. The contents of this external padding MUST follow the rules
given in Section Section 6.2.1. given in Section 6.2.1.
7. HIP Packets 7. HIP Packets
There are eight basic HIP packets. Four are for the base HIP There are eight basic HIP packets. Four are for the base HIP
exchange, one is for rekeying, one is a broadcast for use when there exchange, one is for rekeying, one is a broadcast for use when there
is no IP addressing (e.g., before DHCP exchange), one is used to send is no IP addressing (e.g., before DHCP exchange), one is used to send
certificates, and one is for sending unencrypted data. certificates, and one is for sending unencrypted data.
Packets consist of the fixed header as described in Section 6.1, Packets consist of the fixed header as described in Section 6.1,
followed by the parameters. The parameter part, in turn, consists of followed by the parameters. The parameter part, in turn, consists of
skipping to change at page 40, line 43 skipping to change at page 43, line 43
7.1 I1 - the HIP initiator packet 7.1 I1 - the HIP initiator packet
The HIP header values for the I1 packet: The HIP header values for the I1 packet:
Header: Header:
Packet Type = 1 Packet Type = 1
SRC HIT = Initiator's HIT SRC HIT = Initiator's HIT
DST HIT = Responder's HIT, or NULL DST HIT = Responder's HIT, or NULL
IP(HIP()) IP ( HIP () )
The I1 packet contains only the fixed HIP header. The I1 packet contains only the fixed HIP header.
Valid control bits: None Valid control bits: R
The Initiator gets the Responder's HIT either from a DNS lookup of 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 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 table. If the Initiator does not know the Responder's HIT, it may
attempt opportunistic mode by using NULL (all zeros) as the attempt opportunistic mode by using NULL (all zeros) as the
Responder's HIT. Responder's HIT.
Since this packet is so easy to spoof even if it were signed, no 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. attempt is made to add to its generation or processing cost.
Implementation MUST be able to handle a storm of received I1 packets, Implementation MUST be able to handle a storm of received I1 packets,
discarding those with common content that arrive within a small time discarding those with common content that arrive within a small time
delta. delta.
If a host has rebooted and it is trying to re-establish a Security
Association based on incoming and unidentified ESP traffic, it sends
an I1 packet with R bit set.
7.2 R1 - the HIP responder packet 7.2 R1 - the HIP responder packet
The HIP header values for the R1 packet: The HIP header values for the R1 packet:
Header: Header:
Packet Type = 2 Packet Type = 2
SRC HIT = Responder's HIT SRC HIT = Responder's HIT
DST HIT = Initiator's HIT DST HIT = Initiator's HIT
IP ( HIP ( BIRTHDAY_COOKIE, IP ( HIP ( BIRTHDAY_COOKIE,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_TRANSFORM, HIP_TRANSFORM,
ESP_TRANSFORM, ESP_TRANSFORM,
( HOST_ID | HOST_ID_FQDN ), HOST_ID,
HIP_SIGNATURE_2 ) ) HIP_SIGNATURE_2 ) )
Valid control bits: C, A Valid control bits: C, A
The R1 packet may be followed by one or more CER packets. In this The R1 packet may be followed by one or more CER packets. In this
case, the C-bit in the control field MUST be set. case, the C-bit in the control field MUST be set.
If the responder HI is an anonymous one, the A control MUST be set. If the responder HI is an anonymous one, the A control MUST be set.
The initiator HIT MUST match the one received in I1. If the R1 is a The initiator HIT MUST match the one received in I1. If the R1 is a
skipping to change at page 42, line 38 skipping to change at page 45, line 42
Header: Header:
Type = 3 Type = 3
SRC HIT = Initiator's HIT SRC HIT = Initiator's HIT
DST HIT = Responder's HIT DST HIT = Responder's HIT
IP ( HIP ( SPI_LSI, IP ( HIP ( SPI_LSI,
BIRTHDAY_COOKIE, BIRTHDAY_COOKIE,
DIFFIE_HELLMAN, DIFFIE_HELLMAN,
HIP_TRANSFORM, HIP_TRANSFORM,
ESP_TRANSFORM, ESP_TRANSFORM,
ENCRYPTED { HOST_ID | HOST_ID_FQDN }, ENCRYPTED { HOST_ID },
HIP_SIGNATURE ) ) HIP_SIGNATURE ) )
Valid control bits: C, E, A Valid control bits: C, A
The HITs used MUST match the ones used previously. The HITs used MUST match the ones used previously.
If the initiator HI is an anonymous one, the A control MUST be set. If the initiator HI is an anonymous one, the A control MUST be set.
The Birthday is a reboot count used to manage state re-establishment The Birthday is a reboot count used to manage state re-establishment
when one peer rebooted or timed out its SA. when one peer rebooted or timed out its SA.
The Cookie contains the random # I from R1 and the computed # J. The The Cookie contains the random # I from R1 and the computed # J. The
low order K bits of the SHA-1(I | ... | J) MUST be zero. low order K bits of the SHA-1(I | ... | J) MUST be zero.
skipping to change at page 43, line 34 skipping to change at page 46, line 37
The HIP header values for the R2 packet: The HIP header values for the R2 packet:
Header: Header:
Packet Type = 4 Packet Type = 4
SRC HIT = Responder's HIT SRC HIT = Responder's HIT
DST HIT = Initiator's HIT DST HIT = Initiator's HIT
IP ( HIP ( SPI_LSI, HMAC, HIP_SIGNATURE ) ) IP ( HIP ( SPI_LSI, HMAC, HIP_SIGNATURE ) )
Valid control bits: E Valid control bits: none
The HMAC and signature are calculated over whole HIP envelope. The The HMAC and signature are calculated over whole HIP envelope. The
Initiator MUST validate both the HMAC and the signature. Initiator MUST validate both the HMAC and the signature.
7.5 NES - the HIP New SPI Packet 7.5 UPDATE - the HIP New SPI Packet
The NES packet is MANDATORY. The UPDATE packet is MANDATORY.
The NES serves three functions. Firstly, it provides the peer system The UPDATE serves three functions. Firstly, it provides the peer
with a new SPI to use when sending packets. Secondly, it optionally system with a new SPI to use when sending packets. Secondly, it
provides a new Diffie-Hellman key to produce new keying material. optionally provides a new Diffie-Hellman key to produce new keying
Thirdly, it provides any intermediate system with the mapping of the material. Thirdly, it provides any intermediate system with the
old SPI to the new one. This is important to systems like NATs [21] mapping of the old SPI to the new one. This is important to systems
that use SPIs to maintain address translation state. like NATs [21] that use SPIs to maintain address translation state.
The NES packet is a HIP packet with NES_INFO and optional The UPDATE packet is a HIP packet with NES and optional
DIFFIE_HELLMAN and in the HIP payload. The NES_INFO parameter DIFFIE_HELLMAN in the HIP payload. The NES parameter contains the
contains the old and new SPI values. It also contains a NES ID and old and new SPI values. It also contains a UPDATE ID and HMAC to
HMAC to provide DoS and replay protection. Each system must have a provide DoS and replay protection. Each system must have a UPDATE ID
NES ID counter, initialized to zero and incremented on each NES. counter, initialized to zero and incremented on each UPDATE.
The HIP header values for the NES packet: The HIP header values for the UPDATE packet:
Header: Header:
Packet Type = 5 Packet Type = 5
SRC HIT = Sender's HIT SRC HIT = Sender's HIT
DST HIT = Recipients's HIT DST HIT = Recipient's HIT
IP ( HIP ( [ DIFFIE_HELLMAN, ] NES_INFO , HMAC, HIP_SIGNATURE ) ) IP ( HIP ( NES, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) )
Valid control bits: None Valid control bits: None
During the life of an SA established by HIP, one of the hosts may During the life of an SA established by HIP, one of the hosts may
need to reset the Sequence Number to one (to prevent wrapping) and need to reset the Sequence Number to one (to prevent wrapping) and
rekey. The reason for rekeying might be an approaching sequence rekey. The reason for rekeying might be an approaching sequence
number wrap in ESP, or a local policy on use of a key. Rekeying ends number wrap in ESP, or a local policy on use of a key. Rekeying ends
the current SAs and starts new ones on both peers. the current SAs and starts new ones on both peers.
NES packets are always used in pairs, one in both directions, with UPDATE packets are always used in pairs, one in both directions, with
identical NES IDs. In the case both parties decide to rekey at the identical UPDATE IDs. In the case both parties decide to rekey at
same time, the result is four NES packets, two in both directions. the same time, the result is four UPDATE packets, two in both
directions.
Intermediate systems that use the SPI will have to inspect HIP Intermediate systems that use the SPI will have to inspect HIP
packets for a NES packet. The packet is signed for the benefit of packets for a UPDATE packet. The packet is signed for the benefit of
the intermediate systems. Since intermediate systems may need the the intermediate systems. Since intermediate systems may need the
new SPI values, the contents of this packet cannot be encrypted. new SPI values, the contents of this packet cannot be encrypted.
Processing NES signatures is a potential DoS attack against Processing UPDATE signatures is a potential DoS attack against
intermediate systems. intermediate systems.
7.6 BOS - the HIP Bootstrap Packet 7.6 BOS - the HIP Bootstrap Packet
The BOS packet is OPTIONAL. The BOS packet is OPTIONAL.
In some situations, an Initiator may not be able to learn of a In some situations, an Initiator may not be able to learn of a
Responder's information from DNS or another repository. Some examples Responder's information from DNS or another repository. Some examples
of this are DHCP and NetBios servers. Thus, a packet is needed to of this are DHCP and NetBIOS servers. Thus, a packet is needed to
provide information that would otherwise be gleaned from a provide information that would otherwise be gleaned from a
repository. This HIP packet is either self-signed in applications repository. This HIP packet is either self-signed in applications
like SoHo, or from a trust anchor in large private or public like SoHo, or from a trust anchor in large private or public
deployments. This packet MAY be broadcasted in IPv4 or multicasted deployments. This packet MAY be broadcasted in IPv4 or multicasted
to the all hosts multicast group in IPv6. The packet MUST NOT be to the all hosts multicast group in IPv6. The packet MUST NOT be
sent more often than once in every second. Implementations MAY sent more often than once in every second. Implementations MAY
ignore received BOS packets. ignore received BOS packets.
The HIP header values for the BOS packet: The HIP header values for the BOS packet:
Header: Header:
Packet Type = 7 Packet Type = 7
SRC HIT = Announcer's HIT SRC HIT = Announcer's HIT
DST HIT = NULL DST HIT = NULL
IP ( HIP ( ( HOST_ID | HOST_ID_FQDN ), HIP_SIGNATURE ) ) IP ( HIP ( HOST_ID, HIP_SIGNATURE ) )
The BOS packet may be followed by a CER packet if the HI is signed. The BOS packet may be followed by a CER packet if the HI is signed.
In this case, the C-bit in the control field MUST be set. If the BOS In this case, the C-bit in the control field MUST be set. If the BOS
packet is broadcasted or multicasted, the following CER packet(s) packet is broadcasted or multicasted, the following CER packet(s)
MUST be broadcasted or multicasted to the same multicast group and MUST be broadcasted or multicasted to the same multicast group and
scope, respectively. scope, respectively.
Valid control bits: C, A Valid control bits: C, A
7.7 CER - the HIP Certificate Packet 7.7 CER - the HIP Certificate Packet
skipping to change at page 45, line 35 skipping to change at page 48, line 37
The Optional CER packets over the Announcer's HI by a higher level The Optional CER packets over the Announcer's HI by a higher level
authority known to the Recipient is an alternative method for the authority known to the Recipient is an alternative method for the
Recipient to trust the Announcer's HI (over DNSSEC or PKI). Recipient to trust the Announcer's HI (over DNSSEC or PKI).
The HIP header values for CER packet: The HIP header values for CER packet:
Header: Header:
Packet Type = 8 Packet Type = 8
SRC HIT = Announcer's HIT SRC HIT = Announcer's HIT
DST HIT = Recipients's HIT DST HIT = Recipient's HIT
IP ( HIP ( { <CERT>i }, HIP_SIGNATURE ) ) or IP ( HIP ( <CERT>i , HIP_SIGNATURE ) ) or
IP ( HIP ( ENCRYPTED { <CERT>i }, HIP_SIGNATURE ) ) IP ( HIP ( ENCRYPTED { <CERT>i }, HIP_SIGNATURE ) )
Valid control bits: None Valid control bits: None
Certificates in the CER packet MAY be encrypted. The encryption Certificates in the CER packet MAY be encrypted. The encryption
algorithm is provided in the HIP transform of the previous (R1 or I2) algorithm is provided in the HIP transform of the previous (R1 or I2)
packet. packet.
7.8 PAYLOAD - the HIP Payload Packet 7.8 PAYLOAD - the HIP Payload Packet
The PAYLOAD packet is OPTIONAL. The PAYLOAD packet is OPTIONAL.
The HIP header values for the PAYLOAD packet: The HIP header values for the PAYLOAD packet:
Header: Header:
Packet Type = 64 Packet Type = 64
SRC HIT = Senders's HIT SRC HIT = Sender's HIT
DST HIT = Recipients's HIT DST HIT = Recipient's HIT
IP ( HIP ( ), payload ) IP ( HIP ( ), payload )
Valid control bits: None Valid control bits: None
Payload Proto field in the Header MUST be set to correspond the Payload Proto field in the Header MUST be set to correspond the
correct protocol number of the payload. correct protocol number of the payload.
The PAYLOAD packet is used to carry a non-ESP protected data. By The PAYLOAD packet is used to carry a non-ESP protected data. By
using the HIP header we ensure interoperability with NAT and other using the HIP header we ensure interoperability with NAT and other
skipping to change at page 47, line 46 skipping to change at page 50, line 46
multi-homing case will be specified separately. multi-homing case will be specified separately.
If the IPv4 backward compatible APIs and therefore LSIs are If the IPv4 backward compatible APIs and therefore LSIs are
supported, it is assumed that the LSIs will be converted into proper supported, it is assumed that the LSIs will be converted into proper
HITs somewhere in the stack. The exact location of the conversion is HITs somewhere in the stack. The exact location of the conversion is
an implementation specific issue and not discussed here. The an implementation specific issue and not discussed here. The
following conceptual algorithm discusses only HITs, with the following conceptual algorithm discusses only HITs, with the
assumption that the LSI-to-HIT conversion takes place somewhere. assumption that the LSI-to-HIT conversion takes place somewhere.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
outgoing datagrams destinated to a HIT. outgoing datagrams destined to a HIT.
1. If the datagram has a specified source address, it MUST be a HIT. 1. If the datagram has a specified source address, it MUST be a HIT.
If it is not, the implementation MAY replace the source address If it is not, the implementation MAY replace the source address
with a HIT. Otherwise it MUST drop the packet. with a HIT. Otherwise it MUST drop the packet.
2. If the datagram has an unspecified source address, the 2. If the datagram has an unspecified source address, the
implementation must choose a suitable source HIT for the implementation must choose a suitable source HIT for the
datagram. In selecting a proper local HIT, the implementation datagram. In selecting a proper local HIT, the implementation
SHOULD consult the table of currently active HIP sessions, and SHOULD consult the table of currently active HIP sessions, and
preferably select a HIT that already has an active session with preferably select a HIT that already has an active session with
skipping to change at page 48, line 40 skipping to change at page 51, line 40
Incoming HIP datagrams arrive as ESP protected packets. In the usual Incoming HIP datagrams arrive as ESP protected packets. In the usual
case the receiving host has a corresponding ESP security association, case the receiving host has a corresponding ESP security association,
identified by the SPI and destination IP address in the packet. identified by the SPI and destination IP address in the packet.
However, if the host has crashed or otherwise lost its HIP state, it However, if the host has crashed or otherwise lost its HIP state, it
may not have such an SA. may not have such an SA.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
incoming ESP protected datagrams targeted to an ESP security incoming ESP protected datagrams targeted to an ESP security
association created with HIP. association created with HIP.
1. Detect the proper IPsec SA, using the destination IP address and 1. Detect the proper IPsec SA using the SPI. If the resulting SA is
the SPI. If the resulting SA is a non-HIP ESP SA, process the a non-HIP ESP SA, process the packet according to standard IPsec
packet according to standard IPsec rules. If there are no SAs rules. If there are no SAs identified with the SPI, the host MAY
identified with the SPI, the host MAY send an R1 with a NULL send an I1 with a NULL Responder HIT and the R-bit set indicating
Initiator SPI. Sending such R1s MUST be rate limited. re-establishment of an SA. Sending such I1s MUST be rate
limited.
2. If a proper HIP ESP SA is found, the packet is processed normally 2. If a proper HIP ESP SA is found, the packet is processed normally
by ESP, as if the packet were a transport mode packet. The by ESP, as if the packet were a transport mode packet. The
packet may be dropped by ESP, as usual. In a typical packet may be dropped by ESP, as usual. In a typical
implementation, the result of succesful ESP decryption and implementation, the result of successful ESP decryption and
verification is a datagram with the original IP addresses as verification is a datagram with the original IP addresses as
source and destination. source and destination.
3. The IP addresses in the datagram are replaced with the HITs 3. The IP addresses in the datagram are replaced with the HITs
associated with the ESP SA. Note that this IP-address-to-HIT associated with the ESP SA. Note that this IP-address-to-HIT
conversion step MAY also be performed at some other point in the conversion step MAY also be performed at some other point in the
stack, e.g., before ESP processing. stack, e.g., before ESP processing.
4. The datagram is delivered to the upper layer. Demultiplexing the 4. The datagram is delivered to the upper layer. Demultiplexing the
datagram the right upper layer socket is based on the HITs (or datagram the right upper layer socket is based on the HITs (or
LSIs). LSIs).
8.3 Initiation of a HIP exchange 8.3 HMAC and SIGNATURE calculation and verification
The following subsections define the actions for processing HMAC,
HIP_SIGNATURE and HIP_SIGNATURE2 TLVs.
8.3.1 HMAC calculation
The HMAC TLV is defined in Section 6.2.10. HMAC calculation and
verification process:
Packet sender:
1. Create the HIP packet, without the HMAC or any possible
HIP_SIGNATURE or HIP_SIGNATURE2 TLVs.
2. Calculate the Length field in the HIP header.
3. Compute the HMAC.
4. Add the HMAC TLV to the packet and any HIP_SIGNATURE or
HIP_SIGNATURE2 TLVs that may follow.
5. Recalculate the Length field in the HIP header.
Packet receiver:
1. Verify the HIP header Length field.
2. Remove the HMAC TLV, and if the packet contains any HIP_SIGNATURE
or HIP_SIGNATURE2 fields, remove them too, saving the contents if
they will be needed later.
3. Recalculate the HIP packet length in the HIP header and clear the
Checksum field (set it to all zeros).
4. Compute the HMAC and verify it against the received HMAC.
8.3.2 Signature calculation
The following process applies both to the HIP_SIGNATURE and
HIP_SIGNATURE2 TLVs. When processing HIP_SIGNATURE2, the only
difference is that instead of HIP_SIGNATURE TLV the HIP_SIGNATURE2
TLV is used, and the Initiator's HIT is cleared (set to all zeros)
before computing the signature. The HIP_SIGNATURE TLV is defined in
Section 6.2.11 and the HIP_SIGNATURE2 TLV in Section 6.2.12.
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:
1. Verify the HIP header Length field.
2. Save the contents of the HIP_SIGNATURE TLV and remove it from the
packet.
3. Recalculate the HIP packet Length in the HIP header and clear the
Checksum field (set it to all zeros).
4. Compute the signature and verify it against the received
signature.
The verification can use either the HI received from a HIP packet,
the HI from a DNS query, if the FQDN has been received either in the
HOST_ID or in the CER packet, or one received by some other means.
8.4 Initiation of a HIP exchange
An implementation may originate a HIP exchange to another host based An implementation may originate a HIP exchange to another host based
on a local policy decision, usually triggered by an application on a local policy decision, usually triggered by an application
datagram, in much the same way that an IPsec IKE key exchange can datagram, in much the same way that an IPsec IKE key exchange can
dynamically create a Security Association. Alternatively, a system dynamically create a Security Association. Alternatively, a system
may initiate a HIP exchange if it has rebooted or timed out, or may initiate a HIP exchange if it has rebooted or timed out, or
otherwise lost its HIP state, as described in Section 5.3. otherwise lost its HIP state, as described in Section 5.3.
The implementation prepares an I1 packet and sends it to the IP The implementation prepares an I1 packet and sends it to the IP
address that corresponds to the peer host. The IP address of the address that corresponds to the peer host. The IP address of the
peer host may be obtained via conventional mechanisms, such as DNS peer host may be obtained via conventional mechanisms, such as DNS
lookup. The I1 contents are specified in Section 7.1. The selection lookup. The I1 contents are specified in Section 7.1. The selection
of which host identity to use, if a host has more than one to choose of which host identity to use, if a host has more than one to choose
from, is typically also be a policy decision. from, is typically a policy decision.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
initiating a HIP exchange: initiating a HIP exchange:
1. The Initiator gets the Responder's HIT and one or more addresses 1. The Initiator gets the Responder's HIT and one or more addresses
either from a DNS lookup of the responder's FQDN, from some other 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 repository, or from a local table. If the initiator does not know
the responder's HIT, it may attempt opportunistic mode by using the responder's HIT, it may attempt opportunistic mode by using
NULL (all zeros) as the responder's HIT. NULL (all zeros) as the responder's HIT.
2. The Initiator sends an I1 to one of the Responder's addresses. 2. The Initiator sends an I1 to one of the Responder's addresses.
The selection of which address to use is a local policy decision. The selection of which address to use is a local policy decision.
3. Upon sending an I1, the sender shall transition to state E1, 3. Upon sending an I1, the sender shall transition to state I1-SENT,
start a timer whose timeout value should be larger than the start a timer whose timeout value should be larger than the
worst-case anticipated RTT, and shall increment a timeout counter worst-case anticipated RTT, and shall increment a timeout counter
associated with the I1. associated with the I1.
4. Upon timeout, the sender SHOULD retransmit the I1 and restart the 4. Upon timeout, the sender SHOULD retransmit the I1 and restart the
timer, up to a maximum of I1_RETRIES_MAX tries. timer, up to a maximum of I1_RETRIES_MAX tries.
8.3.1 Sending multiple I1s in parallel 8.4.1 Sending multiple I1s in parallel
For the sake of minimizing the session establishment latency, an For the sake of minimizing the session establishment latency, an
implementation MAY send the same I1 to more than one of the implementation MAY send the same I1 to more than one of the
Responder's addresses. However, it MUST NOT send to more than three Responder's addresses. However, it MUST NOT send to more than three
(3) addresses in parallel. Furthermore, upon timeout, the (3) addresses in parallel. Furthermore, upon timeout, the
implementation MUST refrain from sending the same I1 packet to implementation MUST refrain from sending the same I1 packet to
multiple addresses. These limitations are placed order to avoid multiple addresses. These limitations are placed order to avoid
congestion of the network, and potential DoS attacks that might congestion of the network, and potential DoS attacks that might
happen, e.g., because someone claims to have hundreds or thousands of happen, e.g., because someone claims to have hundreds or thousands of
addresses. addresses.
skipping to change at page 50, line 27 skipping to change at page 55, line 10
As the Responder is not guaranteed to distinguish the duplicate I1's As the Responder is not guaranteed to distinguish the duplicate I1's
it receives at several of its addresses (because it avoids to store it receives at several of its addresses (because it avoids to store
states when it answers back an R1), the Initiator may receive several states when it answers back an R1), the Initiator may receive several
duplicate R1's. duplicate R1's.
The Initiator SHOULD then select the destination address using the The Initiator SHOULD then select the destination address using the
source address of the first received R1 as a source address for the source address of the first received R1 as a source address for the
next I2, and discards subsequent R1's. This strategy seems to be next I2, and discards subsequent R1's. This strategy seems to be
quite good in terms of RTT. quite good in terms of RTT.
8.3.2 Processing incoming ICMP Protocol Unreachable messages 8.4.2 Processing incoming ICMP Protocol Unreachable messages
A host may receive an ICMP Destination Protocol Unreachable message A host may receive an ICMP Destination Protocol Unreachable message
as a response to sending an HIP I1 packet. Such a packet may be an as a response to sending an HIP I1 packet. Such a packet may be an
indication that the peer does not support HIP, or it may be an indication that the peer does not support HIP, or it may be an
attempt to launch an attack by making the Initiator to believe that attempt to launch an attack by making the Initiator to believe that
the Responder does not support HIP. the Responder does not support HIP.
When a system receives an ICMP Destination Protocol Unreachable When a system receives an ICMP Destination Protocol Unreachable
message while it is waiting for an R1, it MUST NOT terminate the message while it is waiting for an R1, it MUST NOT terminate the
wait. It MAY continue as if it had not received the ICMP message, wait. It MAY continue as if it had not received the ICMP message,
and send a few more I1s. Alternatively, it MAY take the ICMP message and send a few more I1s. Alternatively, it MAY take the ICMP message
as a hint that the peer most probably does not support HIP, and as a hint that the peer most probably does not support HIP, and
return to state E0 earlier than otherwise. However, at minimum, it return to state UNASSOCIATED earlier than otherwise. However, at
MUST continue waiting for an R1 for a reasonable time before minimum, it MUST continue waiting for an R1 for a reasonable time
returning to E0. before returning to UNASSOCIATED.
8.4 Processing incoming I1 packets 8.5 Processing incoming I1 packets
An implementation SHOULD reply to an I1 with an R1 packet, unless the An implementation SHOULD reply to an I1 with an R1 packet, unless the
implementation is unable or unwilling to setup a HIP association. If implementation is unable or unwilling to setup a HIP association. If
the implementation is unable to setup a HIP association, the host the implementation is unable to setup a HIP association, the host
SHOULD send an ICMP Destination Protocol Unreachable, SHOULD send an ICMP Destination Protocol Unreachable,
Administratively Prohibited, message to the I1 source address. If Administratively Prohibited, message to the I1 source address. If
the implementation is unwilling to setup a HIP association, the host the implementation is unwilling to setup a HIP association, the host
MAY ignore the I1. This latter case may occur during a DoS attack MAY ignore the I1. This latter case may occur during a DoS attack
such as an I1 flood. such as an I1 flood.
skipping to change at page 51, line 22 skipping to change at page 56, line 5
Under no circumstances does the HIP state machine transition upon Under no circumstances does the HIP state machine transition upon
sending an R1. sending an R1.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
responding to an I1 packet: responding to an I1 packet:
1. The responder MUST check that the responder HIT in the received 1. The responder MUST check that the responder HIT in the received
I1 is either one of its own HITs, or NULL. I1 is either one of its own HITs, or NULL.
2. If the implementation chooses to respond to the I1 with and R1 2. If the responder is in ESTABLISHED state, the incoming I1 packet
MUST have the R bit set. The responder MAY respond to this with
an R1 packet, prepare to drop existing SAs and move to RESYNC
state.
3. If the responder is in UNASSOCIATED state and the incoming I1 has
the R bit set, the responder MAY respond with an R1. It may be
that the initiator is now under an attack, or both the initiator
and the responder have lost the state.
4. If the implementation chooses to respond to the I1 with and R1
packet, it creates a new R1 or selects a precomputed R1 according packet, it creates a new R1 or selects a precomputed R1 according
to the format described in Section 7.2. to the format described in Section 7.2.
3. The R1 MUST contain the received responder HIT, unless the 5. The R1 MUST contain the received responder HIT, unless the
received HIT is NULL, in which case the Responder may freely received HIT is NULL, in which case the Responder may freely
select among its HITs. select among its HITs.
4. The HIP control bits MUST be ignored in the received I1. The 6. The responder sends the R1 to the source IP address of the I1
received initiator HIT MUST be copied over to the Initiator HIT
field in the R1.
5. The responder sends the R1 to the source IP address of the I1
packet. packet.
8.4.1 R1 Management 8.5.1 R1 Management
All compliant implementations MUST produce R1 packets. An R1 packet All compliant implementations MUST produce R1 packets. An R1 packet
MAY be precomputed. An R1 packet MAY be reused for time Delta T, MAY be precomputed. An R1 packet MAY be reused for time Delta T,
which is implementation dependent. R1 information MUST not be which is implementation dependent. R1 information MUST not be
discarded until Delta S after T. Time S is the delay needed for the discarded until Delta S after T. Time S is the delay needed for the
last I2 to arrive back to the responder. last I2 to arrive back to the responder.
An implementation MAY keep state about received I1s and match the An implementation MAY keep state about received I1s and match the
received I2s against the state, as discussed in Section 4.1.1. received I2s against the state, as discussed in Section 4.1.1.
8.5 Processing incoming R1 packets 8.6 Processing incoming R1 packets
A system receiving an R1 MUST first check to see if it has sent an I1 A system receiving an R1 MUST first check to see if it has sent an I1
to the originator of the R1 (i.e., it is in state E1). If so, it to the originator of the R1 (i.e., it is in state I1-SENT). If so,
SHOULD process the R1 as described below, send an I2, and go to state it SHOULD process the R1 as described below, send an I2, and go to
E2, setting a timer to protect the I2. If the system is in state E0 state I2-SENT, setting a timer to protect the I2. If the system is in
or state E2 with respect to that host, it SHOULD silently drop the any other state with respect to that host, it SHOULD silently drop
R1. the R1.
If the system is in state E3/E4, it SHOULD process with a Security
Association and Birthday check as described in Section 5.3, before
further processing. In this last case, if the R1 is successfully
processed, the system sends an I2, sets a retransmit timer to protect
the I2, prepares to replace its old Security Associations with the
newly generated ones upon receiving a matching R2, and goes to state
E3. Note that if the system was in state E4, it stops the rekey
attempt and goes to state E3.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
responding to an R1 packet: responding to an R1 packet:
1. A system receiving an R1 MUST first check to see if it has sent 1. A system receiving an R1 MUST first check to see if it has sent
an I1 to the originator of the R1 (i.e., it has a HIP an I1 to the originator of the R1 (i.e., it has a HIP
association that is in state E1 and that is associated with the association that is in state I1-SENT and that is associated with
HITs in the R1). If so, it should process the R1 as described the HITs in the R1). If so, it should process the R1 as
below. described below.
2. If the received R1 has a NULL Initiator HIT, the system should
look for a HIP association in state E3/E4 that is associated
with the received Responder HIT. If it finds one, it MUST
perform the Security Association and Birthday checks as
described in Section 5.3. If the SA and Birthday checks
succeed, it should process the R1 as described below.
3. Otherwise, if the system is in state E0 or state E2 with respect 2. Otherwise, if the system is in any other state than I1-SENT with
to the HITs included in the R1, it SHOULD silently drop the R1 respect to the HITs included in the R1, it SHOULD silently drop
and remain in E0 or E2. the R1 and remain in the current state.
4. If the HIP association state is E1, the received Initiator's HIT 3. If the HIP association state is I1-SENT, the received
MUST correspond to the HIT used in the original, I1 and the Initiator's HIT MUST correspond to the HIT used in the original,
Responder's HIT MUST correspond to the one used, unless the I1 I1 and the Responder's HIT MUST correspond to the one used,
contained a NULL HIT. If the HIP association state is E3/E4, unless the I1 contained a NULL HIT.
the received Initiator's HIT MUST either be NULL or correspond
to the one stored in the HIP association, and the Responder's
HIT MUST correspond to the one stored in the association.
5. The system SHOULD validate the R1 signature before applying 4. The system SHOULD validate the R1 signature before applying
further packet processing, according to Section 6.2.13. further packet processing, according to Section 6.2.12.
6. The R1 packet may have the C bit set -- in this case, the system 5. The R1 packet may have the C bit set -- in this case, the system
should anticipate the receipt of HIP CER packets that contain should anticipate the receipt of HIP CER packets that contain
the host identity corresponding to the responder's HIT. the host identity corresponding to the responder's HIT.
7. The R1 packet may have the A bit set -- in this case, the system 6. The R1 packet may have the A bit set -- in this case, the system
MAY choose to refuse it by dropping the R1 and returning to MAY choose to refuse it by dropping the R1 and returning to
state E0. The system SHOULD consider dropping the R1 only if it state UNASSOCIATED. The system SHOULD consider dropping the R1
used a NULL HIT in I1. If the A bit is set, the Responder's HIT only if it used a NULL HIT in I1. If the A bit is set, the
is anonymous and should not be stored. Responder's HIT is anonymous and should not be stored.
8. The system SHOULD attempt to validate the HIT against the 7. The system SHOULD attempt to validate the HIT against the
received Host Identity. received Host Identity.
9. The system MUST store the received Birthday count for future 8. The system MUST store the received Birthday count for future
reference. reference.
10. The attempts to solve the cookie puzzle in R1. The system MUST 9. The attempts to solve the cookie puzzle in R1. The system MUST
terminate the search after a number of tries, the minimum of the terminate the search after a number of tries, the minimum of the
degree of difficulty specified by the K value or an degree of difficulty specified by the K value or an
implementation- or policy-defined maximum retry count. It is implementation- or policy-defined maximum retry count. It is
RECOMMENDED that the system does not try more than 2^(K+2) RECOMMENDED that the system does not try more than 2^(K+2)
times. If the cookie puzzle is not successfully solved, the times. If the cookie puzzle is not successfully solved, the
implementation may either resend I1 within the retry bounds or implementation may either resend I1 within the retry bounds or
abandon the HIP exchange. abandon the HIP exchange.
11. The system computes standard Diffie-Hellman keying material 10. The system computes standard Diffie-Hellman keying material
according to the public value and Group ID provided in the according to the public value and Group ID provided in the
DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material
Kij is used for key extraction as specified in Section 9. If Kij is used for key extraction as specified in Section 9. If
the received Diffie-Hellman Group ID is not supported, the the received Diffie-Hellman Group ID is not supported, the
implementation may either resend I1 within the retry bounds or implementation may either resend I1 within the retry bounds or
abandon the HIP exchange. abandon the HIP exchange.
12. The system selects the HIP transform and ESP transform from the 11. The system selects the HIP transform and ESP transform from the
choices presented in the R1 packet and uses the selected values choices presented in the R1 packet and uses the selected values
subsequently when generating and using encryption keys, and when subsequently when generating and using encryption keys, and when
sending the I2. If the proposed alternatives are not acceptable sending the I2. If the proposed alternatives are not acceptable
to the system, it may either resend I1 within the retry bounds to the system, it may either resend I1 within the retry bounds
or abandon the HIP exchange. or abandon the HIP exchange.
13. The system prepares and creates an incoming IPsec ESP security 12. The system prepares and creates an incoming IPsec ESP security
association. It may also prepare a security association for association. It may also prepare a security association for
outgoing traffic, but since it does not have the correct SPI outgoing traffic, but since it does not have the correct SPI
value yet, it cannot activate it. value yet, it cannot activate it.
14. The system initialized the remaining variables in the associated 13. The system initialized the remaining variables in the associated
state, including NES ID counters. state, including UPDATE ID counters.
15. The system prepares and sends an I2, as described in Section 14. The system prepares and sends an I2, as described in Section
7.3. 7.3.
16. The system SHOULD start a timer whose timeout value should be 15. The system SHOULD start a timer whose timeout value should be
larger than the worst-case anticipated RTT, and MUST increment a larger than the worst-case anticipated RTT, and MUST increment a
timeout counter associated with the I2. The sender SHOULD timeout counter associated with the I2. The sender SHOULD
retransmit the I2 upon a timeout and restart the timer, up to a retransmit the I2 upon a timeout and restart the timer, up to a
maximum of I2_RETRIES_MAX tries. maximum of I2_RETRIES_MAX tries.
17. If the system is in state E1, it shall transition to state E2. 16. If the system is in state I1-SENT, it shall transition to state
If the system is in state E3, it remains so. If the system is in I2-SENT. If the system is in any other state, it remains in the
state E4, it stops the rekey attempt and goes to E3. current state.
18. If the system is in state E3/E4, the system prepares to drop its
old outgoing Security Association and replace the incoming
Security Association with the newly generated ones upon
receiving a matching R2.
8.6 Processing incoming I2 packets 8.7 Processing incoming I2 packets
Upon receipt of an I2, the system MAY perform initial checks to Upon receipt of an I2, the system MAY perform initial checks to
determine whether the I2 corresponds to a recent R1 that has been determine whether the I2 corresponds to a recent R1 that has been
sent out, if the Responder keeps such state. For example, the sender sent out, if the Responder keeps such state. For example, the sender
could check whether the I2 is from an address or HIT that has could check whether the I2 is from an address or HIT that has
recently received an R1 from it. If the I2 is considered to be recently received an R1 from it. If the I2 is considered to be
suspect, it MAY be silently discarded by the system. suspect, it MAY be silently discarded by the system.
Otherwise, the HIP implementation SHOULD process the I2. This Otherwise, the HIP implementation SHOULD process the I2. This
includes validation of the cookie puzzle solution, generating the includes validation of the cookie puzzle solution, generating the
skipping to change at page 55, line 12 skipping to change at page 59, line 24
ESP_TRANSFORM parameters, which MUST each match one of the ESP_TRANSFORM parameters, which MUST each match one of the
values offered to the Initiator in the R1 packet. values offered to the Initiator in the R1 packet.
5. The system must derive Diffie-Hellman keying material Kij based 5. The system must derive Diffie-Hellman keying material Kij based
on the public value and Group ID in the DIFFIE_HELLMAN on the public value and Group ID in the DIFFIE_HELLMAN
parameter. This key is used to derive the HIP and ESP parameter. This key is used to derive the HIP and ESP
association keys, as described in Section 9. If the association keys, as described in Section 9. If the
Diffie-Hellman Group ID is unsupported, the I2 packet is Diffie-Hellman Group ID is unsupported, the I2 packet is
silently dropped. silently dropped.
6. The encrypted HOST_ID or HOST_ID_FQDN is decrypted by the 6. The encrypted HOST_ID decrypted by the Initiator encryption key
Initiator encryption key defined in Section 9. If the decrypted defined in Section 9. If the decrypted data is not an HOST_ID
data is not an HOST_ID or HOST_ID_FQDN parameter, the I2 packet parameter, the I2 packet is silently dropped.
is silently dropped.
7. The implementation SHOULD also verify that the Initiator's HIT 7. The implementation SHOULD also verify that the Initiator's HIT
in the I2 corresponds to the Host Identity sent in the I2. in the I2 corresponds to the Host Identity sent in the I2.
8. The system MUST verify the HIP_SIGNATURE according to Section 8. The system MUST verify the HIP_SIGNATURE according to Section
6.2.12 and Section 7.3. 6.2.11 and Section 7.3.
9. If the system is in state E3 with respect to the HITs, the 9. If the system is in state ESTABLISHED with respect to the HITs,
system MUST perform the birthday cookie check as defined in the system MUST perform the birthday cookie check as defined in
Section 5.3. Section 5.3.
10. If the checks above are valid, then the system proceeds with 10. If the checks above are valid, then the system proceeds with
further I2 processing; otherwise, it discards the I2 and remains further I2 processing; otherwise, it discards the I2 and remains
in the same state. in the same state.
11. The I2 packet may have the C bit set -- in this case, the system 11. The I2 packet may have the C bit set -- in this case, the system
should anticipate the receipt of HIP CER packets that contain should anticipate the receipt of HIP CER packets that contain
the host identity corresponding to the responder's HIT. the host identity corresponding to the responder's HIT.
12. The I2 packet may have the A bit set -- in this case, the system 12. The I2 packet may have the A bit set -- in this case, the system
MAY choose to refuse it by dropping the I2 and returning to MAY choose to refuse it by dropping the I2 and returning to
state E0. If the A bit is set, the Initiator's HIT is anonymous state UNASSOCIATED. If the A bit is set, the Initiator's HIT is
and should not be stored. anonymous and should not be stored.
13. The I2 packet may have the E bit set. If so, the HIP
implementation MUST treat the ESP sequence numbers as 64 bit
quantities as described in Section 11.4.
14. The Birthday count is extracted from the BIRTHDAY_COOKIE 13. The Birthday count is extracted from the BIRTHDAY_COOKIE
parameter and stored for future use. parameter and stored for future use.
15. The SPI_LSI field is parsed to obtain the SPI that will be used 14. The SPI_LSI field is parsed to obtain the SPI that will be used
for the Security Association outbound from the Responder and for the Security Association outbound from the Responder and
inbound to the Initiator. inbound to the Initiator.
16. If the system supports LSIs, it should check that the received 15. If the system supports LSIs, it should check that the received
LSI is an acceptable representation of its own identity, and LSI is an acceptable representation of its own identity, and
create an appropriate state. If the LSI is not acceptable, the create an appropriate state. If the LSI is not acceptable, the
behaviour is currently undefined; see Appendix A. behaviour is currently undefined; see Appendix A.
17. The system prepares and creates both incoming and outgoing ESP 16. The system prepares and creates both incoming and outgoing ESP
security associations. security associations.
18. The system initialized the remaining variables in the associated 17. The system initialized the remaining variables in the associated
state, including NES ID counters. state, including UPDATE ID counters.
19. Upon successful processing of an I2 in states E0, E1, and E2, an 18. Upon successful processing of an I2 in states UNASSOCIATED,
R2 is sent and the state machine transitions to state E3. I1-SENT, and I2-SENT, an R2 is sent and the state machine
transitions to state ESTABLISHED.
20. Upon successful processing of an I2 in state E3/E4 (which 19. Upon successful processing of an I2 in state ESTABLISHED/
includes a successful Birthday check), the old Security REKEYING/RESYNC (which includes a successful Birthday check),
Association is dropped and a new one is installed, an R2 is the old Security Association is dropped and a new one is
sent, and the state machine transitions to E3, dropping any installed, an R2 is sent, and the state machine transitions to
possibly ongoing rekeying attempt. ESTABLISHED, dropping any possibly ongoing rekeying attempt.
8.7 Processing incoming R2 packets 8.8 Processing incoming R2 packets
An R2 received in states E0, E1, E3 or E4 results in the R2 being An R2 received in states UNASSOCIATED, I1-SENT, ESTABLISHED, REKEYING
dropped and the state machine staying in the same state. If an R2 is or RESYNC results in the R2 being dropped and the state machine
received in state E2, it SHOULD be processed. staying in the same state. If an R2 is received in state I2-SENT, it
SHOULD be processed.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
responding to an I2 packet: incoming R2 packet:
1. The system MUST verify that the HITs in use correspond to the 1. The system MUST verify that the HITs in use correspond to the
HITs that were received in R1. HITs that were received in R1.
2. The system MUST verify the HMAC according to the procedures in 2. The system MUST verify the HMAC according to the procedures in
Section 6.2.11. Section 6.2.10.
3. The system MUST verify the HIP signature according to the 3. The system MUST verify the HIP signature according to the
procedures in Section 6.2.12. procedures in Section 6.2.11.
4. If any of the checks above fail, there is a high probability of 4. If any of the checks above fail, there is a high probability of
an ongoing man-in-the-middle or other security attack. The an ongoing man-in-the-middle or other security attack. The
system SHOULD act accordingly, based on its local policy. system SHOULD act accordingly, based on its local policy.
5. The R2 packet may have the E bit set. If so, the HIP 5. If the system is in any other state than I2-SENT, the R2 is
implementation MUST treat the ESP sequence numbers as 64 bit silently dropped.
quantities as described in Section 11.4.
6. If the system is already in state E3 or E4, it drops the old
outbound ESP Security association. If the system is in state E4,
it stops the rekey attempt.
7. The SPI_LSI field is parsed to obtain the SPI that will be used 6. The SPI_LSI field is parsed to obtain the SPI that will be used
for the ESP Security Association inbound to the Responder. The for the ESP Security Association inbound to the Responder. The
system uses this SPI to create or activate the outgoing ESP system uses this SPI to create or activate the outgoing ESP
security association used to send packets to the peer. security association used to send packets to the peer.
8. If the system supports LSIs, it should check that the received 7. If the system supports LSIs, it should check that the received
LSI is an acceptable representation of its own identity, and LSI is an acceptable representation of its own identity, and
create an appropriate state. If the LSI is not acceptable, the create an appropriate state. If the LSI is not acceptable, the
behaviour is currently undefined; see Appendix A. behaviour is currently undefined; see Appendix A.
9. Upon successful processing of the R2, the state machine moves to 8. Upon successful processing of the R2, the state machine moves to
state E3. state ESTABLISHED.
8.8 Initiating rekeying 8.9 Initiating rekeying
A system may initiate the rekey procedure at any time. It MUST A system may initiate the rekey procedure at any time. It MUST
initiate a rekey if its incoming ESP sequence counter is about to initiate a rekey if its incoming ESP sequence counter is about to
overflow. overflow.
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
initiating a rekey: initiating a rekey:
1. The system SHOULD generate a new Diffie-Hellman public key. 1. The system SHOULD generate a new Diffie-Hellman public key.
2. The system MUST increment its outgoing NES ID counter. 2. The system MUST increment its outgoing UPDATE ID counter.
3. The system creates a NES packet, which SHOULD contain a 3. The system creates a UPDATE packet, which SHOULD contain a
Diffie-Hellman parameter. If the NES packet contains the Diffie-Hellman parameter. If the UPDATE packet contains the
Diffie-Hellman parameter, the Keymat Index in the NES_INFO Diffie-Hellman parameter, the Keymat Index in the NES parameter
parameter MUST be zero. MUST be zero.
4. The system sends the NES packet and transitions to state E4. 4. The system sends the UPDATE packet and transitions to state
REKEYING.
5. The system SHOULD start a timer whose timeout value should be 5. The system SHOULD start a timer whose timeout value should be
larger than the worst-case anticipated RTT, and MUST increment a larger than the worst-case anticipated RTT, and MUST increment a
timeout counter associated with NES. The sender SHOULD retransmit timeout counter associated with UPDATE. The sender SHOULD
the NES upon a timeout and restart the timer, up to a maximum of retransmit the UPDATE upon a timeout and restart the timer, up to
NES_RETRIES_MAX tries. a maximum of UPDATE_RETRIES_MAX tries.
6. The system MUST NOT delete its existing SAs, but continue using 6. The system MUST NOT delete its existing SAs, but continue using
them if its policy still allows. The NES procedure SHOULD be them if its policy still allows. The UPDATE procedure SHOULD be
initiated prior enough in order to make sure that the SA replay initiated prior enough in order to make sure that the SA replay
counters do not overflow. counters do not overflow.
8.9 Processing NES packets 8.10 Processing UPDATE packets
When a system receives a NES packet, its processing depends on When a system receives a UPDATE packet, its processing depends on
whether the packet is a reply to a previously sent NES packet or the whether the packet is a reply to a previously sent UPDATE packet or
NES is a new packet. the UPDATE is a new packet.
The following steps define the conceptual processing rules responding The following steps define the conceptual processing rules responding
handling a received NES packet: handling a received UPDATE packet:
1. If the system is in state E3 and the NES has the R-bit set, the 1. If the system is in state ESTABLISHED and the UPDATE has the
packet is silently dropped. R-bit set in the NES TLV, the packet is silently dropped.
2. If the NES ID in the received NES is smaller than the stored 2. If the UPDATE ID in the received UPDATE is smaller than the
incoming NES ID, the packet MUST BE dropped. Note that if the stored incoming UPDATE ID, the packet MUST BE dropped. Note
NES ID is equal to the stored value, the packet can be expected that if the UPDATE ID is equal to the stored value, the packet
to be a retransmission, and acted accordingly. However, the can be expected to be a retransmission, and acted accordingly.
HMAC verification (next step) MUST NOT be skipped. (A However, the HMAC verification (next step) MUST NOT be skipped.
byte-by-byte comparison of the received and a store packet would (A byte-by-byte comparison of the received and a store packet
be OK, though.) would be OK, though.)
3. The system MUST verify the HMAC in the NES packet. If the 3. The system MUST verify the HMAC in the UPDATE packet. If the
verification fails, the packet MUST be dropped. verification fails, the packet MUST be dropped.
4. If the received NES contains a Diffie-Hellman parameter, the 4. If the received UPDATE contains a Diffie-Hellman parameter, the
received Keymat Index MUST zero. If this test fails, the packet received Keymat Index MUST be zero. If this test fails, the
SHOULD be dropped and the system SHOULD log an error message. packet SHOULD be dropped and the system SHOULD log an error
message.
5. If the received NES does not contain a Diffie-Hellman parameter, 5. If the received UPDATE does not contain a Diffie-Hellman
the received Keymat Index MUST be larger or equal to the index parameter, the received Keymat Index MUST be larger or equal to
of the next byte to be drawn from the current KEYMAT. If this the index of the next byte to be drawn from the current KEYMAT.
test fails, the packet SHOULD be dropped and the system SHOULD If this test fails, the packet SHOULD be dropped and the system
log an error message. SHOULD log an error message.
6. The system MAY verify the SIGNATURE in the NES packet. If the 6. The system MAY verify the SIGNATURE in the UPDATE packet. If the
verification fails, the packet SHOULD be dropped and an error verification fails, the packet SHOULD be dropped and an error
message logged. message logged.
7. The system MUST record the NES ID in the received packet, for 7. The system MUST record the UPDATE ID in the received packet, for
replay protection. replay protection.
8. If the system is in state E3, and the NES does not have the 8. If the system is in state ESTABLISHED, and the UPDATE does not
R-bit set, the packet is processed as specified in Section have the R-bit set in the NES TLV, the packet is processed as
8.9.1. specified in Section 8.10.1.
9. If the system is in state E4, and the NES has the R-bit set, the 9. If the system is in state REKEYING, and the UPDATE has the R-bit
packet is processed as specified in Section 8.9.2. set in the NES TLV, the packet is processed as specified in
Section 8.10.2.
10. If the system is in state E4, and the NES doesn't have the R-bit 10. If the system is in state REKEYING, and the UPDATE doesn't have
set, there are apparently two NES packets crossing each other in the R-bit set in the NES TLV, there are apparently two UPDATE
the network. Consequently, the R-bit-less packet is handled as packets crossing each other in the network. Consequently, the
specified in Section 8.9.1. However, in order not to R-bit-less packet is handled as specified in Section 8.10.1.
unnecessarily spend cycles in Diffie-Hellman computations, there However, in order not to unnecessarily spend cycles in
are minor differences to the case of receiving such a packet in Diffie-Hellman computations, there are minor differences to the
state E3. case of receiving such a packet in state ESTABLISHED.
8.9.1 Processing an initial NES packet 8.10.1 Processing an initial UPDATE packet
When a system receives an initial NES packet, i.e. one that does not When a system receives an initial UPDATE packet, i.e. one that does
have the R-bit set, it prepares new incoming and outgoing SAs, but not have the R-bit set, it prepares new incoming and outgoing SAs,
does not change the outgoing SA yet. Once it has the new SAs in but does not change the outgoing SA yet. Once it has the new SAs in
place, it sends a reply NES. The contents of the reply NES depend on place, it sends a reply UPDATE. The contents of the reply UPDATE
whether the system was in state E3 or E4 upon receiving the initial depend on whether the system was in state ESTABLISHED or REKEYING
NES packet. upon receiving the initial UPDATE packet.
The following steps define the conceptual processing rules responding The following steps define the conceptual processing rules responding
handling a received initial NES packet: handling a received initial UPDATE packet:
1. If the system is in state E3, it consults its policy to see if it 1. If the system is in state ESTABLISHED, it consults its policy to
needs to generate a new Diffie-Hellman key, and generates a new see if it needs to generate a new Diffie-Hellman key, and
key if needed. If the system is in state E4, it may already have generates a new key if needed. If the system is in state
generated a new Diffie-Hellman key, and SHOULD use it. REKEYING, it may already have generated a new Diffie-Hellman key,
and SHOULD use it.
2. If either the received NES contains a new Diffie-Hellman key, the 2. If either the received UPDATE contains a new Diffie-Hellman key,
system has a new Diffie-Hellman key from the previous step, or the system has a new Diffie-Hellman key from the previous step,
both, the system generates new KEYMAT. If there is only one new or both, the system generates new KEYMAT. If there is only one
Diffie-Hellman key, the other old key is used. new Diffie-Hellman key, the other old key is used.
3. If the system generated new KEYMAT in the previous step, it sets 3. If the system generated new KEYMAT in the previous step, it sets
Keymat Index to zero, independent on whether the received NES Keymat Index to zero, independent on whether the received UPDATE
included a Diffie-Hellman key or not. included a Diffie-Hellman key or not.
4. The system draws keys for new incoming and outgoing ESP SAs, 4. The system draws keys for new incoming and outgoing ESP SAs,
starting from the Keymat Index, and prepares new incoming and starting from the Keymat Index, and prepares new incoming and
outgoing ESP SAs. The SPI for the outgoing SA is the new SPI outgoing ESP SAs. The SPI for the outgoing SA is the new SPI
value from the received NES. The SPI for the incoming SA is value from the received UPDATE. The SPI for the incoming SA is
locally generated, and SHOULD be random. The system MUST NOT locally generated, and SHOULD be random. The system MUST NOT
start using the new outgoing SA before it receives traffic on the start using the new outgoing SA before it receives traffic on the
new incoming SA. new incoming SA.
5. The system prepares a reply NES packet, with the R-bit one, 5. The system prepares a reply UPDATE packet, with the R-bit one in
Keymat Index being the one used above, NES ID being equal to the the NES TLV, Keymat Index being the one used above, UPDATE ID
one in the received NES, old SPI being the current incoming SPI, being equal to the one in the received UPDATE, old SPI being the
and new SPI being the newly generated incoming SPI. If the current incoming SPI, and new SPI being the newly generated
system generated a new Diffie-Hellman key above, the new key is incoming SPI. If the system generated a new Diffie-Hellman key
included in the packet in the Diffie-Hellman payload. Note that above, the new key is included in the packet in the
if the system is in state E4, the new Diffie-Hellman key was Diffie-Hellman payload. Note that if the system is in state
probably generated and sent already earlier, in which case it REKEYING, the new Diffie-Hellman key was probably generated and
MUST NOT be included into the reply packet. sent already earlier, in which case it MUST NOT be included into
the reply packet.
8.9.2 Processing a reply NES packet 8.10.2 Processing a reply UPDATE packet
When a system receives a reply NES packet, i.e. one that has the When a system receives a reply UPDATE packet, i.e. one that has the
R-bit set, it starts to use the new outgoing SA. It must also R-bit set in the NES TLV, it starts to use the new outgoing SA. It
complete its new incoming SA. must also complete its new incoming SA.
The following steps define the conceptual processing rules responding The following steps define the conceptual processing rules responding
handling a received reply NES packet: handling a received reply UPDATE packet:
1. If either the received NES contains a new Diffie-Hellman key, the 1. If either the received UPDATE contains a new Diffie-Hellman key,
system has a new Diffie-Hellman key from initiating rekey, or the system has a new Diffie-Hellman key from initiating rekey, or
both, the system generates new KEYMAT. If there is only one new both, the system generates new KEYMAT. If there is only one new
Diffie-Hellman key, the old key is used as the other key. Diffie-Hellman key, the old key is used as the other key.
2. If the system generated new KEYMAT in the previous step, it sets 2. If the system generated new KEYMAT in the previous step, it sets
Keymat Index to zero, independent on whether the received NES Keymat Index to zero, independent on whether the received UPDATE
included a Diffie-Hellman key or not. included a Diffie-Hellman key or not.
3. The system draws keys for new incoming and outgoing ESP SAs, 3. The system draws keys for new incoming and outgoing ESP SAs,
starting from the Keymat Index, and prepares new incoming and starting from the Keymat Index, and prepares new incoming and
outgoing ESP SAs. The SPI for the outgoing SA is the new SPI outgoing ESP SAs. The SPI for the outgoing SA is the new SPI
value from the NES. The SPI for the incoming SA was generated value from the UPDATE. The SPI for the incoming SA was generated
when rekey was initiated. when rekey was initiated.
4. The system starts to send to the new outgoing SA. It should 4. The system starts to send to the new outgoing SA. It should
start receiving data on the new incoming SA as soon as the peer start receiving data on the new incoming SA as soon as the peer
receives data on the new SA. receives data on the new SA.
5. If the system has no data to send for 500ms, it SHOULD send an 5. If the system has no data to send for 500ms, it SHOULD send an
ESP packet anyway. The purpose of this packet is to acknowledge ESP packet anyway. The purpose of this packet is to acknowledge
the other party that the NES reply came through, and to allow the the other party that the UPDATE reply came through, and to allow
other party to switch over to the new outgoing SA. It is the other party to switch over to the new outgoing SA. It is
RECOMMENDED that the system sends an empty ESP packet, i.e., one RECOMMENDED that the system sends an empty ESP packet, i.e., one
where the Next Header field is IPPROTO_NONE (decimal 59). where the Next Header field is IPPROTO_NONE (decimal 59).
8.10 Processing BOS packets 8.11 Processing BOS packets
Processing BOS packets is OPTIONAL, and currently undefined. Processing BOS packets is OPTIONAL, and currently undefined.
8.11 Processing CER packets 8.12 Processing CER packets
Processing CER packets is OPTIONAL, and currently undefined. Processing CER packets is OPTIONAL, and currently undefined.
8.12 Processing PAYLOAD packets 8.13 Processing PAYLOAD packets
Processing PAYLOAD packets is OPTIONAL, and currently undefined. Processing PAYLOAD packets is OPTIONAL, and currently undefined.
9. HIP KEYMAT 9. HIP KEYMAT
HIP keying material is derived from the Diffie-Hellman Kij produced HIP keying material is derived from the Diffie-Hellman Kij produced
during the base HIP exchange. The Initiator has Kij during the during the base HIP exchange. The Initiator has Kij during the
creation of the I2 packet, and the Responder has Kij once it receives creation of the I2 packet, and the Responder has Kij once it receives
the I2 packet. This is why I2 can already contain encrypted the I2 packet. This is why I2 can already contain encrypted
information. information.
skipping to change at page 62, line 27 skipping to change at page 66, line 27
where where
K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 ) K1 = SHA-1( Kij | sort(HIT-I | HIT-R) | 0x01 )
K2 = SHA-1( Kij | K1 | 0x02 ) K2 = SHA-1( Kij | K1 | 0x02 )
K3 = SHA-1( Kij | K2 | 0x03 ) K3 = SHA-1( Kij | K2 | 0x03 )
... ...
K255 = SHA-1( Kij | K254 | 0xff ) K255 = SHA-1( Kij | K254 | 0xff )
K256 = SHA-1( Kij | K255 | 0x00 ) K256 = SHA-1( Kij | K255 | 0x00 )
etc. etc.
Sort(HIT-I | HIT-R) is defined as the numeric network byte order Sort(HIT-I | HIT-R) is defined as the network byte order
comparison of the HITs, with lower HIT preceding higher HIT, concatenation of the two HITs, with the smaller HIT preceding the
resulting in the concatenation of the HITs in the said order. The larger HIT, resulting from the numeric comparison of the two HITs
initial keys are drawn sequentially in the following order: interpreted as positive (unsigned) 128-bit integers in network byte
order.
Initiator HIP encryption key The initial keys are drawn sequentially in the following order:
Initiator HIP integrity (HMAC) key HIP-IR encryption key for Initiator's outgoing HIP packets
Responder HIP encryption key (currently unused) HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets
Responder HIP integrity (HMAC) key HIP-RI encryption key (currently unused) for Responder's outgoing
HIP packets
Initiator ESP encryption key HIP-RI integrity (HMAC) key for Responder's outgoing HIP packets
Initiator ESP authentication key SA-IR ESP encryption key for Initiator's outgoing traffic
Responder ESP encryption key SA-IR ESP authentication key for Initiator's outgoing traffic
Responder ESP authentication key SA-RI ESP encryption key for Responder's outgoing traffic
SA-RI ESP authentication key for Responder's outgoing traffic
The IR and RI denotes the direction of the traffic where the key is
applied. The IR describes "from the Initiator to the Responder"
-direction and the RI the other direction.
The number of bits drawn for a given algorithm is the "natural" size The number of bits drawn for a given algorithm is the "natural" size
of the keys. For the mandatory algorithms, the following sizes of the keys. For the mandatory algorithms, the following sizes
apply: apply:
3DES 192 bits 3DES 192 bits
SHA-1 160 bits SHA-1 160 bits
NULL 0 bits NULL 0 bits
Subsequent rekeys without Diffie-Hellman just require drawing out The four HIP keys are only drawn from KEYMAT during a HIP I1->R2
more sets of ESP keys. In the situation where Kij is the result of a exchange. Subsequent rekeys using UPDATE will only draw the four ESP
HIP rekey exchange with Diffie-Hellman, there is only the need from keys from KEYMAT. Section 8.10 describes the rules for reusing or
one set of ESP keys, without the HIP keys. These are then the only regenerating KEYMAT based on the UPDATE exchange.
keys taken from the KEYMAT.
10. HIP Fragmentation Support 10. HIP Fragmentation Support
A HIP implementation must support IP fragmentation / reassembly. A HIP implementation must support IP fragmentation / reassembly.
Fragment reassembly MUST be implemented in both IPv4 and IPv6, but Fragment reassembly MUST be implemented in both IPv4 and IPv6, but
fragment generation MUST be implemented only in IPv4 (IPv4 stacks and fragment generation MUST be implemented only in IPv4 (IPv4 stacks and
networks will usually do this by default) and SHOULD be implemented networks will usually do this by default) and SHOULD be implemented
in IPv6. In the IPv6 world, the minimum MTU is larger, 1280 bytes, in IPv6. In the IPv6 world, the minimum MTU is larger, 1280 bytes,
than in the IPv4 world. The larger MTU size is usually sufficient for than in the IPv4 world. The larger MTU size is usually sufficient for
most HIP packets, and therefore fragment generation may not be most HIP packets, and therefore fragment generation may not be
skipping to change at page 65, line 19 skipping to change at page 69, line 19
address; all internal control of the SA is by the HIT and LSI. XXX address; all internal control of the SA is by the HIT and LSI. XXX
BEET mode. BEET mode.
Since HIP does not negotiate any lifetimes, all lifetimes are local Since HIP does not negotiate any lifetimes, all lifetimes are local
policy. The only lifetimes a HIP implementation MUST support are policy. The only lifetimes a HIP implementation MUST support are
sequence number rollover (for replay protection), and SA timeout. An sequence number rollover (for replay protection), and SA timeout. An
SA times out if no packets are received using that SA. The default SA times out if no packets are received using that SA. The default
timeout value is 15 minutes. Implementations MAY support lifetimes timeout value is 15 minutes. Implementations MAY support lifetimes
for the various ESP transforms. for the various ESP transforms.
11.1 Security Association Management 11.1 ESP Security Associations
Each HIP association is linked with two ESP SAs, one incoming and one
outgoing. The Initiator's incoming SA corresponds with the
Responder's outgoing one. The initiator defines the SPI for this
association, as defined in Section 3.3. This SA is called SA-RI, and
the corresponding SPI is called SPI-RI. Respectively, the Responder's
incoming SA corresponds with the Initiator's outgoing SA and is
called SA-IR, with the SPI-IR.
The Initiator creates SA-RI as a part of R1 processing, before
sending out the I2, as explained in Section 8.6. The keys are derived
from KEYMAT, as defined in Section 9. The Responder creates SA-RI as
a part of I2 processing, see Section 8.7.
The Responder creates SA-IR as a part of I2 processing, before
sending out R2, see Step 17 in Section 8.7. The Initiator creates
SA-IR when processing R2, see Step 7 in Section 8.8.
11.2 Updating ESP SAs during rekeying
After the initial 4-way handshake and SA establishment, both hosts
are in state ESTABLISHED. There are no longer Initiator and
Responder roles and the association is symmetric. In this
subsection, the initiating party of the rekey procedure is denoted
with I' and the peer with R'.
The I' initiates the rekeying process when needed (see Section 8.9).
It creates a UPDATE packet with required information and sends it to
the peer node. The old SAs are still in use.
The R', after receiving and processing the UPDATE (see Section 8.10),
generates new SAs: SA-I'R' and SA-R'I'. It does not take the new
outgoing SA into use, but uses still the old one, so there exists two
SA pairs towards the same peer host. For the new outgoing SA, the
SPI-R'I' value is picked from the received UPDATE packet. The R'
generates the new SPI value for the incoming SA, SPI-I'R', and
includes it in the response UPDATE packet.
When the I' receives a response UPDATE from the R', it generates new
SAs, as described in Section 8.10: SA-I'R' and SA-R'I'. It starts
using the new outgoing SA immediately.
The R' starts using the new outgoing SA when it receives traffic from
the new incoming SA. After this, the R' can remove old SAs.
Similarly, when the I' receives traffic from the new incoming SA, it
can safely remove old SAs.
11.3 Security Association Management
An SA pair is indexed by the 2 SPIs and 2 HITs (both HITs since a An SA pair is indexed by the 2 SPIs and 2 HITs (both HITs since a
system can have more than one HIT). An inactivity timer is system can have more than one HIT). An inactivity timer is
recommended for all SAs. If the state dictates the deletion of an recommended for all SAs. If the state dictates the deletion of an
SA, a timer is set to allow for any late arriving packets. SA, a timer is set to allow for any late arriving packets.
11.2 Security Parameter Index (SPI) 11.4 Security Parameter Index (SPI)
The SPIs in ESP provide a simple compression of the HIP data from all The SPIs in ESP provide a simple compression of the HIP data from all
packets after the HIP exchange. This does require a per HIT- pair packets after the HIP exchange. This does require a per HIT- pair
Security Association (and SPI), and a decrease of policy granularity Security Association (and SPI), and a decrease of policy granularity
over other Key Management Protocols like IKE. over other Key Management Protocols like IKE.
When a host rekeys, it gets a new SPI from its partner. When a host rekeys, it gets a new SPI from its partner.
11.3 Supported Transforms 11.5 Supported Transforms
All HIP implementations MUST support 3DES [7] and HMAC-SHA-1-96 [4]. All HIP implementations MUST support 3DES [7] and HMAC-SHA-1-96 [4].
If the Initiator does not support any of the transforms offered by If the Initiator does not support any of the transforms offered by
the Responder in the R1 HIP packet, it MUST use 3DES and the Responder in the R1 HIP packet, it MUST use 3DES and
HMAC-SHA-1-96 and state so in the I2 HIP packet. HMAC-SHA-1-96 and state so in the I2 HIP packet.
In addition to 3DES, all implementations MUST implement the ESP NULL In addition to 3DES, all implementations MUST implement the ESP NULL
encryption and authentication algorithms. These algoritms are encryption and authentication algorithms. These algorithms are
provided mainly for debugging purposes, and SHOULD NOT be used in provided mainly for debugging purposes, and SHOULD NOT be used in
production environments. The default configuration in production environments. The default configuration in
implementations MUST be to reject NULL encryption or authentication. implementations MUST be to reject NULL encryption or authentication.
11.4 Sequence Number 11.6 Sequence Number
The Sequence Number field is MANDATORY in ESP. Anti-replay The Sequence Number field is MANDATORY in ESP. Anti-replay
protection MUST be used in an ESP SA established with HIP. protection MUST be used in an ESP SA established with HIP.
This means that each host MUST rekey before its sequence number This means that each host MUST rekey before its sequence number
reaches 2^32, or if extended sequence numbers are used, 2^64. Note reaches 2^32, or if extended sequence numbers are used, 2^64. Note
that in HIP rekeying, unlike IKE rekeying, only one Diffie-Hellman that in HIP rekeying, unlike IKE rekeying, only one Diffie-Hellman
key can be changed, that of the rekeying host. However, if one host key can be changed, that of the rekeying host. However, if one host
rekeys, the other host SHOULD rekey as well. rekeys, the other host SHOULD rekey as well.
In some instances, a 32 bit sequence number is inadequate. In either In some instances, a 32 bit sequence number is inadequate. In the
the I2 or R2 packets, a peer MAY require that a 64 bit sequence ESP_TRANSFORM parameter, a peer MAY require that a 64 bit sequence
number be used. In this case the higher 32 bits are NOT included in number be used. In this case the higher 32 bits are NOT included in
the ESP header, but are simply kept local to both peers. 64 bit the ESP header, but are simply kept local to both peers. 64 bit
sequence numbers must only be used for ciphers that will not be open sequence numbers must only be used for ciphers that will not be open
to cryptoanalysis as a result. AES is one such cipher. to cryptanalysis as a result. AES is one such cipher.
12. HIP Policies 12. HIP Policies
There are a number of variables that will influence the HIP exchanges There are a number of variables that will influence the HIP exchanges
that each host must support. All HIP implementations MUST support that each host must support. All HIP implementations MUST support
more than one simultaneous HIs, at least one of which SHOULD be more than one simultaneous HIs, at least one of which SHOULD be
reserved for anonymous usage. Although anonymous HIs will be rarely reserved for anonymous usage. Although anonymous HIs will be rarely
used as responder HIs, they will be common for Initiators. Support used as responder HIs, they will be common for Initiators. Support
for more than two HIs is RECOMMENDED. for more than two HIs is RECOMMENDED.
skipping to change at page 73, line 4 skipping to change at page 78, line 4
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[13] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [13] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[14] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [14] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
3526, May 2003. 3526, May 2003.
[15] Kent, S., "IP Encapsulating Security Payload (ESP)", [15] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003. draft-ietf-ipsec-esp-v3-05 (work in progress), April 2003.
[16] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [16] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-10 (work in progress), August 2003. draft-ietf-ipsec-ikev2-07 (work in progress), April 2003.
[17] Moskowitz, R., "Host Identity Protocol Architecture", [17] Moskowitz, R., "Host Identity Protocol Architecture",
draft-moskowitz-hip-arch-03 (work in progress), May 2003. draft-moskowitz-hip-arch-03 (work in progress), May 2003.
[18] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. [18] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995.
Informative references Informative references
[19] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)", [19] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)",
draft-ietf-ipsec-jfk-04 (work in progress), July 2002. draft-ietf-ipsec-jfk-04 (work in progress), July 2002.
skipping to change at page 76, line 38 skipping to change at page 81, line 38
is an IP address or an LSI? The fact that a name resolver library is an IP address or an LSI? The fact that a name resolver library
gave an application an LSI is no guarantee that the application gave an application an LSI is no guarantee that the application
will use that information in its socket call. It may also have will use that information in its socket call. It may also have
cached some IP address from before or received an IP address as cached some IP address from before or received an IP address as
side information. This difficulty is now relieved as the LSIs are side information. This difficulty is now relieved as the LSIs are
constrained to the well-known private subnet space. constrained to the well-known private subnet space.
Handing an LSI may confuse legacy applications that assume that Handing an LSI may confuse legacy applications that assume that
what is being passed to them is an IP address. Good examples of what is being passed to them is an IP address. Good examples of
this are diagnostic tools such as dig and ping. The conclusion is this are diagnostic tools such as dig and ping. The conclusion is
that HIP should most not be used with diagnostic applications. that HIP should not be used with diagnostic applications.
What does kernel do with an LSI that it cannot map to an address What does kernel do with an LSI that it cannot map to an address
based on information that it has locally cached? based on information that it has locally cached?
It seems that some modification to the resolver library (to It seems that some modification to the resolver library (to
explicitly convey HIP information rather than spoofing IP addresses), explicitly convey HIP information rather than spoofing IP addresses),
as well as modifications to socket API to explicitly let the kernel as well as modifications to socket API to explicitly let the kernel
know that the application is HIP aware, are the cleanest long-term know that the application is HIP aware, are the cleanest long-term
solution, but what to do about legacy applications?? -- still solution, but what to do about legacy applications?? -- still
partially an open issue. The HUT team has been considering these partially an open issue. The HUT team has been considering these
skipping to change at page 77, line 26 skipping to change at page 82, line 26
applications use resolver for other reasons than just prior applications use resolver for other reasons than just prior
to initiating a flow. Since LSIs are a subset of the HIT to initiating a flow. Since LSIs are a subset of the HIT
bits, we could avoid having to do the HIP exchange to find bits, we could avoid having to do the HIP exchange to find
the LSIs, if it weren't for the possibility of collision. the LSIs, if it weren't for the possibility of collision.
So, this approach seems to be pointing us towards doing HIP So, this approach seems to be pointing us towards doing HIP
exchanges prior to the application's initial socket calls. exchanges prior to the application's initial socket calls.
Note that this would also break the opportunity to piggyback Note that this would also break the opportunity to piggyback
data on the I2/R2. data on the I2/R2.
2. Some applications might actually want IP addresses 2. Some applications might actually want IP addresses
explicitly, such as diagnostic applcations. explicitly, such as diagnostic applications.
3. Some applications likely will obtain addresses out-of-band, 3. Some applications likely will obtain addresses out-of-band,
so even in this scenario, the kernel may be faced with a case so even in this scenario, the kernel may be faced with a case
where it would like to use HIP from a policy standpoint, but where it would like to use HIP from a policy standpoint, but
the invoking application called connect() with an IP address. the invoking application called connect() with an IP address.
One way around might be to have a separate resolver call that One way around might be to have a separate resolver call that
returns an LSI, or enhance the data structure returned by returns an LSI, or enhance the data structure returned by
resolver to include LSI in addition to IP address, but this then resolver to include LSI in addition to IP address, but this then
throws the burden on applications to be HIP-aware. throws the burden on applications to be HIP-aware.
skipping to change at page 80, line 18 skipping to change at page 85, line 18
puzzle in this way when the K value is large? puzzle in this way when the K value is large?
Answer: No, it is not guaranteed. But it is not guaranteed even in Answer: No, it is not guaranteed. But it is not guaranteed even in
the old mechanism, since the Initiator may start far away from J and the old mechanism, since the Initiator may start far away from J and
arrive to J after far too many steps. If we wanted to make sure that arrive to J after far too many steps. If we wanted to make sure that
the Initiator finds a value, we would need to give some hint of a the Initiator finds a value, we would need to give some hint of a
suitable J, and I don't think we want to do that. suitable J, and I don't think we want to do that.
In general, if we model the hash function with a random function, the In general, if we model the hash function with a random function, the
probability that one iteration gives are result with K zero bits is probability that one iteration gives are result with K zero bits is
2^-K. Thus, the probablity that one iteration does *not* give K zero 2^-K. Thus, the probability that one iteration does *not* give K
bits is (1 - 2^-K). Consequently, the probablity that 2^K iterations zero bits is (1 - 2^-K). Consequently, the probability that 2^K
does not give K zero bits is (1 - 2^-K)^(2^K). iterations does not give K zero bits is (1 - 2^-K)^(2^K).
Since my calculus starts to be rusty, I made a small experiment and Since my calculus starts to be rusty, I made a small experiment and
found out that found out that
lim (1 - 2^-k)^(2^k) = 0.36788 lim (1 - 2^-k)^(2^k) = 0.36788
k->inf k->inf
lim (1 - 2^-k)^(2^(k+1)) = 0.13534 lim (1 - 2^-k)^(2^(k+1)) = 0.13534
k->inf k->inf
skipping to change at page 81, line 11 skipping to change at page 86, line 11
than random functions, 2^(K+3) is probably an overkill. OTOH, the than random functions, 2^(K+3) is probably an overkill. OTOH, the
currently suggested 2^K is clearly too little. The draft has been currently suggested 2^K is clearly too little. The draft has been
changed to read 2^(K+2). changed to read 2^(K+2).
Appendix D. Using responder cookies Appendix D. Using responder cookies
As mentioned in Section 4.1.1, the Responder may delay state creation As mentioned in Section 4.1.1, the Responder may delay state creation
and still reject most spoofed I2s by using a number of pre-calculated and still reject most spoofed I2s by using a number of pre-calculated
R1s and a local selection function. This appendix defines one R1s and a local selection function. This appendix defines one
possible implementation in detail. The purpose of this appendix is possible implementation in detail. The purpose of this appendix is
to give the implementators an idea on how to implement the mechanism. to give the implementors an idea on how to implement the mechanism.
The method described in this appendix SHOULD NOT be used in any real The method described in this appendix SHOULD NOT be used in any real
implementation. If the implementation is based on this appendix, it implementation. If the implementation is based on this appendix, it
SHOULD contain some local modification that makes an attacker's task SHOULD contain some local modification that makes an attacker's task
harder. harder.
The basic idea is to create a cheap, varying local mapping function The basic idea is to create a cheap, varying local mapping function
f: f:
f( IP-I, IP-R, HIT-I, HIT-R ) -> cookie-index f( IP-I, IP-R, HIT-I, HIT-R ) -> cookie-index
That is, given the Initiator's and Responder's IP addresses and That is, given the Initiator's and Responder's IP addresses and
HITs, the function returns an index to a cookie. When processing an HITs, the function returns an index to a cookie. When processing an
I1, the cookie is embedded in an pre-computed R1, and the Responder I1, the cookie is embedded in an pre-computed R1, and the Responder
simply sends that particular R1 to the Initiator. When processing an simply sends that particular R1 to the Initiator. When processing an
I2, the cookie may still be embedded in the R1, or the R1 may be I2, the cookie may still be embedded in the R1, or the R1 may be
depracated (and replaced with a new one), but the cookie is still deprecated (and replaced with a new one), but the cookie is still
there. If the received cookie does not match with the R1 or saved there. If the received cookie does not match with the R1 or saved
cookie, the I2 is simply dropped. That prevents the Initiator from cookie, the I2 is simply dropped. That prevents the Initiator from
generating spoofed I2s with a probability that depends on the number generating spoofed I2s with a probability that depends on the number
of pre-computed R1s. of pre-computed R1s.
As a concrete example, let us assume that the Responder has an array As a concrete example, let us assume that the Responder has an array
of R1s. Each slot in the array contains a timestamp, an R1, and an of R1s. Each slot in the array contains a timestamp, an R1, and an
old cookie that was sent in the previous R1 that occupied that old cookie that was sent in the previous R1 that occupied that
particular slot. The Responder replaces one R1 in the array every particular slot. The Responder replaces one R1 in the array every
few minutes, thereby replacing all the R1s gradually. few minutes, thereby replacing all the R1s gradually.
skipping to change at page 82, line 42 skipping to change at page 87, line 42
Whenever the Responder receives an I2 that fails on the index check, Whenever the Responder receives an I2 that fails on the index check,
it can simply drop the packet on the floor and forget about it. New it can simply drop the packet on the floor and forget about it. New
I2s with the same or other spoofed parameters will get dropped with a I2s with the same or other spoofed parameters will get dropped with a
reasonable probability and minimal effort. reasonable probability and minimal effort.
If a Responder receives an I2 that passes the index check but fails If a Responder receives an I2 that passes the index check but fails
on the puzzle check, it should create a state indicating this. After on the puzzle check, it should create a state indicating this. After
two or three failures the Responder should cease checking the puzzle two or three failures the Responder should cease checking the puzzle
but drop the packets directly. This saves the Responder from the but drop the packets directly. This saves the Responder from the
SHA-1 calculations. Such block should not last long, however, or SHA-1 calculations. Such block should not last long, however, or
there would be a danger that a legitimite Initiator could be blocked there would be a danger that a legitimate Initiator could be blocked
from getting connections. from getting connections.
A key for the success of the defined scheme is that the mapping A key for the success of the defined scheme is that the mapping
function must be considerably cheaper than computing SHA-1. It also function must be considerably cheaper than computing SHA-1. It also
must detect any changes in the IP addresses, and preferably most must detect any changes in the IP addresses, and preferably most
changes in the HITs. Checking the HITs is not that essential, changes in the HITs. Checking the HITs is not that essential,
though, since HITs are included in the cookie computation, too. though, since HITs are included in the cookie computation, too.
The effectivity of the method can be varied by varying the size of The effectivity of the method can be varied by varying the size of
the array containing pre-computed R1s. If the array is large, the the array containing pre-computed R1s. If the array is large, the
probability that an I2 with a spoofed IP address or HIT happens to probability that an I2 with a spoofed IP address or HIT happens to
map to the same slot is fairly slow. However, a large array means map to the same slot is fairly slow. However, a large array means
that each R1 has a fairly long life time, thereby allowing an that each R1 has a fairly long life time, thereby allowing an
attacker to utilize one solved puzzle for a longer time. attacker to utilize one solved puzzle for a longer time.
Appendix E. Running HIP over IPv4 UDP Appendix E. Running HIP over IPv4 UDP
In the IPv4 world, with the deployed NAT devices, it may make sense In the IPv4 world, with the deployed NAT devices, it may make sense
to run HIP over UDP. When running HIP over UDP, the following packet to run HIP over UDP. When running HIP over UDP, the following packet
structure is used. The structure is followed by the HITs, as usual. structure is used. The structure is followed by the HITs, as usual.
Both the Source and Destionation port MUST be 272. Both the Source and Destination port MUST be 272.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| Source port | Destination port | \ | Source port | Destination port | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >UDP
| Length | Checksum | / | Length | Checksum | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<
| HIP Controls | HIP pkt Type | Ver. | Res. | >HIP | HIP Controls | HIP pkt Type | Ver. | Res. | >HIP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
It is currently undefined how the actual data transfer, using ESP, is It is currently undefined how the actual data transfer, using ESP, is
handled. Plain ESP may not go through all NAT devices. handled. Plain ESP may not go through all NAT devices.
It is currently FORBIDDEN to use this packet format with IPv6. It is currently FORBIDDEN to use this packet format with IPv6.
Appendix F. Example checksums for HIP packets
The HIP checksum for HIP packets is specified in Section 6.1.2.
Checksums for TCP and UDP packets running over HIP-enabled security
associations are specified in Section 3.5. The examples below use IP
addresses of 192.168.0.1 and 192.168.0.2 (and their respective
IPv4-compatible IPv6 formats), and type 1 HITs with the first two
bits "01" followed by 124 zeroes followed by a decimal 1 or 2,
respectively.
F.1 IPv6 HIP example (I1)
Source Address: ::c0a8:0001
Destination Address: ::c0a8:0002
Upper-Layer Packet Length: 40 0x28
Next Header: 99 0x63
Payload Protocol: 59 0x3b
Header Length: 4 0x04
Packet Type: 1 0x01
Version: 1 0x1
Reserved: 0 0x0
Control: 0 0x0000
Checksum: 49672 0xc208
Sender's HIT: 4000::0001
Receiver's HIT: 4000::0002
F.2 IPv4 HIP packet (I1)
The IPv4 checksum value for the same example I1 packet is the same as
the IPv6 checksum (since the checksums due to the IPv4 and IPv6
pseudo-header components are the same).
F.3 TCP segment
Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets
use the IPv6 pseudo-header format [8], with the HITs used in place of
the IPv6 addresses.
Sender's HIT: 4000::0001
Receiver's HIT: 4000::0002
Upper-Layer Packet Length: 20 0x14
Next Header: 6 0x06
Source port: 32769 0x8001
Destination port: 22 0x0016
Sequence number: 1 0x00000001
Acknowledgment number: 0 0x00000000
Header length: 20 0x14
Flags: SYN 0x02
Window size: 5840 0x16d0
Checksum: 54519 0xd4f7
Urgent pointer: 0 0x0000
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 85, line 29 skipping to change at page 92, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 86, line 7 skipping to change at page 93, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 263 change blocks. 
686 lines changed or deleted 830 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/